SPF/DMARC are not optimal tools for detecting malice. In my experience, the abundance of sender configuration errors are the limiting factor.
However, I disagree about negative reputation. Content filtering alone is insufficient and even more error prone. In the last year, I have had spam campaigns about LED lighting, stand-up desks, touchless thermometers, and knife sharpeners. I cannot anticipate all the ways that spammers will hide their dirty deeds. But I know it is spam, not merely unwanted advertising, because of receiving many similar messages from many different domains using many different servers. Third-party RBLs help but are insufficient. I am gradually building my own reputation database based on the traffic that I am receiving. By blocking the problem sources, I have been able to get the spam problem under something approaching good control. Content filtering is a useful tool for day-zero detection of a new spam source. Once a source is detected, it needs to be blocked. Whether a message passes SPF and DMARC criteria is part of my search critieria for unwanted traffic, but definitely not the only one. As has been observed, actual spoofing of the From address is not a huge part of my problem at present. This is largely because spammers have easy enough tools in Friendly Name spoofing and corporate logo misuse. But I also attribute that low volume to the existence of SPF and DMARC. Doug Foster From: Murray S. Kucherawy [mailto:superu...@gmail.com] Sent: Monday, September 07, 2020 4:30 PM To: Doug Foster Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing lists Historically, I've found that a negative source reputation is easy to dodge. It's trivial to come from an unknown IP address or register a new domain name, so an actor with a negative reputation can trivially move to a neutral one. Thus, a receiver/verifier seeking to make a meaningful judgement can only really focus on positive reputations when making meaningful filtering decisions; everyone else is basically the same in terms of value. Another way to look at this: DKIM (and I believe SPF) only really tells you something interesting when it passes. That means (for DKIM) the content was unmodified, and the signature is validated by a key that is verifiably present in some domain's DNS data. That means the domain announcing that key implicitly "takes some responsibility" for the content just verified. So the only variable here is the value, or reputation, of the verified name. All of this is orthogonal to DMARC though, which doesn't care about reputation. It only cares about alignment, and specifically alignment that is under complete control of the sender. -MSK On Sat, Sep 5, 2020 at 10:55 AM Douglas E. Foster <fosterd=40bayviewphysicians....@dmarc.ietf.org> wrote: What I am trying to accomplish is different than what can be accomplished with the canned-modifications indicator. To explain, I need to digress into my theory of operation for spam filters: 1) Source identification allows assignment of a Source reputation. Source reputation is more important than content filtering, because hostile content always comes from a source that should not be trusted. Content filtering always produces false positives and false negatives, and the workarounds to those errors are always dependent on source identification 2) Impersonation is always attractive to an attacker because it allows him to exploit the reputation of the impersonated identity. Therefore impersonation is an inherently untrusted activity. 3) Spam filtering will assign sources to three reputation groups: negative reputation (rejected), neutral reputation (acceptance depends on content filtering), and positive reputation (some or all content filtering bypassed.) SPF and DMARC are designed to block impersonation, and mailing lists look like impersonated traffic, so the message moves from neutral to negative reputation. How to overcome that? One solution is to use out-of-band information to justify overlooking the negative clues, then implementing local policy based on that informatoin, so that traffic is moved from negative reputation to positive reputation. ARC and canned-modification tagging are approaches to providing in-message data intended to support application of that local policy. But we have found no way to ensure the out-of-band information flow needed to justify the local policy, for all of the mediators that need that status. We have also identified no method for the recipient to notify the mediator that the local policy is established, although this could also be handed out-of-band. However, these techniques have the benefit of depending on the mediator and the recipient, and not on the sender. A second solution depends on explicit sender authorization to eliminate the apparent impersonation. This category encompasses conditional signatures, ATSP, RHSWL, DKIM delegation, and SPF inclusion. These approaches require the involvement of sender, list, and recipient. We have concluded that these approaches are victims of unlikely participation by senders, and further limited because the list does not know if a recipient will recognize the sender's authorization. Finally, I observed that this solution cannot help with the problem created by spam filter tagging prior to an auto-forward, so it cannot solve the whole problem. A third solution is to abandon DMARC and allow impersonation to be unrestricted. I am suggesting a fourth approach. This one seeks to address the impersonation problem by clearly identifying each part of the message to its source, so that impersonation is not an issue, and each source's contribution is evaluated based on that source's reputation and that source's content. The goal is to move the imputed source reputation from negative to neutral, rather than from negative to positive. If the source reputation can be defaulted to neutral, the approach can be used by any mediator without prior registration with recipients and without any prior authorization by senders. But on continued reflection, I realize that this approach requires complete isolation between the content added by a mediator and the content provided by the originator. Any other changes to the original content could maliciously alter the original intent of the author, and an automated spam filter has no ability to identify changes of intent. So is there a group of mediators who only require the ability to add a subject prefix, subject suffix, body header, or body footer? - The better spam filters offer URL rewrite, which alters original content. The weaker spam filters may only use these four features, but they are the ones that are least likely to add an exotic new feature like dual authorship detection. So I reluctantly conclude that there is no significant opportunity for using this approach on the "spam filter with auto-forward" problem. - But is there is a group of mailing lists that only need these four capabilities? I was hoping so. DF _____ From: Alessandro Vesely <ves...@tana.it> Sent: 9/5/20 5:36 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing lists On Fri 04/Sep/2020 04:05:24 +0200 Douglas E. Foster wrote: > > Of the three types of content changes that I proposed, the easiest to specify > and get implemented is the first type, where the mediator only adds content, > adds a change log indicating the additions, and signs the result. I am > hoping > and assuming that if mailing lists have freedom to add their branding to the > subject and body, most lists would not need to make more complex changes. The change log must not be a generic patch, but rather a stylized list of pre-canned modifications, much like envisaged in the dkim-transform draft. This limitation can reduce the attack surface, although it cannot prevent malicious URLs in the footer. > The signed change log would allow participating recipients to identify the > signed additions added by the list or other mediator, while also identifying > the signed original after the list additions are virtually removed. I don't think the change log has to be signed. If undoing the changes leads to a verifiable signature, then add a dkim=pass for the original signer. Else dkim=fail. Signing the change log doesn't hurt, but it doesn't help either. If verification succeeds, Authentication-Results: can report enough transformation details to allow the MDA to restore the original From:, in case the MLM rewrote it. > Once the additions and the original are reliably identified to a source > domain, suspicion of spoofing is no longer a concern. Each chunk of content > can be evaluated based on the reputation of the verified source domain and > the specifics of the content. > > Nested additions are possible. Each new signature adds an entry to a > verification stack. Any change can be removed, virtually or actually, by > reversing the change at each level, working backwards from last to first. I beg to disagree. On the one hand, we already have ARC to unwind a chain of message handlers. The "defect" of ARC is that it needs a full domain reputation system in order to work reliably. Where the reputation of "intermediate" mediators is needed, ARC is the right tool. On the other hand, a deterministic tool should only be interested in who is the actual author of a message and what has the domain owner to say about attributing such authorship. This can be done without assessing reputation. IMHO, the original author domain deserves an aggregate report mentioning the result of evaluating DKIM transformations, even if From: was rewritten. So does the last From: rewriter. Intermediate mediators don't. Best Ale -- _______________________________________________ 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
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
