reject mail if dns and rdns differ

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

reject mail if dns and rdns differ

ratatouille-2
Hello all!

Received: from mail.namase.de (s1.bomberg.city [62.173.139.77])

I would like to reject incoming email if dns- and rdns-entries differ.
Does this make sense and how could I achieve this?

Kind regards

  Andreas
Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Matus UHLAR - fantomas
On 11.11.19 14:27, ratatouille wrote:
>Received: from mail.namase.de (s1.bomberg.city [62.173.139.77])
>
>I would like to reject incoming email if dns- and rdns-entries differ.
>Does this make sense and how could I achieve this?

they do not differ above.  The IP 62.173.139.77, rDNS is s1.bomberg.city and
points back to 62.173.139.77.

If the 62.173.139.77 did not have reverse name, or its reverse name (s1.bomberg.city
here) would not point back to 62.173.139.77, you'd see unknown instead of
s1.bomberg.city (the DNS name).

You can reject those cases by reject_unknown_client_hostname (either fails)
or reject_unknown_reverse_client_hostname (IP has no reverse DNS, no matter
if it points back).

mail.namase.de is the HELO (EHLO) name. You must not reject mail when helo
name differs from DNS name (RFC violation).


--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Depression is merely anger without enthusiasm.
Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Daniel Ryšlink
In reply to this post by ratatouille-2

Hello!

I believe you can achieve that by this restriction from "smtpd_client_restrictions" that can be included into the main.cf file:

      reject_unknown_client_hostname (with Postfix < 2.3:
       reject_unknown_client)
              Reject the request when 1) the client IP address->name mapping
              fails, or 2) the name->address mapping fails, or 3) the
              name->address mapping does not match the client IP address.
              This is a stronger restriction than the
              reject_unknown_reverse_client_hostname feature, which triggers
              only under condition 1) above.
              The unknown_client_reject_code parameter specifies the response
              code for rejected requests (default: 450). The reply is always
              450 in case the address->name or name->address lookup failed due
              to a temporary problem.

Please note that you can use several different restrictions, and besides client restrictions, there are also helo restrictions, recipient restrictions and sender restrictions that apply during their corresponding phases of the SMTP relation, so careful study of "man 5 postconf" or other documentation and examples is highly recommended.


-- 
S pozdravem,
Daniel Ryšlink
System Administrator

Dial Telecom a. s.
Křižíkova 36a/237
186 00 Praha 3, Česká Republika
Tel.:+420.226204627
[hidden email]
-----------------------------------------------
www.dialtelecom.cz
Dial Telecom, a.s.
Jednoduše se připojte
----------------------------------------------- 
On 11. 11. 19 14:27, ratatouille wrote:
Hello all!

Received: from mail.namase.de (s1.bomberg.city [62.173.139.77])

I would like to reject incoming email if dns- and rdns-entries differ.
Does this make sense and how could I achieve this?

Kind regards

  Andreas

Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Bill Cole-3
In reply to this post by Matus UHLAR - fantomas
On 11 Nov 2019, at 8:47, Matus UHLAR - fantomas wrote:

> On 11.11.19 14:27, ratatouille wrote:
>> Received: from mail.namase.de (s1.bomberg.city [62.173.139.77])
>>
>> I would like to reject incoming email if dns- and rdns-entries
>> differ.
>> Does this make sense and how could I achieve this?
>
> they do not differ above.  The IP 62.173.139.77, rDNS is
> s1.bomberg.city and
> points back to 62.173.139.77.
>
> If the 62.173.139.77 did not have reverse name, or its reverse name
> (s1.bomberg.city
> here) would not point back to 62.173.139.77, you'd see unknown instead
> of
> s1.bomberg.city (the DNS name).
>
> You can reject those cases by reject_unknown_client_hostname (either
> fails)

Which is unsafe, if you care about not rejecting even small amounts of
legitimate mail from some systems that transport large amounts of
legitimate mail.

> or reject_unknown_reverse_client_hostname (IP has no reverse DNS, no
> matter
> if it points back).

The 2nd clause inside the parentheses is redundant. :)

reject_unknown_reverse_client_hostname is much safer than
reject_unknown_client_hostname. In many years of using it I have only
seen a handful of undesirable rejections due to it or its analogs with
other MTAs. In every case, those have been due to objectively and
transiently broken DNS.

> mail.namase.de is the HELO (EHLO) name. You must not reject mail when
> helo
> name differs from DNS name (RFC violation).

True.

However, being a RFC violation is not by itself a sound reason to reject
any particular mail security tactic. RFC821, RFC822, and their
descendants are strongly influenced by the Postel's Robustness
Principle. Unfortunately, that has historically meant that MTA
implementations tolerate practices that are useful for spammers or are
simply wrong and idiosyncratic to particular spammers or spamming tools.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Fred Morris
I (mostly) concur with what Bill Cole says (maybe I'd quibble with the
"2nd clause" part).

