ietf-822
[Top] [All Lists]

RE: Sieve

2002-06-04 10:58:39

A mailing list would rewrite the envelope-from address.  So vacation
notices sent to envelope-from wouldn't be seen by the person posting
to the mailing list, nor would the vacation notice appear as a
'post' on the mailing list itself.

Even if the reverse-path has been rewritten to reference an appropriate
mailbox, the owner of the mailing list is likely to be uninterested in the
sender's vacation plans. After enough of these, the owner may even
manually pause or remove the sender from the list, resulting in the same
effect.

Yep, which is why I stated below the best bet is only send vacation
when recipient is on to/CC, and send vacation to the envelope-from.

If the reverse-path has been misconfigured to reference an inappropriate
mailbox (eg, list-request(_at_)domain) then this might even happen
automatically. This is *designed* to happen automatically with mailing
lists that use VERP and similar proposals:

 |                                         The VERP extension implements
 | a way of automatically identifying undeliverable mail recipients,
 | even when non-delivery reports originate from mail systems that do
 | not implement delivery status notifications

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

Even outside the list world, there are scenarios where sending to the
reverse-path is inappropriate. EG, when the Sender/From construct is
actually used, the notification is returned to the Sender instead of the
From parties.

Sender/From is classically described for use with a secretary and an
executive:  the secretary would be Sender, the executive would be From.
In that case, I argue the executive isn't interested in NDNs (or 
vacation notices) and thus the return-path should be the sender.
This causes NDNs to be sent to the secretary.  Likewise, if 
vacation notices are sent to the return-path (as vacation works
on Unix), the vacation notices are sent to the secretary (Sender).

I believe you're arguing that the executive should see the NDNs and
should see the vacation messages for a Sender/From message?

I might be using a terminal or kiosk with a reverse-path referencing the
mobile account, but with From pointing to my master mailstore. I may not
see the notification messages for several months, if ever.

You won't see NDNs, either.

These examples are all really beside the ultimate point, however:
out-of-office notifications are an application of the messaging network
and not in-band management messages, so they really should use the headers
rather than the envelope.

What of NOTIFY=DELAY, then, and its default usage in many mailers,
including sendmail (which implements the behavior of NOTIFY=DELAY
by default).

-d


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