On Sun, Aug 6, 2023, at 2:00 PM, Emanuel Schorsch wrote: > > > On Sun, Aug 6, 2023 at 11:52 AM Wei Chuang > <[email protected]> wrote: >> >> >> On Sat, Aug 5, 2023 at 4:51 AM Laura Atkins <[email protected]> wrote: >>> >>> >>>> On 5 Aug 2023, at 02:43, Jesse Thompson <[email protected]> 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. >
What can ESPs do to make these zone boundaries easier for receivers to determine alignment in their disposition algorithms? Or rather, predictable non-alignment patterns? I know that you probably already have a clear picture by analyzing historical patterns, but many receivers won't take as much of an algorithmic/learning approach. > > 2) The actual recipient is included in the DKIM signed message (non-BCC). > For messages which are originally submitted as BCC and, depending on the circumstances, it's necessary for us to identify the recipient in the headers, what is/should be the standard header to use for this purpose? BCC? Forwarded-to? Jesse > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-dkim >
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
