Advanced E-Mail Reverse Lookup Matching

Avitar.Net - Plan, Protect, Grow
Plan, Protect, Grow


Log In or Register
Search Site

Navigation

Keep The Project Going!
Donate to Project JAK



Avitar.Net / Advanced E-Mail Reverse Lookup Matching

Abstract

Discusses advanced email reverse lookup methods that should be implemented in email servers.

Advanced E-Mail Reverse Lookup Matching

As it is now, Reverse lookup matching as implemented in most email servers is not helpful because it is too strict and restrictive. If it gets a slight tweak it can be used to reject spoofed email.

To make this feature useful again, I suggest that reverse lookup matching also considers all A records that correspond to MX records for the domain to be valid. Part of the problem is that the HELO/EHLO commands are used to get server info (which i belive isn't a RFC requirement followed much). Here is my idea which does pretty much the same thing, but with DNS servers:

  • bill@microsoft.com
The email address domain is removed from the email address.
  • microsoft.com
The IP address of the email server is compared to this address:
  • if it is "207.46.130.108" we stop and accept the email; this is valid (unlikely).
If the above address is not valid, get all the mail servers (MX) for microsoft.com.
  • maila.microsoft.com. 131.107.3.125 131.107.3.124
  • mailb.microsoft.com. 131.107.3.123 207.46.121.51
  • mailc.microsoft.com. 207.46.121.53 207.46.121.52
Now if the email is coming from any of these ip addresses we stop and accept the email, or else we fail and reject the email message.

Basically what we are doing is rejecting email that is originating from a mail server that is not authorized in the DNS server to be a mail server. This is similar to an SPF record lookup, however there a few differences:

Good:

  1. DNS MX records are a prestandardized methodology that is implemented for mail servers as per the RFC's
  2. It is the exception, not the rule that email is legitimately sent from an email address that does not have a IP address that corresponds to a valid MX record.

Bad:

  1. Slower lookup times since you will have to perform a MX query then a SPF (many records returned instead of 1) although it should have a positive return on total server overhead.

Types of email this will prevent: Simple scripts that abuse relay servers from bogus addresses like:

  • god@heaven.com
  • viagra@.com
  • hello
Of course admins should implement white lists of trusted IP's for any rare exception they may have to this rule. In addition they can ignore this check if there is a proper match already when checking SPF records. This is a type of backup that can be used in the case that spf records return a hard fail or a soft fail to enhance security.

Related