Julian Mehnle writes:
I guess you're now going to claim that receiver MTA admins cannot easily
know their users' forwarding setups in the general case. I concede that
this may traditionally be the case, but I claim that there is no
fundamental obstacle keeping receiver MTA admins from communicating with
their users, either manually or through some technical mechanism with
which the users can easily configure their incoming forwardings to their
mailbox hoster. This is not rocket science.
I claim there is no fundamental obstacle keeping domain owners from
communicating with all their correspondents to determine what
forwarders need to be listed in their domains' SPF records. That is
not rocket science either.
What's more, for those of you who view SPF as something for the
protection of domain owners, this would put the burden of keeping mail
working in the face of an SPF impediment squarely where it belongs: on
those who benefit from the impediment.
I'm not entirely serious, of course - but then I also don't view SPF
as something domain owners do for themselves or that receiver MTA
admins bear the burden of accommodating.
I'm not entirely un-serious either. As a receiver I check SPF, and I
reject on -all. If that causes a problem with legitimate mail, I tell
both sender and (potential) recipient that I'm just doing what the
domain owner's policy says and that the sender needs to get the policy
fixed.
So far my users have proven far more tolerant of losing legitimate
mail coming from a source not allowed by the sending domain's policy
than they are of losing it because the source is on an anti-spam
blocklist.
--
Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com
Gatekeeper, NetHeaven, Saratoga Springs, NY
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com