"Certum est, quia impossibile est."
What happened to my mail?
Last week we took a brief look at the SMTP protocol and noticed that besides the usual HELO there is also EHLO which makes the ExtendedSMTP server advertise its capabilities beyond the original standard. One of these is DSN. DSN? Are DNA and DDT not enough?
To argue that email is unreliable, that somebody should "...feed their server better; it ate my mail..." is not uncommon. I do it myself. Yet, there is very little reason to this (compared to other things we do not doubt, like our eyes or that Canadians like questions, eh?). Delivery Status Notification has been around since RFC 821 (from 1982). As soon as the DATA part of the SMTP protocol is finished and the server has accepted the email for delivery it is responsible for it. If, for any reason, it cannot get it through to the recipient it must send it back with notification of the error to the original sender (if only Elvis could have seen this). This resulted in some obscure email and I'm sure you know what I mean.
Apart from that, this old convention meant that either you got an error massege or you got nothing in which case you knew nothing: the email may have arrived or it may not. The error messages in many cases were just as helpful as no error messages. With email becoming more and more important this is no longer satisfactory (as if it was before).
DSN extensions to SMTP
RFC 1891 proposes some extensions to the SMTP protocol that should result in a more reliable and more usable DSN system. It is a set of extensions to the MAIL and RCPT commands (if this means nothing to you, read how SMTP works and then return here.).
No EHLO, no fun
First, we have to make sure that the server supports DSN. Thus, we have to say EHLO to him and listen carefully. If it responds with DSN somewher in the feature list we can assume that it will be able to serve our requests. If not, then not: we can try another server or simply fall back to email without DSN. For example (my input being blue, the server's output black):
220 larose.magnet.at ESMTP Sendmail 8.8.6/8.8.6; Sun, 24 Aug 1997 18:23:22 +0200
250-larose.magnet.at Hello localhost [127.0.0.1], pleased to meet you
Luckily, among other things we find DSN.
The next command typically is MAIL FROM:. With DSN, this is no different. But there are two additional options you may issue: RET and ENVID.
The RET option was rather arbitrarily placed in the MAIL command, but it fits here as well as it would anywhere else. The purpose is to specify how much of your original message should be returned in case of a delivery failure. Valid arguments are FULL and HDRS. The former means that the complete message should be included in the error message, HDRS instructs the server to only return the headers of the failed mail. If RET is not specified, it is up to the server what to do. In most cases HDRS will be the default value.
ENVID really belongs to the sender as she or (rather) her email client will be the only one that makes us of this envelope identifier. Its purpose is to tell the sender which email a possibly issued error message corresponds to. The format of this ID is basically left to the imagination of the sender. We will not use ENVID in our example (imagination!):
MAIL FROM: firstname.lastname@example.org RET=HDRS
250 email@example.com... Sender ok
Apparently, we only want to get the headers back in our DSN.
The RCPT TO: gets its fair share of extensions as well: NOTIFY and ORCPT.
NOTIFY is the real heart of DSN. It tells the server when to send a delivery status notification. The first possible value is NEVER which means that under no circumstances a DSN must be returned to the sender. This was not possible without DSN. Then there is SUCCESS which will notify you when your mail as arraved at its destination. FAILURE is SUCCESS's counterpart(!): a DSN will arrive if an arror occured during delivery. The last option is DELAY: you will be notified if there is an unusual delay in delivery, but the actual delivery's outcome (success or failure) is not yet decided. NEVER must be the only argument if it specified, the other three may appear in a list, delimeted by a comma. SUCCESS and FAILURE make up for a pretty strong team together(!), telling you in (almost) any case what happened to your mail.
The purpose of ORCPT is to preserver the original recipient of an email message, for example if it is forwared to another address. The argument to this option is the email address of the original recipient together with the address type. The address type comes first, followed by a semicolon and finally the address. For example:
RCPT TO: firstname.lastname@example.org NOTIFY=FAILURE,DELAY ORCPT=rfc822;email@example.com
250 firstname.lastname@example.org... Recipient ok (will queue)
This is followed by the DATA as we know it and eventually, hopefully, a delivery statis notification notifying you of a success.
Does it work?
Of course, all this beauty and wit will only work if the mail transport agents from sender to recipient support DSN. Some day they will.