On 2021-04-01 at 07:36 -0700, Marcel Becker wrote: > On Thu, Apr 1, 2021 at 12:43 AM Hans-Martin Mosner wrote: > > One option that you should consider to mitigate the effects for > > recipients is to allow per-recipient DMARC exceptions, because the > > recipient is the one who ultimately decides whether mail is wanted > > or unwanted. > > Recipients are the ones least able to make a decision whether a mail > claiming to be from brand.com was really sent from brand.com. They > don't even know that a mail from lookslikebrand.com is not legit, > move it out of the spam folder and then proceed to interact with > it...
I have mixed feelings on this. Users manually overriding DMARC indeed weaken the ecosystem. They should never need to e.g. override that for their bank, or a normal page. That site is misconfigured. If they get used you end up in the situation where hard errors are no longer "hard", since users will bypass the certificate error anyway. On the other hand, by dumbing down the users with binary spam filters, that leads to poor accountability. If you filter the legitimate bank mail into spam, even if it was because the bank dns records are utterly broken, then it's suddenly "your fault", Clearly showing to the user the assertion by Bank on which you relied would allow to be relayed back to the entity originating the non-compliant mail. You might have a power user wanting to override a bad entry for a system with an unresponsive postmaster, but that would be a really advanced feature. I would suggest to just let the user switch between a strict (reject what the sender asked to be rejected) or soft behavior (only quarantine if the user wants to be extra sure to receive mail from broken systems, albeit showing they should have been rejected). That covers the use case of a user adding exceptions for directly received mails. However, if the user set up mail forwarding, there user *should* be able to state they are forwarding from _host_. The user requisite in laymen terms will be something like "I want mail sent to mr...@example.com on my account j...@gmail.com" Such option would be an obscure one, but it's a one-time thing that would need to be documented, anyway. User would need to follow some instructions stating how to forward its mail on example.com *and* how to configure gmail.com to know it will be forwarding from X ip address (or, better yet, a given ARC signature). That's simple for everyone involved, the sending side only needs to setup forwarding, and the receiving one to augment the user perimeter to trust that server [signature, Authorization-Results, etc.]. It's simpler for receiver's anti-spam system, that won't need to care about that "spoofed" legitimate mail it is receiving, and will allow it to avoid that noise and produce better results. It's simpler as well for the forwarder, no need of tricks like forwarding some of the mails and providing others through a POP3 pull (and what if they consider it legacy and didn't want to provide POP3?). And even for the user, which should get more consistent results with a similar effort. Best regards _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
