Postfix: Fixing common DNS problems

Is my DNS a Mess? Probably!!

We don’t have time and space here to fix all those problems, but I’d like to concentrate now on:

How to Keep Your DNS from Blocking Mail Delivery from your and your Clients’ Mail Servers

Short, snappy headlines rule, OK!

IPv6, when widely implemented (you do have a plan, don’t you?) will fix a ton of Internet security problems. Until Nirvana arrives, we’ll have to do the best we can with the (DNS) technology in hand, which is a lot better than than mess we’ve got now.

Since I’ve become involved with postfix, a wonderful Mail Tranfser Agent (MTA) by Wietse Venema and IBM, used as the basis of my IMGate project (see link in left column), I’ve learned a lot about how advanced MTA’s such as postfix, qmail, and the latest version of sendmail can be setup to triangulate and validate any other mail servers who want to send them mail.

Using postfix as as example, just take a look at this page:

“Postfix Configuration – UCE Controls”

… to see how these MTA’s can really slam shut the mail door to any but the most trustworthy and identifiable mail servers.

How DNS Queries are used to Validate “SMTP Clients”

First of all, let’s look at snippet of an Ipswitch Imail “SMTPD server” log to see what information is provided by the “SMTP client” trying to send mail to our “SMTPD server”:

What kind of validations can the most circumspect, the most paranoid mail servers out there run against you and your hosted clients’ attempts to send mail?

With the ip of the SMTP client:

• Query DNS for PTR record of ip (reverse lookup)
  • Does the PTR record exist?
    No: reject mail.
  • Does the PTR record refer to the HELO / EHLO hostname?
    No: reject mail.
• Does the ip address’s “PTR hostname” have an A record??
  No: reject mail.
• Does the ip address’s “PTR hostname” have an MX record??
  No: reject mail.
• Is the ip address in Mail-Abuse.org’s MAPS databases of black-holes, open-relays, or dial-ups?
  Yes: reject mail.
• Is the reverse delegation the existent and/or correct?
  No: reject mail.

With the HELO / EHLO hostname:

• Does the hostname resolve to an A record?
  No: reject mail.
• Does the hostname resolve to an MX record?
  No: reject mail.
• Is the hostname a FQHN: Fully Qualified Host Name ?
  No: reject mail.
• If there is an A record, is the ip address in Mail-Abuse.org’s MAPS databases of black-holes, open-relays, or dial-ups?
  Yes: reject mail.

With the MAIL FROM: @senderdomain:

• Does the senderdomain resolve to an A record?
  No: reject mail.
• Does the senderdomain resolve to an MX record?
  No: reject mail.
• Is the senderdomain a FQHN: Fully Qualified Host Name ?
  No: reject mail.
• If there is an A record, is the ip address in Mail-Abuse.org’s MAPS databases of black-holes, open-relays, or dial-ups?
  Yes: reject mail.

NOTE: If you want to be able to control access to your mail server with aggressive validation like the above (and that’s not all that’s available), visit my site IMGate mentioned in the left column. No matter what brand of mail server you use, you can implement IMGate, increasing the availability, speed, reliability, and overall quality of your mail infrastructure. Without spending a penny.

 

How to Keep Your Domains UnMessy
(… and sending mail reliably!)

From the above, you can see that today’s “better” mail servers (eg.: my IMGate project link in left column) are using DNS database records to validate any alleged mail server presumptious enough to try to send mail.

So, being a responsible and freshly knowledgeable DNS administrator, you’re asking “How can I setup my DNS so that my own and my clients’ mail is reliably delivered to most restrictive mail servers?”

 

• Keep yo bad @ssout of the blocking databases such as Mail-Abuse.org and ORBS.Assuming you aren’t a spammer, the most common screw-up is running your mail server as an open-relay. What’s that?

  If you don’t know what these anti-spam databases are about, then spend some time studying the pages at Mail-Abuse.org.

• RFC 2505: Anti-Spam Recommendations for SMTP MTAs
• RFC 1912 Common DNS Operational and Configuration Errors
• Make sure your DNS has been delegated with reverse authority for your ip blocks by a higher, wider authority DNS.
• If your DNS is delegated with reverse zone authority, make sure your reverse zone is setup perfectly, at least for the ip addresses of your mail servers. But why stop there? Just populate your entire reverse zone with real hostnames and generic placeholder hostnames.Check your reverse zone: Is it, or is it not, working? Use the “ip block” and “Scan rDNS” tools at www.SamSpade.org. With the rDNS tool, if you get no results or the results are not what you put in your db. reverse zone file, then your reverse zone is broken.
• For every domainin your DNS, make sure the zone files contain at least these records:

  $ORIGIN mydomain.com.
  @    A      ip.ad.re.ss
  @    MX     10  mailhost.domain.com.

• For every mail host (real and virtual)in your DNS, make sure the zone files contain at least these records:

  $ORIGIN somedomain.com.
  mailhost   A   ip.ad.re.ss
  @          MX  10   mailhost.somedomain.com.
  mailhost   MX  10   mailhost.somedomain.com.

• For every mail host (real and virtual) in your DNS, make sure you know how your mailserver(s) is announcing itself in the HELO / EHLO hostnamefield.Is your SMTP client sending mail by first announcing itself as:

  EHLO mail.mydomain.com

  or

  EHLO mydomain.com

  or

  EHLO smtp.mydomain.com

  or

  EHLO (nothing)

  or

  EHLO someotherdomain.com

  ? ? ? ? ?

  And for whatever the “EHLO/HELO hostname” is:

  • It’s a FQHN, Fully Qualified Host Name: host.domain.com.
  • The FQHN has a A record.
  • The FQHN has an MX record.

If you get on top of the issues on this page, your DNS won’t be a mess anymore.

Consequently, your mail and mail servers will have the best chance of not being rejected or blacklisted.