This old convention either meant that you received an error message or you received nothing. The email may have arrived or it may not have arrived. The error messages, in many cases, were just as helpful as no error messages.
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.
No EHLO, No Fun
First, make sure that the server supports DSN—that is, say EHLO to it and listen carefully. If it responds with DSN somewhere in the feature list, it will be able to serve requests. If not, try another server or fall back to email without DSN. For example: 220 larose.magnet.at ESMTP Sendmail 8.8.6/8.8.6; Sun, 24 Aug 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Hello localhost [127.0.0.1], pleased to meet you250-EXPN250-VERB250-8BITMIME250-SIZE250-DSN250-ONEX250-ETRN250-XUSR250 HELP
DSN Sender Extensions
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 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 the original message should be returned in case of a delivery failure. Valid arguments are FULL and HDRS. FULL 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 is the default value. ENVID belongs to the sender as the sender or (rather) the sender’s email client will be the only one that makes use 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 left to the imagination of the sender. ENVID is not used in this example: MAIL FROM: sender@example.com RET=HDRS250 sender@example.com… Sender ok
DSN Recipient Extensions
The RCPT TO gets its fair share of extensions as well: NOTIFY and ORCPT. NOTIFY is the core of DSN. It tells the server when to send a delivery status notification. The options include:
NEVER means that under no circumstances must a DSN be returned to the sender. This was not possible without DSN.SUCCESS notifies when mail has arrived at its destination.FAILURE delivers a DSN if an error occurred during delivery.DELAY sends a notification if there is an unusual delay in delivery, but the actual delivery’s outcome (success or failure) is not yet decided.
The purpose of ORCPT is to preserve the original recipient of an email message, for example, if it is forwarded to another address. The argument for 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: support@example.com NOTIFY=FAILURE,DELAY ORCPT=rfc822;support@example.com250 support@example.com… Recipient ok (will queue) This is followed by the DATA and a delivery status notification of success.
Does DSN Work?
DSN only works if the mail transport agents from sender to recipient support DSN.
