Extensions to SMTP

Hector Santos | 16 Aug 2011 22:32

Re: Mail Data termination


Randall Gellens wrote:
> 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.

Agree.

The problem is that a 250 was already issued once the <CRLF>.<CRLF> is 
detected so the only current possible SMTP "allowed" action is to not 
deliver (complete the transaction) due to a NO QUIT command 
cancellation which is what happened in our server setup.  I never saw 
these IETF messages.

Looking further for other similar senders (within the past 3-4 days 
logs) with this problem, I saw mainly two sender sources and each seem 
to have two important different modes:

- A sender that only needs the 250 server response for message 
completion, it will not  try to resend even if the server dropped the

(Continue reading)

headers

Keith Moore | 17 Aug 2011 00:02

Re: Mail Data termination


On Aug 16, 2011, at 4:32 PM, Hector Santos wrote:

> 
> Randall Gellens wrote:
>> 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.
> 
> Agree.
> 
> The problem is that a 250 was already issued once the <CRLF>.<CRLF> is detected so the only current
possible SMTP "allowed" action is to not deliver (complete the transaction) due to a NO QUIT command
cancellation which is what happened in our server setup.  I never saw these IETF messages.

no QUIT is a lousy reason to not deliver a message.  

Keith

headers

Hector Santos | 17 Aug 2011 00:49

Re: Mail Data termination

Keith Moore wrote:

>> The problem is that a 250 was already issued once the <CRLF>.<CRLF> is detected 
>> so the only current possible SMTP "allowed" action is to not deliver (complete 
>> the transaction) due to a NO QUIT command cancellation which is what happened 
>> in our server setup.  I never saw these IETF messages.
> 
> no QUIT is a lousy reason to not deliver a message.  

I agree with both sides of this argument for and against.  I don't 
wish to spend too much time justifying the pros and cons, but the fact 
is, it is a SMTP requirement and for good reasons too, yet, there are 
reasons when its less optimal.

Our smtp server, originally never supported it for multi-threaded and 
RPC related design reasons. Onnce threaded receiver issued a 250 
message acceptance response, it immediately signaled the router 
threads to deal with it.  No waiting for a QUIT or a new transaction 
command (MAIL FROM).

But in the name of conforming with RFC2821,  back in early 2000, we 
added a bunch a stuff related to RFC2821 compliant including the NO 
QUIT SMTP requirement as a default behavior knowing full well there 
could be new surprises here.

For one thing, it slowed down the instant signaling and delivery by 
holding it longer, not something that tickled  me.  But its in the 
specs, an as long a fall back was available for customers affected by 
it, I was fine with it.

(Continue reading)