[exim-dev] [Bug 938] 'smtp' transport does not assert '\n' b…

Pàgina inicial
Delete this message
Reply to this message
Autor: J R Binks
Data:  
A: exim-dev
Assumpte: [exim-dev] [Bug 938] 'smtp' transport does not assert '\n' before sending '.' in DATA transmission
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=938

J R Binks <jethro.binks@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jethro.binks@???





--- Comment #3 from J R Binks <jethro.binks@???> 2009-12-22 10:28:58 ---
I also see this problem, and have alluded to it in the past but didn't mention
MailScanner in the context back then:

http://lists.exim.org/lurker/message/20081003.110247.ada9331e.en.html

The topica ones that I commonly see stuck on the mail queue do commonly have
very long sender addresses.

I agree this is almost certainly a MailScanner bug, but it would be very useful
if Exim could be more helpful in fixing this up. An option on the transport to
add CRLF on an outbound message if it does not already have one would be
extremely useful.

Exim already has a history of fixups to work around bugs in other systems :) I
do not know if any of the other MTAs (sendmail, postfix) that MailScanner
supports are more forgiving in this regard.

Assuming the original message had a newline (which we assert it must have done
to be able to be received over SMTP), then there should be no implications for
any message integrity signing, since we're merely returning what was taken out
within MailScanner.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email