Wei Chuang wrote in <CAAFsWK2d96iWrpyK7CGT7FTkWQWD5R=ai8aki6rrn_9au22...@mail.gmail.com>: |DKIM2 is meant to support forwarding and DMARC from the start. One area
If you mean alias expansion, how do want to achieve this in a scenario where SPF is handled by a different program than the iterated DKIM? Btw i also said *no* for ACDC and the "safe hop" registry you envisioned, but gave links that might be of interest regarding the complexity of building such a database: | https://mailman.ripe.net/archives/list/[email protected]/thread/USQUMN\ | OE3L3UUD3JZVI6LH7VMDRPL7K4/ | |and they also created a draft | | https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-ta-tiebrea\ | ker These are way off-topic, except you mentioned PKI yourself, but they show how complicated it is to create and maintain such a database, and how, after a long time, surprising and profound problems are revealed. |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 Isn't that its main purpose? Initially i think it was, at least. (It now can also send mail.) |messages, and forwarders will likely also want a say in what happens to a |message that fails validation. Another area we should clarify is |application of DMARC policies to DKIM2 messages including those that are |forwarded. Lastly there is a set of proposed anti-abuse detection |mechanisms in DKIM2, and this suggests using DMARC to define how to enforce |as DMARC. This builds upon earlier discussions with Allen Robinson , |Richard Clayton and Bron Gondwona. | |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 How is a "forwarder" identified? What makes for the difference of a "forwarder"? I note that in DKOR (for which i cannot speak) and ACDC you have a secured path S->[1->2->...->]R. If R then expands an alias and forwards to actually RR ("real R"), then that changes the SMTP envelope. It is, effectively, "a new message". (However, DKOR carries the elder envelope around, and flag combinations of ACDC can deduce "only SMTP envelope changed (notes: ACDC O flag as in latest draft needs revisit "as is"; i note that 5863 and 6376 proclaim i= -- other than that ACDC had to be trusted as elder SMTP envelope no longer exists). Disclaimer: i asked about the legal status of making SMTP envelope data a permanent member of an 5322 message, but i have problems with a moderator. It must be said that today, with SPF as implemented, this cannot be done without a non-standardized extension, SRS (sender rewriting scheme iirc). How do you want to bypass this with DKIM2? Also, as above, if the SPF evaluation happens in a different program? I note that a VERP extension can be used to rewrite the SMTP envelope from, but the IMF From is a thing, with today's SPF. I also asked that the group should maybe talk about active mitigations done by the enhanced DKIM, but i have problems with a moderator. (Yet, how could it be done? This is likely impossible, i must give in to that. *Or* the way the IETF lists do it, but then DKIM would need a subdomain, or include some kind of SRS! That seems a bad idea..) Again, how do you want to do this in a real life software constellation, if you control only DKIM? |DMARC "p=" policy that's based on the origination "From" header. However |the forwarder can specify a distinct forwarder policy with the tag "fp=" |that uses the same policy values as "p=". This may be helpful when a |domain wants to specify a less strict forwarding policy than for those that |it originated. Upon DMARC DKIM2 validation failure, a receiver determines |which policies to apply. The receiver gathers the originator DMARC policy |and any forwarder policies. It applies the strictest policy found subject |to local policy. This also calls for DMARC reporting to be generated for |forwarders. By default the "rua=" and "ruf=" tags specify where the |forwarder reports may go. However forwarders may specify a different |location "frua=" and "fruf=" to distinguish forwarding traffic from |origination traffic in the reports. For ACDC: no. If the message fails at "RR", it comes back to "R". It is up to "R" to decide, maybe via a VERP rewritten address it recognizes it was a forward, or maybe it is different as it happened for alias expansion, and that software path is decades old. It likely then bounces back to "S". (This is what happens today.) |Application of DMARC Policies to DKIM2 messages ... (For ACDC DMARC is out of scope. Just as DMARC is out of scope for DKIM as of today.) |Forwarder DKIM2 Anti-abuse Mechanisms | |The header draft proposes two anti-abuse mechanisms: "m=" never |exploded in section |1 |<https://datatracker.ietf.org/doc/html/draft-gondwana-dkim2-header-00#na\ |me-the-dkim2-header> |and "nomodify" i.e. never modified policies in section 1.4 |<https://datatracker.ietf.org/doc/html/draft-gondwana-dkim2-header-00#na\ |me-registry-of-values-for-m> |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. Forwarders may wish to propagate the "m=" policy of the |originator to indicate support for the never explode policy. Expansion is |fairly localized in the mail handling stack, meaning feasible to implement. | Receivers can then check if there are duplicates and enforce if |duplicates are found. Enforcements SHOULD follow the sender's or |forwarders' DMARC policy subject to local policy as mentioned above. If such a feature is desired; but i cannot imagine this to really work out. If the company is "S"ender, and the "R"ecipient is something "that explodes", then SMTP will do that. For my approach thus: no. DKIM creates a cryptographic signature for an email message, now cryptographically verifiable up to the original sender (if you are lucky). It is not a 1984 vehicle, and does not introduce policy of any kind. "Do one thing, and do it well." The word "forwarder" is mysterious to me, too. A mailing-list is not a "forwarder", in my world. In real life software installations the SMTP/DKIM combination may not even recognize that the message comes from a mailing-list, if you call that "forwarder", instead of a normal user. |The never modify policy is potentially harder to implement, and the gain |smaller or non-existent IMO. The problem I see is that there are many |places in the mail handling stack that modify the message in large and |small ways such as re-encode the MIME part or adding a trace header which |is potentially problematic for normal delivery processing. I also don't |see how this helps senders as DKIM2 already provides strong mechanisms for |detecting tampering by forwarders. And milters like mimedefang or normal mailing-list "undesired part stripping" that you mention and i also mentioned in another message, but i have problems with a moderator, they exist, they are in use (even in a default mailman2 install i think), some MLs actively strip HTML from multipart/alternative, etc etc etc. I agree with you. No. Now that i possibly come back with at least one message to the mailing list, i want to revive one message that did not pass, edited a bit after time. I think it is beneficial to hear a voice, a voice with *very* high reputation, in "the real world", beyond the ivory tower of email specialists which have their head in the material all day long, possibly even via statistical approaches. Steffen Nurpmeso wrote in <20250429103100.IYpWgSdx@steffen%sdaoden.eu>: ... |[.]one example with *very* high reputation in |the Open Source aka Security-related software world. Just last |week, happily, i do not have to search: | | https://www.openwall.com/lists/oss-security/2025/04/24/9 | |says | | This was a special case - DKIM-breaking message body modification | shouldn't normally happen here. | | However, the list is indeed not DMARC-compatible: we insert | [oss-security] into the Subject when it's not already near the beginning | of that header (may break DKIM), and we relay messages from the list | server's IP address (may be against the From header domain's SPF, | although recipient servers may look at envelope-from instead, which we | do rewrite, so SPF will match in that respect). | | For now, this is simply how it is. Most delivery problems occur when | the sender's domain has strict DMARC policy ("p=reject"), so e.g. when | someone from google.com posts, the message doesn't get through to | subscribers on gmail.com. For gmail.com to gmail.com, everything is | usually "fine" for now. | | Yes, we may need to bite the bullet and add From header rewriting. | |(They use PGP encrypted messages in the private list variant.) |I think these people are traditional email users. Actually, i find this matches a hundred percent the introductional note of the DKIM v1 extension ACDC draft stating the very email situation "in the wild", and the very IETF responsibility for that, and therefore i replicate this to the list as such. The iteration of DKIM should, and that is my personal very and true opinion, try to improve the situation. And that can only mean that the infrastructure is "intercepted" where it is, and bolstered, until it, over time, iterates to something better. Ie, integration into DKIM that continues to work, but with enhanced handling for those "hops" which have been upgraded. I do not say that ACDC/EDKIM is the only possible approach to get there, it may not even be the right one, but that was at least one of its design ideas, whereas the DKIM2 approach says "the world has to change in its entirety, then i function properly" (which also nicely rhymes), and DKOR only addresses one fraction of the problem, and has several problems, as stated (reveals envelope or signature broken upon removal, single recipient). It would be interesting if there are any legal issues related with permanently revealing SMTP envelope data. (This could become an issue for already existing IETF standards, i think.) There is a reason why big companies start(ed) to create anonymized trace headers, i would presume. No words of legality i have ever heard on this list. The list should possibly talk about several things which would be necessary to "embrace" the current infrastructure. For example, should the iterated DKIM actively mitigate? Ie, should "From rewriting" be performed actively in order to ensure that *normal* DKIM software "gets the right DKIM signature" further down the line? And if so, how should that look and feel? Likely not, thus? But bitter that is! All that: regardless of a published DMARC strategy, of course (to not cause downstream consumers to generate totally useless "happy eyeball" traffic and/or DNS lookup delays and useless DKIM verification tries -- ie, do not consciously act anti-social and arrogant. Reduce necessary traffic if at all possible, cause existing infrastructure to succeed. And, lastly, a part of an also rejected message. I can only recommend reading at least the introduction of Papst Franziskus' Enzyklika "Laudato si", may his soul rest in paradise forever. He is much missed on Earth. This includes btw quotes back to what not (aside the "Club of Rome" i always cite), but in respect to the not very base SMTP parts of the IETF i can only refer to the cited german Pope Benedikt, who asks for removing the "structural disfunctioning". Turning SMTP into a single-recipient protocol is an exact manifestation of structural disfunctioning "that is unsuitable to guarantee respect for the environment". It would possibly make sense to enforce a setting of i=, in order to create "some UUID" that goes beyond RFC 5322 IMF From, as the RFC 5321 SMTP envelope, with EDKIM ACDC, is not recreatable, and is not part of any signature, if the message is bounced or otherwise needs to be linked/able at some later time. Certain large german email infrastructures, for example, always set i= -- even if the value is identical to From:! Ie, this is extensively described in RFC 6376 DKIM already, and provides "an upgrade path" as part of the DKIM signature. Thank you. And ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
