-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Hannah
Schroeter
Sent: Monday, November 22, 2004 11:47 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Electronic Frontier Foundation (EFF) Article
On Anti-Spam Technologies Mentions SPF
Things should go on a more realistic route: Reality is there *are*
different forwarding setups, by far not all of them run SRS, perhaps
not even anything spf-related at all. If your goal reality is a sender
controlled level of 2821-mail-from authentication w/o false positives,
I'd rather suggest things like solve forwarding first, in whatever way,
*then* start publishing -all and rejecting spf fail. Not the other way
round, as it seems to be done, unfortunately.
Kind regards,
Hannah.
I think the burden is on the mail receiver to deal with forwarding. If you
or your user base receive mail that you (or your users) have had forwarded
to you, then you have to figure out how to deal with it.
SPF only breaks forwarding when the receiver of the forwarded message checks
SPF, so, for SPF to break forwarding, the receiving MTA has to have been
changed. It would seem to me, that the MTA administrator making this
change, ought to figure out how to deal with this before rejecting on -all.
In the major implementations, it's possible to whitelist forwarders. Since
it's the receiver that has established a trust relationship with the
forwarder, they need to implement that trust relationship when they set up
SPF checking.
Personally, I have a lot more trouble with what I would describe as
legitimate forgeries sent via a third party mailer. I have yet to get a
bounce due to a message of mine being forwarded. I spend a fair amount of
time working on the spf-help list. We see cases of this, but they are a
small fraction of what we deal with.
Scott Kitterman