Blocked by RFC-IGNORANT … Now what?

From time to time, customers wind up getting blocked by a seldom seen blacklist called ‘RFC-Ignorant.’  Unlike classical blacklists that are usually honeypot driven, this one is driven by people who have manually reported you as violating RFC.

RFC-Ignorant targets 5 specific faux-pas:

1. Lack of a Postmaster address on the server
2. Inability to accept an empty email address (mailfrom: <>)
3. Lack of an abuse mailbox
4. Bad WHOIS information about your domain
5. Bad MX record for your domain

1. Lack of Postmaster address

I often deal with customers who run Microsoft Exchange servers, and it’s very surprising that such a popular mail server doesn’t have a Postmaster email address by default.  It’s vitally important to have one. Here’s what RFC822 says about this:

‘It often is necessary to send mail to a site, without knowing any of its valid addresses.  For example, there may be mail system dysfunctions, or a user may wish to find out a person’s correct address, at that site.

This standard specifies a single, reserved mailbox address (local-part) which is to be valid at each site.  Mail sent to that address is to be routed to a person responsible for the site’s mail system or to a person with responsibility for general site operation.  The name of the reserved local-part address is: Postmaster, so that ‘Postmaster@domain’ is required to be valid.’

In other words, for RFC compliance, you must have a Postmaster address.

RFC-Ignorant goes one step further: most people who do have a Postmaster will have an auto-ack (automatic acknowledgement).  You must not say in your auto-ack to ‘Please email alternateadress@yourdomain.com if you have a problem,’ otherwise that too is grounds for blacklisting.

At best, you could write something like ‘Thank you for your submission.  Please note that you will get a faster response if you email alternateaddress@yourdomain.com.’

So, to recap:

– You must have a Postmaster address for each of your domains
– If it has an auto-ack, it should NOT say to ’email someone else otherwise it won’t be read’
– A human being should regularly check the contents of the Postmaster mailbox

2. Inability to accept an empty email address (mailfrom: <>)

Usually, when a bounce notification comes in, it will either come from postmaster@externaldomain.com or from a blank address.  Your mail server MUST accept emails with an SMTP mailfrom: <>. Rejecting these is grounds for blacklisting.

This is covered by RFC1123:

“The syntax shown in RFC-821 for the MAIL FROM: command omits the case of an empty path: “MAIL FROM: <>’ (see RFC-821 Page 15). An empty reverse path MUST be supported.’

3. Lack of an abuse mailbox

If, when you register a domain and plan to provide a mail server, you must provide an abuse@yourdomain.com email address.  Not having an abuse mailbox (especially if you’re an ISP) is grounds for blacklisting.  Again, Microsoft Exchange and most MTAs, by default, do not come with an abuse box.

For an ISP or xSP, it’s very important to have an abuse box. This is where most spam complaints will wind up should a spammer manage to get control of one your user’s accounts (via password phishing) and start spamming at large, or if one of your users starts spamming due to having their machine compromised by a botnet.

Lack of an abuse box can be grounds for blacklisting by RFC-Ignorant.

Section 4 of RFC2142 specifies the purpose of the abuse (and other) local-parts:

‘Operations addresses are intended to provide recourse for customers, providers and others who are experiencing difficulties with the organization’s Internet service.’

The rules for the Postmaster box also apply to the abuse box:

– You must have an abuse address for each of your domains
– If it has an auto-ack, it should NOT say to ’email someone else otherwise it won’t be read’
– You should have a human being that checks the abuser box regularly

4.  Bad WHOIS information about your domain

RFC-Ignorant can blacklist you if your domain WHOIS information is out of date or simply inaccurate.  This is fairly rare since someone must complain for you to be listed, but it is usually wise to keep your domain WHOIS, including contact information, up-to-date (the abuse contact being the most important aspect).

RFC1032 specifies that contact data for domains can be found via the WHOIS system:

Verification of Data

‘The verification process can be accomplished in several ways. One of these is through the NIC WHOIS server. If he has access to WHOIS, the DA can type the commmand ‘whois domain

‘. The reply from WHOIS will supply the following: the name and address of the organization ‘owning’ the domain; the name of the domain; its administrative, technical, and zone contacts; the host names and network addresses of sites providing name service for the domain.’

5. Bad MX record for your domain

RFC-Ignorant can blacklist you if you have an MX record that points back to an internal IP address (a reserved address that is not externally routable).

This is defined in the following RFCs:

– If any publicly listed MX record for a domain contains a hostname which points to a bogus IP address space, such as those documented in RFC 3330, or IPv6 reservations detailed in RFCs 3879, 4048, 4193, and 4291,
– Or if the domain contains an MX RR that points to an IP address, in violation of RFC 1035,
– Or if the domain has MX RRs which point to hostnames which themselves do not have an associated A record (including MXs which return an NXDOMAIN, or which are CNAMEs)
In a nutshell

– Make sure you have a Postmaster address for each domain
– Make sure you have an abuse address for each domain
– Make sure someone READS those mailboxes and RESPONDS to complaints
– Make sure that, if you have an auto-ack, it doesn’t stipulate that the mailboxes won’t be read and to   redirect complaints to an alternate box
– Make sure your MTA does not block empty mailfrom’s (mailfrom: <>)
– Make sure you have a valid WHOIS record for your domain(s)
– Make sure you do not have an MX record pointing to non routable (ie: internal/reserved) address

Links:

http://www.faqs.org/rfcs/rfc822.html
http://www.faqs.org/rfcs/rfc1123.html
http://www.faqs.org/rfcs/rfc2142.html
http://www.faqs.org/rfcs/rfc3030.html