--On Monday, 12 September, 2005 11:32 +0200 Frank Ellermann
John C Klensin wrote:
I am not persuaded that there is consensus on deprecating the
"accept, process, and then return (or drop)" model in favor
of requiring that everything be done while the SMTP
connection is open.
"Requiring" cannot work, but "favouring" should be okay. Just
enough so that something like draft-hutzler-spamops has a base
to build on.
Sigh. I wasn't explicit enough. Suppose we have
(1) MUA -> (2) Submission-MTA ->
(3) Real-relay ->
(5) Delivery-MTA -> (6) Mailbox or MDA etc.
Now, being a real relay, (3) doesn't have a list of the valid
addresses at (6), nor does it have any business inspecting
content. Put differently, if it starts inspecting content, if
isn't a real relay, it is something else.
Now, let's say we decide to avoid having negative results
(inability to deliver or content-based decision to not deliver)
returned to (2) or (1) by mail messages. Let's look at only
the most obvious and simple case of an invalid delivery address.
The transactions (2) -> (3) -> (5) have to be
(2) opens connection to (3)
(3) 220 hi there
(2) EHLO confused.example.com
(3) 250 8BITMIME
(2) MAIL FROM:<joebloggs(_at_)example(_dot_)com>
(3) 250 return path ok
(2) RCPT TO:<melvin(_dot_)furd(_at_)bogus(_dot_)domain(_dot_)name>
(3) opens connection to (5)
(5->3) 220 mailserver.bogus.domain.name connection open
(3->5)-> EHLO stupid.domain.name
(5->3) 250 8BITMIME
(3->5) MAIL FROM:<joebloggs(_at_)example(_dot_)com>
(5->3) 250 return path ok
(3->5) RCPT TO:<melvin(_dot_)furd(_at_)bogus(_dot_)domain(_dot_)name>
(5->3) 550 At least to you I deny knowing anyone named melvin
(3->5) QUIT **
(5->3) 221 sweet dreams **
(3) closes connection **
(3->2) 550 user unknown
(3) 221 spammers should all rot
(2) closes connection
** these three steps can occur asynronously from what follows.
Note that, if (5)'s reasons for rejecting the transmission
involves content, not addresses, (3) would need to get back an
OK from (5) after the RCPT TO, send DATA and the (possibly very
large) content including the CRLF.CRLF, and then wait until (5)
does its content evaluation and potentially returns a 550 or 554
and a "spammers should all die" message.
Now I suggest to you that this scenario is not going to work, at
least without keeping connections open much longer than
necessary in normal cases -- keeping those connections open is
considered a bad thing in normal operation and would facilitate
denial of service attacks. Moreover, while the case is not
common, inserting a second relay at (4) would require the relay
at (3) to maintain an open connection to it, and (2) to maintain
an open connection to (3), while it negotiates with (5). With a
large message to be transmitted, this virtually guarantees
timeouts at (2), even under 2821's minimum timeout rules. The
situation would be even worse if, as many have suggested,
timeouts be shortened to counter spammer behavior. Since
timeouts imply retries, trying to do this could yield to
self-inflicted denial of service attacks.
And, even if all of that works with the connection open, either
(2) will need to generate mail messages to send the errors back
to (1): keeping the connection between (1) and (2) open through
all of this is unfeasible in the (extremely common)
queue-connect-send-disconnect mode and effectively impossible if
(2) is expected to maintain a retry queue for messages that
cannot be immediately delivered.
Now, what are you proposing that 2821 be redesigned to "favour"?
I should probably not say this for fear of being inflammatory,
but, if draft-hutzler-spamops cannot build on, or work in, the
one-relay environment without those open connections, then it is
DOA in the real world.
If we have some "consensus" that most SMTP traffic today is
unsolicited / unwanted it has consequences, the old model with
"accept and return" (where does it talk about "drop" ?) is not
more good enough.
It talks about "drop", but only in the context of protection
against attack. IMO, that is how it should be. The
alternative, it seems to me, is to turn the email environment
into one is which there is no expectation of reliable delivery.
And that, again IMO, is the point at which it is time to abandon
SMTP and design something else instead.