There are some basic principles that need to be considered:. DMARC did not break mailing list privileges, unwanted mail did.
A fully legitimate message has these characteristics: Intended by the originatorAcceptable to the policies of the domain owner, which are partially implemented in its outbound mail filterDesired by the recipientAcceptable to the recipient domain owner, as partially implemented in its inbound mail filter. One example of a message that is not acceptable to the originator is a message spoofed by an authorized server. This is one of the problems addressed by DMARC. More specifically, what characteristics make a message acceptable to the recipient: A recognized / trusted senderA message which looks like previous-good messagesA message with no identifiable risk factors. To elaborate, incoming mail filters separate mail into three buckets: Probably unwantedUnknown and hopefully harmlessDefinitely wanted The administrators of the incoming mail filter will be continually seeking to move traffic from bucket 2 to bucket 1 or bucket 3, so a strategy based on bucket 2 is not guaranteed to work indefinitely. >From the viewpoint of the inbound mail filter, forwarded mail is >indistinguishable from spoofed mail using an open relay. In a world where >all mail was wanted mail, mailing lists could do what they want. But we are >not on Arpanet anymore, and unwanted mail is a huge problem. If a mailing list is violating DMARC, it is likely to be put in bucket 1. Once one message ends up in bucket 1, all messages from that source are likely to be blocked as well. For a sender to be promoted from bucket 1 to bucket 2, messages need to distinguish themselves from untrusted email. Preserving DKIM signatures is one way of doing so. Header munging is another way of doing so. To move into bucket 3, the forwarder needs to obtain a sponsor to negotiate with the recipient organization's email security team.. For two messages from the same forwarder to land in the same bucket, both messages must have similar qualifying characteristics. An Example Consider the risk profile of a request to auto-forward from UserA@DomainA to UserB@DomainB This request could reflect a range of behaviors from low risk to high risk. UserB actually wants the forward to occur.UserB is the accidental victim of a typing error.UserA is going to be used as a proxy to attack UserB.Forwarding to UserB is contrary to DomainA policy because it is likely to permit violation of DomainA's regulatory obligations under GDPR, PCI DSS, HIPPA, Sarbanes-Oxley or something else.Forwarding to UserB is in conflict with DomainB policy for whatever reason.UserA is an inside attacker seeking to exfiltrate data to an external accomplice. So both DomainA and DomainB administration have reasons to be involved in this request. Even for legitimate requests, DomainA does not want to forward traffic to DomainB if it is unwanted, since unwanted mail may impact the reputation of DomainA, and likely cause unwanted blacklisting of other messages. Therefore, the wisest procedure is as follows: DomainA detects the forward request and begins an approval workflow.DomainA reviews the request to see if they are willing to grant internal approval.Postmaster@DiomainA contacts UsersB@DomainB asking them to submit the request to their email security team for approval.Administrators for DomainA and DomainB communicate to discuss the administrative controls at DomainA as well as the fingerprint characteristics of the incoming mail.Upon approval, DomainB administration gives DomainA administration permission to proceed. DomainA activates the forwarding and notifies the user.DomainA monitors the outbound mailstream for deliverability and terminates the forwarding if repeated failures occur, or upon request from DomainB administration or UserB@DomainB. I suspect most mailing systems would need a lot of new code to implement a workflow like this, but my perspective is limited and may be wrong. The mailing list scenario is not much different, except that the request process begins when UserB@DomainB attempts to subscribe to the mailing list, and the approval process involves both the handling of messages coming from the list as well as messages going to the list. The process may be limited by the features of the DomainB email filter. Without header munging, fingerprinting the mailing list will require combining the list headers with forward confirmed host names, or something along those lines. Low-end email filters may be unable to filter on list name, or filter on multiple attributes together. Getting prior approval will be a lot of work, and i wonder how many lists will be willing to try. In the absence of prior approval, I see no solution better than header munging. Header munging is an inferior solution because neither sender policies nor receiver policies are evaluated or respected, but it is the path of least resistance.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
