Subject: bouncetwo: was Re: [Asrg] DSN generation and handling

From: "Tom Petch" <[email-masked]>
Date: Fri, 8 Dec 2006 18:15:27 +0100

----- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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?
>

A bit more research like.

For details of the principles on which this analysis is based, see the companion
e-mail with a "Subject:" of 'bounceone'

This e-mail contains the analysis of 400 bounce (Delivery Status Notification)
messages received by a single e-mail address between 20 June and 9 October 2006.
In the same timeframe, the e-mail address itself received approximately 5430
messages containing the MyDoom worm with a forged "Return-Path" together with a
somewhat smaller number of similar messages carrying screen savers and such
like; in a very few cases (less than 10), the worm had been removed in transit
by an MTA.

Bounce messages were received from the following software.  The number in
(parentheses) is the number of messages received.

[7.2.0] (2)
8.12.8 (52)
Active Spam Killer (1)
[AIMC] (1)
BitDefender (1)
blueyonder (3)
ClamAV (4)
CommuniGate Pro (23)
ConcentricHost MX (1)
CoreMail (1)
exim (17)
ezmlm (2)
[Intermail] (3)
[Internet Mail Service] (5)
[iPlanet Messaging Server] (4)
Kaspersky Anti-Virus (1)
Kerio MailServer(1)
LISTSERV (4)
L-soft (12)
Lyris Listmanager (1)
MailEnable (5)
AV MAILGATE BTC-NET (1)
X-Optimum Internet Ltd-MailScanner (2)
Majordomo (3)
[Merak] (3)
[MOS] (3)
Panda GateDefender Performa (3)
PMDF e-Mail Interconnect (1)
Postfix (65)
qmail-send (34)
[QMQP] (1)
SMPTD32 (3)
[Sophos] Puremessage (2)
Sun Java System Messaging Server (12)
Symantec AntiVirus (32)
[Terrace MailWatcher] (1)
TMDA (1)
trimMail (1)
[v112] (15)
Network Associates WebShield SMTP (1)
zmailer (1)

The identity of theFrom [email-masked] Fri Dec 08 13:25:00 2006
From: "Tom Petch" <[email-masked]>
To: "John Levine" <[email-masked]>, <[email-masked]>
Subject: bouncetwo: was Re: [Asrg] DSN generation and handling
Date: Fri, 8 Dec 2006 18:15:27 +0100
Cc: [email-masked]
Reply-To: Tom Petch <[email-masked]>

----- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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?
>

A bit more research like.

For details of the principles on which this analysis is based, see the companion
e-mail with a "Subject:" of 'bounceone'

This e-mail contains the analysis of 400 bounce (Delivery Status Notification)
messages received by a single e-mail address between 20 June and 9 October 2006.
In the same timeframe, the e-mail address itself received approximately 5430
messages containing the MyDoom worm with a forged "Return-Path" together with a
somewhat smaller number of similar messages carrying screen savers and such
like; in a very few cases (less than 10), the worm had been removed in transit
by an MTA.

Bounce messages were received from the following software.  The number in
(parentheses) is the number of messages received.

[7.2.0] (2)
8.12.8 (52)
Active Spam Killer (1)
[AIMC] (1)
BitDefender (1)
blueyonder (3)
ClamAV (4)
CommuniGate Pro (23)
ConcentricHost MX (1)
CoreMail (1)
exim (17)
ezmlm (2)
[Intermail] (3)
[Internet Mail Service] (5)
[iPlanet Messaging Server] (4)
Kaspersky Anti-Virus (1)
Kerio MailServer(1)
LISTSERV (4)
L-soft (12)
Lyris Listmanager (1)
MailEnable (5)
AV MAILGATE BTC-NET (1)
X-Optimum Internet Ltd-MailScanner (2)
Majordomo (3)
[Merak] (3)
[MOS] (3)
Panda GateDefender Performa (3)
PMDF e-Mail Interconnect (1)
Postfix (65)
qmail-send (34)
[QMQP] (1)
SMPTD32 (3)
[Sophos] Puremessage (2)
Sun Java System Messaging Server (12)
Symantec AntiVirus (32)
[Terrace MailWatcher] (1)
TMDA (1)
trimMail (1)
[v112] (15)
Network Associates WebShield SMTP (1)
zmailer (1)

The identity of the software was either explicitly specified, usually in the
body of the message, or else inferred from the most recent "Received: by" header
in the original message; the latter are enclosed in [brackets].  No attempt has
been made to interpret these names; thus [8.12.8/8.12.8] (and similar values)
might be the version, release and level of a well-known software package.  Some
71 messages contained no apparent identification although many of them showed
one of two distinct patterns and may represent two anonymous, if well-known,
software packages.

The software listed here is a mixture of traditional e-mail software, of
anti-virus software and of list servers.  Since all these generated bounce
messages in response to forged "Return-path:", all are treated equally.

Two general comments on the analysis.  Since almost all the direct messages to
the address in question contained the 'MyDoom' worm (or similar), it is assumed
that the original messages that triggered these bounce messages also contained
such a payload and so the failure of the bounce message to mention the presence
of such is taken as a failing on the part of the software to detect the worm.
Apart from that, the bounce messages have been analysed 'as is' with no attempt
to interpret them eg by allowing for possible customisation of the software by
its implementor to provide the mail service on offer.

This analysis should not be taken as representative of bounce messages in
general, just those that dominate e-mail traffic.  After all, the bounce
messages are themselves spam (in a general sense) and the best, or best
implemented, software would not generate them at all and so would not be present
in this analysis.

Analysis by software of nine largest contributors

[8.12.9/8.12.8] (or similar numbers)
Software identity: taken from "Received: by", could be Version.Release.Level
From: informative (Mail Delivery Subsystem)
Subject: unhelpful (Returned Mail)
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: unhelpful, no statement of what this e-mail is
Advice: none
Expert user: comprehensive (reply code, enhanced status code, session
transcript, original message headers)
Worm detected: mostly not
Original message: dangerous (attachment complete with worm)

Communigate Pro SMTP
Software identity: in body, with version.release.level
From: informative (MAILER-DAEMON)
Subject: informative ('Undeliverable mail' or 'Virus warning' plus original
subject)
Content Type: multipart/report message/delivery-status text/rfc822-headers
Body:-
Lay user: clear (but sometimes 'you sent ...')
Advice: none
Expert user: good (reply code, original message headers)
Worm detected: 8/23
Original message: headers only

