reject_unknown_client_hostname seems broken in postfix-2.11.20130710

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

reject_unknown_client_hostname seems broken in postfix-2.11.20130710

Why 42? The lists account.
Hello List,

a week or so ago I upgraded my OpenBSD mail server from OpenBSD 5.3 to 5.4, and
at the same time went from postfix-2.9.6 to postfix-2.11.20130710.
postfix-2.11.20130710 is the OpenBSD 5.4 default package, in case someone is
wondering "why that?".

I've been using "reject_unknown_client_hostname" more or less successfully for
years.

I understand that reject_unknown_client_hostname is not recommended for
indiscriminate use. In the meantime I have changed to
reject_unknown_reverse_client_hostname (and the false rejections stopped).  I
understand the risks of rejecting mail from mail servers with incorrect DNS
configurations. The point of this mail is not to go down a rat-hole about using
FCrDNS (Forward-Confirmed reverse DNS), but rather to point out a possible
problem with the postfix implementation of FCrDNS.

Since postfix-2.11.20130710 we have been falsely rejecting mails on a large
scale. The error message is:

    450 4.7.1 Client host rejected: cannot find your hostname, [<ip-address>]

The false rejects seem to have one thing in common: their DNS mappings are
non-trivial. By "trivial" I mean an IP-address has a single PTR record.  The
false rejects have either multiple PTR records, or there is a CNAME record that
must be looked up before the PTR record can be looked up.

The rejects are also not, AFAICT, caused by transient DNS lookup errors. I saw
many cases of repeated, consistent false rejection.

I wrote a simple Perl script to check each IP-address from which postfix
rejected a mail due to FCrDNS. The output of the script is at the end of this
mail. For a given IP-address, the script first looks up any/all PTR records,
following a CNAME record if necessary, and then it looks up all A records for a
PTR result and checks whether there is an IP-address that matches the original
address. Below I only list the false postfix rejections that occurred a few days
ago. Postfix rejected mails for a total of 25 addresses in the corresponding log
file, but I removed the correct rejections.

cheers,

Rob Urban

--snip--
82.165.11.104
    PTR:   [104.11.165.82.in-addr.arpa] --> [listserv.isdn4linux.de]
  - checking forward mapping -
    OK: listserv.isdn4linux.de maps to 82.165.11.104

163.20.103.129
    CNAME: [129.103.20.163.in-addr.arpa] --> [129.128/26.103.20.163.in-addr.arpa]
    PTR:   [129.128/26.103.20.163.in-addr.arpa] --> [dns.ymps.ntpc.edu.tw]
  - checking forward mapping -
    OK: dns.ymps.ntpc.edu.tw maps to 163.20.103.129

195.234.50.30
    PTR:   [30.50.234.195.in-addr.arpa] --> [dns1.tle.de]
    PTR:   [30.50.234.195.in-addr.arpa] --> [mail1.tle.de]
  - checking forward mapping -
    OK: dns1.tle.de maps to 195.234.50.30
    OK: mail1.tle.de maps to 195.234.50.30

72.26.200.202
    CNAME: [202.200.26.72.in-addr.arpa] --> [202.200/29.200.26.72.in-addr.arpa]
    PTR:   [202.200/29.200.26.72.in-addr.arpa] --> [mail.centos.org]
  - checking forward mapping -
    OK: mail.centos.org maps to 72.26.200.202

96.47.67.46  
    CNAME: [46.67.47.96.in-addr.arpa] --> [46.32/27.67.47.96.in-addr.arpa]
    PTR:   [46.32/27.67.47.96.in-addr.arpa] --> [forth.proz.com]
  - checking forward mapping -
    OK: forth.proz.com maps to 96.47.67.46

173.231.138.204
    CNAME: [204.138.231.173.in-addr.arpa] --> [204.192/27.138.231.173.in-addr.arpa]
    PTR:   [204.192/27.138.231.173.in-addr.arpa] --> [mail267.us2.mcsv.net]
  - checking forward mapping -
    OK: mail267.us2.mcsv.net maps to 173.231.138.204

195.178.100.249
    PTR:   [249.100.178.195.in-addr.arpa] --> [bmx1.immobilienscout24.de]
    PTR:   [249.100.178.195.in-addr.arpa] --> [bmx.bounce.immobilienscout24.de]
  - checking forward mapping -
    OK: bmx1.immobilienscout24.de maps to 195.178.100.249
    OK: bmx.bounce.immobilienscout24.de maps to 195.178.100.249

192.83.181.136
    PTR:   [136.181.83.192.in-addr.arpa] --> [webmail.ntsu.edu.tw]
    PTR:   [136.181.83.192.in-addr.arpa] --> [mail.ntsu.edu.tw]
    PTR:   [136.181.83.192.in-addr.arpa] --> [staffmail.ntsu.edu.tw]
  - checking forward mapping -
    OK: webmail.ntsu.edu.tw maps to 192.83.181.136
    OK: mail.ntsu.edu.tw maps to 192.83.181.136
    OK: staffmail.ntsu.edu.tw maps to 192.83.181.136

200.20.112.34
    PTR:   [34.112.20.200.in-addr.arpa] --> [correio.psycho.ufrj.br]
    PTR:   [34.112.20.200.in-addr.arpa] --> [correio.psicologia.ufrj.br]
  - checking forward mapping -
    OK: correio.psycho.ufrj.br maps to 200.20.112.34
    OK: correio.psicologia.ufrj.br maps to 200.20.112.34

