Tero, your forwarding scenario does not apply in the general case. When UserA@domainA intends to auto-forward to UserB@DomainB, there are three concerns to consider:
1. Is the proposed forward consistent with the administrative policy of DomainA, or will it cause unacceptable leakage of information? 2. If DomainA allows any forwarding, Is this particular recipient acceptable? 3. Is the intended recipient entered correctly, so that the intended recipient is the actual recipient? 4. Does the intended recipient want the forward? An auto-forward can easily be used as a tool for anonymously assaulting an intended victim. For all of these reasons, auto-forwarding should always be arbitrated by domain administrators, even though most mailing list software products allow a user to configure forwarding without any oversight or safety checks. The scenario for mailing lists is not much different. It may easy for evaluating software to assume that a mailing list recipient is an intentional subscriber, but this is not always the case. The list server may simply be acting as a distribution list for unwilling recipients. But on your other point, if an email filter ever uses sender authentication results to block messages, it needs an override mechanism for the many situations where a wanted message is caught by authentication failure. My workflow looks like this: - detect the authentication problem - confirm that the mail stream is wanted - configure an override to the authentication failure. If the mail stream is unwanted, ARC does not matter. If it is wanted, ARC provides an alternative to exemption from authentication checks. The ability to configure overrides is a prerequisite to ARC. Doug On Fri, Feb 28, 2025 at 3:04 PM Tero Kivinen <[email protected]> wrote: > Alessandro Vesely writes: > > On Fri 28/Feb/2025 14:27:25 +0100 Douglas Foster wrote: > > > The issue of ARC trust is irrelevant to the topic that Ale has > > > raised. ARC is useful for an evaluator to detect forwarding, but > > > it is useless for the problem of "From munging" that has consumed > > > so much time in this WG. > > > > By transferring trust to the user, it only remains to detect > > forwarding, which is what ARC is used for. From: munging can then be > > omitted. > > And in most cases of "wanted" forwarding, user already knows about > that. When I added .forward in netbsd.org to forward my emails to me, > I know I put it there, and I do trust netbsd.org enough that I can > trust their ARC headers are generated correctly and if they say > spf=pass, dkim=pass I can trust that even if they do not pass in my > final destination. > > When I joined the IETF mailing-list I also did that on purpose, and I > know that ietf.org is forwarding emails to me, so I can again trust > ARC headers generated by ietf.org... > > Of course one of the problem is that ietf.org does not generate ARC > header. > > Another problem is that my email filtering do check ARC, but > spamassassin can only validate ARC signatures, I do not think there is > a way to say that it should set SPF/DKIM/DMARC test results based on > the valid ARC signature from trusted source, so I can't really use the > ARC signatures yet. > -- > [email protected] > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
