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 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
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: SMTP and DKIM/POLICY Rejection Handling, (continued)
Re: Abort data transfer?, SM
Re: Abort data transfer?, Sabahattin Gucukoglu
Re: Abort data transfer?,
David MacQuigg <=
Re: Abort data transfer?, Sabahattin Gucukoglu
Re: Abort data transfer?, Hector Santos
Re: Abort data transfer?, Paul Smith
Re: Abort data transfer?, David MacQuigg
Re: Abort data transfer?, John Levine
Re: Abort data transfer?, Arnt Gulbrandsen
Re: Abort data transfer?, John R Levine
Re: Abort data transfer?, Paul Smith
Re: Abort data transfer?, John R Levine
Re: Abort data transfer?, Hector Santos
|
|
|