On 16/08/2011 19:07, Hector Santos wrote:
I've been seeing (maybe because I'm looking) more transactions from
one of more particular senders that include a <CRLF>.<CRLF> end of
data terminator in the body but continue with additional text after
the DATA has been accepted.
Investigating it seems to be something we can't reliably address short
of looking ahead of the receiver buffers to nullify these invalid
<CRLF>.<CRLF>.
In once such message, it originated as a IETF mailing list message
submission and looking at the archive, the message contains a series
of super long single line non-wrapper paragraphs but it appeared
during the list server distribution, it was transmitting a QP
conversion. Comparing the original archived message which what our
receiver was getting, prematurely getting a <CRLF>.<CRLF>, accepting
the message and the all the remaining data ending up as 500 command
unknowns, I can see what happen.
In the last line our receiver got, the archived had the long unwrapped
paragraph with an ending like so:
blah blah, when normative language ought to have been used.<CR><LF>
and during the QP conversion, it chopped it up into shorter lines:
blah blah, when normative language ought to have been used=<CR><LF>
.<CR><LF>
So it cut it off at the sentence ending period and put it on its own
line and that is where the receiver saw the DATA terminator sequence
<CRLF>.<CRLF>.
Is this something that is addressable? Something the QP RFC needs to
make a note off if not already there?
This is a broken sender, pure and simple. I think all you can do is what
you've been doing. Hopefully the sender will be fixed soon.
QP is irrelevant. The mail sender should be dot padding as the message
is sent. The encoding should make no difference.