FWIW - There was a thread on this Gmail IPv6 spam filtering problem on another list I'm on where it *is* affecting large'ish enterprise folks using business gmail and there are a more of whom will be putting in enterprise tickets to get visibility - as some tickets have yet to get appropriate responses and sadly the workaround for folks has been to not use v6 to send to Google MXs. From that list I'm gleaning there as some change possibly made in April that is affecting how spam in v6 is being handled but I have no definitive data on this. Some folks on that other list do have PTR, SPF and DKIM in place.
Again, since a Google engineer on that other list is compiling specific details from the people that chimed in with them and forwarding issues to internal teams responsible, let's see what outcome is. He is filing a bug report. Certainly getting lots of visibility on many lists. - merike On Aug 24, 2014, at 9:32 AM, Philipp Kern <[email protected]> wrote: > On Sat, Aug 23, 2014 at 06:31:33PM +0000, Matthew Huff wrote: >> Sorry, but it hasn't happened yet. It isn't computationally infeasible, it's >> that the implementations on the RBLS haven't caught up. Currently the backend >> for the RBLS in many cases are based on DNS resolvers such as bind, etc, >> which doesn't have a mechanism to return values for subnets, so until the RBL >> users add new features, test and roll them out, currently there is very >> limited IPv6 address reputation systems. Until there are, many mail systems >> are relying instead on rDNS/SPF/DKIM/DMARC. It's not an unsolvable problem >> it's just that it hasn't been implemented. > > Caching problems aside you can serve wildcards as long as the IP parts are > reversed. > > Kind regards > Philipp Kern >
signature.asc
Description: Message signed with OpenPGP using GPGMail
