ietf-smtp
[Top] [All Lists]

RE: Abort data transfer?

2009-10-22 14:46:48


-----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: Thursday, October 22, 2009 9:43 AM
To: IETF SMTP list
Subject: Re: Abort data transfer?

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.

This isn't how Sendmail works.  The entire message is cached to the queue
before milter is told anything about the headers or body.  There's no "a few
seconds ahead", it's all the way ahead.  Milter has no opportunity to say
REJECT in the middle of the SMTP DATA phase because the filter doesn't even
know that's where the MTA is.

Interesting... Our milter implementation actually sends the message to the
client as it is received. Of course any REJECTs or ACCEPTs or whatever that
occur along the way are noted and further output to the milter is blocked.
The status is then considered after the message is complete.

Read the code in srvrsmtp.c and note that collect() is called before
milter_data(); the former collects the entire message from the incoming 
stream,
and the latter is what sends header and body information down to the filters.

Implementing it the way we did was something of a PITA; I certainly  can
understand why sendmail opted for the collect then send approach.

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.

That's an MTA timeout and has nothing to do with milter.  Upon reaching this
timeout, the filter has received the envelope data but none of the header or
body, and will be given an "abort" instruction.

FWIW, our implementation has a similar timeout, but when it is reached it
spits back a 421 4.4.2 blah blah blah sort of line and closes the
connection. And of course we abort any milter that's in progress at this
point.

I have to say I don't understand the distinction between disconnection and
closing the connection that's being made here. AFAIK the only available
semantic here is to close the socket, and AFAIK the only socket option that
might affect how the close is done is SO_LINGER. We don't mess with SO_LINGER
when this sort of timeout happens, and when I try it with a telnet client I get
the 421 response and then the telnet client exits.

                                Ned

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