reject_unknown_reverse_client_hostname query

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

reject_unknown_reverse_client_hostname query

Nick Howitt
I have the follosing restrictions in main.cf:

    smtpd_client_restrictions = permit_mynetworks,
    reject_unknown_reverse_client_hostname
    smtpd_recipient_restrictions = permit_mynetworks,
    permit_sasl_authenticated, reject_non_fqdn_hostname,
    reject_non_fqdn_sender, reject_non_fqdn_recipient,
    reject_invalid_hostname, check_policy_service
    unix:/var/spool/postfix/postgrey/socket, reject_unauth_pipelining,
    reject_unknown_recipient_domain, reject_rbl_client zen.spamhaus.org
    smtpd_relay_restrictions = permit_mynetworks,
    permit_sasl_authenticated, reject_unauth_destination
    smtpd_sender_restrictions = permit_mynetworks, check_sender_access
    hash:/etc/postfix/access, permit_sasl_authenticated,
    reject_non_fqdn_sender, reject_invalid_hostname


and I recently received an e-mail I thought should have been rejected.
The header is below (x headers and DKIM removed):

    Return-Path: <[hidden email]>
    Received: from localhost (localhost [127.0.0.1])
          by server.howitts.co.uk (Cyrus
    v2.4.17-Fedora-RPM-2.4.17-8.v7.1) with LMTPA;
          Sun, 24 Mar 2019 10:09:39 +0000
    Received: from localhost (localhost [127.0.0.1])
         by howitts.co.uk (Postfix) with ESMTP id 16BB7401361E
         for <[hidden email]>; Sun, 24 Mar 2019 10:09:39 +0000 (GMT)
    Authentication-Results: server.howitts.co.uk (amavisd-new);
         dkim=pass (2048-bit key) header.d=howitts.co.uk
    Received: from howitts.co.uk ([127.0.0.1])
         by localhost (server.howitts.co.uk [127.0.0.1]) (amavisd-new,
    port 10024)
         with ESMTP id 2mbKEOm3NT5q for <[hidden email]>;
         Sun, 24 Mar 2019 10:09:35 +0000 (GMT)
    Received: from localhost (localhost [127.0.0.1])
         by howitts.co.uk (Postfix) with ESMTP id E1436403B6E4
         for <[hidden email]>; Sun, 24 Mar 2019 10:09:34 +0000 (GMT)
    Received: from hz.cn (unknown [220.191.208.116])
         by howitts.co.uk (Postfix) with ESMTP id 6614E401361E
         for <[hidden email]>; Sun, 24 Mar 2019 10:09:30 +0000 (GMT)
    Received: from [92-245-104-63.mega.kg] (unknown [92.245.104.63])
         by app2 (Coremail) with SMTP id wROGCgAXH_P5Updcy7ZsAw--.3795S5;
         Sun, 24 Mar 2019 17:51:01 +0800 (CST)
    From: <[hidden email]>
    Organization: Jkhkuhcoqn
    Subject: [SPAM] username
    User-Agent: SquirrelMail/1.4.8-21.el5.centos
    List-Unsubscribe:
      <https://oylnc.us3.list-manage.com/unsubscribe?u=umdm5qcwce820ce70m9rutyr6&id=ly5letal4f&e=ll9g3ot0od&c=pyfmiaa2ye>,
    <mailto:[hidden email]?subject=unsubscribe>
    Message-ID: <um6q1ali-l34m-1ngs-7v36-9xquw37ned8b>
    X-Sender-Info: <[hidden email]>
    Date: Sun, 24 Mar 2019 10:51:03 +0100
    To: [hidden email]
    Content-Type: multipart/related;
      boundary="--_com.android.email_77040368709730"
    MIME-Version: 1.0
    Sender: [hidden email]


