Douglas Otis wrote:
> The response was specifically against the use of
> "authorization." With respect to SPF/Sender-ID or SSP,
> these are indeed email-address "authorization" schemes.
"Sender-ID" is in fact spf2.0 with two "scopes" also known
as "pra" and "mfrom". There's no actual draft for "mfrom",
we can only guess that it's either essentially the same as
v=spf1, or it's v=spf1 minus recommended HELO checks (maybe
back to optional HELO checks as in 2004).
But for the latter to make sense we'd need another missing
draft "spf2.0/helo". So let's asumme that "mfrom" would be
the same as v=spf1. PRA has several technical issues, let's
forget it for the moment - until somebody manages to modify
2476bis 8.1 and 2822 3.6.6 for PRA.
For SSP we have months to discuss all technical details in
the proposed DKIM WG, I can't judge it yet. Removing PRA
and SSP from the equation results in SPF PASS. That can be
a PASS for the "HELO-identity", and in that case you can of
course use it (like CSV) as a base for some MTA-reputation.
Or it's a PASS for a MAIL FROM coming from one of the MTAs
"permitted" to use it. If it's no "per-user sender policy",
built with the SPF %{l} macro (mnemonic "local part"), then
it's simply a domain based policy.
This is all very KISS, and of course you're free to use this
PASS result as it pleases you, combine it with white lists,
ignore it as irrelevant for your purposes, or extend the
white list concept to a more detailed "reputation" scheme.
There's no "burden shifting". If you have a PASS you know
that the Return-Path is no random garbage, you can bounce or
challenge without hitting innocent bystanders.
Of course it's the problem of the domain owner to get his
SPF policy right, Of course there's a risk of "cross-user
forgeries" if one of the permitted MTAs (or rather its MSAs)
don't implement 2476bis 6.1 or a similar solution. I hope
that the next draft-hutzler will address this issue, as it is
it could be reduced to two statements:
1 - implement 2476bis
2 - at least MDAs should reject all garbage
Point 1 is state of the art 2476 or seven years old, point 2
is also not exactly new, relevant for a few [censored] still
believing that 2821 is the SMTP bible. Do we really need a
separate BCP for these two points ? 2476bis is already a DS,
how dense are those folks ignoring it, and would they read
and understand a draft-hutzler BCP ?
Back to SPF PASS, I'm free to say "v=spf1 +all". If that
backfires with whatever you do it is my problem, it's not
your problem. A bogus SPF record is as bad as bogus MX
records, that's no "burden shifting", it's a fact of live.
It's trivial (but not cheap at about 1 US cent per minute)
to forge MAIL FROM @xyzzy coming from its permitted IPs.
But once again it's my problem if my ISP doesn't implement
2476bis 6.1 or a similar scheme. If you get spam with a
PASS from @xyzzy hold "me" accountable for it as you see
fit. If I'd want more security I'd know where to buy it.
And if I'm paranoid about it I could (in theory) publish
a policy with a NEUTRAL result instead of PASS for this
situation.
Over all SPF is fine, start to build something with PASS
(I'd prefer it if you stay away from C/R systems), or if
you don't like it ignore it.
So far I see no reason at all to replace SPF by one of the
other schemes, they are all less efficient, more expensive,
more restrictive, or technically flawed (pick at least two)
from _my_ POV. I'm sure that YMMV. I'm a KISS extremist:
821 worked, 1123 broke it, SPF fixed it, end of story. Bye
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf