Wei Chuang writes: > DKIM2 is meant to support forwarding and DMARC from the start. One area where > we haven't looked deeply is at the interaction between forwarding and DMARC > with DKIM2. We have been generally assuming that DKIM2 will expand passing > scenarios for cases where DKIM and SPF would fail hence fail DMARC. But DMARC > is also a way to express what senders think about failing messages, and > forwarders will likely also want a say in what happens to a message that fails > validation.
I think all this is bad idea. The recipient should do everything it does based in its own policies, whatever the sender wants or does not want does not matter. I think this is the main problem with DMARC, i.e., it tries to give policy instractions when all the policy processing should only happen on the receiving end. DMARC should have given only information whether DMARC is supported or no, i.e., whether mail did have valid DKIM when it left (and had passing SPF when it left) and nothing else. In DKIM2 case this is not needed as my understanding is that if mail starts with DKIM2, it should stay in DKIM2 fully through, and if it drops out from DKIM2, then all DKIM2 header stuff is completely useless without any value. So when mail is received by the recipient, the recipient will know whether it is DKIM2 validated or not, and does the policy decisions based on that and whathever the original sender said something about policy does not really matter. DKIM2 validation will just be one of the inputs to the local recipient policy that will decided what to do with email. Even if the email has valid DKIM2, but looks like spam it might end up in spam mailbox, and even if it does not validate with DKIM2, but does not look like spam or phishing attack at all, it can still be delivered to the final mailbox. > Forwarder Intent > > DKIM2 requires From header alignment at the origination of the message. It > also requires the forwarders in distinct SMTP ADministrative Management > Domains (ADMDs) to DKIM2 sign the message and the signing domain must be in > alignment with the previous signature's "rf=" address. This lets us say that > the forwarder domain identity is well identified in the DMARC sense, and may > be useful as an input to reputation systems. If DKIM2 signature validation > fails or the RCPT TO recipient check fails, we propose that the forwarder > domain be able to publish a policy that specifies the forwarder's intent on > what enforcement to apply. By default the receiver uses the same DMARC "p=" > policy that's based on the origination "From" header. If the DKIM2 signature validation fails there is no point of checking anything from the original source, as the original source cannot be validated properly. Note, that the original source DOES NOT KNOW whether the email will be going through the forwarding system that breaks DKIM/DKIM2 etc, so it can't give any meaning full policy for that situation. As I said the final recipient mailbox configuration usually do know whether it should assume that it will be forwarded by the broken forwarder in the middle, thus it can have specific rules to whitelist those broken situations, but only if the email actually reaches the final recipient, it can't do that if the email has been discarded along the route. > Forwarder DKIM2 Anti-abuse Mechanisms > > The header draft proposes two anti-abuse mechanisms: "m=" never exploded in > section 1 and "nomodify" i.e. never modified policies in section 1.4 that an > originator can express in the DKIM2 signature to forwarders to support and can > be enforced by receivers to help protect the mail against abuse. Many > commercial or transactional senders may wish to declare that their traffic > must not be duplicated i.e. "exploded" in mailing list expansion. Why should the sender have ability to deny me reading my emails is in multiple different addresses? There are lots of people who forward some of their emails to both "work" and "home" addresses, as they want to receive them quickly and depending where they are they might not be able to read one or the other of the mailboxes. Now what you are proposing would disallow that as if the sender suddenly has this "no duplication" restriction all those emails would fail completely and would not be received by either mailbox. For example I have set up a system in iki where my emails are forwarded to my final mailbox, but separate copy of them is sent to read only web-mail, that I can use when I need to quickly find some email without loggin in to my actual mailbox machine. Of course would would define those services to completely ignore that kind of policy, but I think it is better that no such feature is ever even added, as I only think such things will make harm and does not benefit the actual end user at all. If the end user who is setting up the forwarding does not want to expand some emails to multiple addresses, he can set up his forwarding in such way in the first place. It is not something sender should be able to dictate. -- [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
