On 13 Jul 2016, at 9:50, Phil Stracchino wrote:
On 07/13/16 01:52, Bill Cole wrote:
On 12 Jul 2016, at 15:44, 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!
1st note: You have a lot of explicitly set parameters that simply
replicate defaults. That's not harmful per se, but it adds noise to
postconf -n. The ones I found trivially are:
[...]
So you can reduce clutter in main.cf and postconf -n by removing the
explicit setting of those. There are likely others.
So noted, and cleaned up those. I'll check through and see if I can
spot any others, with the reservation that in some cases I've left the
default explicitly set as a reminder to myself of what the default
*is*.
I get that, and it also has the tangible benefit of nailing down
defaults that you depend on not being changed by Wietse (rare and almost
never wrong) or an intermediary packager (less rare, less consistently
right.)
smtpd_client_restrictions = permit_mynetworks
Noise. There's no need to define any of the smtpd_*_restrictions
lists
if the definition only includes a sequence of conditions that are
going
to show up in logically later ones.
Hm, don't think I'd been aware of that.
Well, I understand it to be an innovation somewhere near v2... :)
[...]
Also, consider putting all of that in smtpd_recipient_restrictions
instead, after permit_mynetworks.
reject_invalid_helo_hostname can go in smtpd_recipient_restrictions?
Yes. This has been true for at least as long as Postfix has had milter
support (which is when I tossed Sendmail aside for anything other than
than null-client and completely insane rigs involving hand-built
cf-ese.) Like I said above, I think this was a v2 innovation.
There are corner cases where particular needs make it helpful to put
logically early restrictions and permissions into the client/helo/sender
lists but the side effects can be subtle and non-intuitive. By default
(i.e. with smtpd_delay_reject=yes) all of the smtpd restriction lists
are evaluated in order at RCPT time, with PERMIT results from early
lists being effectively DUNNO results. See the SMTPD_ACCESS_README file
for details and examples of where you might want to make use of multiple
lists vs. putting all client/ehlo/sender directives in
smtpd_recipient_restrictions.
smtpd_milters = inet:localhost:8891
Presumably opendkim?
Yup. I'll have to study the docs (and possibly ask on the opendkim
list) on how to have opendkim sign only *outgoing* mail. I hadn't
actually looked closely enough to see that it was signing incoming
mail
as well. Though possibly the forged sender was tricking it.
smtpd_recipient_restrictions = permit_mynetworks
smtpd_recipient_restrictions =
permit_mynetworks,reject_unauth_destination,
reject_unknown_reverse_client_hostname,reject_invalid_helo_hostname,
check_helo_access pcre:/etc/postfix/helo.pcre,
reject_unknown_sender_domain,reject_non_fqdn_sender,
check_sender_access btree:/etc/postfix/block-local-sender
...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.
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.
