[Top] [All Lists]

Mail Data termination

2011-08-16 12:24:54

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>

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?

When I first was seeing these I chalked it up as a stupid sender just blasting commands and data ignoring server responses as it it was behaving in pipelining mode.

But now with DKIM logs showing failure, it was highlighted with me personally when I saw the IETF message and going back a few days, there was several of these.

The good news I think, it was the only with submissions by the same person but overall it seems to be a QP conversion issue by the list server.

I am posting wondering is there could be something more that can be done, like maybe looking at incoming circular buffers to address this in a reliable fashion. Sounds like that is more trouble than it is worth in trying to save what appears to be a broken behavior by the list server QP conversion process.

Any thoughts, comments?


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>