I would have expected this to have been dropped by the
reject_unknown_reverse_client_hostname filter as 220.191.208.116 does
not have a PTR record. The logs for this transaction (amavis and
opendkim removed to cut the output) are:

    Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
    mail.hz.cn does not resolve to address 220.191.208.116
    Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
    unknown[220.191.208.116]
    Mar 24 10:09:31 server postgrey[800]: action=pass, reason=triplet
    found, delay=724, client_name=unknown,
    client_address=220.191.208.116, sender=[hidden email],
    recipient=[hidden email]
    Mar 24 10:09:31 server postfix/smtpd[8102]: 6614E401361E:
    client=unknown[220.191.208.116]
    Mar 24 10:09:32 server postfix/cleanup[8108]: 6614E401361E:
    message-id=<um6q1ali-l34m-1ngs-7v36-9xquw37ned8b>
    Mar 24 10:09:34 server postfix/qmgr[4531]: 6614E401361E:
    from=<[hidden email]>, size=242365, nrcpt=1 (queue active)
    Mar 24 10:09:34 server postfix/smtpd[8127]: connect from
    localhost[127.0.0.1]
    Mar 24 10:09:34 server postfix/smtpd[8127]: E1436403B6E4:
    client=localhost[127.0.0.1]
    Mar 24 10:09:34 server postfix/cleanup[8108]: E1436403B6E4:
    message-id=<um6q1ali-l34m-1ngs-7v36-9xquw37ned8b>
    Mar 24 10:09:35 server postfix/qmgr[4531]: E1436403B6E4:
    from=<[hidden email]>, size=242537, nrcpt=1 (queue active)
    Mar 24 10:09:35 server postfix/smtpd[8127]: disconnect from
    localhost[127.0.0.1]
    Mar 24 10:09:35 server postfix/pipe[8124]: 6614E401361E:
    to=<[hidden email]>, relay=mailprefilter, delay=4.2,
    delays=3.9/0.01/0/0.28, dsn=2.0.0, status=sent (delivered via
    mailprefilter service)
    Mar 24 10:09:35 server postfix/qmgr[4531]: 6614E401361E: removed
    Mar 24 10:09:35 server postfix/smtpd[8102]: disconnect from
    unknown[220.191.208.116]
    Mar 24 10:09:39 server postfix/smtpd[8146]: connect from
    localhost[127.0.0.1]
    Mar 24 10:09:39 server postfix/smtpd[8146]: 16BB7401361E:
    client=localhost[127.0.0.1]
    Mar 24 10:09:39 server postfix/cleanup[8108]: 16BB7401361E:
    message-id=<um6q1ali-l34m-1ngs-7v36-9xquw37ned8b>
    Mar 24 10:09:39 server postfix/qmgr[4531]: 16BB7401361E:
    from=<[hidden email]>, size=244229, nrcpt=1 (queue active)
    Mar 24 10:09:39 server postfix/smtpd[8146]: disconnect from
    localhost[127.0.0.1]
    Mar 24 10:09:39 server postfix/smtp[8129]: E1436403B6E4:
    to=<[hidden email]>, relay=127.0.0.1[127.0.0.1]:10024,
    delay=4.4, delays=0.23/0.01/0/4.2, dsn=2.0.0, status=sent (250 2.0.0
    from MTA(smtp:[127.0.0.1]:10026): 250 2.0.0 Ok: queued as 16BB7401361E)
    Mar 24 10:09:39 server postfix/qmgr[4531]: E1436403B6E4: removed
    Mar 24 10:09:39 server lmtp[8153]: Delivered:
    <um6q1ali-l34m-1ngs-7v36-9xquw37ned8b> to mailbox: user.username
    Mar 24 10:09:39 server lmtp[8153]: USAGE username user: 0.002008
    sys: 0.005020
    Mar 24 10:09:39 server postfix/pipe[8150]: 16BB7401361E:
    to=<[hidden email]>, relay=mailpostfilter, delay=0.44,
    delays=0.23/0.01/0/0.21, dsn=2.0.0, status=sent (delivered via
    mailpostfilter service)
    Mar 24 10:09:39 server postfix/qmgr[4531]: 16BB7401361E: removed


Have I misunderstood something or is something else at play?

Thanks,

Nick
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_reverse_client_hostname query

Wietse Venema
Nick Howitt:
> I have the follosing restrictions in main.cf:
>
>     smtpd_client_restrictions = permit_mynetworks,
>     reject_unknown_reverse_client_hostname

What is the output from "postconf mynetworks"?

If the client matches that, then "permit_mynetworks"
will override reject_unknown_reverse_client_hostname.

        Wietse

