20

I've recently dropped SpamAssassin and am now basing spam rejection on DNSRBL's, grey-listing and other basic tests and I'm wondering whether I should also block hosts that don't have a valid RDNS matching the EHLO?

If I do this, am I going to make trouble for much legitimate mail and upset my customers? I've heard people griping that AOL do this, which makes me think it's perhaps too uncommon for me to do.

I'm also wondering if I can compromise by checking that RDNS is at least set to something, but not try to match it to the EHLO. Is this possible with Postfix (and is it useful)?

Andrew B
  • 31,858
  • 12
  • 90
  • 128
Peter White
  • 576
  • 1
  • 7
  • 17
  • 4
    Yes, it's commonly done, even if a very tiny number of people have issues with it. See [Fighting Spam - What can I do as an: Email Administrator, Domain Owner, or User?](http://serverfault.com/a/419475/126632) for further discussion. – Michael Hampton Sep 20 '13 at 14:32
  • [Jon Postel disagrees](http://en.wikipedia.org/wiki/Robustness_principle) :-) – Mathias R. Jessen Sep 24 '13 at 20:54
  • Many moons ago, reverse lookup on a fresh install of sendmail in Red Hat was the default... I think rDNS, while not a formal standard for mail servers, is pretty much the defacto standard. It screws over folks on dynamic IP addresses (i.e. homes with consumer grade ISP connetions) but it used to be, once upon a time, that the bulk of those dynamic IPs with connections were botnets...dunno about nowdays. – Avery Payne Oct 03 '14 at 21:33

5 Answers5

12

It's extremely common to block SMTP servers that don't have these basics:

  1. Hostname in HELO forward resolves to IP connection originated from.
  2. Connections origin IP reverses to the Hostname claimed in HELO.
  3. If SPF, DKIM, or DMARC policies exist, verify.

Anyone griping about getting blocked because of one of these should be tarred and feathered.
People who end up getting blocked for other reasons, particularly situations that rely on RFC conformance in "abnormal" situations, I'll have sympathy for. Spam is such a problem that there's just no excuse for missing the basics though.

Wesley
  • 32,320
  • 9
  • 80
  • 116
Chris S
  • 77,337
  • 11
  • 120
  • 212
  • 2
    Reverse lookuped name is not required to match HELO at all. Host can operate alot of domains while reverse lookup returns only one primary name. – Kondybas Sep 21 '13 at 00:37
  • 1
    Sure, you can do whatever you want. Your sever will be getting a `511 Your rDNS doesn't match your HELO` from my servers, and a whole lot of others as well. Spam is a major problem, that the designers of the SMTP RFC didn't have to deal with. Realistic requirements are distinctly different from the RFCs in little ways. – Chris S Sep 21 '13 at 04:08
  • Spam is not a problem when MTA is properly configured. My experience shows that (failed rDNS `OR` matched short local regex-list `OR` bayes matched) detects 99.99% of spam. No DNSBLs, no greylists, no DKIM, no SPF. 200k+ incoming messages monthly. 1-2 false-p, 10-20 false-n per month. – Kondybas Sep 21 '13 at 13:11
12

I have tried multiple approaches with the HELO/EHLO checking with a fairly decent sized customer base of between 100k-200k users and ended up going with a solution that does the following:

  • Check that the HELO/EHLO contains a domain name. -- This mostly boils down to does the name have a dot in it. Checking the DNS on the name led to MANY failed servers as its not uncommon to have the server present an internal name or something you can't resolve properly.
  • Check that the IP has a reverse DNS record. -- Again this is a lax setting as we don't check it against the HELO/EHLO. Checking against the HELO/EHLO created so many tickets this setting didn't last even a single day.
  • Check the senders domain name is valid. -- This is a basic check to make sure if we do have to bounce the message there will at least be some way to find a server for it.

Here's the Postfix block we use for these checks:

smtpd_recipient_restrictions =
    reject_non_fqdn_sender,
    reject_unauth_destination,
    reject_unknown_reverse_client_hostname,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_sender_domain,
    reject_non_fqdn_recipient
Ed.
  • 416
  • 2
  • 8
  • 1
    Also good additional approach is to check hostname against list of regexes that matches various names dynamically assigned by ISP like `xxxx.dynamic.yyy.com` or `12-34-56-78.dsl.zzz.com`. All such hosts should send their mail through ISP's relay and not directly to the recipient's MX. Mainly such hosts are the botnet nodes and their messages I've use to learn my bayes. – Kondybas Sep 21 '13 at 00:03
  • This looks like it might be the solution for me. Is there a way to run SpamAssassin and let it be by-passed by all, except for those mails which failed HELO matching with RDNS, then we only bounce those above a certain score? Other mails continue to completely by-pass this step. – Peter White Sep 21 '13 at 00:43
  • With the exim MTA I've done that way, sequentially: sender's addr/host is checked against white list. If matched - accepted immediately, else is checked against black list. If matched - variable flag raised "Gotcha!" and message is also accepted. If message has been passed through the lists - it is passed to the SA that acts as daemon. If returned value high enough, flag "Gotcha!" raised and message also accepted. Then message passed to the routers. – Kondybas Sep 25 '13 at 09:36
  • 1
    If flag is not raised message is delivered as usual. Otherwise blind copy is produced. Original message is delivered as usual again, while BC is passed to the special router that has sa-learn as transport. Such scheme allow to split mailflow into the definitely spam branch that learn SA-bayes, and suspicious the rest that checked by SA-bayes. Messages with flag raised also have an additional header that allow to sort them into the "Junk" – Kondybas Sep 25 '13 at 09:44
  • I checked those rules against my mailbox, and there are e-mails that would have been rejected because of non-domain HELO or the lack of a reverse DNS record. There are admittedly very few of them (just a few senders in a mailbox with 40 000 emails), but there is important stuff there. In particular, if I had used `reject_unknown_reverse_client_hostname`, an email with the results of my visa application to a particular Southeast Asian country wouldn't have come through. I'd advise against using `reject_invalid_helo_hostname` and `reject_unknown_reverse_client_hostname`. – michau Jul 31 '19 at 16:30
  • @michau most of us probably don't need a visa from a country that can't afford to setup a standard email server :))) – Mladen B. Nov 27 '21 at 16:44
