[Top] [All Lists]

Re: Mail Data termination

2011-08-16 17:03:41

At 1:07 PM -0400 8/16/11, 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>.

This is something that is so broken I think the best course is to
reject it.  Hopefully the sender will notice and fix their bug.

Not sure rejecting is such a great idea... The problem is that unless the
on-the-fly encoding or whatever is causing a <CRLF>.<CRLF> in the output stream
that isn't a terminator is also doing something else that's invalid and which
can be checked, the mail transaction is legitimate and complete at the point in
the dialog where that terminator was received. So in order to detect that there
is a problem, the receiver has to peek at the  input stream and see if there's
anything waiting beyond the transaction. And if there is it could just as
easily be a problem like, say, the sender not implementing pipelining properly.

The peek may also not be reliable - it's entirely possible that the sender
sends out one line at a time. (Yes, that's inefficient, but considering
the brokenness here would you be surprised if the client is also inefficient?)

It's even possible for some problem with a subsequent message in the stream
to present as invalid command data having nothing to do with the previous,
correct message.

Another way to handle this on the receiving end is not to peek but to do a hard
disconnect after some small number of bad commands are seen. This will likely
have the effect of causing the transaction to fail (from the sender's
perspective - but of course it will have succeeded with a partial message from
the receiver's perspective). The result will be a series of duplicate partial
messages for the receiver and a series of transmission failures for the sender.
The duplicates will no doubt be annoying, but this has the advantage that it
doesn't cause damage when this particular set of symptoms are the result of a
different underlying problem.

The required buffer peek may also be an issue. Servers that support pipelining
may already have code in place to do this (so command replies can be batched
up), in which case it may pretty trivial to implement. But if not ... fiddling
with your buffer management has it's own set of risks.

Meh. I think this may be one where trying to compensate for this on the server end is a poor substitute for tracking down whoever is doing this,
contacting them and urging them to fix the problem.


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