On Sun, Aug 6, 2023 at 11:52 AM Wei Chuang <weihaw= 40google....@dmarc.ietf.org> wrote:
> > > On Sat, Aug 5, 2023 at 4:51 AM Laura Atkins <la...@wordtothewise.com> > wrote: > >> >> >> On 5 Aug 2023, at 02:43, Jesse Thompson <z...@fastmail.com> wrote: >> >> On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote: >> >> I agree with this and have been working to recruit folks to come here. >> I’ll also be in Brooklyn and pitching the need for participation in the >> IETF working group from folks in the email space who are seeing issues with >> this. >> >> >> I'll be there and interesting in participating. As an ESP/infrastructure >> provider I can say that we are "having" the issue, but can't say that we >> "seeing" the issue since visibility is only available to anti-spammers, and >> domain owners (who receive DMARC reports). >> >> We don't have visibility either as DKIM replay from an authentication > perspective looks like legitimate traffic. Of course the content looks > spammy which has a negative impact, and it's hard to differentiate DKIM > replay from day to day variations. > > >> A big driver of the work is actually Google. As I understand it, they are >> having issues because the replay attackers are successfully stealing >> reputation of otherwise good senders in order to bypass some spam >> filtering. The replay attackers aren’t sending what we commonly think of as >> spam through the signers - as the message is sent to one recipient (not >> bulk) and it is opt-in (that recipient wants and has asked for the mail). >> > > Agreed. For a while DKIM replay was our number one source on increased > escalations, and that was heading towards an unsustainable place. > Fortunately DKIM replay and escalations calmed down quite a bit, perhaps > due to the ecosystem implementing various mitigation techniques. For > example we've had good success with the duplicate message counting idea > reported at M3AAWG (and mentioned in the problem statement document), as > well as many implementing other techniques. My worry is that these > techniques don't tackle the issue at the protocol level and several have > thresholds that spammers can exploit. I suspect they will be back once > their current large-scale campaign with SPF runs its course. > To add to what Wei said, enforcing RFC5322 (duplicate Headers), and quota limits on duplicate messages has been effective so far, and we will likely continue to tighten those quota limits over time. The downside is that benign non-DKIM replayed traffic might be affected by the message counting approach. There are certain criteria which indicate the message is NOT dkim replay. The two simplest are: 1) The SPF zone and DKIM zone are aligned. 2) The actual recipient is included in the DKIM signed message (non-BCC). Any message that meets either of these criteria can be excluded from duplicate message quota limits. If there are cases where there would be large volumes of duplicate messages that don't meet these criteria then that is a case where we might need new standards to allow those indirect flows to proceed unimpacted. Otherwise, if everyone is happy that their cases are covered it might be that RFC5322 and DuplicateMessageCounting is enough to mitigate the problem. Note the goal here is not to prevent EVERY dkim replay message. The goal is to make the possible amplification factor small enough that dkim replay is not an attractive technique to spammers.
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