> I would have expected this to have been dropped by the
> reject_unknown_reverse_client_hostname filter as 220.191.208.116 does
> not have a PTR record. The logs for this transaction (amavis and
> opendkim removed to cut the output) are:
>
>     Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
>     mail.hz.cn does not resolve to address 220.191.208.116
>     Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
>     unknown[220.191.208.116]
>     Mar 24 10:09:31 server postgrey[800]: action=pass, reason=triplet
>     found, delay=724, client_name=unknown,
>     client_address=220.191.208.116, sender=[hidden email],
>     recipient=[hidden email]
>     Mar 24 10:09:31 server postfix/smtpd[8102]: 6614E401361E:
>     client=unknown[220.191.208.116]
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_reverse_client_hostname query

Nick Howitt


On 24/03/2019 21:53, Wietse Venema wrote:

> Nick Howitt:
>> I have the follosing restrictions in main.cf:
>>
>>      smtpd_client_restrictions = permit_mynetworks,
>>      reject_unknown_reverse_client_hostname
> What is the output from "postconf mynetworks"?
>
> If the client matches that, then "permit_mynetworks"
> will override reject_unknown_reverse_client_hostname.
>
> Wietse
[root@server ~]# postconf mynetworks
mynetworks = 127.0.0.0/8, [::1]/128, 172.17.2.0/23, $clearglassnetwork

and:

[root@server ~]# postconf clearglassnetwork
clearglassnetwork = 172.19.0.0/16

>> I would have expected this to have been dropped by the
>> reject_unknown_reverse_client_hostname filter as 220.191.208.116 does
>> not have a PTR record. The logs for this transaction (amavis and
>> opendkim removed to cut the output) are:
>>
>>      Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
>>      mail.hz.cn does not resolve to address 220.191.208.116
>>      Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
>>      unknown[220.191.208.116]
>>      Mar 24 10:09:31 server postgrey[800]: action=pass, reason=triplet
>>      found, delay=724, client_name=unknown,
>>      client_address=220.191.208.116, sender=[hidden email],
>>      recipient=[hidden email]
>>      Mar 24 10:09:31 server postfix/smtpd[8102]: 6614E401361E:
>>      client=unknown[220.191.208.116]

Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_reverse_client_hostname query

Viktor Dukhovni
In reply to this post by Nick Howitt
On Sun, Mar 24, 2019 at 09:00:24PM +0000, Nick Howitt wrote:

[ Please avoid pasting "non-breaking space" characters into
  your email.  It is tedious to have to convert these to ASCII. ]

> The header is below (x headers and DKIM removed):
>  
>     Return-Path: <[hidden email]>
>     Received: from hz.cn (unknown [220.191.208.116])
>          by howitts.co.uk (Postfix) with ESMTP id 6614E401361E
>          for <[hidden email]>; Sun, 24 Mar 2019 10:09:30 +0000 (GMT)

The "unknown" means that either:

    1. The IP did not resolve to a PTR (name) record
    2. The name did not resolve back to the same IP

In case 2. the IP could have had a reverse name.

>     Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
>     mail.hz.cn does not resolve to address 220.191.208.116
>     Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
>     unknown[220.191.208.116]

This is case 2.

> Have I misunderstood something or is something else at play?

Inattention to detail, and/or unfamiliarity of the meaning of
"unknown" in the Received header.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_reverse_client_hostname query

Nick Howitt


On 24/03/2019 22:13, Viktor Dukhovni wrote:

> On Sun, Mar 24, 2019 at 09:00:24PM +0000, Nick Howitt wrote:
>
> [ Please avoid pasting "non-breaking space" characters into
>    your email.  It is tedious to have to convert these to ASCII. ]
>
>> The header is below (x headers and DKIM removed):
>>  
>>      Return-Path: <[hidden email]>
>>      Received: from hz.cn (unknown [220.191.208.116])
>>           by howitts.co.uk (Postfix) with ESMTP id 6614E401361E
>>           for <[hidden email]>; Sun, 24 Mar 2019 10:09:30 +0000 (GMT)
> The "unknown" means that either:
>
>      1. The IP did not resolve to a PTR (name) record
>      2. The name did not resolve back to the same IP
>
> In case 2. the IP could have had a reverse name.
>
>>      Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
>>      mail.hz.cn does not resolve to address 220.191.208.116
>>      Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
>>      unknown[220.191.208.116]
> This is case 2.
>
>> Have I misunderstood something or is something else at play?
> Inattention to detail, and/or unfamiliarity of the meaning of
> "unknown" in the Received header.
>
Sorry but I am unfamiliar with the term "non-breaking space". Is pasting
from PuTTy or Notepad++ causing an issue?

