On Tue, Jul 13, 2021 at 06:06:16PM -0400, post...@ptld.com wrote: > > A DKIM signature does not imply any expectation that > > all messages will have valid signatures. > > Why does DKIM signature exist if not to provide a way to know if an email > has been altered after someone sent it?
That's not what it is for. There are ways to detect alteration in transit, but DKIM is not one of them. If alteration occurred, and part of the alteration was the removal of the DKIM header, you wouldn't know that it had been altered. So it's no good for that purpose. According to RFC6376: "(DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message" According to https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail: "(DKIM) is an email authentication method designed to detect forged sender addresses in email (email spoofing" But that doesn't sound correct to me. The "sender address" and the "signing domain" are not necessarily the same thing. The "signing domain" is the value of the "d" tag in the DKIM header. The "sender address" is the envelope sender and/or the address in the From: header. Even if the From: header is covered by the signature (which it will be), that's just saying that the signing domain is taking responsibility for the From: header. The signing domain can lie about the From: header, and then sign that lie. I've seen it done in phishing emails. But I think you might have misinterpreted the intent of the statement above (or I might have misinterpreted it). Saying that "A DKIM signature does not imply any expectation that all messages will have valid signatures" (to me) means that just because an email from a domain has a valid DKIM signature, that does not mean that all emails from that domain will or should have a DKIM header. DKIM doesn't make that claim. It's only DMARC that enables the sending domain to make that claim. > Why can't someone expect a signature to be valid? I assume computers > are capable of creating a valid signature 100% of the time. One example would be when an email with a DKIM header is sent to a mailing list. The mailing list distributes that message to its members, possibly leaving the existing DKIM header in place, rather than removing it or replacing it with a new DKIM header of its own. The mailing list members would then receive a DKIM header that might contain an invalid signature (depending on which headers the mailing list alters). Auto-forwarding of emails from one email account to another could conceivably also break the DKIM signature (depending on what headers are covered by the signature). It definitely breaks SPF validation. But in general, not all mail servers have been configured to produce DKIM headers at all. Those that haven't are not (yet) capable of producing a valid DKIM signature. Assuming that every mail server on the planet be configured for DKIM is presumptuous. Anything involving private keys is complicated, especially looking after them properly (See NIST SP 800-57 Parts 1-3). It's an onerous undertaking. > > That's because DMARC (which I don't use or recommed) > > Why don't you recommend DMARC? What is wrong with it? Do you accept *ALL* > mail sent to you in your inbox spam or not? Other than SPF records and DMARC > what other tools exist to verify if mail came from the domain they purport > to? I'm not an expert, but one thing I don't like about DMARC is not DMARC's fault. It's the way that it is mis-used by some corporate mail providers. At work, we were having our outgoing emails treated as spam by one client's third-party mail provider just because we didn't have SPF or DMARC. I refuse to believe that that's a correct implementation of either. :-) > > DKIM does not convey any policy, and the correct default policy is > > to treat invalid signatures the same way as you would treat missing > > signatures. > > Yes, DKIM is a signature, and DMARC is the policy that says if the signature > is invalid you are allowed to p=reject that mail. Not quite. You (the recipient mail server administrator) are only allowed to p=reject that mail if the sender's DMARC policy says to do that. If it says to q=quarantine that mail, then you can't reject it. You have to add an indication that it should be quarantined and deliver it to the actual recipient. If the DMARC policy does not say to reject or quarantine it, or if there is no DMARC policy at all, then you just deliver it as usual. It's not the recipient mail server's administrator's decision to reject the email. It's the sending domain's mail administrator's decision. The recipient mail server's administrator can ignore that decision if they want, but ignoring it should mean just delivering the mail. Otherwise, you'll have to deal with user complaints about where there mail has gone. The point is that DKIM on its own, and therefore OpenDKIM, is not the correct place to be rejecting emails. That's OpenDMARC's job, because it consults the sender domain's policy. You might not agree with the relevant RFCs, but they say what they say, usually for very well thought out reasons, and implementations that don't do what they say will be considered broken by others. > But you're telling me at > no time are you allowed to reject a message for an invalid signature. Im > wondering if that is the case why does DKIM or DMARC exist? Maybe i read it > wrong but within DMARC policy isn't it allowed for mail servers to have > local policies that override the policy request of what to do with invalid > DKIM signatures? It's only DKIM that forbids rejection based on an invalid signature. It was written before DMARC. It's DMARC that deals with policy and rejection. In other words, software that implements DKIM should not reject mails, but software that implements DMARC can, if instructed to do so by the sender domain's policy. It might seem like a minor distinction but it's not. DKIM doesn't provide a mechanism for the sender domain to specify policy. DMARC does. Leave the policy to DMARC which was designed for it. Just because OpenDKIM provides a mechanism for the recipient mail server administrator to reject mails, that doesn't mean it's the right thing to do. It takes away choice from the sender domain and it takes away choice from the actual human recipient, and instead gives that choice to the recipient mail server administrator. That's a policy bottleneck that doesn't need to exist. I think the only good choices for the recipient mail administrator are to either follow the sender domain's DMARC policy and do what *they* instruct, or to ignore it and just deliver emails (presumably with extra headers added so the real recipients can decide what to do with it in their MUA). That removes the policy bottleneck. Ignoring any stated DMARC policy and then rejecting mails in OpenDKIM doesn't sound like a good idea. > > You can break your system if you wish. For the record, nobody else > > should follow your example. > > How is giving end users the choice, the control, over what happens with > their email "breaking" my system? Do you work for Apple? :) that was a joke. > But seriously how is that breaking things? Isn't that what sieve was created > for? I think you might be misidentifying who the "end users" are. I think the problem here is that OpenDKIM's users are recipient mail server administrators. Giving them the "choice" to reject emails based on DKIM signature failure takes away the choice of the users that really matter: the human recipients of the emails that are arriving at the mail server. Of course, the senders of those emails are also end users that matter. It's OpenDKIM's user's users that matter more than OpenDKIM's users. No offense meant to mail server administrators. :-) You're all amazing people and the world would fall apart without you! Apologies for the length and opinions and repetition above, but as the old saying goes: "The world is complex, and the mail configuration reflects that" And that was true long before SPF and DKIM and DMARC came along. :-) cheers, raf