Here's a shopworn blade which is in my list of things to rewrite in Python
one day:

     http://athena.m3047.net/pub/perl/mail-processing/realmailer.pl.txt

You call it from e.g. procmail, or in other words it expects a mail
message on STDIN and writes it back out with changes on STDOUT. It makes a
bunch of DNS queries. It adds a bunch of headers; it's up to you to do
with them as you wish.

It does a crappy job with SPF, oh well.

There are lots of reasons not to run this, and mitigations for most of the
reasons. I would strongly recommend pointing it at a local caching
resolver which is also used by the MTA.

On the plus side, it runs on Perl 5.26.1.

--

Fred Morris

Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Matus UHLAR - fantomas
On 11.11.19 09:29, m3047 wrote:

>I (mostly) concur with what Bill Cole says (maybe I'd quibble with the
>"2nd clause" part).
>
>Here's a shopworn blade which is in my list of things to rewrite in
>Python one day:
>
>    http://athena.m3047.net/pub/perl/mail-processing/realmailer.pl.txt
>
>You call it from e.g. procmail, or in other words it expects a mail
>message on STDIN and writes it back out with changes on STDOUT. It
>makes a bunch of DNS queries. It adds a bunch of headers; it's up to
>you to do with them as you wish.

why not spamassassin instead?

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
99 percent of lawyers give the rest a bad name.
Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Dusan Obradovic-2
In reply to this post by ratatouille-2


> On Nov 11, 2019, at 2:27 PM, ratatouille <[hidden email]> wrote:
>
> Hello all!
>
> Received: from mail.namase.de (s1.bomberg.city [62.173.139.77])
>
> I would like to reject incoming email if dns- and rdns-entries differ.
> Does this make sense and how could I achieve this?
>
> Kind regards
>
>  Andreas

Although it's a common occurrence that the host name specified in a HELO does not match IP rDNS (even from a well-known mail providers), you'd look into Postfix SMTP access policy delegation protocol to implement custom policy action based on helo_name and client_name. http://www.postfix.org/SMTPD_POLICY_README.html

Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

John Schmerold
On 11/12/2019 6:33 AM, Dusan Obradovic wrote:

>
>> On Nov 11, 2019, at 2:27 PM, ratatouille <[hidden email]> wrote:
>>
>> Hello all!
>>
>> Received: from mail.namase.de (s1.bomberg.city [62.173.139.77])
>>
>> I would like to reject incoming email if dns- and rdns-entries differ.
>> Does this make sense and how could I achieve this?
>>
>> Kind regards
>>
>>   Andreas
> Although it's a common occurrence that the host name specified in a HELO does not match IP rDNS (even from a well-known mail providers), you'd look into Postfix SMTP access policy delegation protocol to implement custom policy action based on helo_name and client_name. http://www.postfix.org/SMTPD_POLICY_README.html

You will be rejecting everything you get from Office 365, rDNS is for
the little people.

I am a big fan of rigid adherence to rDNS & SPF rules, doing so, however
would sentence me to a life in isolation.

--
John Schmerold
Katy Computer Systems, Inc
https://katycomputer.com
St Louis

Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

황병희-2
> I am a big fan of rigid adherence to rDNS & SPF rules, doing so,
> [...]

Well i don't know what rules are right things. Still i did not setup
SPF. Instead i think User-Agent/X-Mailer are important. In most case
linux softwares[1] have good manners in email world.

Sincerely,

[1] Mutt, ELM, PINE, Alpine, Evolution, Thunderbird, Sylpheed,
ClawsMail, Emacs, etc.

--
^고맙습니다 _地平天成_ 감사합니다_^))//
Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Ralph Seichter-2
* 황병희:

> i did not setup SPF. Instead i think User-Agent/X-Mailer are
> important.

The contents of these headers are easily faked, so relying on them is
questionable to me. Also, you will encounter User-Agent headers
generated by various libraries, like Java SMTP implementations. Finally,
what about emails without User-Agent header, which are perfectly valid?

SPF, by contrast, has at least some benefit when it comes to spam
prevention.

-Ralph
Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Viktor Dukhovni
In reply to this post by Bill Cole-3


> On Nov 11, 2019, at 11:09 AM, Bill Cole <[hidden email]> wrote:
>
>> mail.namase.de is the HELO (EHLO) name. You must not reject mail when helo
>> name differs from DNS name (RFC violation).
>
> True.

