Michael Thomas has asked some questions which have stimulated my thinking about how to describe the big-picture questions here.
I suggest that too much attention has been focused on solving the “mailing list” problem, and too little on the “message receiver” problem. Forwarded email creates big problems for message receivers. First, lets begin with the obvious: malicious messages come from enterprises that are in the malicious message business. They rarely send just one message, and their content changes continually. Therefore, my priority is to block malicious sources. Messages that are correctly blocked on content, rather than source, are the canary-in-the-mine which warns me that my sender blocks need to be tightened. I currently use 5 identifiers to apply a reputation, and therefore a disposition, to a message source: Source IP, HELO name, ReverseDNS name, SMTP Address, and From Address. These identifiers are combined with the available verification methods: Forward-confirming the two DNS names to the source IP, SPF PASS, and DMARC-compliant. On any specific message, some of this information is not required to assign a reputation and disposition, but across a day’s messages, each of these identifiers and attributes are needed at some point. If a message is not forwarded, every organization involved in its delivery is assumed to have a relationship to the sender and therefore a shared responsibility for the final product. DMARC, SPF, and many spam filters assume that the adjacent MTA is the only source that needs to be evaluated. Forwarding introduces an intermediary organization which presumably operates on behalf of the recipient, rather than the sender. It is not involved in the creation of the message and has no economic relationship with most of the message sources. More importantly, because it will be forwarding messages from sources with a variety of reputations, the forwarder will be perceived as having a very unreliable reputation – sending both very much unwanted content and very much wanted content from the same or overlapping identifiers. SPF and DMARC force the forwarder to reliably identify itself, but in this process, they force the forwarder to hide information that the receiving MTA needs for proper message filtering. This aggravates any effort to filter based on original-source identity. Consequently, both the recipient MTA and the forwarding MTA need for the recipient MTA to evaluate a message based on the true source, the entity (or entities) prior to the forwarder. Unfortunately, we have no reliable way to know if a message has been forwarded, although some guessing strategies are available. Even when forwarding is presumed, reconstructing the 5-identifier / 4 verification dataset is nearly impossible due to data loss. Any attempt to evaluate prior sources requires evaluating the entire Received chain, and the supporting data, including ARC, which goes with it. ARC begins to give us a way to trust parts of the Received chain, and this moves us toward the possibility of evaluating the Received chain effectively. But it does not meet my needs, because it does not ensure that I can use any specific ARC Set to reconstruct the 5 identifier / 4 verifications dataset needed to evaluate the source correctly. Additionally, evaluating the Received chain is a huge increase in complexity, for both the code to implement an algorithm and the run-time processing needed to execute the algorithm. Processing power and coding sophistication keeps getting better, so perhaps the main problem is getting the data set right.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
