Dan Field wrote:
Doesn't guarantee that the message is from the actual sender
when a shared MTA is used (Which is the case most of the time
for most Small/Medium sized business I would of thought?)
True. Addressed by RfC 2476 6.1 "enforced submission rights"
and related ideas like draft-hutzler-spamops op op=auth.
At the moment assume that PASS is "hard enough" from your POV
as a receiver. If PASS is "too hard" from your POV as sender
use Scott's idea, replace + (PASS) by ? (NEUTRAL).
- Doesn't always guarantee the address is correct...
ACK, but a PASS does guarantee that bounces / challenges / or
other auto-replies won't hit (spoofed) innocent bystanders.
Not against their explicit will published as sender policy.
Of course if sombody uses "v=spf1 +all" he has exactly the
same problems as without SPF, but then he wanted it. SPF
is very flexible... ;-)
Can Phising attacks can gain a pass by publishing SPF for
their domain, but use different headers which will then be
displayed in a standard e-mail client such as outlook.
Yes. SPF does not check 2822 mail header fields. Spammers
are free to use a Return-Path: <always(_dot_)spf(_at_)pass(_dot_)example> if
they control the DNS records of the domain pass.example.
SPF PASS from unknown strangers is dubious, like "trust me".
I suppose this is a benefit in that it is easier to blacklist
said spammer.
Dubious, hardcore spammers change spamvertized domains for
each spam run, they can as well use new pass.example domains
n the Return-Path.
PASS is more interesting in conjucntion with white lists. Or
reputation (for a HELO PASS). On its own it's all you get by
a PASS is a "permission" to bounce / auto-reply (= RfC 3834).
- Forwarding caused problems unless SRS or some other
re-writing is employed?
Or if the next hop white listed the forwarder. There are a
lot of ways to solve it. If you do nothing the worst case is
a good bounce to the real sender.
Okay, there's one worse case, the next hop accepts the SPF FAIL
(it shouldn't), marks it as "suspicious", and then the end user
happily deletes it together with the other crap.
OTOH it was this end user who arranged the forwarding that way,
he'll see his error very soon and filter "suspicious" mails
more reliably.
We're talking about a special case, the admin of the forwarder
insists on doing nothing, and the admin of the next hop refuses
to white list the forwarder _and_ does not reject SPF FAIL, but
tags it. In that case a clueless end user has a nice chance to
shoot into his own foot.
concerns about how sucessful it can be in that area.
If you get an SPF FAIL for any @xyzzy address please _reject_
If you want more value greylist the sending IP until it shows
up on your ordinary DNSBLs: once a liar, always a liar, Bye
-------
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