For the record, it is NOT an RFC violation for the EHLO name to
differ from the name in the PTR record of the connecting IP.
It suffices for the EHLO name to be some valid FQDN for the
client.  Thus it is for example valid to have:

        ehlo.example. IN A 192.0.2.1
        ptr.example. IN A 192.0.2.1
        1.2.0.192.in-addr.arpa. ptr.example.

The RFC merely says:

  https://tools.ietf.org/html/rfc5321#section-4.1.1.1

  4.1.1.1.  Extended HELLO (EHLO) or HELLO (HELO)

   These commands are used to identify the SMTP client to the SMTP
   server.  The argument clause contains the fully-qualified domain name
   of the SMTP client, if one is available.

  https://tools.ietf.org/html/rfc5321#section-2.3.5

   o  The domain name given in the EHLO command MUST be either a primary
      host name (a domain name that resolves to an address RR) or, if
      the host has no name, an address literal, as described in
      Section 4.1.3 and discussed further in the EHLO discussion of
      Section 4.1.4.

  https://tools.ietf.org/html/rfc5321#section-4.1.4

   The SMTP client MUST, if possible, ensure that the domain parameter
   to the EHLO command is a primary host name as specified for this
   command in Section 2.3.5.  If this is not possible (e.g., when the
   client's address is dynamically assigned and the client does not have
   an obvious name), an address literal SHOULD be substituted for the
   domain name.

There is no requirement for any relationship between the EHLO name and
any PTR record for the connecting IP address.

> However, being a RFC violation is not by itself a sound reason to reject any particular mail security tactic.

Yes, even when moot.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Bill Cole-3
On 12 Nov 2019, at 14:26, Viktor Dukhovni wrote:

>> On Nov 11, 2019, at 11:09 AM, Bill Cole
>> <[hidden email]> wrote:
>>
>>> mail.namase.de is the HELO (EHLO) name. You must not reject mail
>>> when helo
>>> name differs from DNS name (RFC violation).
>>
>> True.
>
> For the record, it is NOT an RFC violation for the EHLO name to
> differ from the name in the PTR record of the connecting IP.

Right and as was stated & I affirmed: it is explicit in RFC5321 S.4.1.4:

    An SMTP server MAY verify that the domain name argument in the EHLO
    command actually corresponds to the IP address of the client.
    However, if the verification fails, the server MUST NOT refuse to
    accept a message on that basis.

i.e. using an EHLO name that doesn't match the client IP in DNS isn't a
RFC violation and rejecting because of a mismatch IS a RFC violation.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Benny Pedersen-2
In reply to this post by Matus UHLAR - fantomas
Matus UHLAR - fantomas skrev den 2019-11-12 12:09:

> On 11.11.19 09:29, m3047 wrote:
>> I (mostly) concur with what Bill Cole says (maybe I'd quibble with the
>> "2nd clause" part).
>>
>> Here's a shopworn blade which is in my list of things to rewrite in
>> Python one day:
>>
>>    http://athena.m3047.net/pub/perl/mail-processing/realmailer.pl.txt
>>
>> You call it from e.g. procmail, or in other words it expects a mail
>> message on STDIN and writes it back out with changes on STDOUT. It
>> makes a bunch of DNS queries. It adds a bunch of headers; it's up to
>> you to do with them as you wish.
>
> why not spamassassin instead?

lockup_mx does not test for domains without mx

else its a nice perl
Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Viktor Dukhovni
In reply to this post by Bill Cole-3
> On Nov 12, 2019, at 3:52 PM, Bill Cole <[hidden email]> wrote:
>
>> For the record, it is NOT an RFC violation for the EHLO name to
>> differ from the name in the PTR record of the connecting IP.
>
> Right and as was stated & I affirmed: it is explicit in RFC5321 S.4.1.4:
>
>   An SMTP server MAY verify that the domain name argument in the EHLO
>   command actually corresponds to the IP address of the client.
>   However, if the verification fails, the server MUST NOT refuse to
>   accept a message on that basis.

The correct way to verify that would be to resolve the EHLO name to
an address, NOT to resolve the address to a name.  This would then
find no anomalies with:

        Received: from ehlo.example (ptr.example [192.0.2.1])

when ehlo.example also resolves to 192.0.2.1.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Matus UHLAR - fantomas
>>> For the record, it is NOT an RFC violation for the EHLO name to
>>> differ from the name in the PTR record of the connecting IP.

>> On Nov 12, 2019, at 3:52 PM, Bill Cole <[hidden email]> wrote:
>> Right and as was stated & I affirmed: it is explicit in RFC5321 S.4.1.4:
>>
>>   An SMTP server MAY verify that the domain name argument in the EHLO
>>   command actually corresponds to the IP address of the client.
>>   However, if the verification fails, the server MUST NOT refuse to
>>   accept a message on that basis.

