ietf-smtp
[Top] [All Lists]

Re: Abort data transfer?

2009-10-22 13:03:44

Murray S. Kucherawy wrote:
-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of David MacQuigg
Sent: Wednesday, October 21, 2009 10:52 AM
To: IETF SMTP list
Subject: Re: Abort data transfer?

My guess is that well-established programs already know how to deal
with
this.  In my own receiver, which is standard issue Sendmail plus my own
milter routines, I get a call after every header, and after every 60KB
body chunk.  If the number of chunks exceeds 20, I return a REJECT.
What Sendmail does with that REJECT, I have not verified, but I get no
further milter calls on that message.

About sendmail in particular:

By the time your filter gets the body call, the entire message has already been 
collected (and probably queued).  If the MTA runs out of disk or other 
resources while the message is in transit, your filter will be told the 
transaction was aborted.  It won't even have seen the header block yet, 
although it will have the envelope and know that DATA was at least started.

If the receiver is accepting data so fast, that it runs a few seconds ahead of the milter process, then a few seconds of data might accumulate *beyond* where the milter says REJECT. That's certainly less of a problem than receiving data forever.

I just did an experiment with Sendmail using telnet as the client. If I send one line of data, then pause, Sendmail waits 10 minutes then disconnects with no message to telnet. There is no timeout in telnet, so it just sits there until I force a disconnect on that end.

So it seems that Sendmail is doing what I suggested earlier - the least possible work on the receiver side, no TCP reset, no attempt to close the connection, just disconnect and let the transmitter hang.

Does anyone have experience with other MTAs?  It's a simple experiment.

-- Dave

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