On Fri, 16 Nov 2018 at 06:49, Dennis Carr <dennistheti...@chez-vrolet.net> wrote:
> On Fri, 16 Nov 2018 06:10:28 +0000 > Dominic Raferd <domi...@timedicer.co.uk> wrote: > > > - you say you want to ban based on the 'From:' address which if true > > would require you to use header_checks ( > > http://www.postfix.org/header_checks.5.html) not sender_access > > That'd work better, then. > > > I think you actually want to reject based on the envelope sender (not > > From header), in which case you want main.cf unchanged and > > sender_access like: qq.com REJECT > > Here's the thing, it's a spam campaign where emails from qq.com are > coming from what appears to be a few different IP blocks on two > different providers and cycling through the IPs as to dodge > blacklisting, as well as randomizing their FQDNs - so in this case, I > don't think scanning the envelope is going to work unless there's > something I'm missing. I've tried contacting the providers' upstream, > but the upstream doesn't seem to listen either - at least, not if I > send a third party report from Spamcop. > > The ONLY other common thing is that everything is 'From: *@qq.com' in > the headers. I could probably figure out the IP ranges, but that > opens the possibility of changing the IP ranges if the providers are > so flexible - and I'd be patient with the BLs, but this is affecting > users. > The reason I think you actually want to reject based on the envelope sender is because I too see lots of attempted spam from @qq.com envelope sender addresses. On our servers these are blocked by fqrdns ( https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre). I can't tell what the 'From' header is because they are all blocked before data is sent. Blocking by sender (or using fqrdns) is much cheaper than blocking by header.