>Question to the group: Does silent discard help? Or rather, do we have >any indication that noisy "p=reject" does or can hurt?
ADSP had silent discard. It avoided the problem of people bouncing off lists, but made the "where did my mail go" problem even worse. DMARC has p=quarantine. In discussions with people running large mail systems, they said they thought about it and decided it would not be an improvement. >One way or the other, the different approaches are trying to trick >legacy receivers into being unable to process the weaker signature. As >the cliche goes, we are merely haggling price. >The premise is that a version number change will be noticed by a legacy >DKIM engine. > >While of course it ought to be noticed, do we have evidence that it >reliably is? >The DKIM specification leaves it to the receive-side evaluator to decide >whether "enough" of a message was covered and whether the signature was >"sufficiently" strong. If engines are currently ignoring this issue, we >have a deeper problem, IMO, and should focus on fixing that, rather than >treating it as an acceptable given. ... I don't know anyone who's checked whether DKIM validators verify the version number, but if it's an issue, there aren't that many widely used DKIM engines so it wouldn't be hard to check. It seems to me it's a lot easier to verify a specific check for a version number than an ill defined acceptance of "too weak" signatures. It's also not clear to me that there is any reason for a verifier to care about the strength of a signature. If a signer wants to put weak signatures on mail and take the risk that his reputation will be sullied by heavily mutated messages, that's not the verifier's problem. (Note that this is not the same as what I'm proposing, a weak signature that is valid only if there is an additional signature from a second signer that I trust to put on a reasonable signature.) >Adding a requirement that one validation needs to be accompanied by a >particular other valid signature is just such an additional factor. I don't see it that way. In my version, at least, the second signature is part of what makes the signature valid, just like a body hash that matches the body or an expiration date that hasn't passed. It's not a matter of opinion, it's either there or not. >> With respect to Stephen's concern about libraries knowing when to >> construct v1 or v2 signatures, really, that's no big deal. We've been >> doing that sort of stuff for version bumps since approximately >> forever, and it's a nit compared to the other stuff it'll have to do >> to interpret the conditional signatures. > >Please point to details on the long history of successfully doing >version bumps in Internet protocols. I'm not aware of it. ssh seems to work OK with versions 1 and 2 both in use NFS moved from 4.0 (RFC 3530) to 4.1 (RFC 5661) >> It also occurs to me that there are all sorts of ways that a >> conditionally valid signature would be useful. For example: > >The signature is not "conditionally valid". The signature validates or >it doesn't. Binary choice. That a signature is what we are calling >weak does not make it more or less valid. By "conditionally valid" I mean more conditions the verifier uses to make the binary choice. Better wording always welcome. R's, John _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
