Thank you for your comments; see <inline>
Tom Petch
----- Original Message -----
From: "der Mouse" <mouse(_at_)Rodents(_dot_)Montreal(_dot_)QC(_dot_)CA>
To: <asrg(_at_)ietf(_dot_)org>
Sent: Friday, December 08, 2006 8:26 PM
Subject: Re: bounceone Re: [Asrg] DSN generation and handling
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.
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.
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
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.)
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?
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.)
Do you accept multipart/mixed as well as multipart/report? The former is not
strictly RFC3462 but seems quite widely used.
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.)
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:-)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(_at_)rodents(_dot_)montreal(_dot_)qc(_dot_)ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg