Dan Wing wrote:
Simplistic implementations of auto-unsubscribe will likewise have
issues with unable-to-send-for-8-hours informational messages, such
as are common with many sendmail configurations. I expect that any
auto-unsubscribe system will have to deal with those informational
messages (which are sent to the envelope-from).
To be clear, I'm not endorsing VERP. Having said that, the idea is to
catch notifications which are not DSNs. Status: Delayed can be trapped
easily. I would ass-u-me that implementors also look for WARNING: and
other magic strings appropriately. At that point the question would be
about the ~thresholds for any kind of auto-unsub action that might take
place.
If you parse the message enough to be sure that it is a nondelivery report
(whether a DSN or not) and treat it as such, I have no problem with that.
But it's foolish to treat unrecognized messages as if they were nondelivery
reports.
I would argue that Sender: secretary should receive the delivery failure
notification but From: PHB should receive the out-of-office notification.
You're assuming too much. Just because a message is sent by someone's
authority does NOT mean that they want to receive any kind of automatic
notifications. It would be perfectly reasonable for a CEO to send out
a message of the form:
From: CEO
Reply-to: customer-relations
Sender: secretary
Return-Path: bounce-address (set on delivery from MAIL FROM)
To: customers:;
From says who authorized sending of the message, or on whose behalf the
message is to be sent, but he/she has asked that replies go elsewhere.
Sender says who sent the message, but this is mostly to identify the
responsible party - responses should essentially never go there.
Essentially all automatic notifications should go to Return-Path.
Replies (made by humans, and based on the actual content of the message)
should go to Reply-To.
Now if the secretary wants to review the automatic response messages,
he/she can either arrange for the return-path to point to a mailbox
where the responses can be collected and reviewed, or he/she can
put his/her own address in return-path.
Delay DSNs are management messages, IMO. I would have argued against MDNs
using the envelope data though.
As far as I can tell, the best criteria for when to use Reply-To/From
instead of Return-Path are:
- if the message is a manual response, made by a human, based on the
content of the message and the kind of response that the sender of
that message anticipated, send the message to the Reply-To address.
other recipients of the subject message may be cc'ed if appropriate
but this should not be assumed.
(e.g. a reply to an invitation to a meeting or social function)
- if the message is a manual response, made by a human, based on the
content of the message but is a kind of response unlikely to have
been anticipated by the sender, the above rule does not apply.
the respondent must use his/her best judgement when deciding where
to send such responses, keeping in mind the intended purposes of
From, Sender, Reply-To, and Return-Path.
(e.g. a reply to an invitation where the purpose of the reply is to
discretely point out a faux pas on the part of the party who
issued that invitation. anticipated responses - such as acceptances
or regrets - should go to the reply-to address.)
- if the message is an automatic response, it should go to the
return-path address.
the above is a more of a statement about etiquette between humans
rather than about either user interface or protocol between computers.
to the extent that the user interfaces and mail protocols don't
support reasonable exchanges between humans, they need to be clarified
or changed.
Keith