----- Original Message -----
From: "John Levine" <asrg(_at_)johnlevine(_dot_)com>
To: <asrg(_at_)ietf(_dot_)org>
Cc: <hjp-asrg(_at_)hjp(_dot_)at>
Sent: Sunday, September 03, 2006 6:02 PM
Subject: Re: [Asrg] DSN generation and handling
An interesting topic. I've seen a fair amount of discussion but nothing
approaching research.
* What format are DSN messages generated in? Do they conform to
RFC 3464? Do they contain all relevant information? Is it presented in
a human (user) readable manner?
Do they contain the complete undelivered message or just part of it?
Not exactly research but .....
An e-mail earlier this year wondered what format bounce messages used; just
happening to receive several hundred, I decided to take a look. This e-mail
gives the principles on which my analysis is based; a companion e-mail, with a
"Subject:" of 'bouncetwo', contains the analysis.
Bounce messages (Delivery Status Notification messages, RFC3464) form a
significant part of e-mail traffic and most of them are false, in the sense that
they are being sent to a "Return Path:" address that was forged in the first
place, along with forged, but perhaps existing, "Subject:", "From:", message
body and so on.
The assumption here is that bounce messages will most often be delivered to and
viewed by a lay, non-technical user, one with no particular skills in SMTP, one
who perhaps thinks that DSN is a dyslexic reference to the Domain Name System
and that worms are responsible for the health of the soil. As such, the message
should convey its intent in simple, unemotional terms, telling the recipient
what has happened and what they might do about it. Suitable fields for this are
those that the lay user is most likely to see, namely "From:", "Subject:" and
the first 10-20 lines of the message body. At the same time, the message should
also contain more technical information so that, when passed to suitably skilled
support staff, further analysis and action is possible. Such information should
be placed in the remainder of the body or in attachments. Since most bounce
messages are the result of forged "Return-Path:" or "From:" addresses, they
should avoid being dogmatic; 'the e-mail <with this subject> that you sent
contains a virus' may alienate or upset a lay user who knows full well that they
did no such thing.
Subject:
The "Subject:" of the bounce message should convey clearly, within the
constraints of what can be viewed from the subject line, say 35 characters, that
this is a message about the non-delivery of e-mail This is well conveyed by
Delivery Status Notification
Delivery Failure
Mail Delivery Failed.
It is not well conveyed by
Mail System Error
Returned Mail
There is no Error in the Mail System - it is working just as it is designed to
(although it would be working better if no bounce messages were present) - and
the Mail must not be returned; the mail most likely contains a virus or worm and
should not be returned (or alleged to be returned).
'Failure Notice' is too bland; what is it that is alleged to have failed?
If the presence of a virus/worm has been detected, then
Virus detected
may be a suitable alternative
From:
"From:" should be used in conjunction with "Subject:" since these two are
commonly displayed together in a user's inbox. Thus if the "From:" conveys the
meaning that this message is to do with mail delivery, then that may be omitted
from the "Subject:". Thus suitable choices are
Mail Delivery Subsystem
Mailer-Daemon
Mail Administator
Less good is
postmaster@<domain-name>
since, while technically correct, it is unlikely to convey the meaning clearly
to a lay user, especially as the <domain-name> may be unknown to the user.
Other e-mail addresses are likely to mislead.
Body
The body of the message should restate, in more detail, that this is a bounce
message, give more details about the message that has been bounced and why; it
should also identify the software that is generating this message. It must
always allow for the probability that the "Return-Path:" in the original mesage
was forged and so this will be the first that the user knows of the matter.
Thus text of the form
"A message that you sent ..."
" a message from your address"
is always unhelpful. Rather, it should be of the form 'the following message',
'a message received' preferrably with the qualification that the bounce message
may be being sent in response to a forged e-mail address ie this is the first
the user has heard of it.
The first paragraph, such as can be seen in a preview pane of an e-mail client,
should be couched in terms understandable to the lay reader eg an e-mail
message, more details below, has not been delivered because ... followed by
suggested actions for a user who does not understand the bounce message, either
for the user to contact their own mail administator, or if the sender of the
bounce message is willing, to contact the sender by e-mail.
This should be followed by the reason for non-delivery in more technical terms
eg
'reason: 550 Error: No attachments allowed'
'The email contained the virus: Email-Worm.Win32.Mydoom'
'550 5.1.1 User unknown'
using reply codes [RFC821] and enhanced status codes [RC3463] as appropriate;
and, perhaps, a SMTP trace eg
----- Transcript of session follows -----
... while talking to mail.example.com:
DATA
<<< 554 5.7.1 virus Exploit.HTML.IFrame detected
554 5.0.0 Service unavailable
The body must contain enough to identify the original message that caused the
bounce message to be created and clearly identify that this is what it is and
not an artifact of the bounce message itself; a solid line across the screen or
------ This is a copy of the message, including all the headers. ------
conveys this well. At the very least, the extract from the original mesage must
contain "From:", "To:" and "Date:". It should contain the entire message
header, particularly the earliest "Received:" to show where the message entered
the system. It also should contain part of the body of the original message
but, since this is likely to be worm or virus, must not contain the entire body.
To date, such bodies are in excess of 20kbyte so providing up to 10kbyte runs no
risk of propagating a virus while providing enough of a footprint to identify
what was sent (note that while message headers are currently one or two kbyte,
they are steadily increasing in size with the advent of anti-spam procedures
such as SPF and DKIM).
Note that a typical e-mail client will treat a "Content-Type:" of
'text/rfc822-headers' as part of the body and display it as such while a
"Content-Type:" of 'message/rfc822' will be treated as an attachment and require
the user to perform further contortions to view it; this makes a "Content-Type:"
of 'message/rfc822' suitable for the (truncated) original message with the
headers of the original message included as a "Content-Type:" of
'text/rfc822-headers'.
Finally the body should identify the software that is generating the bounce
message. Standards-based diagnostic messages and codes are coarse-grained; the
software will usually have more information available and will include or imply
that in the bounce message; but to make sense of this information, it is
important to know precisely what software is generating the information. Thus
the software should be identified by manufacturer, software product name,
software version/level/release, plus a date of release or build if that is
significant to the manufacturer.
Tom Petch
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg