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

Reply via email to