I believe this document provides a path forward for solving this problem, and it has relatively low complexity of implementation.
Doug Foster Current situation Incoming mail filters options when evaluating mailing list messages:Filter evaluates the message as if it is a direct message from the list domain This is the header munging solution that creates problems for the MUA. This can also be achieved if the sender uses SRS encoding of the RFC5321 MailFrom address, and the incoming filter does no evaluation of the “From” header address.Filter evaluates the message as if it is a direct message from the originator domain, ignoring the evidence that the message came from servers on the list domain, but accepting the message as long as it has a verifiable DKIM signature for the “From” header address. This is the situation when a DKIM-signed message is relayed without modification. Messages may be blocked by the incoming filter because the list members are viewed as unfamiliar and therefore untrusted senders.. An ideal filtering configuration should recognize that there are three potential mail flows, not two. In an ideal world, all three should be identifiable uniquely, since the recipient organization may wish to apply differential policies:Direct messages from the list domain.Direct messages from the originator domain.Forwarded messages from the originator domain through the list. As long as the mailing list applies signature-invalidating changes, Any option requires that the incoming filter chooses to given enhanced trust to the list domain. Specific aspects of that trust:The list performs no deception. Header records are relayed legitimately.The list inserts no malicious content.The list has reasonable controls on list enrollment.The list has reasonable controls to ensure that list submissions are really from the stated email address.The list applies its best effort to block content that the recipient systems would find objectionable.If objectionable content is detected, the fault should be attributed to the originator, not the list domain, so that list message from other originators will continue to be accepted. Once trust is granted to the list, SPF and DKIM checking of the originator becomes relaxed:SPF and DKIM checking can be computed using relayed header information, because the incoming filter trusts that the headers are not fraudulent, orSPF and DKIM checking can be omitted, because the incoming filter trusts the controls applied by the list. A few issues remain:How does the incoming filter prove that the message is really from the list, rather than someone spoofing the list? Since the RFC5321 M<ail+From address and theHow does the list know that the incoming filter will allow them to bypass From-header rewrite? Alternate Authentication I begin by assuming that the incoming mail filter is willing to grant preferred treatment to the mailing list, and that this trust is obtained by administrative processes external to this document. In the case of a new subscription to a mailing list, the list may send an enrollment notice to the subscriber, asking him to request preferred treatment from his email security team. Once that administrative grant has been obtained, the technical side can be configured to allow list authentication and originator authentication to be performed using alternate algorithms. I also assume that messages exchanged using an alternate authentication algorithm will preserve the originator value for RFC5321 MAILFROM and RFC5322 “From” header address. (No SRS encoding.) For lists, I propose that the list source be verified by applying the LIST-ID address to the SPF algorithm. For other types of forwarders, I propose that Postmaster@Helodomain be passed o the SPF algorithm. Checking for a verifiable DKIM signature which aligns with those addresses would be an additional option, or a cautious incoming filter might require both SPF and DKIM to verify. The configured requirements need not be standardized. I tentatively call this FWDRAUTH – alternate authentication of a forwarder. Once the forwarding tests have been passed, the incoming filter has a range of options for evaluating the originator:No checking – assume that the originator was adequately verified by the forwarding system’s controls.DKIM – For messages that were not altered during the forwarding process, a DKIM-verified signature can be matched to the From header address.Authentication Results Chain – accept ARC results provided by the forwarder, describing the tests performed by the forwarder when the message was received.Inferred SPF – Parse the received header chain to determine when the message entered the forwarding domain, and evaluate SPF based on the IP address of the server that submitted the message to the forwarder. Again, the choice of techniques is specific to the incoming filter, and need not be standardized. All that matters is that the incoming filter has the capability to evaluate the list and the originator using alternate authentication methods. Collectively, these alternate authentication algorithms allow the From address to match the originator without causing desired messages to be blocked. Forwarder Notification All of the above is useless unless the mailing list or other forwarder knows that a particular subscriber can evaluate messages using Alternate Authentication, so a signalling technique is needed, in the form of a DNS entry , within the recipient domain, that the forwarder can use to verify that the recipient domain has the ability to apply alternate authentication. My current thinking is that this would be as simple as txt=”FWDAUTH v-1”. It seems too complex and too risky for the receiving domain to publish the specific lists for which it is willing to apply alternate authentication. But if the forward detects the signal, it can invoke supporting administrative processes, including test messages, to determine if the alternate authentication method is successful. Changes required for implementation:At least some email recipient filters would need to implement the code for alternate authentication, then publish the DNS entry to indicate that it is available.MLMs would need to track which approach to use for each recipient: For recipients that can use the alternate authentication method, messages would be sent without header munging. For recipients that do not use the alternate authentication method, header munging would still be needed.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
