nobody at xyzzy
Nov 2, 2006, 10:18 AM
Post #1 of 1
(671 views)
Permalink
|
|
Re: Trouble with Sender Authentication
|
|
K.J. Petrie wrote:
> I hate to spoil a good party
The party was closed more than two years ago. You're a bit late... :-)
<http://en.wikipedia.org/wiki/MARID> This is a historic battle field.
> SPF, for instance, breaks forwarding.
The variant explained in RFC 1123 5.3.6(a) or RFC 2821 3.10.1 doesn't
work directly if it's checked "again", yes. Actually SPF works only
at the first MX of the receiver, and not (without tricks) behind it.
Working as designed (back in 2003, before this list existed).
> the forwarding company, over which the domain owner may have no
> control, must take action.
Nope, they can ignore it. The mail FAILs, they bounce it, and the
"sender can make other plans" (quote stolen from an unrelated draft).
A perfectly sound situation, if you grep for "551" in RFC 821.
> This could be fixed by adding a Recipient Protocol Framework (my
> name - apologies if something called this already exists)
Other names for ideas to arrange things on the side of the receiver
are SRS (sender rewriting system), and various "forward plans", the
next hop can white-list known "good" forwarders (saving the time for
pointless SPF checks resulting in predictable FAIL rejects). There
are many ways to solve this, some are mentioned in RFC 4408.
> However, this is only a minor flaw.
ACK, actually it's the design, SPF enumerates IPs allowed to send
mail from the domain in question. For obvious reasons it cannot
enumerate IPs somewhere on the side of the various receivers. One
of the predecessors was "RMX", like what we know as MX today (for
receivers), only "reverse", the IPs of the sender.
> What is published for the use of the good guys is also available
> to the baddies, and that's the real problem.
If a spammer comes to the conclusion that forging my address isn't
in the interest of his "business" it's no problem, it's good for me.
> Once the spammers have such a database it will be relatively
> simple for them to write software which spoofs credible domains
> for every spam injection point they use.
"Relatively". How ISPs arrange mail submission is a separate issue,
they should use SMTP AUTH and enforce submission rights. If I can
get a PASS, then I could still get it if I'm a zombie sending spam.
A PASS from unknown strangers has a very limited value, wrt SPF it
only means that a bounce won't hit innocent bystanders. If it's a
PASS from me and you know me I could still be a fresh zombie. But
you'd think twice if somebody claiming to be me with SPF PASS etc.
suddenly talks about phar*aceu*ical*.
For more serious PASS senders like PayPal I'd hope that they limit
the zombies sending from within their "borders". So far it works :-)
> Do we really imagine people who do that will be put off by the
> need to run a little more automated research?
No, it's okay if they just stay away from protected addresses. SPF
is about avoiding bogus bounces, and encouraging legit bounces, not
a magic wand to eliminatie all spam.
> I was directed to this list by the spf-discuss sign-up response.
Oops, that's wrong, I'll post my reply there too, let the old mxcomp
rest in peace, it's dead.
Frank
-------
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/?listname=spf-discuss[at]v2.listbox.com
|
