Jon Callas wrote:
If the sender says, "I'd rather you threw away a good message than
accept a bad one," then the receiver has a hint as to what to do
with it. Don't bother trying to process it, just junk it.
Unfortunately "first author" and "sender" are unrelated concepts.
DKIM can't pick the envelope sender because it's SMTP-agnostic.
After that decision PRA is the only existing algorithm to figure
out an entity that's likely the "sender", and PRA only picks the
2822-From address if there is no Resent-Sender, Resent-From, or
Sender. It's also the only logical interpretation of (2)822(upd)
after ignoring the envelope sender address for whatever reasons.
As a receiver, if I see a broken signature, do an SSP check
and if it says "sign all" I can now just throw the message
with the broken signature away.
Better don't, if the "first author" isn't the "sender". That's
a design flaw in SSP, let's give the Sender ID folks the credit
that they got *this* right.
While this addition (SSP check on every message) is certainly
a Good Thing, it means that we've gone back on our word to the
rest of the IETF.
The WG charter lists an early SSP draft as input, and that I-D
mentions a check of messages without valid originator signature.
I think it could be argued that that this violates the DKIM
charter, in spirit, if not in the letter.
I'd reject the appeal: It's kind of obvious that checking SSP
in the presence of a valid originator signature is a waste of
bandwidth. Of course receivers are free to check SSP *always*
if they want it as input for their decision to check DKIM.
the sender cannot mandate
Especially some "first author" can't pretend to be the "sender"
if he's not. But actually the I-D doesn't "mandate", it only
needs to trimmed. E.g. no "bounce suspicious mails" recipe :-(
I see here the makings of an exploitable architectural flaw.
Any redefinition of "originator" bypassing 2822upd cannot work,
it breaks the email architecture. A mail Resent-From: me is a
mail from me, I'm the sender, and if I find a MUA supporting
this Resent-feature that breaks a DKIM signature of the "first
author" in this mail then I'm still the sender, and the "first
author" got no SSP-veto right over my broken MUA. (That was a
theoretical example, actually I don't like the Resent-* feaure)
We need to seriously look at all policies other than the
original "sign everything" policy and discuss them thoroughly.
If SSP gets its definition of "originator" right, using the PRA
because nothing else will do (for DKIM). Admittedly I'm lost
what "all deny" could be, the three other cases "all process",
"strict process", and "strict deny" could make sense.
I'm not sure about "all process", is that like NEUTRAL, a kind
of "thank you" from the sender to the receiver for trying DKIM
and SSP, unfortunately in vain ?
I offer as a suggestion that we issue an SSP document that
describes only the basic broken-signature-only model of SSP
with only the one policy (sign-all).
IMO the basic model was and is "no valid originator signature".
If, as JohnL said, receivers decide to accept a mail based on
other indicators (trustwothy valid third party signature or
whatever they like) they'd have no reason to check SSP at all,
in other words SSP doesn't need to talk about these scenarios:
SSP is for those who wish to check it, after they found no
valid originator signature. Or before, if they wish to check
it always, or if they think "before" is faster because they
won't waste their time with DKIM if there's no "strict deny".
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html