On 07/13/16 11:34, Bill Cole wrote: > On 13 Jul 2016, at 9:50, Phil Stracchino wrote: >> One thing I USED to do back when I was running an OpenBSD firewall box >> was reject incoming connections to port 25 from Windows hosts. Any >> legitimate mail coming directly from a Windows machine would fall back >> to my MX relay. It stopped a LOT of botnet spam. I don't imagine >> there's any way to do that with Postfix though, and there doesn't seem >> to be a way to do ut ising netfilter/shorewall on my current firewall, >> which is a Ubiquiti embedded appliance. > > I think the world has largely moved beyond that being useful. Microsoft > is actually using Exchange for their free and cheap mail hosting these > days and doing so in a very big way, and there are botnets of shoddy > Linux machines. Those include at least one that sustains itself by > exploiting BusyBox (i.e. embedded Linux) flaws. We live in a world of > small routers, firewalls, lightbulbs, doorbells, and refrigerators > sending spam.... YAY!
Agreed, it's no longer really a useful strategem anyway. So I haven't tried too hard to figure out a way to re-implement it. >> ...And then remove the settings from smtp_sender_restrictions that are >> now duplicated in the expanded smtpd_recipient_restrictions list? > > Yes. Note that ordering becomes critical when collapsing everything into > smtpd_recipient_restrictions because a PERMIT from any directive in a > restriction list causes a message to bypass later directives in that > list. It is not inherently better or worse to split up the directives > between lists but with the ones you are using, it should work correctly > and avoids duplication of directives in multiple lists. That would make sense. Early PERMITs only where you want them to be unconditionally accepted regardless of other conditions. >>>> unknown_client_reject_code = 450 >>> >>> If you're sticking with reject_unknown_reverse_client_hostname only >>> (which I'd recommend) you can change this safely to 550 (and in my >>> opinion should, on a 'fail fast' principle.) >> >> I'm not actually sure why I had that set to 450. Might have been a >> testing setting that I forgot. > > It's also duplicative of the default setting. Using 450 makes sense as a > default IF you use the more aggressive and accident-prone > reject_unknown_client_hostname. Since that restriction relies on DNS > coordination of 2 zones that may not have a common administrative > authority, it is more likely to "catch" on temporary mistakes that are > resolved within the retry lifetime of a legitimate message. Noted. Makes sense. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: 603.293.8485
