On Sun, Aug 6, 2023 at 10:23 PM Jesse Thompson <z...@fastmail.com> wrote:
> On Sun, Aug 6, 2023, at 2:00 PM, Emanuel Schorsch wrote: > > > > 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. > > > 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. > In my opinion, it seems like one nice solution would be to offer a way for a sending domain to specify the expected SPF that should go with a DKIM message (e.g. maybe an additional DKIM field). Then any domain that is negatively affected by DKIM Replay could adopt this solution. ESPs might be a particularly good use case if by default they use the same SPF for many different customers. Though of course if this isn't possible, a simple solution is to keep the number of BCC recipients for the same message to a reasonable limit. > 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? > If there are not that many BCC recipients for a message then it is likely not necessary as the duplicate message counting is unlikely to have a negative impact. If there are a large number of BCC recipients for a given message then I think the solutions proposed in Wei's DARA draft are helpful: standardizing the way to indicate BCC/Forwarded-To and signing a separate copy of the message for each BCC recipient so that it can still be verified as direct mail. I think the most likely to have a negative impact from Duplicate Message Counting is mailingLists and ListExpanders. But I would love to hear more areas where this would have challenges! For mailingLists as long as they use a MailingList DKIM signature there shouldn't be issues. For MailingLists that don't modify the content and don't use their own DKIM signature it might be tricky. This is where more involved solutions would be needed like the ones Wei proposes.
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
