At 09:00 08/07/2009 Wednesday, Michael Deutschmann wrote:
On Tue, 7 Jul 2009, Scott Kitterman wrote:
On Mon, 6 Jul 2009 01:10:01 -0700 (PDT) Michael Deutschmann
But others may see SPF as valuable only as a backscatter preventer, and
presently not very effective because sane ISPs will not turn SPF on
globally.
They would love to use "fm=hard" to tell a receiver "go ahead and ignore
the
forwarder problem; I accept responsibility for the FP risk.".
This is what the current -all means (to a very close approximation). Why
would receivers believe this if they don't believe -all.
The problem is that there are basically two different versions of SPFv1,
which use identical syntax but have different semantics. (SenderID produced
another pair, but that's a whole other story....)
In Gathman-SPF, SPF is applied by default after a forwarder whitelist has
exempted part of the mailstream. No forwarder whitelist means no rejecting
solely due to SPF fail. In this protocol, almost everyone can use -all
senderside, but it is foolish for an mail admin who doesn't know his users
well (such as in large ISPs) to deploy receiverside SPF checking that does
more than header tagging.
In Vessely-SPF, SPF is to be applied literally, with SPF fail being binding.
In this protocol, only two groups are entitled to actually use -all
senderside: SES/BATV users with a magic DNS server referenced in exists, and
people who are desperate enough to stop backscatter that they will willingly
risk rejected forwards. But receiver admins are assured that they can and
should arm reject-on-fail for users they don't know much about.
V-SPF mostly gives inferior information. In V-SPF, softdeny is pointless,
and V-SPF neutral collapses together G-SPF neutral, softdeny and fail. But
V-SPF's fail maps to something that just doesn't exist in G-SPF.
i think this definition is pointless and misleading
All spf domains can have -all
{if and only if they control the outgoing mail-flow entirely or know all the
originating ip's that users will use}
if they do not they then use ? or ~ all
all receivers MUST whitelist non-SRS forwarders that their users are using as
in either scheme {above} the ip of their users external forwarders will not be
passed by either SPF
{SRS forwarders exist just to enable forwarding to not
require whitelisting}
if any receiver dosn't whitelist forwarders and rejects on -all, they will
loose legit user mail
{if and only if that user has a non-SRS forwarder}
thus a receiver choosing to not whitelist forwarders cannot use SPF to make any
determination about email, simple
if any receiver just blindly allows all mail from forwarders this too becomes a
point of injection for spoofed addresses {if forwarder not rejecting on spf
failure}
the intrinsic difference is if the spf record contains a bunch of ip's the mail
is valid from followed by -all it should be accepted if it came from a
forwarder {whitlisted} as it is likely it came to the forwarder via valid ip
{users problem if forwarder is not spf checking he should complain to forwarder
about spoofs incomming}
if the spf record contains no valid ip's followed by -all {ie v=spf1 -all} the
receiver should reject from anywhere including whitelisted forwarders as the
envelope-from is invalid from anywhere {regardless of whether spf publisher
uses SES/BATV or just static per-user spf or one record for the whole domain}
its really simple
same way mail from a whitelisted forwarder should only be considered exempt
from -all match,
if it is envelope-to the user that whitelisted that forwarder
{as mail from that forwarder to any other user is not part of the forwarding
setup and is thus just another spoof-attempt possibly by a provider that does
user-forwards and unsanitized-outgoing-mail on the same machine}
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com