0

Does forward confirmed reverse dns (fcrdns) only lookup ip to hostname and then hostname to ip or does it compare to the first hostname as well (especially in spam filtering)?

Let's say i have these records:

  • A reverse.somedomain: 127.0.0.1
  • A mail.somedomain: 127.0.0.1
  • A mail.mailserverdomain: 127.0.0.1
  • PTR 127.0.0.1: reverse.somedomain

A MTA tries to verify the RDNS of the host and resolves mail.mailserverdomain to 127.0.0.1, then reverse 127.0.0.1 to reverse.somedomain, and then forward reverse.somedomain to 127.0.0.1. Will this be a valid FCRDNS or does the PTR record need to point to the name given in the HELO command (how the mailserver identifies itself)?

The question boils down to the question, if FCRNDS uses two or three queries, so the sequence is either:

  • Got HELO mail.senderdomain
  • Resolve mail.senderdomain to the IP.
  • Resolve connecting IP to hostname.senderdomain

FAIL: hostname.senderdomain != mail.senderdomain

or

  • Got HELO mail.senderdomain
  • Resolve mail.senderdomain to the IP
  • Resolve IP to hostname.senderdomain
  • Resolve hostname.senderdomain to the same IP

SUCCESS: hostname.senderdomain matches the connecting ip and vice versa.

As a useful check needs to confirm the HELO hostname against the ip (else my mailserver could claim in HELO to be google), there will be a forward lookup, which is compared against the connecting ip. Then the next step is the reverse lookup, giving a hostname of the connecting ip. Now the shorter sequence would compare the hostnames, while the longer does another forward lookup and compares the ips.

If the first sequence is used, this would mean, that using functional hostnames like mail.domain in the mailserver configuration while using hostnames which identify a host in the rDNS like server123.domain would get your message flagged as possible spam.

allo
  • 1,524
  • 1
  • 19
  • 35

1 Answers1

1

Actually neither.

FCRDNS stands for "Forward Confirmed Reverse DNS".

How this works is that, first, the PTR record of the connecting IP address is looked up. If it hasn't got a PTR record, then the check instantly fails. A mail server with this feature on will then reject the connection, such as this rejection taken from my own mail server:

Sep 18 02:48:10 grummle postfix/smtpd[16577]: NOQUEUE: reject: RCPT from unknown[204.51.178.49]: 450 4.7.1 Client host rejected: cannot find your hostname, [204.51.178.49]; from=<sent19274@eachbuyermail.net> to=<me@example.com> proto=ESMTP helo=<smtp49.rsend1.com>

Because 204.51.178.49 has no PTR record, the reverse DNS check fails.

The second step is to take the hostname that was returned, and look up its IP address. That IP address must match the IP address that made the connection to the server. This is what forward confirmed means. If it does not, then again we reject the connection. (So few make it this far that I don't even have an example in the last week's worth of logs.)

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • So neither the DNS name in the used MX record needs to match, nor the Hostname sent after the HELO command and only the A(AAA) record of the FQDN returned in the reverse lookup is checked? My fear was, that the mailserver needs to send the hostname from the reverse record of it's ip. – allo Sep 20 '16 at 16:01
  • @allo You never said anything about HELO in your question. That's a separate check (and you could probably even make a third question). – Michael Hampton Sep 20 '16 at 17:14
  • Sorry, there is a wrong thought in there. When i send mail, my own MX record should be irrelevant. I extended the question with the two possible check sequences and why i fear that the shorter one could get you spam points. – allo Sep 20 '16 at 22:33
  • @allo Yes, it sounds like you are still confused. Nobody said anything about your own MX record. So I don't know why you mention it. Again, a DNS check of the string given with HELO is separate from the FCRDNS check of the IP address. – Michael Hampton Sep 20 '16 at 22:34
  • Are you sure about this? Because i thought for spam checking purposes you may want to ensure the identity of the connecting mailserver (given in the HELO command) matches the identity given by the rDNS. And this could use the first or second flow, depending on if the dedication of the ip to the mailserver should be checked. MX records do not matter there at all. – allo Sep 20 '16 at 22:41
  • @allo For the last time, the DNS check of HELO is completely separate to the FCRDNS check of the connecting IP address. – Michael Hampton Sep 20 '16 at 23:06