Back on this thread after letting it rest for a bit...
On 02/13/2006 19:46, Frank Ellermann wrote:
Scott Kitterman wrote:
I think that productive work in this type of framework
is MUCH more important than a new SPF protocol version.
We can only do what folks actually _want_ to do, adding
any complexity to SPF as is might be difficult. I'm
interested in explaining things as they are.
True and better explaining we definitely need.
Apparently many folks not limited to the ASRG Chair have
serious difficulties to understand what 821 source routes
were, why 251-forwarding wasn't meant to be a lifetime
solution, that getting such forwarding right is trivial,
and why 1123 5.3.6(a) was always plain wrong wrt STD 10.
Perhaps, but I think you're tilting at windmills here. Let's lay out the
cookbook of different solutions and let people pick. If forwarding is more
important than fixing forgery in the long run, then we're working on the
wrong project here. This too shall pass.
So even if wannabe-anti-spammers obstruct SPF they still
have a broken SMTP system and no solution for this bug.
Yes. And nothing else on the horizon works for domain owners that down have
admin control over their MTA.
Any modifier would require modified processing, but has
to leave the basic SPF result undamaged.
Let's agree to disagree here. In my terminology it's the
purpose of a modifier to modify the SPF result. Normally
FAIL means 'reject', and if a modifier somehow results in
accepting FAILed mail, then that's no FAIL anymore in my
terminology. Maybe we mean the same thing.
I think we do. I say it's still a FAIL, but what you do with it might be
different based on the modifier.
One of the big disadvantages of this type of approach
is that it requires waiting until after DATA to reject
SPF FAIL messages.
Yes, but apparently that's okay for some MXs. Those who
don't like it won't enable the support for such modifiers.
[hypothetical op=from]
if Mail From domain != From domain, you look for both an
SPF record for the Mail From domain and the From domain
Oops, that's interesting. For MAIL FROM:<alice(_at_)a(_dot_)example>
you first check a.example. Without any dkim or similar
modifier (only op=from) reject FAIL as always before DATA.
Otherwise note op=from and get DATA.
If the 2822-From is "different" reject it here. Probably
we have to define "different" = different domain ignoring
the local part (alice@).
Now MAIL FROM:<bob(_at_)b(_dot_)example>, _no_ op=from for b.example,
mail somehow passes SPF, and the DATA offers a different
2822-From alice(_at_)a(_dot_)example(_dot_)
Now you propose to fetch the sender policy of a.example
only to see if there might be an op=from. That's rather
expensive. Maybe you can justify it with "only 12% (or
similar) of all mails have different 2821 / 2822-From-s".
And it cripples many normal 2822-caaes. Maybe Boh has
simply resent Alice's mail, and that's perfectly legal.
Maybe Bob is a mailing list <g>. Maybe Bob is a normal
SRS-forwarder on behalf of a final receiver for Alice's
mail.
IMO that's the same old problem again, anything trying
to outsmart PRA is doomed. PRA _is_ the best "working"
idea for 2822 wrt any "path registration" like SPF. Any
other proposal is invariantly worse than PRA, much worse.
Except for where it's better. The things the op=from would break are pretty
much the exact same things that DKIM breaks and big phishing targets are
allegedly begging for restrictive SSP to fight phishing. This is the poor
man's equivalent.
Mail From: bigbadbob(_at_)bogus(_dot_)example
....
Resent-Sender: bigbadbob(_at_)bogus(_dot_)example
From: account_activation(_at_)bigbank(_dot_)example
If bigbadbog publishes a technically correct SPF record, this will pass both
SPF and PRA (this is why we need reputation systems, but in the meantime) and
all the user will see on virtually any MUA is From:
account_activation(_at_)bigbank(_dot_)example(_dot_) They may also see
indications in the MUA
(if, for example, the MUA is Hotmail's web site) indications that it's passed
some kind of validation test. This is bad.
In the op=from case, if bigbank.example publishes an SPF record that has
op=from in it, you pull that record and find out that the message is outside
the scope of bigbank.example's sender policy. [Note, unless there's a macro
usage in there somewhere, and I haven't thought about it much, I'd suggest
ignoring the local part for op=from, so the secretary Sender example isn't
broken by this.] Now mailing lists, send-a-friend, and forwarding is all
broken by this, forwarding not being unique to op=from.
So, for a domain that is a phishing target, the breakage may well be a small
part to pay.
You cannot "fix" or improve it directly. PRA is the best,
but unfortunately not good enough. Okay, one theoretical
fix was "assume Sender = MAIL FROM if there is no Sender,
no Resent-*, and the 2822-From is different". But that
idea died with MARID - and as far as I'm concerned that
precise issue ultimately resulted in the IAB appeal. :-(
It's not always obvious, but from the PRA enemies I'm one
who thinks that it's only a near miss. Very near, almost
no room to improve it, some necessary 2822 and 2476bis 8.1
tweaks to address William's appeal not withstanding.
An op=from telling me that I can't resend your mail can't
fly, it's fundamentally against common email practice.
Even the most desperate phishing victim can't pull that
stunt, above all he wants to be able to send legit mails,
surviving completely sound scenarios like SRS before SPF.
Is there enough SRS in the wild today to make the big bank phishing target
really care?
Cases where the "DKIM invalid" and "DKIM missing"
outcomes are different would be critical. What about
the eleven "?" cases ?
DKIM missing and invalid must be treated the same in
all cases, and so those can be combined.
That's why I said "critical". But the complete table was
nonsense, there never will be anything like op=from, it's
FUBAR. Sorry for the waste of time. Simplified table:
FUBAR for general use yse, but there is, I think, a class of domain that would
think the gain was worth the breakage.
v=spf1 DKIM: valid invalid or missing
dkim=weak dkim=strong
PASS accept accept reject
n/a accept accept reject
FAIL accept reject reject
No question marks left. And it's also clearly pointless
to evaluate SPF for some kind of dkim=strong / op=strong
Obviously dkim=strong means "all 'my' mails as defined by
the MAIL FROM are signed by 'me' (i.e. ignore 3rd parties)".
For dkim=weak there might be a simple attack: The spammer
uses your MAIL FROM and adds his own valid DKIM signature.
How's that supposed to work ? Signing domain must match
MAIL FROM domain ? Or additionally the 2822-From domain ?
It would be the 2822-From domain to match up with the way SSP is supposed to
work.
Your idea could be a new op=nomail (if you're checking
MAIL FROM exit with FAIL).
Yes. I'd say op=nomailfrom, but yes.
Okay, op=nomailfrom. Still pointless, it's covered by a
normal HELO-only "v=spf1 a -all" (or similar) policy.
We should definitely not add useless modifiers / options
to SPF. Unless it's merely for educational purposes as a
known discussed idea, and why nobody really needs it.
Agreed. It was more of an example than something one would actually go off
and do.
One problem of the op-draft, so far no implementor was so
delighted by one of these modifiers / options that (s)he
made noises about actually implementing it. From an IETF
POV anything that's not implemented is dead.
Sure. I think the DKIM modifier is the best one and DKIM isn't far enough
along to really understand what it should do. We need to think this one
through in parallel.
The op-draft saying "do not implement this" is of course
not exactly helpful, but removing that statement would be
simple as soon as somebody actually wants to implement a
part of it. Sanity check... no, your validator claims
that "v=spf1 op=helo,nohelo" (with a comma) is "valid",
in other words it doesn't validate the op= as specified.
What result did you expect? The validator is a good little v=spf1 engine and
properly ignores modifiers it doesn't understand.
the naive idea of a modifier, it modifies the SPF result,
op=nohelo means "FAIL for HELO no matter what".
I disagree. It either changes what the receiver should
do about the SPF result or either eliminates the need to
check for the SPF result, but PASS is still PASS and FAIL
is still FAIL.
See above, maybe we mean the same thing from different POVs.
Yes.
I'd say "op=nohelo" found in a HELO check means "do whatever
you normally do for FAIL, and that SHOULD be 'reject'". You
say "a PASS is still a PASS for this HELO" (and in fact that
is the case for all SPF implementations _not_ supporting the
new op=nohelo). But finally we both want that this HELO is
rejected by implementations supporting op=nohelo. I'd even
say that it's a waste of time to determine the "unmodified"
result, op=nohelo in HELO tests shoukd be a fast showstopper.
Yes.
Currently deployed programs can continue on just fine.
Currently deployed records can continue on just fine.
Of course. That's something like an axiom in the op-draft,
you can ignore any new modifier / option. But if you wish
to support them they can modify results, as the name says.
Or modify what you do about the results.
Something like exp=an.example or op=auth that doesn't modify
the evaluation is an exception. And actually op=auth also
"modifies" results, it says that a PASS is your new HARDPASS
with some possible consequences for reputation services.
I think that's another one to spend some time thinking on.
Scott K
-------
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(_dot_)listbox(_dot_)com