Let's not conflate "spaminess" with authentication (specifically DMARC and ARC) and forwarding. DMARC deals with direct domain abuse. ARC is an attempt to show an authenticated chain of handling outside of DMARC when DKIM and/or SPF is broken through forwarding. Consideration of "spaminess" is outside the scope of either DMARC or ARC.
A receiver may choose to use DMARC validation and/or ARC as an input into their spam filters, reputation or otherwise, but again, that is outside the scope of DMARC (or ARC) and should be a separate discussion/effort/RFC. My comments should not be taken as opposition to Wei's proposal, only to entangling it with discussions of "spaminess". If a forwarder (for example a maillist recipient) attempts to forward email to a nonexistent email address, that is well beyond the scope of DMARC or ARC. Michael Hammer On Sun, Mar 19, 2023 at 7:51 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