exim
Software identity: sometimes in body, otherwise from "Received: by", with
Version.Release
From: informative (Mail Delivery System)
Subject: ok (Mail Delivery Failed or Warning(3))
Content Type: none!
Body:-
Lay user: unhelpful ("A message that you sent could not be delivered"
Advice: none
Expert user: weak (message but no codes, original message headers)
Worm detected: mostly not
Original message: dangerous (complete with worm in the body)

L-soft Listserv
Software identity: in "From:" with Version.Release
From: informative (Listserv)
Subject: unhelpful ('Message')
Content Type: none!
Body:-
Lay user: unhelpful ("The distribution of your message ... "
Advice: weak ('No action is required ...')
Expert user: none
Worm detected: no
Original message: no part thereof

Postfix
Software identity: first line of body (mostly), no Version.Release.Level
From: informative (Mail Delivery System)
Subject: informative (Undelivered Mail)
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: ok ("I'm sorry to have to inform you ..." but then "your message could
not ..."
Advice: yes ("For further assistance..."
Expert user: weak (error message, occasional reply code, original message as
attachment)
Worm detected: mostly not
Original message: mostly dangerous (complete with worm a software was either explicitly specified, usually in the
body of the message, or else inferred from the most recent "Received: by" header
in the original message; the latter are enclosed in [brackets].  No attempt has
been made to interpret these names; thus [8.12.8/8.12.8] (and similar values)
might be the version, release and level of a well-known software package.  Some
71 messages contained no apparent identification although many of them showed
one of two distinct patterns and may represent two anonymous, if well-known,
software packages.

The software listed here is a mixture of traditional e-mail software, of
anti-virus software and of list servers.  Since all these generated bounce
messages in response to forged "Return-path:", all are treated equally.

Two general comments on the analysis.  Since almost all the direct messages to
the address in question contained the 'MyDoom' worm (or similar), it is assumed
that the original messages that triggered these bounce messages also contained
such a payload and so the failure of the bounce message to mention the presence
of such is taken as a failing on the part of the software to detect the worm.
Apart from that, the bounce messages have been analysed 'as is' with no attempt
to interpret them eg by allowing for possible customisation of the software by
its implementor to provide the mail service on offer.

This analysis should not be taken as representative of bounce messages in
general, just those that dominate e-mail traffic.  After all, the bounce
messages are themselves spam (in a general sense) and the best, or best
implemented, software would not generate them at all and so would not be present
in this analysis.

Analysis by software of nine largest contributors

[8.12.9/8.12.8] (or similar numbers)
Software identity: taken from "Received: by", could be Version.Release.Level
From: informative (Mail Delivery Subsystem)
Subject: unhelpful (Returned Mail)
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: unhelpful, no statement of what this e-mail is
Advice: none
Expert user: comprehensive (reply code, enhanced status code, session
transcript, original message headers)
Worm detected: mostly not
Original message: dangerous (attachment complete with worm)

Communigate Pro SMTP
Software identity: in body, with version.release.level
From: informative (MAILER-DAEMON)
Subject: informative ('Undeliverable mail' or 'Virus warning' plus original
subject)
Content Type: multipart/report message/delivery-status text/rfc822-headers
Body:-
Lay user: clear (but sometimes 'you sent ...')
Advice: none
Expert user: good (reply code, original message headers)
Worm detected: 8/23
Original message: headers only

exim
Software identity: sometimes in body, otherwise from "Received: by", with
Version.Release
From: informative (Mail Delivery System)
Subject: ok (Mail Delivery Failed or Warning(3))
Content Type: none!
Body:-
Lay user: unhelpful ("A message that you sent could not be delivered"
Advice: none
Expert user: weak (message but no codes, original message headers)
Worm detected: mostly not
Original message: dangerous (complete with worm in the body)

L-soft Listserv
Software identity: in "From:" with Version.Release
From: informative (Listserv)
Subject: unhelpful ('Message')
Content Type: none!
Body:-
Lay user: unhelpful ("The distribution of your message ... "
Advice: weak ('No action is required ...')
Expert user: none
Worm detected: no
Original message: no part thereof

Postfix
Software identity: first line of body (mostly), no Version.Release.Level
From: informative (Mail Delivery System)
Subject: informative (Undelivered Mail)
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: ok ("I'm sorry to have to inform you ..." but then "your message could
not ..."
Advice: yes ("For further assistance..."
Expert user: weak (error message, occasional reply code, original message as
attachment)
Worm detected: mostly not
Original message: mostly dangerous (complete with worm as attachment)

qmail-send
Software identity: first line of body, no Version.Release.Level
From: informative (MAILER-DAEMON)
Subject: unhelpful ('failure notice' mostly)
Content Type: mostly none (multipart/mixed in 2 cases)
Body:-
Lay user: clear ("I wasn't able to deliver .." but then "your message ...")
Expert user: erratic (a few reply codes, a few enhanced status codes, error
message, complete original message)
Worm detected: mostly not
Original message: mostly dangerous (complete with worm in body)

Sun Java System Messaging Server
Software identity: taken from "Received: by" with Version.Release.Level and
build date
From: informative (Service de distribution du courrier)
Subject: informative (Notification de l'état de remise)
Content Type: multipart/report message/delivery-status text/rfc822-headers
Body:-
Lay user: clear ("Ce rapport fait référence à un message ...", "Le message ne
peut pas être remis..."
Advice: none
Expert user: excellent (message, reply code, enhanced status code, transport
quintuple, dns name, original message headers)
Worm detected: sometimes
Original message: headers

Symantec AntiVirus
Software identity: first line of body, no Version.Release.Level
From: unhelpful (often the From: of the original message)
Subject: unhelpful (the "Subject:" of the original message, "Mail System Error",
"Returned Mail")
Content Type: mostly multipart/mixed message/rfc822
Body:-
Lay user: unhelpful (talks about detecting a virus, omits any mention of e-mail)
Advice: none
Expert user: weak (truncated original message as an attachment)
Worm detected: yes (but calls it "Mydoom")
Original message: good (worm truncated else complete as attachment)

v112 (or similar)
Software identity: from "Received: by" with Release number
From: informative (Mail Delivery System)
Subject: unhelpful ('Returned Mail' mostly)
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: unhelpful ("The original message ..." and "your e-mail is being
returned to you ..."
Advice: yes ("Please direct further questions ..."
Expert user: ok (error message, session transcript, original message headers)
Worm detected: sometimes (5/15)
Original message: headers

As may be apparent, if these were in a heap I would place Communigate Pro SMTP
and Sun Java System Messaging Server on top and Symantec AntiVirus towards the
bottom

Tom Petch

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 8 Dec 2006 18:10:09 +0100

Lists attachment)

qmail-send
Software identity: first line of body, no Version.Release.Level
From: informative (MAILER-DAEMON)
Subject: unhelpful ('failure notice' mostly)
Content Type: mostly none (multipart/mixed in 2 cases)
Body:-
Lay user: clear ("I wasn't able to deliver .." but then "your message ...=
")
Expert user: erratic (a few reply codes, a few enhanced status codes, err=
or
message, complete original message)
Worm detected: mostly not
Original message: mostly dangerous (complete with worm in body)

Sun Java System Messaging Server
Software identity: taken from "Received: by" with Version.Release.Level a=
nd
build date
From: informative (Service de distribution du courrier)
Subject: informative (Notification de l'=E9tat de remise)
Content Type: multipart/report message/delivery-status text/rfc822-header=
s
Body:-
Lay user: clear ("Ce rapport fait r=E9f=E9rence =E0 un message ...", "Le =
message ne
peut pas =EAtre remis..."
Advice: none
Expert user: excellent (message, reply code, enhanced status code, transp=
ort
quintuple, dns name, original message headers)
Worm detected: sometimes
Original message: headers

Symantec AntiVirus
Software identity: first line of body, no Version.Release.Level
From: unhelpful (often the From: of the original message)
Subject: unhelpful (the "Subject:" of the original message, "Mail System =
Error",
"Returned Mail")
Content Type: mostly multipart/mixed message/rfc822
Body:-
Lay user: unhelpful (talks about detecting a virus, omits any mention of =
e-mail)
Advice: none
Expert user: weak (truncated original message as an attachment)
Worm detected: yes (but calls it "Mydoom")
Original message: good (worm truncated else complete as attachment)

v112 (or similar)
Expert user: ok (error message, session transcript, original message head=
ers)

As may be apparent, if these were in a heap I would place Communigate Pro=
 SMTP
and Sun Java System Messaging Server on top and Symantec AntiVirus toward=
s the
bottom

Tom Petch

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 8 Dec 2006 18:10:09 +0100

----- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, September 03, 2006 6:02 PM
Subject: Re: [Asrg] DSN generation and handling

> >  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 -Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/asrg>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

----- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, September 03, 2006 6:02 PM
Subject: Re: [Asrg] DSN generation and handling

> >  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

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

---

From: der Mouse <[email-masked]>
Date: Fri, 8 Dec 2006 14:26:32 -0500 (EST)

> 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
> conveys this well.

Perhaps, but that kind of inclusion of the bounced message makes it
approximately impossible - difficult, at the very least - to
*mechanically* identify the bounce as a bounce and extract the bounced
message.  My mailserver pries open bounces and checks to see if the
bounce bears evidence of having been sent through my machines; if not,
the bounce is rejected as being a bounce of a forgery.  (This works
only because I send mail only through channels that add the relevant
spoor, of course.)

But this requires either that the bounce message be in a standardized
format - RFC 3462 is the only such standard I know of - or that I try
to track assorted nonstandard bounce formats.  I chose the former; I
complain to sites that send me non-3462 bounces of forgeries, blocking
repeat offenders.  (I'm waffling on the question of whether to complain
about non-3462 bounces of non-forgeries; at the moment I don't.)

This is not to say that a user-agent couldn't take a 3462-formatted
bounce and *display* it the way you describe, if the UA's author(s)
think that is appropriate for their target market.

> At the very least, the extract from the original mesage must contain
> "From:", "To:" and "Date:".

I would say the message-ID is another must-have.  From/To/Date is often
not enough to find the message in logs.  (If there is no message-ID, I
would say the message should not have been accepted at all.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 8 Dec 2006 20:49:52 +0100

Thank you for your comments; see <inline>

Tom Petch

----- Original Message -----
From: "der Mouse" <[email-masked]>
To: <[email-masked]>
Sent: Friday, December 08, 2006 8:26 PM
Subject: Re: bounceone Re: [Asrg] DSN generation and handling

> message.

I see this line of text in bounces that have no Content-type specified (eg exim)
which, from what you say, you will not process.

>  My mailserver pries open bounces and checks to see if the
I am looking more from the lay user perspective so it is a question of how the
e-mail client presents the information; message/delivery-status is typically
reduced to a solid line across the screen so we can both have what we want if
your mailserver uses message/delivery-status or message/rfc822; does it?

> about non-3462 bounces of non-forgeries; at the moment I don't.)

Do you accept multipart/mixed as well as multipart/report?  The former is not
strictly RFC3462 but seems quite widely used.

> would say the message should not have been accepted at all.)
Yes, the message-ID is in the original message but what I saying here is that
there is no imperative to display it; what I am seeing is bounce generators
being selective about what they display in the body as plain/text or as
text/rfc822-headers; what some include is too little for the message ever to
have reached them in the first place:-)

---

From: der Mouse <[email-masked]>
Date: Fri, 8 Dec 2006 16:23:57 -0500 (EST)

> I am looking more from the lay user perspective so it is a question
> of how the e-mail client presents the information;

Right; I don't much care how it's presented to the end user.  That's
between the UA's authors and its users.

> message/delivery-status is typically reduced to a solid line across
> the screen so we can both have what we want if your mailserver uses
> message/delivery-status or message/rfc822; does it?
>> [...]
> Do you accept multipart/mixed as well as multipart/report?  The
> former is not strictly RFC3462 but seems quite widely used.

I just checked.  The code accepts multipart/report and multipart/mixed
(and treats them identically in this respect); it requires a
message/rfc822 or text/rfc822-headers portion, which it takes as
containing the bounced message (or at least its headers).

> Yes, the message-ID is in the original message but what I saying here
> is that there is no imperative to display it;

True at the user-agent level; false, I believe, at the
bounce-generation level.

Unless you're talking about the inteded-for-humans text portion of the
bounce, with the message-ID appearing like any other header in the
message/rfc822 or text/rfc822-headers part, in which case I have no
argument with it.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: wayne <[email-masked]>
Date: Sun, 10 Dec 2006 23:56:16 -0600

> Not exactly research but .....

Thanks, it was interesting and useful.

> 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.

IMHO, the single most important thing a mail admin can do to improve
the usefulness of the bounce messages is to make sure as many of the
rejected e-mails get rejected *during* the SMTP session instead of
accepting the email and then generating a bounce.  This, will cause
the sending MTA to generate the bounce.

While the bounce that the sending MTA generates may not be as clear or
informative as possible, it will at least be in a format that the user
of that system will be familiar with.  More over, when you say things
like subject lines of "Deilvery Status Notification" are clearer than
"Mail System Error", you are assuming that the user can understand
English, something that is often not the case.

Your list of MTAs and how many bounces you received from them is
somewhat enlightening, but people need to take into account that
almost(?) all of them were because the worms were not rejected during
the SMTP session on the first SMTP hop.  Higher numbers could mean
that many more MTAs use that particular software, or it could mean
that they do accept-then-bounce.  Or, I guess, that they are often use
as submission servers (ISP, etc.) or for email forwarding and they
don't do good egress filtering.

Anyway, thanks again.

-wayne

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 12 Dec 2006 12:15:34 +0100

----- Original Message -----
From: "wayne" <[email-masked]>
To: <[email-masked]>
Sent: Monday, December 11, 2006 6:56 AM
Subject: [Asrg] Re: bounceone Re: DSN generation and handling
> the sending MTA to generate the bounce.

Agreed; I find it hard to see evidence of this except when there is only one MTA
involved.

> English, something that is often not the case.

I only know English but find that technical terms tend to be very similar.  Thus
I can cope with
' Virus rejeté'
'Ce rapport fait référence à un message envoyé '
'Este mensaje no pudo ser entregado a su(s) destinatario'
'Panda GateDefender Performa ha detectado contenido malicioso'
'Il sistema di scansione ha rilevato un problema'
or, at a pinch,
'Tozi e-mail vi e izpraten ot AV MAILGATE BTC-NET'
'Ten komunikat zostal automatycznie utworzony przez system obslugi poczty'
It is the
'Ã»ÓÐÄÜ¹»·¢ËÍµ½ÒÔÏÂµÄÊÕ¼þÈË:'
that defeat me:-(

Tom Petch
<snip>

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 14 Dec 2006 21:57:17 +0100

Tom Petch wrote:

> 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.

I think you want to say that there should be a display name like
"Mail Administator" in addition to the postmaster@ address, is
that correct ?

> Other e-mail addresses are likely to mislead.

+1  Whatever it is, they must be ready to get "manual" replies
at this address, if there's no separate Reply-To.

> perhaps, a SMTP trace eg

Somebody, maybe AOL, but I'm not sure, managed it to note the
alleged MAIL FROM nowhere, that's bad.   I can determine it,
it ends up in an X-Envelope-To, but that's unreliable.  This
point is of course moot if the bounce contains the complete
header _with_ (forged) Return-Path somewhere, but normally
it's only the complete header _without_ Return-Path.  Yes, I
use one of those funny catchall vanity host mailboxes.

> At the very least, the extract from the original mesage must
> contain "From:", "To:" and "Date:".

NAK, complete header, no compromises, unless it's monstrous,
a loop of Received lines until one party crashed or similar.

> It should contain the entire message header

SHOULD as near to a MUST as possible.

> particularly the earliest "Received:" to show where the
> message entered the system.

It allegedly entered the system there.  In reality it entered
the system later, the bottom timestamp lines were preloaded by
the spammer / worm author, more or less plausible.

> To date, such bodies are in excess of 20kbyte so providing
> up to 10kbyte runs no risk of propagating a virus

After MyDoom (spring 2004) my ISPs blocked or deleted almost
all worms.  Until then the limit went down to 12,000 bytes,
that's for 1200 + 8100 * 4/3 (B64).  IIRC Sober was quite small.

Another approach would be to truncate bodies at the first line
starting with TV or UE (credits for that trick to JohnL).  Or
any potential B64 crap that's not a potential MIME text part.

> 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.

SPF doesn't add message header fields, at least not on the side
of the sender.  Spammers trying in vain to preload Received-SPF
is an idea, but it's futile, receivers would either ignore it
if they normally don't get it, or pick the top Received-SPF as
inserted by their own side.  And Received-SPF is fairly small.

For DKIM it's another issue, so you better state your limits
for the copied part of the body, excl. the complete header, or
you have two limits, with say 8100*4/3 for the body.  Or less.

In Spamcop reports I use POP3 "TOP 10" (first ten lines of the
body) plus complete header.  So far no abuse desk complained
that they needed more... :-)

> a "Content-Type:" of 'message/rfc822' will be treated as an
> attachment

If some broken UAs do this it's their problem.  Content-Type and
Content-Disposition are in essence unrelated.  A MIME part is a
MIME part, it's not necessarily an attachment.  Please don't use
Microsoft (or rather OE) terminology, they don't understand MIME,
it's a hopeless case.

> 'message/rfc822' suitable for the (truncated) original message
> with the headers of the original message included as a
> "Content-Type:" of 'text/rfc822-headers'.

Sending the complete header twice is a bad idea.  The truncated
message/rfc822 is fine, it contains the complete header.  You'd
use text/rfc822 only in conjunction with something that is _not_
message/rfc822.

> Finally the body should identify the software that is generating
> the bounce message.

That should go into the reporting header, as User-Agent or similar,
not as part of the Subject.  Admittedly I add the id. of the tool
truncating bodies (the "TOP 10" mentioned above) below that body,
but that's a kludge.  For some time it was a complete URL, until I
reported my own site as "spamvertized", then I changed it for naive
users incl. me... :-)

Frank

---

From: Daniel Feenberg <[email-masked]>
Date: Thu, 14 Dec 2006 17:50:21 -0500 (EST)

>> may be unknown to the user.
...

I have always found the overuse of the pronoun "localhost" in DSN messages 
a stumbling block to quick understanding. Substituting the actual host 
name wouldn't cost anything, would it? I understand there is no actual 
ambiguity, just a delay while the user figures it out (or gives up 
trying).

If the DSN included the message-id, it would be possible to automate the 
dropping of DSN messages arising from forged return addresses on messages 
to misconfigured MTAs. Most of the DSNs I get have the subject line, but 
few have the message-id. If no reasonably reliable way to determine the 
legitimacy of a DSN is established, then more MTAs will start discarding 
all of them, which would be significant reduction in service and not at 
all desirable.

Daniel Feenberg

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 15 Dec 2006 14:18:30 +0100

This is release 2 of bouncetwo, updated to include a further ten sets of details
and adding a 'machine:' line giving the fields present in the
'message/delivery-status'.

This e-mail contains the analysis of 400 bounce (mostly Delivery Status
Notification) messages delivered to a single e-mail address on a UA between 20
June and 9 October 2006.  In the same time frame, this e-mail address also
received approximately 5430 messages containing the MyDoom worm with a forged
"Return-Path" together with a somewhat smaller number of similar messages
carrying screen savers and such like.  In a very few cases (less than 10), the
worm had been removed in transit by an MTA.

Bounce messages were received from the following 'software'.  The number in
(parentheses) is the number of messages received.  * indicates more details are
given below.

[7.2.0] (2)
8.12.8 (54) *
Active Spam Killer (1)
[AIMC] (1)
BitDefender (1)
blueyonder (3) *
ClamAV (4) *
CommuniGate Pro (23) *
ConcentricHost MX (1)
CoreMail (1)
exim (17) *
ezmlm (2)
[Intermail] (4) *
[Internet Mail Service] (4) *
[iPlanet Messaging Server] (4) *
Kaspersky Anti-Virus (1)
Kerio MailServer(1)
LISTSERV (4)
Lsoft (12) *
Lyris Listmanager (1)
MailEnable (5) *
AV MAILGATE BTC-NET (1)
X-Optimum Internet Ltd-MailScanner (2)
Majordomo (3)
[Merak] (3) *
[MOS] (3) *
Panda GateDefender Performa (3) *
PMDF e-Mail Interconnect (1)
Postfix (65) *
qmail-send (34) *
[QMQP] (1)
Rockliffe (1)
SMTPD32 (3) *
SMTPSVC (6)  *
[Sophos] Puremessage (2)
Sun Java System Messaging Server (12) *
Symantec AntiVirus (32) *
[Terrace MailWatcher] (1)
TMDA (1)
trimMail (1)
[v112] (16) *
Network Associates WebShield SMTP (1)
zmailer (1)

The identity of the software was either explicitly specified, usually in the
body of the message, or else inferred from the most recent "Received: by" header
in the original message; the latter are enclosed in [brackets].  No attempt has
been made to interpret these names; thus [8.12.8/8.12.8] (and simFrom [email-masked] Fri Dec 15 09:24:40 2006
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Subject: bouncetwo R2: was Re: [Asrg] DSN generation and handling
Date: Fri, 15 Dec 2006 14:18:30 +0100
Reply-To: Tom Petch <[email-masked]>

This is release 2 of bouncetwo, updated to include a further ten sets of details
and adding a 'machine:' line giving the fields present in the
'message/delivery-status'.

This e-mail contains the analysis of 400 bounce (mostly Delivery Status
Notification) messages delivered to a single e-mail address on a UA between 20
June and 9 October 2006.  In the same time frame, this e-mail address also
received approximately 5430 messages containing the MyDoom worm with a forged
"Return-Path" together with a somewhat smaller number of similar messages
carrying screen savers and such like.  In a very few cases (less than 10), the
worm had been removed in transit by an MTA.

Bounce messages were received from the following 'software'.  The number in
(parentheses) is the number of messages received.  * indicates more details are
given below.

[7.2.0] (2)
8.12.8 (54) *
Active Spam Killer (1)
[AIMC] (1)
BitDefender (1)
blueyonder (3) *
ClamAV (4) *
CommuniGate Pro (23) *
ConcentricHost MX (1)
CoreMail (1)
exim (17) *
ezmlm (2)
[Intermail] (4) *
[Internet Mail Service] (4) *
[iPlanet Messaging Server] (4) *
Kaspersky Anti-Virus (1)
Kerio MailServer(1)
LISTSERV (4)
Lsoft (12) *
Lyris Listmanager (1)
MailEnable (5) *
AV MAILGATE BTC-NET (1)
X-Optimum Internet Ltd-MailScanner (2)
Majordomo (3)
[Merak] (3) *
[MOS] (3) *
Panda GateDefender Performa (3) *
PMDF e-Mail Interconnect (1)
Postfix (65) *
qmail-send (34) *
[QMQP] (1)
Rockliffe (1)
SMTPD32 (3) *
SMTPSVC (6)  *
[Sophos] Puremessage (2)
Sun Java System Messaging Server (12) *
Symantec AntiVirus (32) *
[Terrace MailWatcher] (1)
TMDA (1)
trimMail (1)
[v112] (16) *
Network Associates WebShield SMTP (1)
zmailer (1)

59 messages contained no apparent identification although many of them showed

The software listed here is a mixture of traditional e-mail software, of
anti-virus software and of list servers.  Since all these sent bounce messages
to a forged "Return-path:", all are treated equally.

This analysis should not be taken as representative of bounce messages in
general, just of those that dominate e-mail traffic.  After all, the bounce
messages are themselves spam (in a general sense) and the best, or best
implemented, software would not generate them at all and so would not be present
in this analysis.

[8.12.8/8.12.8] (or similar numbers)
Software identity: taken from "Received: by", could be Version.Release.Level
From: informative (Mail Delivery Subsystem)
Subject: unhelpful (Returned Mail)
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: unhelpful, no statement of what this e-mail is
Advice: none
Expert user: comprehensive (reply code, enhanced status code, session
transcript, original message headers)
Machine: Reporting-MTA:, Received-From-MTA:, Arrival-Date:, Final-Recipient:,
Action: failed, Status:, Remote-MTA:, Diagnostic-Code:, Last-Attempt-Date:,
(X-Actual-Recipient)
Worm detected: mostly not
Original message: dangerous (as a message/rfc822 complete with worm)

Communigate Pro SMTP
Software identity: in body, with version.release.level
From: informative (MAILER-DAEMON)
Subject: informative ('Undeliverable mail' or 'Virus warning' plus original
subject)
Content Type: multipart/report message/delivery-status text/rfc822-headers
Body:-
Lay user: clear (but sometimes 'you sent ...')
Advice: none
Expert user: good (reply code, original message headers)
Machine: Reporting-MTA:, Original-Recipient:, Final-Recipient:,
Action:, Status:
Worm detected: 8/23 (by Kaspersky AntVirus plugin or McAfee, perhaps not by
SpamAssassin)
Original message: headers only but mostly none if worm detected

exim
Machine: none
Original message: dangerous (complete with worm in the body of the message)

L-soft Listserv
Machine; none
Worm detected: no
Original message: none

Postfix
Expert user: weak (error message, occasional reply code, originalilar values)
59 messages contained no apparent identification although many of them showed

The software listed here is a mixture of traditional e-mail software, of
anti-virus software and of list servers.  Since all these sent bounce messages
to a forged "Return-path:", all are treated equally.

This analysis should not be taken as representative of bounce messages in
general, just of those that dominate e-mail traffic.  After all, the bounce
messages are themselves spam (in a general sense) and the best, or best
implemented, software would not generate them at all and so would not be present
in this analysis.

[8.12.8/8.12.8] (or similar numbers)
Software identity: taken from "Received: by", could be Version.Release.Level
From: informative (Mail Delivery Subsystem)
Subject: unhelpful (Returned Mail)
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: unhelpful, no statement of what this e-mail is
Advice: none
Expert user: comprehensive (reply code, enhanced status code, session
transcript, original message headers)
Machine: Reporting-MTA:, Received-From-MTA:, Arrival-Date:, Final-Recipient:,
Action: failed, Status:, Remote-MTA:, Diagnostic-Code:, Last-Attempt-Date:,
(X-Actual-Recipient)
Worm detected: mostly not
Original message: dangerous (as a message/rfc822 complete with worm)

Communigate Pro SMTP
Software identity: in body, with version.release.level
From: informative (MAILER-DAEMON)
Subject: informative ('Undeliverable mail' or 'Virus warning' plus original
subject)
Content Type: multipart/report message/delivery-status text/rfc822-headers
Body:-
Lay user: clear (but sometimes 'you sent ...')
Advice: none
Expert user: good (reply code, original message headers)
Machine: Reporting-MTA:, Original-Recipient:, Final-Recipient:,
Action:, Status:
Worm detected: 8/23 (by Kaspersky AntVirus plugin or McAfee, perhaps not by
SpamAssassin)
Original message: headers only but mostly none if worm detected

exim
Machine: none
Original message: dangerous (complete with worm in the body of the message)

L-soft Listserv
Machine; none
Worm detected: no
Original message: none

Postfix
Software identity: first line of body (mostly), no Version.Release.Level
From: informative (Mail Delivery System)
Subject: informative (Undelivered Mail)
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: ok ("I'm sorry to have to inform you ..." but then "your message could
not ..."
Advice: yes ("For further assistance..."
Expert user: weak (error message, occasional reply code, original message as
message/rfc822)
Machine: Reporting-MTA:, X-Postfix-Queue-ID:, X-Postfix-Sender:,
Arrival-Date:, Final-Recipient:, Action:, Status:, Diagnostic-Code:
Worm detected: mostly not
Original message: mostly dangerous (complete with worm as message/rfc822)

qmail-send
Expert user: variable (a few reply codes, a few enhanced status codes, error
Machine: none

Sun Java System Messaging Server
Software identity: taken from "Received: by" with Version.Release.Level and
build date
From: informative (Service de distribution du courrier)
Subject: informative (Notification de l'état de remise)
Content Type: multipart/report message/delivery-status text/rfc822-headers
Body:-
Lay user: clear ("Ce rapport fait référence à un message ...", "Le message ne
peut pas être remis..."
Advice: none
Expert user: excellent (message, reply code, enhanced status code, transport
quintuple, dns name, original message headers)
Machine: Reporting-MTA:, Original-recipient:, Final-recipient:, Action:,
Status:, Remote-MTA:, Diagnostic-code:
0r:- Reporting-MTA:, Original-recipient:, Final-recipient:, Action:, Status:
Worm detected: sometimes (by ClamAV)
Original message: headers

Symantec AntiVirus
Software identity: first line of body, no Version.Release.Level
From: unhelpful (often the "From:" of the original message)
Subject: unhelpful (the "Subject:" of the original message, "Mail System Error",
"Returned Mail")
Content Type: mostly multipart/mixed message/rfc822
Body:-
Lay user: unhelpful (talks about detecting a virus, omits any mention of e-mail)
Advice: none
Expert user: weak (truncated original message as message/rfc822)
Machine: none
Worm detected: yes (but calls it "Mydoom")
Original message: good (worm truncated else complete as message/rfc822)

v112 (or similar)
Software identity: from "Received: by" with Release number
From: informative (Mail Delivery System)
Subject: unhelpful ('Returned Mail' mostly)
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: unhelpful ("The original message ..." and "your e-mail is being
returned to you ..."
Advice: yes ("Please direct further questions ..."
Expert user: ok (error message, session transcript, original message headers but
look as if they have been edited)
Machine: Reporting-MTA:, Arrival-Date:, Final-Recipient:, Action:, Status:,
Remote-MTA:, Diagnostic-Code:, Last-Attempt-Date:
Worm detected: sometimes (5/16)
Original message: headers

As may be apparent, if these were in a heap I would place Communigate Pro SMTP
and Sun Java System Messaging Server on top.

---------------------------------------------------------------------
A further ten analyses in R2

blueyonder
Software identity: in body, no Version.Release.Level ('X-Mailer: Kaspersky')
From: ok ('antivirus')
Subject: ok ('antivirus notification')
Content Type: multipart/mixed message/rfc822
Body:- (uses base64)
Lay user: ok ('found a virus' + From:/To:/Sent:)
Advice: yes ('DO NOT REPLY ' + URL)
Expert user: none (apart from message/rfc822)
Machine: none
Worm detected: yes
Original message: ok (message/rfc822 with virus removed)

ClamAV
Software: from body but with [8.12.8/8.12.8] in "Received: by"
From: informative ('Mail Delivery Subsystem')
Subject: unhelpful ('Returned Mail')
Content Type: multipart/report message/delivery-status message/rfc822 or
text/rfc822-headers
Body:-
Lay user: weak ('The original message was received ' 'Virus Worm detected')
Advice: none
Expert user: comprehensive (reply code, enhanced status code, session transcript
+ sometimes (2/4) original message headers)
Machine: Reporting-MTA:, Received-From-MTA:, Arrival-Date:, Final-Recipi message as
message/rfc822)
Machine: Reporting-MTA:, X-Postfix-Queue-ID:, X-Postfix-Sender:,
Arrival-Date:, Final-Recipient:, Action:, Status:, Diagnostic-Code:
Worm detected: mostly not
Original message: mostly dangerous (complete with worm as message/rfc822)

qmail-send
Expert user: variable (a few reply codes, a few enhanced status codes, error
Machine: none

Sun Java System Messaging Server
Software identity: taken from "Received: by" with Version.Release.Level and
build date
From: informative (Service de distribution du courrier)
Subject: informative (Notification de l'état de remise)
Content Type: multipart/report message/delivery-status text/rfc822-headers
Body:-
Lay user: clear ("Ce rapport fait référence à un message ...", "Le message ne
peut pas être remis..."
Advice: none
Expert user: excellent (message, reply code, enhanced status code, transport
quintuple, dns name, original message headers)
Machine: Reporting-MTA:, Original-recipient:, Final-recipient:, Action:,
Status:, Remote-MTA:, Diagnostic-code:
0r:- Reporting-MTA:, Original-recipient:, Final-recipient:, Action:, Status:
Worm detected: sometimes (by ClamAV)
Original message: headers

Symantec AntiVirus
Software identity: first line of body, no Version.Release.Level
From: unhelpful (often the "From:" of the original message)
Subject: unhelpful (the "Subject:" of the original message, "Mail System Error",
"Returned Mail")
Content Type: mostly multipart/mixed message/rfc822
Body:-
Lay user: unhelpful (talks about detecting a virus, omits any mention of e-mail)
Advice: none
Expert user: weak (truncated original message as message/rfc822)
Machine: none
Worm detected: yes (but calls it "Mydoom")
Original message: good (worm truncated else complete as message/rfc822)

v112 (or similar)
Software identity: from "Received: by" with Release number
From: informative (Mail Delivery System)
Subject: unhelpful ('Returned Mail' mostly)
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: unhelpful ("The original message ..." and "your e-mail is being
returned to you ..."
Advice: yes ("Please direct further questions ..."
Expert user: ok (error message, session transcript, original message headers but
look as if they have been edited)
Machine: Reporting-MTA:, Arrival-Date:, Final-Recipient:, Action:, Status:,
Remote-MTA:, Diagnostic-Code:, Last-Attempt-Date:
Worm detected: sometimes (5/16)
Original message: headers

As may be apparent, if these were in a heap I would place Communigate Pro SMTP
and Sun Java System Messaging Server on top.

---------------------------------------------------------------------
A further ten analyses in R2

blueyonder
Software identity: in body, no Version.Release.Level ('X-Mailer: Kaspersky')
From: ok ('antivirus')
Subject: ok ('antivirus notification')
Content Type: multipart/mixed message/rfc822
Body:- (uses base64)
Lay user: ok ('found a virus' + From:/To:/Sent:)
Advice: yes ('DO NOT REPLY ' + URL)
Expert user: none (apart from message/rfc822)
Machine: none
Worm detected: yes
Original message: ok (message/rfc822 with virus removed)

ClamAV
Software: from body but with [8.12.8/8.12.8] in "Received: by"
From: informative ('Mail Delivery Subsystem')
Subject: unhelpful ('Returned Mail')
Content Type: multipart/report message/delivery-status message/rfc822 or
text/rfc822-headers
Body:-
Lay user: weak ('The original message was received ' 'Virus Worm detected')
Advice: none
Expert user: comprehensive (reply code, enhanced status code, session transcript
+ sometimes (2/4) original message headers)
Machine: Reporting-MTA:, Received-From-MTA:, Arrival-Date:, Final-Recipient:,
Action:, Status:, Remote-MTA:, Diagnostic-Code:
Last-Attempt-Date:
Worm detected: yes
Original message: sometimes dangerous (2/4 message/rfc822 complete with worm)

InterMail
Software identity: from "Received: by" with Version.Release.Level
From: informative ('Mail Administrator')
Subject: unhelpful ('Mail System Error - Returned Mail')
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: sparse ('This message was undeliverable ' but no message details, no
mention of worm detected)
Advice: yes ('Please contact ...')
Expert user: weak (original message as message/rfc822)
Machine: Reporting-MTA:, Arrival-Date:, Received-From-MTA:, Final-Recipient:,
Action:, Status:
Worm detected: sometimes (2/4)
Original message: complete as message/rfc822, worm replaced if detected

Internet Mail Server
Software; from X-Mailer in bounce message; nothing in body, no "Received: by"
lines in original message {strange}
From: ok ('System Administrator') would be better if mail is mentioned
Subject: informative ('Undeliverable' + original subject)
Content-Type: multipart/mixed message/rfc822
Body:
Lay user: ok (To:/Subject:/Sent: 'did not receive' but 'Your message' and no
mention of worm detected)
Advice: none
Expert user: none (apart from message/rfc822)
Machine: none
Worm detected: yes
Original message: odd (worm replaced with text but no "Received:" lines -
suppressed?)

MailEnable
Software identity: in body, no Version.Release.level
From: informative ('Delivery Subsystem')
Subject: informative ('Message Delivery Failure')
Content Type: none
Body:-
Lay user: ok ('message could not be delivered'
Advice: none
Expert user: weak (reply code, original message headers)
Machine: none
Worm detected: none
Original message: headers only as part of plain/text

Merak
Software: from "Received: by" with Version.Release.Level
From: informative ('Mail Delivery Subsystem')
Subject: ok ('Warning: antivirus system report'')
Content Type: multipart/report; report-type=virus-report message/rfc822
Body:-
Lay user: confusing ('Peligro: Virus has sido detectado' clear enough but then
runs straight into original message headers)
Advice: misleading ('Verifique su PC')
Expert user: weak; original message headers but not identified as such, virus
identified, 'this e-mail was sent by ...'
Machine: none
Worm detected: yes
Original message: misleading (message/rfc822 but headers only)

MOS
Software identity: taken from "Received: by" with Version.Release.Level
From: informative ('Mail Delivery Subsystem')
Subject: unhelpful ('Returned Mail')
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: unhelpful ('The original message ...')
Advice: none
Expert user: none apart from original headers as message/rfc822
Machine:Reporting-MTA:, Arrival-Date:, X-Message-Diagnostic-Code:,
Final-Recipient:, Action:, Status:, Remote-MTA: X-Unix;, Diagnostic-Code:,
Last-Attempt-Date:
Worm detected: none
Original message: message/rfc822 but headers only

Panda GateDefender Performa
Software identity: first line of body no Version.Release.Level; only three
messages having little in common apart from software identity
From: unhelpful (e-mail addresses)
Subject: variable (1/3 'Probable Spam', 1/3 Delivery Status Notification')
Content Type: multipart/mixed + (1/3) plain/text, (1/3) message/delivery-status
message/rfc822, (1/3) application/octet-stream
Body:-
Lay user: weak (2/3 'worm detected', no details of where)
Advice: none
Expert user: weak (1/3 session trace)
Machine:(1/3) Reporting-MTA:, Received-From-MTA:, Arrival-Date:,
Final-Recipient:, Action:, Status:, Diagnostic-Code:
Worm detected: yes
Original message: (1/3) worm curtailed, (1/3) message/rfc822 with worm removed

SMTPD32
Software identity: taken from "Received: by" with Version.Release
From: informative ('Mail Delivery Subsystem')
Subject: informative ('Undeliverable Mail')
Content Type: plain/text
Body:-
Lay user: ok (reason for non-delivery)
Advice: none
Expert user: original message only
Machine: none
Worm detected: sometimesent:,
Action:, Status:, Remote-MTA:, Diagnostic-Code:
Last-Attempt-Date:
Worm detected: yes
Original message: sometimes dangerous (2/4 message/rfc822 complete with worm)

InterMail
Software identity: from "Received: by" with Version.Release.Level
From: informative ('Mail Administrator')
Subject: unhelpful ('Mail System Error - Returned Mail')
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: sparse ('This message was undeliverable ' but no message details, no
mention of worm detected)
Advice: yes ('Please contact ...')
Expert user: weak (original message as message/rfc822)
Machine: Reporting-MTA:, Arrival-Date:, Received-From-MTA:, Final-Recipient:,
Action:, Status:
Worm detected: sometimes (2/4)
Original message: complete as message/rfc822, worm replaced if detected

Internet Mail Server
Software; from X-Mailer in bounce message; nothing in body, no "Received: by"
lines in original message {strange}
From: ok ('System Administrator') would be better if mail is mentioned
Subject: informative ('Undeliverable' + original subject)
Content-Type: multipart/mixed message/rfc822
Body:
Lay user: ok (To:/Subject:/Sent: 'did not receive' but 'Your message' and no
mention of worm detected)
Advice: none
Expert user: none (apart from message/rfc822)
Machine: none
Worm detected: yes
Original message: odd (worm replaced with text but no "Received:" lines -
suppressed?)

MailEnable
Software identity: in body, no Version.Release.level
From: informative ('Delivery Subsystem')
Subject: informative ('Message Delivery Failure')
Content Type: none
Body:-
Lay user: ok ('message could not be delivered'
Advice: none
Expert user: weak (reply code, original message headers)
Machine: none
Worm detected: none
Original message: headers only as part of plain/text

Merak
Software: from "Received: by" with Version.Release.Level
From: informative ('Mail Delivery Subsystem')
Subject: ok ('Warning: antivirus system report'')
Content Type: multipart/report; report-type=virus-report message/rfc822
Body:-
Lay user: confusing ('Peligro: Virus has sido detectado' clear enough but then
runs straight into original message headers)
Advice: misleading ('Verifique su PC')
Expert user: weak; original message headers but not identified as such, virus
identified, 'this e-mail was sent by ...'
Machine: none
Worm detected: yes
Original message: misleading (message/rfc822 but headers only)

MOS
Software identity: taken from "Received: by" with Version.Release.Level
From: informative ('Mail Delivery Subsystem')
Subject: unhelpful ('Returned Mail')
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: unhelpful ('The original message ...')
Advice: none
Expert user: none apart from original headers as message/rfc822
Machine:Reporting-MTA:, Arrival-Date:, X-Message-Diagnostic-Code:,
Final-Recipient:, Action:, Status:, Remote-MTA: X-Unix;, Diagnostic-Code:,
Last-Attempt-Date:
Worm detected: none
Original message: message/rfc822 but headers only

Panda GateDefender Performa
Software identity: first line of body no Version.Release.Level; only three
messages having little in common apart from software identity
From: unhelpful (e-mail addresses)
Subject: variable (1/3 'Probable Spam', 1/3 Delivery Status Notification')
Content Type: multipart/mixed + (1/3) plain/text, (1/3) message/delivery-status
message/rfc822, (1/3) application/octet-stream
Body:-
Lay user: weak (2/3 'worm detected', no details of where)
Advice: none
Expert user: weak (1/3 session trace)
Machine:(1/3) Reporting-MTA:, Received-From-MTA:, Arrival-Date:,
Final-Recipient:, Action:, Status:, Diagnostic-Code:
Worm detected: yes
Original message: (1/3) worm curtailed, (1/3) message/rfc822 with worm removed

SMTPD32
Software identity: taken from "Received: by" with Version.Release
From: informative ('Mail Delivery Subsystem')
Subject: informative ('Undeliverable Mail')
Content Type: plain/text
Body:-
Lay user: ok (reason for non-delivery)
Advice: none
Expert user: original message only
Machine: none
Worm detected: sometimes (1/3)
Original message: in body, curtailed at 3kb total

SMTPSVC
Software identity: taken from "Received: by" with Version.Release.Level
From: ok ('postmaster@')
Subject: informative ('Delivery Status Notification (Failure)')
Content Type: multipart/report message/delivery-status message/rfc822
Body:-
Lay user: ok ('Delivery Failed')
Advice: none
Expert user: original message as message/rfc822 only
Machine: Reporting-MTA:, Received-From-MTA:,Arrival-Date:, Final-Recipient:,
Action:, Status:
Worm detected: no
Original message: as message/rfc822 sometimes complete with worm

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 15 Dec 2006 14:05:47 +0100

Frank

Many thanks for your comments; some thoughts of mine inline.

Tom Petch

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 14, 2006 9:57 PM
Subject: [Asrg] Re: bounceone

> "Mail Administator" in addition to the postmaster@ address, is

Yes, my terminology is sloppy; I mean that there should be a display name and
not just an e-mail address and especially not the destination e-mail address of
the original e-mail (as some do)

> it ends up in an X-Envelope-To, but that (1/3)

SMTPSVC
Machine: Reporting-MTA:, Received-From-MTA:,Arrival-Date:, Final-Recipien=
t:,

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 15 Dec 2006 14:05:47 +0100

Frank

Tom Petch

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 14, 2006 9:57 PM
Subject: [Asrg] Re: bounceone

> use one of those funny catchall vanity host mailboxes.

Yes, in my message 'bouncetwo', the ones I classify as v112 all have an AOL
address in them and a X-AOL-... in the original message headers.  They have
text/rfc822-headers but the headers look as if they have been edited removing
the lines that would appear before the first 'Received:'; others do this too (eg
Internet Mail Server).

> SHOULD as near to a MUST as possible.
I am looking at this from the viewpoint of the lay user who gets a 'reply' to a
message that they never sent, so what I was trying to convey was that the
immediately visible part should make sense to the lay user - From, To, Date -
while what the professional needs - the complete header - can be in a different
part, as message/rfc822 or text/rfc822-headers.  Giving a lay user all the
'Received:' etc could increase the confusion.

> the spammer / worm author, more or less plausible.

This is the bit that intrigues me; I was expecting forged 'Received:' and I
don't see them; often there is but one 'Received:' which cannot then be forged
(?); in other cases, the additional 'Received:' tie in with the header of the
DSN and so look genuine to me.

> that's for 1200 + 8100 * 4/3 (B64).  IIRC Sober was quite small.
Ah, I was ignorant of that; I know an IETF mail list that has a 10kb limit and
was trusting them to have done their homework.
> that they needed more... :-)
Yes, I was trying to keep it simple and using sloppy terminology; complete
header plus n lines of body is a better approach.  There are a number of headers
I do not recognise eg 'X-Habeas-SWE-' which I take to be anti-spam traps.  Also,
I am proposing this as a good idea for all DSN, including genuine ones to
genuine mail which could have SPF and DKIM in them.  (I agree that SPF is
usually small).

> Microso's unreliable.  This

Yes, in my message 'bouncetwo', the ones I classify as v112 all have an AOL
address in them and a X-AOL-... in the original message headers.  They have
text/rfc822-headers but the headers look as if they have been edited removing
the lines that would appear before the first 'Received:'; others do this too (eg
Internet Mail Server).

> SHOULD as near to a MUST as possible.
I am looking at this from the viewpoint of the lay user who gets a 'reply' to a
message that they never sent, so what I was trying to convey was that the
immediately visible part should make sense to the lay user - From, To, Date -
while what the professional needs - the complete header - can be in a different
part, as message/rfc822 or text/rfc822-headers.  Giving a lay user all the
'Received:' etc could increase the confusion.

> the spammer / worm author, more or less plausible.

This is the bit that intrigues me; I was expecting forged 'Received:' and I
don't see them; often there is but one 'Received:' which cannot then be forged
(?); in other cases, the additional 'Received:' tie in with the header of the
DSN and so look genuine to me.

> that's for 1200 + 8100 * 4/3 (B64).  IIRC Sober was quite small.
Ah, I was ignorant of that; I know an IETF mail list that has a 10kb limit and
was trusting them to have done their homework.
> that they needed more... :-)
Yes, I was trying to keep it simple and using sloppy terminology; complete
header plus n lines of body is a better approach.  There are a number of headers
I do not recognise eg 'X-Habeas-SWE-' which I take to be anti-spam traps.  Also,
I am proposing this as a good idea for all DSN, including genuine ones to
genuine mail which could have SPF and DKIM in them.  (I agree that SPF is
usually small).

> Microsoft (or rather OE) terminology, they don't understand MIME,
Weeelll, there is one software provider whose UA products are in use by
ninety-something point something of the world's workstations, and they are the
ones at which the 'lay users' mostly sit; hence my descent into the language of
the 'hopeless cases'.  I do not see Content-Disposition used in the DSN at all
except where it is part of the original message (the worm is an attachment) so
what I am describing is what I am seeing, text/rfc822-headers displayed in the
body and message/rfc822 not.  Is there a default behaviour for
Content-Disposition described somewhere? (I don't see it in eg RFC3462).

ft (or rather OE) terminology, they don't understand MIME,
> it's a hopeless case.
Weeelll, there is one software provider whose UA products are in use by
ninety-something point something of the world's workstations, and they are the
ones at which the 'lay users' mostly sit; hence my descent into the language of
the 'hopeless cases'.  I do not see Content-Disposition used in the DSN at all
except where it is part of the original message (the worm is an attachment) so
what I am describing is what I am seeing, text/rfc822-headers displayed in the
body and message/rfc822 not.  Is there a default behaviour for
Content-Disposition described somewhere? (I don't see it in eg RFC3462).

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 15 Dec 2006 15:32:51 +0100

---- Original Message -----
From: "Daniel Feenberg" <[email-masked]>
To: "Frank Ellermann" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 14, 2006 11:50 PM
Subject: Re: [Asrg] Re: bounceone

> ambiguity, just a delay while the user figures it out (or gives up
I assume you are referring to something like

"The original message was received at Fri, 15 Dec 2006 15:53:51 +0900
from localhost [127.0.0.1]

   ----- The following addresses had permanent fatal errors -----
<[email-masked]>
    (reason: 553 5.3.0 <[email-masked]>... No such user here)"

which ties in with a similar use of 'localhost' in the "Received:" of the DSN's
headers.  I imagine that this is the way they have configured their MTAs and
yes, I find it unhelpful.

> all of them, which would be significant reduction in service and not at
I do see the message-id in the text/rfc822-headers, which a typical UA will
display in all its glory, and also in message/rfc822, which it will not.  I
haven't yet counted how many of my 400 bounces do use either format but most of
that data is in bouncetwo.

Tom Petch