DevHeads.net

real life reasons not to use reject_unknown_client_hostname

The documentation[1] and several e-mails here mention that
reject_unknown_client_hostname can reject legitimate e-mails.

What exactly are these scenarios? When do they occur in real life? Are
there really legitimate mail servers that don't have a reverse DNS
record that resolves to their IP?

I would like to know so that I can decide whether I should care and
whether I can use this option for my setup. I would only use this option
for port 25 (not submission) and make sure that sasl_authenticated
clients are exempt from it.

[1]http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname

Thomas

Comments

Re: real life reasons not to use reject_unknown_client_hostname

By Bill Cole at 05/12/2018 - 22:04

Yes. Examples:

1. One of the outbound mail servers for my state government (Michigan,
USA) has 5 PTR records, 2 of which give names that don't resolve. So,
40% of the time it would hit reject_unknown_client_hostname.

2. Occasionally, DNS for some of the outbound mail servers for Office365
goes bad and the reverse names for a subset of them return NXDOMAIN
temporarily.

Re: real life reasons not to use reject_unknown_client_hostname

By James at 05/12/2018 - 18:45

I use it. I like it. But... real world can/will bite you in the ass:

1) DNS lookup failures: stuff *does* break occasionally and there *will*
be minutes/hours when you reject stuff unintentionally, and

2) the source changes their systems or email provider, or their email
provider changes their systems, and formerly-working reverse DNS stops
resolving, for all kinds of reasons: I do encounter this occasionally
when exchanging email with small local businesses.

Therefore: watch your mail log. I exchange a very small amount of email
so it's easy for me to do this. Your mileage will vary.

Re: real life reasons not to use reject_unknown_client_hostname

By Bill Cole at 05/12/2018 - 21:14

Yes, it can. Note this Received header from *your* message:

So, it is good that the mail server handling this list does not use
reject_unknown_client_hostname

Re: real life reasons not to use reject_unknown_client_hostname

By James at 05/12/2018 - 22:59

<Sigh />

My DNS server is in fact set up correctly for this, and I have requested
that reverse DNS be delegated down to it, but that delegation hasn't
happened yet.

Hardly any traffic that I get is IPv6, and this postfix mailing list
probably accounts for most of it.

Bottom line: no, it's not perfect, but it currently does what I need,
and I can reasonably expect that the rest will improve over time.

So this actually makes an excellent example for the subject of this
thread: "reject_unknown_client_hostname", I use it, I like it, and I
reliably send and receive all the SMTP email that I feel is necessary.
Occasionally there are wobbles but it's never been a crisis. Watch your
logs. Your mileage will vary.

Re: real life reasons not to use reject_unknown_client_hostname

By Dominic Raferd at 05/13/2018 - 04:05

What do people think about reject_unknown_reverse_client_hostname? I use
this presuming it to be safe, and it blocks lots of stuff.

Re: real life reasons not to use reject_unknown_client_hostname

By Vlad K at 05/14/2018 - 04:59

On 2018-05-13 10:05, Dominic Raferd wrote:

That's what we use, and from what I've seen it is effective, almost all
of the senders with no rDNS are from random-looking "From" addresses.
Those that aren't, are usually spammy @gmail accounts or mailing lists.

Even though others mentioned there may be legitimate senders with no
rDNS, I don't personally care. No rDNS? No mail from you. And in the
past 4 years of that policy we have not received a single complaint from
any of hundreds of our business clients, that some legitimate mail is
not coming through, due to that.

But, for a while I tried running with reject_unknown_client_hostname,
and that rejected legitimate mail. IMHO there's no need to demand full
ip->name->ip map.

Re: real life reasons not to use reject_unknown_client_hostname

By Viktor Dukhovni at 05/12/2018 - 19:00

For the record, when the problem is lost packets, lame delegations,
expired DNSSEC signatures, ... mail will be deferred (4XX error code)
not rejected (5XX). Only when the DNS definitively returns no
reverse or forward data, or the two don't match with the mail be
rejected by this restriction. Which still does not make it broadly
safe, but it is not quite so brittle as to hard fail for a few lost
packets or some other transient problem that makes queries fail.

Re: real life reasons not to use reject_unknown_client_hostname

By LuKreme at 05/12/2018 - 18:42

On 2018-05-12 (15:55 MDT), Thomas Smith <da-postfixusers- ... at abelonline dot de> wrote:
A mail sender doesn't have an A record.

Yes. Not a lot, but they do and they tend to be important things that often have incompetent mail admin (banks, for example).

Yes.

If you receive mail for anyone else but yourself, you cannot.

warn_if_reject reject_unknown_client_hostname

will log times this would have happened. Try it for a few days and see what is logged. Last time I did it, it was a lot of mail that was wanted. Perhaps things are better in 2018, but I doubt it.