Wietse Venema wrote:
My understanding is that DKIM-base can produce only two results:
signature verification succeeds or signature verification fails.
Where fails includes cases like no signature at all, yes. But we
have first party (0 or 1) signatures, and third party signatures
(0 or more), and valid signatures from unknown strangers are not
relevant for receivers.
expanding these two results into >2 involves information outside
DKIM-base.
Yes, we're in an SSP thread, that's info outside BASE. For some
mail claiming to be "from" paypal there are more than two cases:
It can have a valid Paypal signature (assuming you know paypal)
It can have a broken or no Paypal signature
It can have another signature from somebody you know
It can have another signature from somebody you don't know
Any valid signature you don't know can be from a bad actor
It can be resent / redistributed / digested with odd side-effects
for naive decision tables, and some of these cases are perfectly
legit mail uses. Most of these cases will be spam and fraud like
almost all mail, but the decision to treat it as spam can't be
based on the signature decision table without hurting the legit
mail uses.
Whatever paypal claims in their SSP, they can't tell legit users
that resend etc. isn't allowed for mail "from paypal". An SSP
declaring major parts of RFC 2822 as obsolete likely won't fly.
While I'm no fan of PRA for lots of reasons, it's IMO the best
we can do after we've decided to ignore the Return-Path (as it
is the case for DKIM, because it's bound to 2822, not to 2821).
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html