Well, about time I voted...
The reason I bothered registering is that I see one area where the SPF
effort could be guided better. This is the forwarding problem.
An attitude I'd like to see stopped is the position that since SRS patches
now exist for most MTAs, administrators should ignore the forwarding problem
and just enable receiverside SPF checking blindly. Such brinksmanship might
be the only way to drive significant SRS uptake, but I believe that will in
fact hurt us.
First, most recipients will "break" and demand receiverside SPF be turned
off before forwarders "break" and do SRS. Second, and most importantly, this
attitude will inspire some senders to unnecessarily (from our POV) use "?all"
in their senderside SPF to ensure that their mail will go through, even if it
passes first a non-SRS forwarder and then goes to an SPF "protected" mailbox.
Instead, I think we need to accept that, for now, receiverside SPF can only
be deployed by and for mail experts who can identify and whitelist all
traditional forwarders. This is a significant handicap, but it's not any
worse than DCC (which FPs on mailinglists), or the unnamed tactic of blocking
"Bcc:" messages (which is a very powerful last line of defense, but FPs on
both forwarders and mailinglists).
Moving forward, we need to work on a "TENBOX" type solution to make
forwarder-whitelisting (and thus receiverside SPF) accessible to nontechnical
users.
Any reaction from the candidates to this position?
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------
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