Re: Abort data transfer?

> On 19 Oct 2009, at 16:03, David MacQuigg wrote:
>
> > Thanks to all who answered this question.
> >
> > Hector Santos wrote:
> > > SM wrote:
> > > > Hi David,
> > > > At 14:29 17-10-2009, David MacQuigg wrote:
> > > > > Is it permissible to abort data transfer before the end of data, 
> > > > > say after you have received all headers, and you know the DKIM sig 
> > > > > is bad?
> > > > > RFC-5321 section 3.3 says:
> > > > >
> > > > >  If the verb is initially accepted and the 354 reply issued, the DATA
> > > > >  command should fail only if the mail transaction was incomplete (for
> > > > >  example, no recipients), if resources were unavailable 
> > > > > (including, of
> > > > >  course, the server unexpectedly becoming unavailable), or if the
> > > > >  server determines that the message should be rejected for policy or
> > > > >  other reasons.
> > > > That paragraph is about the DATA command.  You haven't received any 
> > > > headers yet.  You don't know whether the DKIM signature is bad.  
> > > > This is more of a SMTP question though.  You can do anything you 
> > > > wish for policy reasons.  As long as you adhere to the RFC 5321, 
> > > > you won't cause interoperability or hard to debug problems.  I 
> > > > suggest not aborting the data transfer to avoid such problems.
> > > +1. Aborted Data transfers can cause retransmissions. Unfortunately, 
> > > it is better to receive the entire payload and then issue a negative 
> > > response.
> > Forget about DKIM.  What if there is some other reason to abort, like 
> > the payload is too large?  We cannot just continue receiving data 
> > forever.  Is there a "permissible" way within SMTP to abort during 
> > data, or should I just ignore these ambiguous requirements, and 
> > either: 1) Send a TCP reset, or 2) Let the transmitter hang.
Arnt Gulbrandsen wrote (about letting the transmitter hang):
> Some people do this in order to be as occupy the sender's resources. 
> There's a fancy name for it. You send one byte every few minutes, so 
> it takes three hours to send the whole SMTP response. I don't know 
> whether doing so really inconveniences the $#(_at_)$#@! spammers and other 
> evil creatures who initiate most SMTP connections.
I wasn't thinking of a tarpit.  That would involve keeping a connection 
on my end.  Just dropping the connection will leave the transmitter with 
an SMTP process filling memory for maybe ten minutes.  Assuming the 
transmitter is a zombie, a bunch of these hung processes might slow the 
machine enough to get the owner's attention.  He will then call his ISP 
or IT department, and that should lead to cleaning the machine and 
avoiding further infections.
If the ISP or IT department is on the ball, they will eventually figure 
out how to block port 25, and avoid tech support calls.

SM wrote:

> Arnt mentioned the RFC for for SMTP Service Extension for message size 
> declaration.
This works only if the client declares the message size, and then abides 
by its declaration.
> You can send a TCP reset to abort the connection.  The SMTP client 
> will retry delivery.  If you want to say "payload too large", you'll 
> need to send a 552 code before you get to the DATA phase.
> Section 4.5.3.1.7 of RFC 5321 discusses about the maximum total length 
> of a message content.  There isn't a permissible way within SMTP to 
> abort during DATA.  It's a "don't do it unless you know what you are 
> doing".
I see no technical problem on the server side with sending "552 Too much 
mail data," then a TCP reset.  If the client keeps retrying, without 
fixing the problem, I would block that IP address for a few hours.

Sabahattin Gucukoglu wrote:

> My implementations note the reason for rejection, then switch the 
> event handler for the connection to one that just reads each buffer 
> and then throws it away.  There is nothing more that can be done.  
This could leave your receiver tied up for as long as the client keeps 
spewing garbage.
> Even trying to inform the sender by writing the error to it while it 
> is sending won't necessarily work, because it might not choose to look 
> at its inbuffers until it's quite finished spewing.  And in any case 
> that's standards violation territory you're wandering into.
Which standard?  The paragraph above from Section 3.3. of 5321 seems to 
be talking about after the 354 reply is issued (past tense).  I assume 
that means any time after that, not necessarily waiting for the end of data.
> So you'll just have to do what you can to keep the connection alive 
> for the data to come in, then reject it and hopefully at that point 
> you can resume the dialogue to finish up and ensure the sender will 
> leave you alone.  Anything else is basically suboptimal.
If we have a broken or malicious sender, it seems that the optimal 
solution would be one with the least resources on the server side.  That 
would be not even keeping the connection alive.

Hector Santos wrote:
> Isn't it sufficient to note SMTP is a single channel client/server 
> state machine protocol?  Clients send commands, Servers respond.
> Server signals are not part of the SMTP client/server framework.
> Server Connection Drops are not expected by clients.
>
> In 3.8, it includes an implicit response for such unexpected drops.
>
>    SMTP clients that experience a connection close, reset, or other
>    communications failure due to circumstances not under their control
>    (in violation of the intent of this specification but sometimes
>    unavoidable) SHOULD, to maintain the robustness of the mail system,
>    treat the mail transaction as if a 451 response had been received
>    and act accordingly.
>
> Clients are expected to end the session with QUIT.
>
> But in principle, for client/server designs, the clients initiates the 
> commands, servers respond.
I guess section 3.8 depends on how we define "normal circumstances", 
especially with the new normal being mostly abusive.  Section 3.8 lists 
such things as "a timeout ... waiting for the client to send a command 
or data".  I guess if that section were being written today, we might 
include "an overload, waiting for the client to stop sending crap".
It looks to me like DKIM was designed with the possibility of supporting 
an abort after receiving the headers.  Why else waste space putting the 
body hash in the sig header?
-- Dave