Let's not gloss over the interaction between spaminess, forwarding, and authentication.
A forwarded mail stream will almost always be viewed as spammy, if any spam exists in the source mail stream. This is because: - The downstream evaluator will give the forwarder no credit for spam which is never forwarded and therefore never seen. - The evaluator will give the forwarder demerits for messages which the forwarder considered acceptable but the downstream evaluator rejected. - Finally, the forwarder will be blamed by the downstream recipient if wanted messages are blocked incorrectly as suspected spam. This creates an incentive for the evaluator to error on the side of weak filtering. The problem becomes worse if the forwarder agrees to forward to a recipient address that does not exist or a recipient that does not want the forward. I am surprised that current practice does not require forwarding approval, from the proposed recipient, before forwarding begins. For forwarded mail, the evaluator wants to make a reputation assessment on both the forwarding source that is submitting the message, and the originator of the message. Without ARC, detecting a forwarded message is fairly tricky, and the algorithm for doing so has never been put into an RFC. ARC allows forwarding to be better documented, which is valuable if the ARC data is actually provided and if it can be trusted. My initial assessment of Wei's DARA proposal is that it helps to assess whether the ARC data is sufficiently complete, which is an important step toward making it trusted. Replay prevention is, of course, desirable as well. Doug Foster >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
