Welcome to the Grok Shop! In this video
we'll be talking about some of the ways
to mitigate spam in the Postfix MTA. So
here I'm showing some example spam. This
is an extortion spam that's become
popular in recent years. So apparently in
this particular case, people do actually
get hacked their passwords get
discovered and they become victims of
this attack. These started showing up
after I had a domain for a few years and
decided to start hosting my own email
for this domain. So they were probably
sending these for quite some time and
they weren't actually going anywhere.
Needless to say, when I decided to start
hosting my own email server for this
domain, it became my problem. So let's
take a look at how we can deal with
these and other types of spam. Now, in
order to fight the spam effectively,
you're gonna have to get intimately
familiar with your mail logs. These of
course live in the /var/log/mail.log
and associated archive files. So for
example, here I've got three log snippets.
The one on top is showing the spam log
entry of the spam that I was showing
earlier and we can see the spammers
populating the envelope "FROM:" with
"RecordedYou..." blah blah blah and we see
the original "TO:" is holly@brackin.net.
And brackin.net is that new
domain that I added. If you saw my
previous Postfix video, you know that
I've set everything up to forward to my
personal gmail account for now (that's
blacked out here). And we can see the
status gets set to sent and the last
entry is "removed". So, it got sent to my
personal email and removed from the
queue. The bottom two snippets show two
more spam attempts - apparently from the
same spammer - that were blocked by
Postfix using two different techniques.
The first technique was rejection based
on a reverse host name lookup failure
and the bottom technique is a mailbox is
non-existent failure. So now let's take a
look at how to configure these and other
spam blocking techniques. OK let's start
out with some version awareness this is
the command to check your Postfix
version. So Postfix version 2.2
introduced the Anvil service. The way
anvil works: there's a time window they
call the "anvil rate time unit" ( defaults
to 60 seconds ) and it provides a number
of per-client
metrics that we can use to limit bad
actors. So, by clamping down on these
parameters we can pretty much mitigate
email flood attacks from out of control
clients. The first three are all tightly
related. So, a client can make (in this
case) up to five errors before getting a
three-second back off delay in responses
and then after ten errors Postfix will
just disconnect the client. The defaults
for these three are one second, ten and
twenty for soft and hard. The last two
parameters specify a total client
connection count. I have it at 5. The
default is 50 and a connection rate
limiter which I have at 20 (the
default is 0) and that's a limit per
the anvil time window. OK, so moving on
to the SMTP restrictions. So, as I showed
I am using Postfix version 3. However
most of these settings should work if
you have Postfix version 2.3 or higher.
If you're working on a mission-critical
server, one cool feature of Postfix is
you can place a warn_if_reject in
front of the restriction that you're
thinking to add, and sort of test it out.
And it will show in the logs what would
happen if you had fully enabled it and
didn't have warn_if_reject in front of
the restriction. So, sort of a nice
non-intrusive way to test out proposed
restrictions. If you have clients which
will authenticate, be sure to put the
permit_sasl_authenticated in your
restriction list. OK, last but not least
be sure to remember that I've set these
restrictions up for my particular
scenario which is a non-mission-critical,
non-busy server (at the moment) and so
these are specific to my needs. Everybody
will have to customize the restrictions
to their own environment and their own
needs, but you can think of it maybe as a
good starting point or boilerplate
restrictions. OK, smtpd_helo_required means
the client should introduce theirselves
with the HELO or EHELO before sending
the MAIL command or any other commands
that require a HELO negotiation. The
default here is "no", so as you don't have
any problems with troubled clients that
can't do that but if you don't have that,
I would recommend setting it to "yes."
OK, next disable_vrfy_command
basically, VRFY command can be used to
query if addresses exist, and they are
abused sometimes for email and login
username harvesting. So, I definitely
recommend setting this to yes unless you
have a particular need otherwise.
OK, by default, if you have an
unverified sender and you're rejecting,
Postfix we'll send the verification
details for the reason why it failed.
Instead of that, you can just have it
send some straight text using the
unverified_sender_reject_reason and that
parameter is available as of Postfix
2.6. One of the nice things
about Postfix is it has this layered
approach to restrictions and you can do
some very complex restrictions. And as of
Postfix 2.10, the relay restrictions were
added which allow you to set up relay
restrictions separate from your other
restrictions. The first three are by
default. I added reject_unauth_destination
which means if the destination
domain is not in the relay domain list,
it'll be deferred. You can also do a
reject_unauth_destination. So to back up
just a minute, Postfix has several
restriction stages. These stages are
processed in a certain order (this stage
here being the relay stage). And within
each stage the restrictions are
evaluated in the order they're listed. In
order for processing to continue within
that stage, each line must evaluate to an
OK or DUNNO. Otherwise, that's the end of
the story for that particular stage. Now,
you'll see in my main.cf file
I pretty much have these restriction
stages listed in the order they occur
except for the relay restrictions
because that was added later. The relay
restrictions would be - I believe - before
the recipient restrictions and after the
sender restrictions. So, they are done in
order and the order does matter. However
if you keep the smtpd_delay_reject parameter
set to the default of yes, then a lot of
the restrictions can be rolled up into
the recipient restrictions. But, you still
want to have a separate relay
restrictions and data restrictions. So, to
be clear, the restriction stages are
evaluated in the order shown here but
the restrictions themselves are
evaluated in the order you list them in
the main.cf file. So in practice what
this means is any restrictions that you
have in the client HELO or sender
stages can be moved into the recipient
stage and that's exactly what I've done
here. So within the recipient restriction
stage, my first restriction is permit_mynetworks
which is actually a whitelist
to permit my network, my IP, and any other
IPS I put in the mynetworks
parameter. Next, I'm telling Postfix
I want to reject anything that's not a
fully qualified domain name for HELO,
sender or recipient, even though in the
HELO stage, it's technically legal and
compliant with the RFC to use an IP
address enclosed in square brackets. OK,
next reject_unknown_reverse_client_hostname -
this basically means that the
reverse DNS has to map to something. A
more strict version of this would be
reject_unknown_client_hostname which
means the forward and reverse have to
match and it has to be the actual IP of
the client. OK next I have
reject_invalid_helo_hostname. That basically
means if the clients HELO host is
malformed, it will be rejected. Of course
you have to have the smtpd_helo_required
field that I showed earlier set,
otherwise they could just go around this.
also benefiting from the smtpd_helo_required
is reject_unknown_helo_hostname. So if
the client's HELO hostname has no A or
MX record, you guessed it, rejected. OK
next reject_unknown_sender_domain; so in
cases where this Postfix is not the
final destination, if the mail FROM
domain has no MX or A record or the MX
record is malformed, rejected.
OK next reject_unknown_recipient_domain;
this works just exactly the same
as reject_unknown_sender_domain except it's
for the RCPT TO domain.
OK reject_unauth_destination; now with
2.10 and higher I shouldn't have this
here. I should have this up in the relay
restrictions and I do I have the defer
one, but I'll probably just get rid of
this and change that one to a reject
up there. OK next I gotcheck_recipient_access
hash. This file is basically for
recipients that you want to specially
address. In this case I had some email
addresses that were attached to the
domain from I guess years ago that we're
still getting email. So I want to make
sure that I reject those. OK next
check_helo_access; its a good idea to have a
hash here for the HELO checks;
basically because HELO can be spoofed. We
want to make sure they're not trying to
impersonate our domains IPS or local hosts.
OK next I had to add a check_sender_access
because Draftkings was
sending email to a defunct account. I did
try to contact them and do it the nice
way, but they wouldn't listen so I went
ahead and set up a special reject just
for them. If you're still having problems
after you've tuned all your Postfix
restrictions you can filter with a
blacklist server using reject_rbl_client.
For me, I haven't needed that so I've got
them commented out right now. The last
little permit at the end is optional. I
put it there just to make it clear that
if you get to this point you're
permitted you're getting through. OK
moving on to data restrictions I've got
reject_unauth_pipelining. What this
does is slow down or stop mail from bulk
mail senders who use illegal pipelining
or basically, speaking out of turn. Quick
note about the status or error codes
you'll notice that except for the check_access
hash files, I didn't specify any
codes other than the default and that's
generally considered best practice.
Unless you really know what you're doing,
let Postfix use the defaults. A really
nice feature Postfix has is this
ability to debug individually-specified
hosts and this is how you do that. And
I'll show you the file that I set up;
it's a regex file. You could do it with a
regular hash but note this is just a
listing so these these fields to the
right ( I have A B and C ) - they don't mean
anything. They're just placeholders. Of
course when you set up your map file,
you're going to want to run postmap on
it and let Postfix munge on it and tell
you if there's any errors. Also you can
run "postmap -q" to test your
mapping. This is especially helpful with
regex since regex gets kind of messy
sometimes. And make sure you've got your
mapping set up the way you want it.
Besides regex - as I showed - you can do a
straight hash which is just a key value
pair map; you can do pcre which is like
the Perl version of regex; and you can do
CIDR. When your run the "postconf -m"
command, it'll show you what all your
Postfix was compiled with ( that type of
maps ) that you can use. Going back to the
debug - other than per client or per host -
you can also set up verbosity on the
Postfix SMTP service just by adding a "-v"
in the master.cf file like so.
Reload your Postfix and you'll see huge
amounts of data in there but it could be
quite useful sometimes. So yeah, there you
have it. As you can see, Postfix is
extremely powerful and flexible in terms
of stopping spam in it's
own right; in fact so much so, you may not
even need to use a third-party spam
software tool like Spam Assassin or some
of the other point based systems. There's
definitely a lot more capability than
just what I showed in this video, so if
you're admining Postfix I totally
recommend spending the time to get to
know all of the things that Postfix can
do. As always, I'll be providing a lot of
reference links. If you're watching this
on my blog just scroll down; everything
you need is below the video. If you're
watching this on youtube be sure to
check out my blog post which I have all
that additional information and make it
easy for you to cut and paste and all
that good stuff. So, that's it for this
video guys. I hope you found it helpful.
Be sure to let me know what you think. I
will be having some more related videos
coming up including a migration from sendmail
to Postfix as well as an in-depth
fail2ban video. But as far as basic
mitigation of spam with Postfix goes...
that's how it's done. Thanks for watching.
[Music]
[Applause]
[Music]