If I understand what's going on, Y! is doing an OR on DKIM & SPF and in this case, your SPF record is bypassed by the DKIM pass. The only thing to be done on your end is to not publish a DKIM record, and then you're at risk for a prefix hijack, though that is visible to some receivers, and it requires a bit more work to do.
I like your idea of the receiver logging b= and for that matter message-id, and tossing messages that are not within a certain date range (that way you can reduce those logs). Eliot On 8/12/16 2:42 AM, Robert Mueller wrote: > Hi mailop > > So it appears at the moment that we're experiencing a DKIM replay attack > against us. Basically some people are signing up a trial FastMail > account, sending a couple of emails to a gmail account (to get them DKIM > signed by us), and then copying the entire content of the email and > sending it from an AWS instance. > > Because Yahoo uses the DKIM signing domain for it's feedback loop > reporting, we're receiving 100's -> 1000's of reports, even though none > of them were actually sent from our servers. > > Here's what the cut in the Received headers looks like: > > Received: from towersevent.net (ec2-52-2-96-133.compute-1.amazonaws.com > [52.2.96.133]) > by alph136.prodigy.net (8.14.4 IN nd2 TLS/8.14.4) with ESMTP id > u7BDOa9x029274 > for <[email protected]>; Thu, 11 Aug 2016 09:25:57 -0400 > Received: from new1-smtp.messagingengine.com > (new1-smtp.messagingengine.com. ) > by mx.google.com with ESMTPS id > y13si203649qkb.155.2016.08.11.06.16.00 > for <[email protected]> > (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 > bits=128/128); > Thu, 11 Aug 2016 06:16:00 -0700 (PDT) > > The bottom Received header shows the jump from us to gmail, but the top > Received header shows that basically they just copied the entire email > content, and sent it from an AWS instance to a @att.net account. > > Obviously we're concerned about this because: > > 1. We only learned about this because yahoo uses DKIM domains for FBL > reporting. If they used IP's, we'd never have known about this > 2. I bet a number of services out there are using the domains in DKIM > signed emails for reputation tracking. So this may be affecting the > reputation of our domains, even though we're not the genuine source of > the majority of the emails. > > Does anyone know if (2) is actually true, or what sites might be doing > to avoid this? I guess checking the uniqueness of b= value in each DKIM > signature to see if it's truly the same email just replayed over and > over is one way? > > That's an interesting thought actually, I wonder if seeing many emails > with the same b= value is an easy way to actually detect spam and/or a > replay attack? > > I can't see an easy way to stop this. It's impossible to block every > single sent spam email ever, and all it takes is one email sent and > signed by us to be able to be replicated as much as anyone wants. > > I know that this is a known problem with DKIM, just wondering if anyone > else has seen this and or dealt with it and has any idea if we should > even be worried about it at all? >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