6

I would expect sending MTA to have valid RDNS but insisting on matching EHLO would depend on who 'the customers' are. You can find some interesting guidelines in RFC5321:

2.3.5.

(...) 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 (...)

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.

but then in 7.9.

It is a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server.(...)

Community
  • 1
Dusan Bajic
  • 2,046
  • 1
  • 17
  • 20
  • 1
    This is probably prohibited because the string sent with EHLO, in the real world, is often not RFC-compliant. I've seen internal hostnames, `localhost`, and many other wrong things sent here, even with perfectly legitimate mail. – Michael Hampton Sep 20 '13 at 15:16
3

Reverse lookup not necessarily points to the hostname provided in HELO. Sometimes multiple domains hosted on the same host, and all of them have the same IP address. But when you try to do the reverse lookup, you'll get the name that has been placed in the PTR-record. It's obvious that both FQDNs will be different - and that is completely acceptible.

The only circumstance that allow to drop message is failed reverse lookup. Any succesful lookup means that host is valid. Names shouldn't match.

Kondybas
  • 6,864
  • 2
  • 19
  • 24
  • 1
    "It's obvious that both FQDNs will be different - and that is completely acceptible." No. You can only configure one PTR record and your mail server can only announce one hostname in the HELO. So it should be obvious that both can match. – Chris S Sep 07 '14 at 14:01
2

I'm wondering whether I should also block hosts that don't have a valid RDNS matching the EHLO?

No, you shouldn't. Blocks a whole email only by one criteria it's a bad practice.

If I do this, am I going to make trouble for much legitimate mail and upset my customers?

more likely you do and will lost legitimate mail

I'm also wondering if I can compromise by checking that RDNS is at least set to something, but not try to match it to the EHLO. Is this possible with Postfix (and is it useful)?

yes, it possible. You can use reject_unknown_reverse_client_hostname instead of reject_unknown_client_hostname

Unfortunately, postfix doesn't have a flexible options for "complex decision". In exim you can add some points for such mails, for e.g.

Score = 0 
1. The HELO or EHLO hostname is not in fully-qualified domain or address literal form. Score +=10
2. The HELO or EHLO hostname has no DNS A or MX record. Score +=20
3. The HELO or EHLO hostname is listed with the A record "d.d.d.d" under rbl_domain. Score +=20
4. The sender domain has no DNS A or MX record. Score +=10
5. SPF checks return softfail. Score +=10, fail, Score +=20
...

And so on. After all checks will be completed and if you had Score > 100, you can reject mail. Actually you can get such behavior, but you would need to write your own policy service

ALex_hha
  • 7,025
  • 1
  • 23
  • 39