Ale's proposal speaks to a portion of the problem space where DMARC is used inappropriately and ineffectively. The other list may be the best place to explore the problem, but the topic is germane to the charter.
The issue applies to all mail streams with these characteristics: - RFC5321.MailFrom address produces SPF PASS - The mail stream includes messages from many different RFC5322.From domains, and all or most are not aligned with the RFC5321.MailFrom address, and - Only a subset of the messages have DKIM signatures. This includes mail streams from: - Email Service Providers - Alias forwarders - Mailing Lists In each case, malicious impersonation of the FROM address is rare, so mindless use of DMARC produces poor results. The critical issue for evaluators is not whether the message is authenticated but rather whether it is wanted. ESPs are presumed to authenticate their clients so that they can invoice for services, but that client base may include malicious actors, nuisance advertisers, as well as critically important messages such as password reset links. Even when an ESP sends uniformly unwanted messages, the evaluator has to consider that a future client might use the service to send high-value messages. For ESPs which host mostly wanted clients, the evaluator's likely strategy is to allow by default and block by exception. For ESPs that host mostly unwanted clients, the evaluator's likely strategy is to quarantine by default and allow by exception. Similarly, Alias forwarders are presumed to relay a general mix of traffic, including both wanted and unwanted source domains, even after a best effort to filter spam. The most important question for the evaluator is whether the recipient of the forwarded stream actually wants to received it.0 The evaluator also has an interest in knowing the sophistication of the alias domain's spam filtering techniques, since it affects his risk. An evaluator may or may not be able to look behind the forwarding process to determine if the message had SPF PASS before forwarding, depending on what information is available and deemed trustworthy (from Received, Received-SPF, Authentication-Results, or ARC-Authentication-results header fields.) Mailing Lists have most of the same issues as Alias forwarders. The evaluator's most important question is whether his users actually subscribed to the list. We have a current problem because GoogleGroups permits attackers to create fake mailing lists with "subscribers" that have never subscribed, so that GoogleGroups becomes an open relay for mass distribution of spam. Worse yet, there seems to be no way to report abuse to GoogleGroups. Once a list has been confirmed as wanted by users, the secondary issue is to evaluate list messages for acceptability. List security is also enhanced by obscurity, assuming that the list only forwards messages from a list of authorized posters. Even if posters are not universally authenticated upon receipt, the impersonation attack surface is limited to the allowed poster list. As with Alias forwarders, the evaluator may or may not be able to judge whether the message was authenticated prior to forwarding. Mailing lists would do well to ensure that their posters are authenticatied, to make their mail streams easier to trust. Both theory and operational experience have shown that when the MailFrom address produces SPF PASS, authentication of the RFC5322.From address is often impossible and possibly useless. Evaluators need to adapt their filtering strategy to the type of mail stream being received. Prior approval is certainly a good way to fix some of this mess. Doug Foster On Sun, Feb 23, 2025 at 6:46 AM Alessandro Vesely <[email protected]> wrote: > Dear chairs and all, > > it seems to me that the WG is somehow resting after most of the work is > finalized. So I ask if we can utilize this time to discuss and possibly > experiment with my fix-forwarding draft[*]. > > I spoke to Wei about it briefly. He was okay with discussing it, but > didn't > want to try it right away. I haven't been able to get a hold of any > developers > at the only other site I forward mail to (libero.it). So there's no > implementation of this protocol. However, it is very easy to implement, > even > trivial. It designs a practical way to get ARC up and running, and thus > could > provide relief until DKIM2. > > I hope that the working group can now take the draft seriously and test it. > > > Best > Ale > -- > > [*] https://datatracker.ietf.org/doc/html/draft-vesely-fix-forwarding > > > > > > > _______________________________________________ > 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]
