wayne wrote:
This I-D is part of the "Unified-SPF" group of I-Ds that
Meng et al talked about publishing several weeks back.
For some obscure reasons I always thought that "unified SPF"
is the same as "MARID SPF" (protocol-00 and core-02). I don't
count "submitter" because anything allowing bounces to a third
party is IMHO a perversion of classic SPF resp. RMX.
I didn't hear about the decision to delay until after I had
already submitted the Unified-SPF/From: draft.
No problem with that as long as I'm not supposed to grep the
I-D list to find new SPF / MARID drafts.
in fact, work has already progressed on the idea of checking
only the From: header and whitelisting exceptions.
2822 From: headers are not necessarily related to the original
RMX / SPF problem, i.e. useless bounces caused by billions of
forged MAIL FROM addresses. Classic SPF will solve my problem,
and I'm very reluctant to consider "better" solutions breaking
legacy software.
I think that Meng, Mark and I are all of the opinion that
existing SPF records can be used with the various Unified-SPF
checks.
From my POV that's not the case, one of my mail providers has
not implemented the "MSA MAY" RfC 2476 8.1. Sender-Id changes
this implicitly to a SHOULD or even a MUST. But maybe I can
convince you that the recipient could simply pretend that this
not yet existing MUST has been done ("default Sender:"), it's
less trouble than different spf1 vs. marid1 sender policies.
what Mark meant by it is that it doesn't change things like
RFC2822 or RFC2821.
Okay, but for Sender-id there's a problem with RfC 2476 8.1
the Unified-SPF/From: I-D requires you to whitelist mailing
lists that you have subscribed to.
Then it's probably a solution only relevant for MUAs, the MX
of a big ISP can't whitelist mailing lists for all users. (?)
IP not okay for xyzzy: SPF classic SPF/FROM-HDR
MAIL FROM:<user(_at_)MSA(_dot_)test> UNKNOWN (UNKNOWN in step 3)
2822 From:<valid(_at_)xyzzy> don't care FAIL (step 5)
[...]
I'm not sure what exactly the problem with this is.
That's the RfC 2476 8.1 "MAY", or rather its "maybe not". My
MUA prepares all outbound messages with From: nobody(_at_)xyzzy
Later I send it with via one of two smart hosts, that's either
MAIL FROM:<nobody(_at_)xyzzy> or MAIL FROM:<user(_at_)msa(_dot_)test>. There
is no matching Sender:, and it's "maybe not" inserted. If you
ask why I use msa.test:
Sometimes (depending on costs and the time of the day, or if
the primary MSA is blocked by a recipient) I cannot use "my"
primary MSA, and then I use the secondary MSA (msa.test). And
the secondary MSA isn't interested in Sender-Id / RfC 2476 8.1,
it "only" insists on a correct MAIL FROM:<user(_at_)MSA(_dot_)test>
If I understand things correctly, someone used MSA.test to
submit a message claiming to be from valid(_at_)xyzzy, but xyzzy
doesn't say that MSA.test is an ok source for such email.
That's it. xyzzy is only a vanity host with a wildcard sender
policy, and my primary ISP has no reason to change this, after
all I can use its MSA as long as I'm online with this ISP. If
I use another dialin ISP then that's my problem. OTOH the 2nd
MSA also has no compelling reason to implement RfC 2476 8.1: I
could add a matching Sender: manually (for Sender-Id).
But for SPF/FROM-HDR even a manually added Sender: won't work.
Okay, I could still modify From: into ReplyTo:, and then add a
new matching From: manually, but that's a very clumsy solution.
you would need to do both Unified-SPF/MAILFROM and either
Unified-SPF/PRA or Unified-SPF/From:.
This _and_ is very important. Maybe we should mention it in
SPF/PRA resp. SPF/FROM, these tests make no sense without a
prior SPF/MAILFROM test. The important thing is SPF/MAILFROM,
and at the moment we have no draft for SPF/MAILFROM (= the old
draft-mengwong-spf-01.txt minus all stuff now covered by MARID
protocol-00.txt).
What's the purpose of step 2 spf_test(To:,IP) ?
Whitelisting the To: address is something that SpamAssassin
does. It allows many emails sent through mail forwarders to
be whitelisted.
So far that's clear.
If I send email to <user(_at_)forwarder(_dot_)tld>, and it gets passed
onto <user(_at_)isp(_dot_)tld), the email will be coming from an IP
address associated with forwarder.tld.
That's also clear.
Since user(_at_)isp(_dot_)tld has been involved with the creation and
running of this forwarding relationship, they can easily
whitelist it.
ACK, now I got it, To: user(_at_)forwarder(_dot_)tld and the forwarding IP
should be matched by the sender policy of forwarder.tld, and
that's something the MUA of user(_at_)isp(_dot_)tld knows. But again a
case which won't work at the MX of isp.tld for big ISPs.
people really want to also protect the From: header.
More than 1000 useless bounces to "my" catch-all vanity domain
per day are a much more pressing problem for me.
I strongly suspect that Unified-SPF/From: can be made to
have a much lower error rate than PRA if there is a good
interface to the whitelisting in the MUA.
Maybe. But things are really confusing if the recipient either
tests this or tests that, and I as sender don't know how my
sender policy is interpreted today. I'd prefer a KISS solution
where sender policies only for SPF/MAILFROM are possible.
Bye, Frank