[dmarc-ietf] DMARC and ARC

[Douglas Foster <[e-mail]>]

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.