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?
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?
--
Sincerely
Hector Santos
http://www.santronics.com