David MacQuigg wrote:
At 06:09 AM 2/6/2008 -0800, Michael Deutschmann wrote:
The only way to avoid backscatter [...]
Excellent! This is good text for a BCP, if we decide to write one.
Agreed. Except for SPF-specific parts, it strongly resembles the way MTAs
currently suppress backscatter. See e.g. the paragraph for *courier show
all* in http://www.courier-mta.org/courier.html
We might be able to reduce the burden of this procedure on Forwarders,
if we "redistribute" some of the responsibilities to other Agents, in
particular the Recipient. If the Recipient is required, when he sets
up a Forwarder, to provide a reliable alternate path for communications
(e.g. another email address, a postal address, or a phone number), then
the Forwarder can contact him to let him know there was a problem at
his MDA.
I agree. However, a generalized statement should mention a "person in
charge", e.g. a user who can login at the Forwarder and write the relevant
forwarding recipe. That is possibly the same person as the Recipient, but
not necessarily. The person in charge is authorized by the admin, referred
to as the "data controller" in privacy parlance. The latter is yet another
alternative contact.
If the alternate path fails, or the Recipient simply abandons his
responsibility, then discarding the dead message after 30 days is
appropriate.
However, in case the recipient mailbox has been deleted, after the message
has been discarded new deadletters will be accepted again. Compare that
to mailing list managers featuring automatic removal of dead addresses.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=94778097-cc7d45
Powered by Listbox: http://www.listbox.com