Well, I sent the message though, with altermime enabled, and it chopped
it off.
I've disabled it to send this message.
Nick
-------- Original Message --------
Message-ID: <532c4b17.2020...@krescendo.com>
Date: Fri, 21 Mar 2014 14:22:15 +0000
From: Nick Warr <nick.w...@krescendo.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
Thunderbird/24.4.0
MIME-Version: 1.0
To: postfix-users@postfix.org
Subject: A strange issue with postfix and altermime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.xx...@krescendo.com>
Date: Thursday, 20 March 2014 16:58
To: XXXX XXXXXX <xxx.x...@xxxx.com>
Cc: "'XX, XXXx XXX'" <xxxx.x...@xxxx.com>, ConQuest Dev
<conquest...@krescendo.com>
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
