[Top] [All Lists]

Re: Abort data transfer?

2009-10-19 21:34:35

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 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

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