Request for feedback on SMTPD restrictions


I have a basic SMTP server set up with what I believe to be good smtpd_*_ restrictions, but I was wondering if anyone could provide any insight on how to improve them or if I have been redundant in the restrictions. Even with reading the man pages, I find some of the restrictions tricky.

I am eventually having a submission service (with an -o smtpd_relay_restrictions=permit_sasl_authenticated in, for this server but right now what follows is just for a SMTP server on port 25.

smtpd_client_restrictions = permit_mynetworks,
check_client_access hash:/etc/postfix/client_acl,

smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
check_helo_access hash:/etc/postfix/helo_acl,

smtpd_sender_restrictions = permit_mynetworks,
check_sender_access hash:/etc/postfix/sender_acl,

smtpd_recipient_restrictions = permit_mynetworks,

smtpd_relay_restrictions = permit_mynetworks,


- J


Re: Request for feedback on SMTPD restrictions

By Noel Jones at 01/21/2018 - 16:35

On 1/20/2018 11:56 PM, J Doe wrote:
reject_unknown_client_hostname is likely to reject legit mail. Use
with caution.

Consider instead using reject_unknown_reverse_client_hostname, which
rejects clients with no PTR record. This is similar to what many
large providers do and is fairly low risk.

The "permit" at the end is unnecessary, but doesn't break anything.
Same with all the other "permit" in restrictions below.

reject_unknown_helo_hostname is likely to reject legit mail. Use
with caution.

-- Noel Jones

Re: Request for feedback on SMTPD restrictions

By J Doe at 01/22/2018 - 22:36

Hi Noel,

Thank you for your feedback.

Ok, I will move from: reject_unknown_client_hostname to: reject_unknown_reverse_client_hostname as I am looking to block senders that do not provide reverse DNS lookup. These usually show up in my logs with Postfix identifying their connecting IP address but a DNS value of “unknown”.

Interesting. Ok, I had thought it was required. I think I may keep them, even though they’re redundant, as it seems to document the intent a bit better.

Ok, although I checked man 5 postconf again for the definition:

“Reject the request when the HELO or EHLO hostname has no DNS A or MX record.”

Is there ever a case where a legitimate mail sender would not have either an A (and I assume if it is an IPv6 sender an AAAA record), or a MX record ?

The other way I had looked at it was that since the SMTP error code for this is 4xx, if it does reject a legitimate sender the sender would queue the message and try again. I would assume that not having A/AAAA or MX would be transient for a legitimate sender.

- J

Re: Request for feedback on SMTPD restrictions

By Noel Jones at 01/23/2018 - 00:20

On 1/22/2018 8:36 PM, J Doe wrote:
Yes, it's not terribly unusual for a legit HELO hostname to not resolve.

postfix will always use a 4xx code for a transient DNS error.

The HELO hostname is treated differently from the client hostname
and the sender email domain.

It's not unusual for the HELO hostname to be non-resolvable, AND
having a non-resolvable HELO hostname isn't a particularly strong
spam indicator.

Strong spam indicators for the HELO are
(note: this is for mail coming from the internet. Authenticated
submission mail or legit mail from devices on your network might
break any of these)
- a dynamic hostname (eg., which
resolves just fine)
- my own hostname or localhost (old spammer trick still in use)
- a bare IP address nn.nn.nn.nn (disallowed by RFC)
- an ip literal eg. [nn.nn.nn.nn] (allowed by RFC; but IME always spam)

-- Noel Jones

Re: Request for feedback on SMTPD restrictions

By Dominic Raferd at 01/23/2018 - 03:06

​Is there a method (regex?) for reliably identifying dynamic ip addresses?​
Take for instance - it looks dynamic
to me but it says it is static. Is it best/safest to rely on '\.dynamic\.'
occurring in the name?

Re: Request for feedback on SMTPD restrictions

By Noel Jones at 01/23/2018 - 12:55

On 1/23/2018 1:06 AM, Dominic Raferd wrote:

There is no simple regexp, but there is the fqrdns.pcre project. The
project is a large hand-maintained list of dynamic hostnames with a
goal of zero false positives. It's not perfect, but it's useful and
safe for general use.

<a href="" title=""></a>

-- Noel Jones

Re: Request for feedback on SMTPD restrictions

By Voytek Eymont at 01/27/2018 - 01:47

within my current list, where should I add ?

check_client_access hash:/etc/postfix/whitelist
check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre

smtpd_recipient_restrictions =.
check_sasl_access hash:/etc/postfix/sasl_access
check_recipient_access hash:/etc/postfix/recipient_no_checks,
check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
check_helo_access hash:/etc/postfix/helo_checks,
check_sender_access hash:/etc/postfix/sender_checks,
check_client_access hash:/etc/postfix/client_checks,
check_client_access pcre:/etc/postfix/client_checks.pcre,

Re: Request for feedback on SMTPD restrictions

By Noel Jones at 01/27/2018 - 16:00

On 1/26/2018 11:47 PM, Voytek wrote:
Generally, something like:

[restrictions applied to your customers/users]
[whitelists for client/sender/recipient exceptions]
[local blacklist access lists]
[policy services]
[DNS blacklists]

In some cases there are good reasons to do things differently, but
the above suits many people.

So generally, you can put it anywhere after
reject_unauth_destination and after any whitelists.

Just above the first reject_rbl_ is fine.

-- Noel Jones

Re: Request for feedback on SMTPD restrictions

By Voytek Eymont at 01/28/2018 - 09:05

Noel, thank you

I was going to place it higher up, but, I can now see sense in where you

with whitelist, I already have one as so:

check_client_access hash:/etc/postfix/client_checks

so I can use that, I use that for both 'OK' and, '554' that's correct, yes ? OK 554 go away


thanks again, V

Re: Request for feedback on SMTPD restrictions

By Matus UHLAR - f... at 01/28/2018 - 14:11

On 29.01.18 00:05, Voytek wrote:

Re: Request for feedback on SMTPD restrictions

By Dominic Raferd at 01/23/2018 - 13:31

On 23 January 2018 at 16:55, Noel Jones < ... at megan dot> wrote:
Thanks Noel I have added that to my recipe (but modified the plus and
max formulae to hold rather than reject mails).

Re: Request for feedback on SMTPD restrictions

By Kris Deugau at 01/23/2018 - 11:50

Dominic Raferd wrote:
Short answer: No.

If you really insist on going down that rabbit hole, look up the
RDNS_DYNAMIC rule from Apache SpamAssassin. It's an aggregation of 25
provider-specific probably-dynamic rDNS patterns.

That, right there, is why not.

There is no One True Standard, and even within the more common
conventions there are quite a few variations.

This particular example would be from a provider that has declared a
range of IPs to be static IP assignments, and which has deployed a set
of default records in a particular form so that (presumably) all of
those IPs have IP->name->IP mappings even if they don't have customer-
or service-specific rDNS names on them.


Re: Request for feedback on SMTPD restrictions

By Andrew Sullivan at 01/23/2018 - 12:12

On Tue, Jan 23, 2018 at 10:50:24AM -0500, Kris Deugau wrote:
And even if people came up with a standard, the operator could lie.
After all, it's just DNS. There are no DNS Police to come and tell
you that you are using names wrong, or revoke your Internet license if
you do so.

Best regards,


Re: Request for feedback on SMTPD restrictions

By Dominic Raferd at 01/23/2018 - 12:41

On 23 January 2018 at 16:12, Andrew Sullivan < ... at anvilwalrusden dot com> wrote:
OK points taken thanks. Corollary: an outgoing mailserver needs an
rDNS that *indicates* a static ip - regardless of whether the ip is
actually static or dynamic. Because plenty of real-world mailservers
do block or severely limit mail from 'dynamic IPs' (e.g. gmail) but
they can base this only on a 'best guess'.

Re: Request for feedback on SMTPD restrictions

By Petri Riihikallio at 01/23/2018 - 05:26

Dominic Raferd < ... at timedicer dot> wrote on 23.01.2018 at 9:06:
You example is probably a static IP a customer has leased from their ISP’s pool. Some ISPs won’t set up a custom PTR record for such.

No, there is no definite way of identifying dynamic IPs. You may use some regex but it will produce both false negatives and positives. Something along:
You'll have to consider whether it is more worth than it is trouble.

br, Petri

Re: Request for feedback on SMTPD restrictions

By lists at 01/21/2018 - 21:44

On Sun, 21 Jan 2018 14:35:42 -0600

Doing some reading on the PTR record, I believe I've have been doing my
MX record incorrectly. The reverse DNS can only point to one domain
name. If you are hosting multiple domains on one server, all MX records
should point to the domain name that has the PTR record.

For example, suppose the "main" domain of the server is In
this case, has the PTR record. If you also host at the same IP address, the MX record for
should point to, not

<a href="" title=""></a>

Is my interpretation correct?

As an aside, note the superfluous "permit" shows up in many guides
online, but not all of them. I experimented dropping the extra permit
and things worked, but put them back in anyway out of paranoia. I'm
going to drop them now.

Re: Request for feedback on SMTPD restrictions

By Bill Cole at 01/22/2018 - 18:18

Not so. Multiple PTR records for one address may violate some people's
expectations, but it's not wrong if the address doesn't really have a
public name that is more "real" than the others.

Niggle: not one server, one IP address. A server can have many IP
addresses and there's a long history of people asking here how to make
Postfix use specific IPs for specific domains, for essentially cosmetic
reasons. The multi-instance support mostly ended that FAQ.

That really makes no difference. It is arguably good practice to have a
PTR reversing every A record but simplicity is arguably more important,
so having just one A and one PTR for each name/IP pair is fine, even if
that IP is handling mail for many domains.

Re: Request for feedback on SMTPD restrictions

By lists at 01/22/2018 - 23:31

Replies in the middle of the email for clarity.
On Mon, 22 Jan 2018 17:18:42 -0500

OK, on Digital Ocean, you only get one reverse DNS per "droplet".

So if I do a reverse DNS lookup on some IP addresses, I will get
multiple domains?
Yeah, I screwed up.
And in practice, doing it wrong doesn't seem to stop the email from
going out.

As it turns out, between the two Digital Ocean droplets I'm running
(the one I'm on now and the new one I'm setting up), none have the
reverse DNS set up properly. Reading the postfix documentation, all
that is required is a reverse DNS point to something. There doesn't
have to be a match.

Reject the request when the client IP address has no address->name

I put in a few "features" from this website:
<a href="" title=""></a>
This link is similar, though he suggests fail2ban. I find the anvil
code works good enough.
<a href="" title=""></a>

Comments appreciated. I generally just trawl this list and makes
changes as people suggest. Or not change anything as Viktor always
suggests. ;-)

