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.
By the same token, if you annoy the list owner, where is their threshold?
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 would argue that Sender: secretary should receive the delivery failure
notification but From: PHB should receive the out-of-office notification.
In the scenario above, the secretary is tasked with getting the message to
the recipient, and dealing with addressing and/or delivery errors is part
of that task. On the other hand, an o-o-f notification is essentially an
acknowledgment that delivery succeeded, which is interesting to the task
but not particularly relevant.
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.
Yeah, good point.
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).
Delay DSNs are management messages, IMO. I would have argued against MDNs
using the envelope data though.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/