As far as I can see 220.191.208.116 has no PTR so should fall under your
case 1? Or have I misunderstood?

[root@server ~]# dig -x 220.191.208.116 @8.8.8.8

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> -x 220.191.208.116 @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29403
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;116.208.191.220.in-addr.arpa.  IN      PTR

;; Query time: 14 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Mar 24 22:24:00 GMT 2019
;; MSG SIZE  rcvd: 57


Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_reverse_client_hostname query

Viktor Dukhovni
On Sun, Mar 24, 2019 at 10:28:27PM +0000, Nick Howitt wrote:

> >>      Received: from hz.cn (unknown [220.191.208.116])
> >>           by howitts.co.uk (Postfix) with ESMTP id 6614E401361E
> >>           for <[hidden email]>; Sun, 24 Mar 2019 10:09:30 +0000 (GMT)
> >
> > The "unknown" means that either:
> >
> >      1. The IP did not resolve to a PTR (name) record
> >      2. The name did not resolve back to the same IP
> >
> > In case 2. the IP could have had a reverse name.
> >
> >>      Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
> >>      mail.hz.cn does not resolve to address 220.191.208.116
> >>      Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
> >>      unknown[220.191.208.116]
> >
> > This is case 2.

We know it is case 2., because Postfix logged failure to map
"mail.hz.cn" back to the address.  So it got the "220.191.208.116"
from somewhere, the only possible source being the PTR record, the
IP address had one at the time the message was received.

> Sorry but I am unfamiliar with the term "non-breaking space". Is pasting
> from PuTTy or Notepad++ causing an issue?

The text you posted had lots of Unicode non-breaking spaces (U+00A0),
rather than ASCII spaces (U+0020).

> As far as I can see 220.191.208.116 has no PTR so should fall under your
> case 1? Or have I misunderstood?

It may not now, but it did then.

> [root@server ~]# dig -x 220.191.208.116 @8.8.8.8
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> -x 220.191.208.116 @8.8.8.8
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29403
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

[ Yet more non-breaking spaces in the pasted dig output. :-( ]

This is not an NXDOMAIN, rather a lookup failure, so the PTR may
be there, just not working presently:

    http://dnsviz.net/d/116.208.191.220.in-addr.arpa/dnssec/

    [220.191 is at this time a lame delegation]

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_reverse_client_hostname query

Wietse Venema
In reply to this post by Viktor Dukhovni
Viktor Dukhovni:

> On Sun, Mar 24, 2019 at 09:00:24PM +0000, Nick Howitt wrote:
>
> [ Please avoid pasting "non-breaking space" characters into
>   your email.  It is tedious to have to convert these to ASCII. ]
>
> > The header is below (x headers and DKIM removed):
> >  
> >     Return-Path: <[hidden email]>
> >     Received: from hz.cn (unknown [220.191.208.116])
> >          by howitts.co.uk (Postfix) with ESMTP id 6614E401361E
> >          for <[hidden email]>; Sun, 24 Mar 2019 10:09:30 +0000 (GMT)
>
> The "unknown" means that either:
>
>     1. The IP did not resolve to a PTR (name) record
>     2. The name did not resolve back to the same IP
>
> In case 2. the IP could have had a reverse name.
>
> >     Mar 24 10:09:30 server postfix/smtpd[8102]: warning: hostname
> >     mail.hz.cn does not resolve to address 220.191.208.116
> >     Mar 24 10:09:30 server postfix/smtpd[8102]: connect from
> >     unknown[220.191.208.116]
>
> This is case 2.
>
> > Have I misunderstood something or is something else at play?
>
> Inattention to detail, and/or unfamiliarity of the meaning of
> "unknown" in the Received header.

To clarify,

1) The reverse name (PTR) lookup succeeded. The client would be NOT
be rejected by reject_unknown_reverse_client_hostname.

2) The IP address lookup for the name produced the wrong IP address.
The client would be rejected by reject_unknown_client_hostname.

        Wietse