On 2018-09-22 10:33 am, Kevin A. McGrail wrote:
> On 9/22/2018 10:29 AM, Matus UHLAR - fantomas wrote: > >> remove those ?'s: /^v=spf1 .*?all/ and /^v=spf1 .*+all/ > > Updated. I was trying to stop a greedy regex if someone was doing a > weird spf but I am overthinking. These SPF records are all effectively equivalent (the fourth is Sender ID [1], we'll get to #5 later): v=spf1 +all v=spf1 all v=spf1 all 192.0.2.0/24 v=spf2.0/mfrom +all v=spf1 1.2.3.0/1 128.4.5.0/2 192.6.7.8/3 -all So therefore I propose regexps like /^v=spf[12].*[s+]allb/ and /^v=spf[12].*s?allb/ (the latter should be very rare and a better indication of a clueless admin than a spammer). The fifth item above permits 0.0.0.0 to 223.255.255.255 and therefore only multicast and the reserved Class E network are banned. To address this, consider /^v=spf[12].*[0-9]/[0-7]b/. I haven't observed this sort of workaround (yet), but it's the attackers' logical escalation in response to this. (I conservatively chose a max mask of /7, though I don't think there's any legitimate use of /8, even by the remaining Class A holders [2] like AT&T, HP, and the US DoD--nobody _should_ have an email network even approaching a /16 let alone a /8, though note that Google currently includes three /16s. I'm not sure where to draw a similar "too large" threshold for IPv6; perhaps /32?) -Adam (still here, sometimes) Links: ------ [1] https://en.wikipedia.org/wiki/Sender_ID [2] https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks#List_of_assigned_/8_blocks
