So I envision something like this: first, use v=spf1 to check the MAIL
FROM, then use spf2.0/pra to check the "i=" tag if present or the M$
PRA if not, then use DKIM to classify the signature verification
state. All that remains then is specifying a matrix of what to do
with all the results.
I probably better duck ...
Not at all, this is a good thing to discuss. You've presented a big picture
for mail validation, something that often gets lost. In the above you
validate MAIL FROM with spf-classic and validate a PRA (however you
determine it) with spf2. At that point, you've validated the domain that
sent the message and validated the PRA in the 2822 headers. What does
further validation of a DKIM signature add?
I tend to come at this from a different angle: what does failure of a
DKIM signature subtract?
Right now, the answer to that is usually "nothing", because as best I
can tell only one domain (cisco.com) is using a DKIM implementation
generating signatures using "l=" so they verify on mailing lists.
However, that's clearly only a near-term answer based on DKIM being
brand new.
I'm a big believer in double-checking, and the big picture I envision
is a time when virtually all mail is verified in multiple redundant
ways. SPF says it arrives in a legitimate envelope. PRA says the
communication is from whom it claims to be from. DKIM says the
communication arrived intact.
In this picture, a forwarder verifies all three on receipt and then
assumes responsibility by forwarding with a new envelope with a new
SRS or SES MAIL FROM and a new Sender: header. The forwarder also
re-signs the entire forwarded message with a new DKIM signature
(without removing any existing signatures).
Something like this is where we want to get to someday isn't it? If
not, why not?
A second minor question is can we rely on the sender's "i=" tag to identify
the PRA? Could that assertion be a lie, even if the DKIM signature
validates? I haven't thought this through (establishing the PRA is hard),
I'm just posing the question.
Well, the domain portion of the "i=" tag is required to be the same
as, or a subdomain of, the ("d=" tag) domain from which the DKIM key
is fetched. So your lie would be like someone making a phone call and
claiming to be at place A when Caller-ID puts them at place B. You
can't prevent such lies with technical solutions, but you can sure
make them harder to get away with.
I said in my earlier mail that the "i=" sounded to me a lot like a
PRA, but the draft warns about making any equivalence between it and
any header identity, citing a still-to-be-written reference. I agree
that establishing the PRA is hard, and my gut feeling is that being
the PRA ought to be something asserted by the sender rather than
inferred by the receiving end. The "i=" tag looks like a way for the
sender to do this. Calling it the PRA might not be appropriate.
Perhaps Asserted Responsible Address would be better.
--
Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com