Hector Santos writes: > > You would simply not use DKIM-Delegate if that's your policy. > > Again, the fault.
Please define "fault". Also "lookup". I doubt I'm the only one who doesn't understand what you mean by these words. > The policy is X, but Y is seen. The payload can be > DKIM-Delegate compliant but the actual policy is exclusive and doesn't > allow it. You're thinking about a case where one or more unprivileged users at the first party have been cracked, and mail that dkim-delegate authenticates is being sent through 3rd parties but shouldn't be? If there's no inside threat I don't see how this can happen (stolen keys are an inside threat, breaking the crypto is outside of scope). > signatures. You are probably right that DKIM-Delegate can't resolve > this, but what we want is for DMARC to have the language to say: > > "I'm ok with any trusted valid signer" Why? "Trusted" by whom? If it's verifier trust, no problem. They know who they trust. If it's Author Domain trust, use dkim-delegate t= and put the intersection of your whitelist and visible and invisible addressees in there (AFAICS this handles Bcc correctly, modulo concerns with revealing Bcc addresses -- but that is something for the originator to determine). Note that AFAICS this is not subject to the "mail-privileges-only user gets cracked" issue, as presumbly the whitelist is maintained by a privileged user. If it's not, this is effectively an "any signature will do" policy. > Overall, the problem is the DMARC verifiers are indeed enforcing the > strong policies. If you have a DKIM-Delegate to address only 3rd > party resigners, then you will need a matching backward compatible DNS > version of this. Not really. The unfortunate semantics of "p=reject" will in practice be worked around by refusing to respect it when respecting it is a socially destructive thing to do (eg, if the Author Domain is Yahoo! or AOL and there's "strong enough" evidence that the message is legitimate). That's a loss of face for DMARC, of course, but no more, since it's already practiced by at least one "billion message" class mailbox provider. I suspect Yahoo! and AOL would be willing to cooperate.[1] I agree that the various issues with *absence* of DKIM-Delegate and verifiers that don't implement DKIM-Delegate need to be considered, and we need to consider the implication of cracking users limited to mail-sending privilege as described above (in which case a policy lookup by DNS would give different information). However, we can, and perhaps should, "handle" this by saying "so don't let your users get cracked if you have a 1st-party-only or no-mail policy." Footnotes: [1] Note that even if a mailbox provider allows the users to populate the whitelist, and an abuser discovers a way to exploit this, the provider can shut them down very quickly by turning off -Delegate headers in their MTA. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