smtpd_sasl_type = dovecot
broken_sasl_auth_clients = yes
smtpd_helo_required = yes
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions =
check_policy_service unix:private/policy
smtpd_client_restrictions =
check_client_access hash:/etc/postfix/spamsources
smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/spamsources
smtpd_relay_restrictions =
check_policy_service unix:private/policy
#lines added after hacker attack
smtpd_error_sleep_time = 2s
smtpd_soft_error_limit = 3
smtpd_hard_error_limit = 6
smtpd_client_connection_rate_limit = 3
smtpd_client_auth_rate_limit = 20
smtpd_client_connection_count_limit = 3
smtpd_client_new_tls_session_rate_limit = 3
smtpd_client_recipient_rate_limit = 3
smtpd_recipient_limit = 14

Re: Request for feedback on SMTPD restrictions

By Bill Cole at 01/23/2018 - 12:51

Yes, as long as you use a DNS resolution tool and not a client of the
abstracted name resolver of your OS (which may use a complex federation
of naming services.) I had multiple PTRs for a dozen years on my
external NAT addresses when my IP provider was willing to delegate
authority for my space to my nameserver. It never caused
any problem more significant than confused humans. The legacy standard
resolver functions (gethostbyname & gethostbyaddr) accommodate the
potential many-to-many mapping of addresses and names, but for reasons I
don't understand, the modern standard reverse resolution function
(getnameinfo) does not.

