Stuart D. Gathman wrote on Thursday, March 15, 2007 8:54 PM -0600:
On Thu, 15 Mar 2007, Seth Goodman wrote:
One approach is to move beyond the idea that you reject on SPF fail
While large systems can fall back to IP blacklists, that is not
practical for a small system, and rejection on FAIL is essential.
I'm not suggesting reverting to IP blacklists. I'm exploring the
possibility of automating forwarder whitelisting, because as you
correctly point out:
A large system would of course not reject on fail for every user, as
I have said many times. In best practices, we recommend that large
system delay checking SPF until RCPT TO so that such policies can be
per user.
Since large systems are unlikely to whitelist forwarders per user,
and global forwarder whitelisting means too much additional spam,
the recommended best practice is not realistic for large systems.
Because of the prevalence of alias forwarding, SPF fail on MAIL
FROM can be viewed as the absence of a confirmed MAIL FROM
identity to assess for reputation. Other confirmed identities
for a sender may still have sufficient positive reputation to
accept mail from them.
The goal here is to reject *more* mail. There is too much as it is.
You suggestion might be appropriate for a large system for specific
users that haven't configured forwarders. Admittedly, probably most
of them - but at least power users get some real SPF fail rejection.
We obviously agree on the goal. Rejecting on SPF fail, except for
whitelisted forwarders on a per user basis, is certainly one way to
accomplish this. It's similar to other methods that are overly
aggressive and use whitelists to mitigate the damage: very effective
but not practical for large systems. It's impractical because
tracking user forwarding arrangements for large numbers of users is
burdensome and nobody wants to alienate users.
SPF could be much more than a technique for small systems with a few
power users. The argument that alias forwarding is broken and we'd be
better off without it has technical merit, but tying SPF to this turns
it into another superior technical concept that is never widely used.
Simply put, alias forwarding in its present form was an enormous
mistake, yet we are probably stuck with it as long we have SMTP.
Other fixes to the forwarding problem, like SRS at forwarders and SES
at senders, do solve their specific problems but don't give recipients
assurance that they won't reject their users forwards. A recipient-
side solution has a better chance of changing this situation. I
don't know if automated whitelisting of forwarders is even feasible,
but that's my motivation for exploring it.
--
Seth Goodman
-------
Sender Policy Framework: http://www.openspf.org/
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/?list_id=735