ietf-822
[Top] [All Lists]

Re: Sieve

2002-06-04 12:28:57

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

<Prev in Thread] Current Thread [Next in Thread>