There is imprecise language in RFC1035 (1987) implying that there should
be only one PTR per IP but it depends on the idea of a "primary host
name" for an IP, which is not universally meaningful or useful as a
naming concept.

Re: Request for feedback on SMTPD restrictions

By Andrew Sullivan at 01/23/2018 - 13:06

On Tue, Jan 23, 2018 at 11:51:37AM -0500, Bill Cole wrote:
We attempted to make this clearer at one point
(<a href="" title=""></a>)
but the draft was so controversial that it never managed to find
consensus until it was watered down to say "A may be A. Or maybe not.
You choose." Didn't seem a lot of point in publishing by then.

Best regards,


Re: Request for feedback on SMTPD restrictions

By Matus UHLAR - f... at 01/22/2018 - 09:43

On 21.01.18 00:56, J Doe wrote:
I'd put check_helo_access before reject_invalid_helo_hostname and
reject_non_fqdn_helo_hostname, so I could allow some hosts use HELO string
that would otherwise be rejected.

You can sometimes get a machine with hardcoded and unconfigurable HELO

Here I recommend the opposite - putting reject_unknown_sender_domain before
check_sender_access, unless you have sane reason to accept mail from invalid
domains (maybe one like the above).

I believe putting "reject_unauth_destination, permit" is better than
"permit_auth_destination, reject", if you put any kind of restrictions in
the future.