74.92.67.124  
    PTR:   [124.67.92.74.in-addr.arpa] --> [terminal.standardelectronics.com]
    PTR:   [124.67.92.74.in-addr.arpa] --> [mail.standardelectronics.com]
  - checking forward mapping -
    OK: terminal.standardelectronics.com maps to 74.92.67.124
    OK: mail.standardelectronics.com maps to 74.92.67.124

195.234.50.3  
    PTR:   [3.50.234.195.in-addr.arpa] --> [dns2.tle.de]
    PTR:   [3.50.234.195.in-addr.arpa] --> [mail2.tle.de]
  - checking forward mapping -
    OK: dns2.tle.de maps to 195.234.50.3
    OK: mail2.tle.de maps to 195.234.50.3

Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname seems broken in postfix-2.11.20130710

Wietse Venema
IMAP List Administration:
> Hello List,
>
> a week or so ago I upgraded my OpenBSD mail server from OpenBSD 5.3 to 5.4, and
> at the same time went from postfix-2.9.6 to postfix-2.11.20130710.
> postfix-2.11.20130710 is the OpenBSD 5.4 default package, in case someone is
> wondering "why that?".

THIS FEATURE HAS NOT CHANGED, Therefore the change is outside of Postfix,
like, OpenBSD or your OpenBDS configuration.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname seems broken in postfix-2.11.20130710

Why 42? The lists account.
[resending to list, where I meant to send it...]

Hi Wietse,

On 01/31/2014 04:46 PM, Wietse Venema wrote:
> IMAP List Administration:
>> Hello List,
>>
>> a week or so ago I upgraded my OpenBSD mail server from OpenBSD 5.3 to 5.4, and
>> at the same time went from postfix-2.9.6 to postfix-2.11.20130710.
>> postfix-2.11.20130710 is the OpenBSD 5.4 default package, in case someone is
>> wondering "why that?".
> THIS FEATURE HAS NOT CHANGED, Therefore the change is outside of Postfix,
> like, OpenBSD or your OpenBDS configuration.

thanks for the quick answer.

Indeed, the problem was being caused by bug(s) in the OpenBSD implementation of
gethostbyaddr().

cheers,

Rob Urban
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname seems broken in postfix-2.11.20130710

Michael Tokarev


3 feb 2014 г. 17:08:31 GMT+04:00, IMAP List Administration <[hidden email]> wrote:
>
>Indeed, the problem was being caused by bug(s) in the OpenBSD
>implementation of
>gethostbyaddr().

Care to give some more information about those bug(s) please?

Thanks,

/mjt
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname seems broken in postfix-2.11.20130710

Michael Tokarev
In reply to this post by Why 42? The lists account.
3 feb 2014 г. 17:08:31 GMT+04:00, IMAP List Administration <[hidden email]> wrote:
>
>Indeed, the problem was being caused by bug(s) in the OpenBSD
>implementation of
>gethostbyaddr().

Care to give some more information about those bug(s) please?

Thanks,

/mjt
--
Отправлено через К-9 Mail. Извините за краткость, пожалуйста.
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname seems broken in postfix-2.11.20130710

Michael Tokarev
In reply to this post by Why 42? The lists account.
3 feb 2014 г. 17:08:31 GMT+04:00, IMAP List Administration <[hidden email]> wrote:
>
>Indeed, the problem was being caused by bug(s) in the OpenBSD
>implementation of
>gethostbyaddr().

Care to give some more information about those bug(s) please?

Thanks,

/mjt
--
Отправлено через К-9 Mail. Извините за краткость, пожалуйста.
--
Отправлено через К-9 Mail. Извините за краткость, пожалуйста.
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname seems broken in postfix-2.11.20130710

Michael Tokarev
In reply to this post by Michael Tokarev
03.02.2014 17:37, [hidden email] wrote:
[]

Please excuse me for this - sent 3 times.
It was my first attempt to use my android client for sending mail,
it had an issue submitting it to our (postfix) serveer and queued
mail, but i weren't able to find where the queue is..

/mjt

Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname seems broken in postfix-2.11.20130710

Why 42? The lists account.
In reply to this post by Michael Tokarev
Hello Michael,

On 02/03/2014 02:41 PM, [hidden email] wrote:
> 3 feb 2014 г. 17:08:31 GMT+04:00, IMAP List Administration <[hidden email]> wrote:
> >
> >Indeed, the problem was being caused by bug(s) in the OpenBSD
> >implementation of
> >gethostbyaddr().
>
> Care to give some more information about those bug(s) please?
apparently a large portion the DNS resolver was rewritten for OpenBSD 5.4. In
the changes for 5.4 one can find a number of bullet-items referring to the "new
resolver". I do not know why it was re-implemented.

Apparently the list of test-cases the author(s) used was not complete. In
particular, gethostbyaddr() would deliver a correct result for a "trivial"
query, i.e., if an address had a single PTR record.  But gethostbyaddr() would
fail for 2 types of non-trivial configurations:

1) if a CNAME record had to be looked up in order to be able to look up the PTR
record (a mechanism used by ISPs to delegate in-arpa address-spaces that are
usually smaller than a class C subnet -- RFC2317).

2) when trying to look up addresses with several PTR records.

Case 1 was caused by not allowing a slash ("/") character in names.

There is a patch available (look at the OpenBSD "tech" list) which seems to fix
the problem.

cheers,

Rob Urban