On Sun, 18 May 2008, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
Another issue is that if you do this sort thing you absolutely must
distinguish between submission and relay somehow, and lots of places are
unable to make such distinctions. It's one thing to force a automatic
relay to retry the second and subsequent recipients of a message, quite
another to force some random user to resubmit the message over and over
in order to get it through.
This kind of problem makes me think there's not much benefit to rejecting
messages at SMTP time from trusted clients, whether they are MUAs or MTAs.
The situation with SMTP submit is a lot more subtle than that. There are at
least two axes involved here: Temporary versus permanent failures and what I'll
call MUA quality.
Let's start with permanent failures. In this case things are strongly biased
towards immediate rejection, because:
(1) It gives the user immediate feedback.
(2) It's much more easily localizable.
(3) It gives the MUA the leeway to allow the error to be corrected,
avoiding the whole "resending again, this time with the correct
address" business.
(4) In many cases it avoids having to transfer the message data - especially
an issue for mobile MUAs where bandwidth is dear.
The one exception that does arise is the occasional deeply broken MUA, e.g.,
ones that fail to present any sort of useful error information to the user.
When such MUAs are prevalent (and there are placess where they are - and again,
just because you haven't encountered them doesn't mean they don't exist) having
the option to accept basically anything and send a DSN later is useful. (FWIW,
the keyword for this in our product is acceptalladdrs.)
Moving on to temporary failures... A very high quality client could take care
of this itself by putting such messages in a queue and retrying them, just like
an MTA does. But in practice such MUAs are rare. In fact not only do a lot of
MUAs treat 4yz pretty much the same as 5yz, they may not even make the
difference clear in the message they present to the user. And that makes this
case a support call generator - and for people operating large scale setups
even serious DDOS attacks are easier for them to deal with than a big influx of
support calls.
So in this case things are strongly biased towards having the MTA accept the
address/message even though it is unsure it will be able to deliver it. (FWIW,
the bias in this case is so strong that we revert to this behavior
unconditionally when operating in SMTP submit mode. Of course we'd consider
changing that if we become aware of a population of high quality clients that
handle temporary failures better.)
An additional wrinkle in all of this is client handling of DSNs. AFAIK there
are very few that attempt to correlate DSNs with the messages that generated
them. This means it is up to the user to figure out what message generated a
given DSN - which can be a problem if the DSN isn't well constructed or the
user is without clue. This issues tends to push things towards immediate error
responses, but IMO not enough to warrant immediate responses in the temporary
error case.
Finally, lurking under or around all of this is the nature of the 4yx response
itself. Using 4yz responses to limit the number of recipients in a given
transaction to 1 is not what the mechanism was intended for. This matters
because right now 4yz errors are usually the result of a server issue of some
sort, and since most messages from legitimate senders don't end up bouncing
most 4yz resolve without a DSN being sent. This changes the minute you start
using 4yz as a sort of protocol modification mechanism and once more DSNs are
in play the issue of poor client handling of DSNs becomes much more important.
Ned
P.S. At least some of these issues could be resolved with an SMTP extension
that let a server announce certain sorts of limits, i.e., on the number of
allowed recipients per transaction. Alternately, a mechanism for a client to
identify itself to the server would allow clever servers to accomodate various
sorts of bustage in well known clients. However, I believe it is better to fix
problems than work around them. (Of course I'm also a server implementor, so
I'm a bit biased against schemes that create open-ended work for me to do...)