Also, with "reject_unauth_destination" you can skip the default "permit"

On 21.01.18 14:35, Noel Jones wrote:
I think that reject_unknown_reverse_client_hostname is not a good idea -
having fake/invalid PTR record is imho worse than than no PTR record.

check_client_access before it (either one) is proper way to configure local

I believe the same as above applies.

On 21.01.18 17:44, <a href="mailto: ... at lazygranch dot com"> ... at lazygranch dot com</a> wrote:
incorrect - IP can have multiple PTR records, although it's not recommended.
- single PTR is more safe, because you need only care about one reverse
(and forward) DNS record.


The only case multiple MX should point to the same hostname is when using
SSL/TLS certificate, and in such case all MX records should point to hostname
in the certificate - not to the contents of PTR record.

Note that using SSL/TLS between servers is not widespread and I don't know
of client rejecting delivery to server with mismatched certificate

simply said:
The PTR record has NOTHING in common with MX records.

I have already encountered cases, where people were doing stupid things to
fullfill this "requirement". This is one of things nice to have, but other
things may be more important than this one.

the "permit" is default (implicit) for most (if not all) of the directives.
As its description says:

Permit the request. This restriction is useful at the end of a
restriction list, to make the default policy explicit.

Re: Request for feedback on SMTPD restrictions

By J Doe at 01/22/2018 - 23:10



The idea behind this was that the only legitimate server I have seen connecting that: a) has a transient reverse DNS lookup problem and b) sometimes passes that but gives a HELO/EHLO hostname that Postfix 3.1.0 rejects is

So for a client restriction I whitelist a client that has a reverse DNS lookup of: permit

I then whitelist the EHLO/HELO hostname with the helo_acl list: permit

This works regardless of the server connecting as the names partially match (ie: a real Outlook server might be, another might be and so forth).

Is this not a good idea, though ?

Also, the last part where you state “You can sometimes get a machine with hard-corded and un-configurable HELO string”, is that you can sometimes get this from a *legitimate* server ?

Ah, right - good catch.

Ok. One thing that confused me even though it works - why is permitting an authorized destination (either through permit_auth_destination or via reject_unauth_destination), required for relaying if I want people to be able to deliver to recipients at my domain ?

If I remove the permission of authorized destinations and if I host mail for say, I cannot receive mail for <a href="mailto: ... at example dot com"> ... at example dot com</a> without the permission of authorized destinations for smtpd_relay_restrictions. I tested this by sending mail to <a href="mailto: ... at example dot com"> ... at example dot com</a> and it would reject it without this permission.

Thanks again,

- J

Re: Request for feedback on SMTPD restrictions

By Matus UHLAR - f... at 01/25/2018 - 10:44

On 22.01.18 22:10, J Doe wrote:
"OK" probably, permit only applies for postscreen

permitting based on dns name? usually not a problem.

I meant local machines like copiers, faxes etc.

If you receive mail for local recipients, you are not relaying.
Relaying means you are sending mail from non-local senders to non-local

both "permit_auth_destination, reject"
and "reject_unauth_destination, permit"

prevent you from relaying unauthenticated clients. However I recommend the
latter, where you:

1. can put other reasons for message rejection
2. don't have to put "permit" at the end

if you leave "reject" at the end, of course you reject all mail.