On 12.11.19 17:01, Viktor Dukhovni wrote:
>The correct way to verify that would be to resolve the EHLO name to
>an address, NOT to resolve the address to a name.  This would then
>find no anomalies with:
>
> Received: from ehlo.example (ptr.example [192.0.2.1])
>
>when ehlo.example also resolves to 192.0.2.1.

I'm afraid this would have FPs too.

postfix supports reject_unknown_helo_hostname which only requires
ehlo.example to resolve.  It's even weaker requirement and has FPs too, but
I consider this one just enough

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
M$ Win's are shit, do not use it !
Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

황병희-2
In reply to this post by Ralph Seichter-2
[Sorry for late, Ralph.]

Ralph Seichter <[hidden email]> writes:

> * 황병희:
>
>> i did not setup SPF. Instead i think User-Agent/X-Mailer are
>> important.
>
> The contents of these headers are easily faked, so relying on them is
> questionable to me. Also, you will encounter User-Agent headers
> generated by various libraries, like Java SMTP implementations. Finally,
> what about emails without User-Agent header, which are perfectly valid?
>
> SPF, by contrast, has at least some benefit when it comes to spam
> prevention.

Totally you are right.

Though let me say more comments.

My point was sending email with good manners. So i am interested in good
software such as Mutt, Gnus, etc. Sorry man, my considering in email
culture is somewhat another universe.

Sincerely, Byung-Hee from South Korea.

--
^고맙습니다 _地平天成_ 감사합니다_^))//
Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Viktor Dukhovni
In reply to this post by Matus UHLAR - fantomas
> On Nov 13, 2019, at 4:30 AM, Matus UHLAR - fantomas <[hidden email]> wrote:
>
> On 12.11.19 17:01, Viktor Dukhovni wrote:
>> The correct way to verify that would be to resolve the EHLO name to
>> an address, NOT to resolve the address to a name.  This would then
>> find no anomalies with:
>>
>> Received: from ehlo.example (ptr.example [192.0.2.1])
>>
>> when ehlo.example also resolves to 192.0.2.1.
>
> I'm afraid this would have FPs too.

I was not suggesting that enforcing the check was a good idea.  Just
explaining *how* one would correctly enforce the check (if one wanted
to make sure that the FQDN in the EHLO matches the IP).

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

@lbutlr
In reply to this post by Matus UHLAR - fantomas
On 13 Nov 2019, at 02:30, Matus UHLAR - fantomas <[hidden email]> wrote:

> On 12.11.19 17:01, Viktor Dukhovni wrote:
>> The correct way to verify that would be to resolve the EHLO name to
>> an address, NOT to resolve the address to a name.  This would then
>> find no anomalies with:
>>
>> Received: from ehlo.example (ptr.example [192.0.2.1])
>>
>> when ehlo.example also resolves to 192.0.2.1.
>
> I'm afraid this would have FPs too.

*Everything* short of accepting all mail regardless has false positives.



--
I find Windows of absolutely no technical interest... Mac OS X is a rock
-solid system that's beautifully designed. I much prefer it to Linux. -- Bill Joy

Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Gregory Heytings

>
> *Everything* short of accepting all mail regardless has false positives.
>

Rejecting emails for non-existing users, or for domains of which your are
neither the final destination nor a relay, or coming from non-existing
domains, are filtering schemes that have zero false positives.  And there
are various techniques (for example connection rate limits, response
delays, greylisting) that prevent you from "accepting all mail" and that
have zero false positives.

Gregory
Reply | Threaded
Open this post in threaded view
|

Re: reject mail if dns and rdns differ

Jaroslaw Rafa
Dnia 21.11.2019 o godz. 23:50:15 Gregory Heytings pisze:
> And there are various techniques (for example connection
> rate limits, response delays, greylisting) that prevent you from
> "accepting all mail" and that have zero false positives.

As for greylisting, it's no more true now.

Some large and popular mail sending services started some time ago to send
mail in a way that is incompatible with greylisting. Greylisting assumes
that after first 4xx reject, the sending server will retry: a) after a few
minutes; b) from the same IP address. These services: a) retry immediately,
after 5-10 seconds; b) use different IP address on each retry and c) give up
after a few unsuccessful attempts. Thus it is possible you never get mail
sent from these services if you use greylisting.

WeTransfer is one example of such service. I ran into this issue when
someone send me files via WeTransfer and I never got the message with
download links. I checked my Postfix logs and discovered this behaviour.
Many other websites behave in a similar way, especially ones that use
Sendgrid to send emails. I also have lost some transactional emails (eg.
registration confirmation or password reset links) from several websites
(for example from Spotify) that way.

I even tried to contact these services and report the problem, but it
seems that they don't even understand what the problem is.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
12