Why SMTP needs a way of communicating partial success for message delivery
September 3, 2008
As illustrated in yesterday's entry, one of the problems of the (E)SMTP
protocol is that after a SMTP server has accepted all of the message's
destination addresses and gets to see the actual message, it has no
way to tell the client that the message was delivered to only some of
those addresses. This decision made perfect sense at the time that
SMTP and then ESMTP were being created, because back then most of the
plausible per-address problems could be detected at
As shown yesterday, you can sort
of fake it by selectively deferring some
Consider a politically complicated environment, where some people just want their email tagged, some people only want to reject email that is all but certain to be spam, and some people are willing to reject more widely. Here you don't know how you want to group the addresses until you've seen the message body, by which time it's too late.
While you can force the sender to split the addresses into groups by the type of filtering (if any) that the person has opted in to, the problem is that this forces the split on every email message, even the ones that don't need it, which makes things increasingly complicated and inefficient (and you are relying on mailers reacting sensibly, where by 'sensibly' you really mean 'the way you want them to'). One unwelcome effect is that users will probably get even their good email more slowly, as legitimate sending mailers get confused by your forced retries.
(Of course, this just brings up the thought that ESMTP could also use an extension to let the server advertise the recommended retry interval on any temporary failure. Increasingly the server has very definite ideas about this; either it wants you to retry very fast, or it knows that there is no point in you retrying before, say, half an hour because you'll just get another temporary failure. Some servers even put this sort of information in the text portion of their 4xx replies, which is at least very useful for sysadmins as we try to figure out why outgoing email to somewhere is being delayed.)
Written on 03 September 2008.
* * *