Primary Navigation

A strange issue with postfix and altermime

I am running a CentOS 6.3 server with postfix 2.6 and altermime 0.3.10. I use altermime to append disclaimers to emails submitted by my users through port port

Message 1 of 6
, Mar 21 7:22 AM

0 Attachment

I am running a CentOS 6.3 server with postfix 2.6 and altermime 0.3.10.

I use altermime to append disclaimers to emails submitted by my users
through port port 587, and 99.95% of the time it works without issue,
recently we've had a few issues with messages sent from Mac Outlook
clients, the issue is definitely related to altermime, if I disable the
filter script, the problem no longer occurs.

The issue is due to what is fortunately a fairly rare occurence, in the
body text, there is a sentence exactly 76 characters long, including
spaces, and as many sentences do, it finishes with a period, but since
the period is the 77th character, it gets bumped down to the next line
(and an = gets appended to the end of the sentence). Here is what it
looks like, with names obscured, if it goes through the server with the
altermime disclaimer disabled.

> This message is in MIME format. Since your mail reader does not understand

I am running a CentOS 6.3 server with postfix 2.6 and altermime 0.3.10.
I use altermime to append disclaimers to emails submitted by my users
through port port 587, and 99.95% of the time it works without issue,
recently we've had a few issues with messages sent from Mac Outlook
clients, the issue is definitely related to altermime, if I disable the
filter script, the problem no longer occurs.
The issue is due to what is fortunately a fairly rare occurence, in the
body text, there is a sentence exactly 76 characters long, including
spaces, and as many sentences do, it finishes with a period, but since
the period is the 77th character, it gets bumped down to the next line
(and an = gets appended to the end of the sentence). Here is what it
looks like, with names obscured, if it goes through the server with the
altermime disclaimer disabled.

> This message is in MIME format. Since your mail reader does not understand

this format, some or all of this message may not be legible.
--B_3478240988_27375889
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Hi XXXXXX,
This is definitely the remains of the EQCallTracker API integration since w=
e
originally only supported secondary allocations for the EQCallTracker teams=
.
I assume it would be easy enough to change this though, with a small
enhancement.
Kind Regards
XXXXX.
From: XXXXX XXXXX <xxxx.xxxxx@...>
Date: Thursday, 20 March 2014 16:58
To: XXXX XXXXXX <xxx.xxxx@...>
Cc: "'XX, XXXx XXX'" <xxxx.xxxx@...>, ConQuest Dev
<conquestdev@...>
Subject: RE: Call API question: handling of Secondary Allocation parameter=
s
Hi XXXXX,
=20
Unfortunately no, there aren=B9t =B3hidden=B2 parameters for secondary allocation
level/group.
For the secondary allocation, the level is always defaulted to L2 and the
group to N/A.
=20
Regards,
There are about three quoted messages underneath that, but I just lopped
them off.
This is what happens when the disclaimer is enabled;

> This message is in MIME format. Since your mail reader does not understand

this format, some or all of this message may not be legible.
--B_3478241259_27341821
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Hi XXXXXX,
This is definitely the remains of the EQCallTracker API integration since w=
e
originally only supported secondary allocations for the EQCallTracker teams=
--B_3478241259_27341821--
As you can see, either postfix or altermime is seeing the period by
itself as a terminator of the SMTP conversation, at least for that
section. I'm fairly sure it's altermime's fault (though through pipe or
when it re-injects the message to postfix, I don't know), and as it's a
rather rare occurence, I'm hesitant to play with the entry in master.cf,
I'm thinking that the EOL setting, or a flag might make a difference,
but I thought asking first might be prudent.
This is the entry in master.cf
dfilt unix - n n - - pipe
flags=Rq user=filter argv=/etc/postfix/disclaimer -f ${sender} --
${recipient}
Any advice or recommendations?
Thanks, Nick

Viktor Dukhovni

... Edit the filter script, and make sure it invokes the sendmail(1) command with a -i option and (as should be already the case) without any -t option.