ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Output summary

2011-04-27 23:17:20
a) If at least one signature verifies, report success with the d=
value(s) of the valid signature(s) and optionally other stuff.

I'm not comfortable with this statement. If I have two signatures, one
from the domain in the From and one from a random 3rd party and the From
domain signature fails and the 3rd party passes then we declare success
with the 3rd party d=signature? To me that dog won't hunt.

That is quite specifically what 4871 says.  To do anything different would 
be a major incompatible change.  We have explicitly rejected the idea that 
"first party" signatures are special in DKIM.  (They are in ADSP, but 
that's ADSP.)  Among the reasons we rejected the "first party" stuff is 
that it would make DKIM unable to work usefully with mailing lists like 
this one.

b) If nothing verified and nothing tempfailed, report no signatures.

c) If nothing verified and something tempfailed, return a hint to try
again later.

And what exactly might this hint be? (not being sarcastic, probably just
dense). How much later? How many retries? How likely is the verifier to
be willing or able to hold large queues to accommodate tempfails? If
not, is this a potential attack vector against the receiver?

Those are all reasonable questions, but I don't think this is a change 
from 4871, which suggests using SMTP 451 codes to force the sender to 
resend the message later, for whatever the sender's interpretation of 
later is.  Can't get much vaguer about retry strategy than that.

d) If at least one signature verified and at least one tempfailed, uh,
flip a coin and either report success or a try again hint.

Ugh, no way on d). For multiple signatures where one or more is a
tempfail, it should really be that each one gets its own output (signing
domain plus result) and leave it to the consumer of the output to
determine what to do. What happens if you have 3 signatures? It gets
messy real quick.

The current language in 4871 says in more than one place that you ignore 
signatures that don't verify.  It also contradicts itself by suggesting 
that you don't quite ignore a tempfail but somehow arrange to try again 
later.

If we require a verifier to report the details of signatures that don't 
verify, that strikes me as a significant incompatible change.

Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet 
for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>