• Domain Based Zones

Mailing List

Submit to:

• DSN ( <> )
• postmaster
• abuse
• whois
• bogusmx

Lookup

Listing Policy:

• General Guidelines
• DSN ( <> )
• postmaster
• abuse
• whois
• bogusmx

Contacting Sites

RSYNC Policy

Contact Us

Hosting of RFCI
provided through
the generosity of

postmaster.rfc-ignorant.org listing policy

Precedent - Annotated Reference: RFC2821/4.5.1

Type: Domain

• If the right-hand-side of an address doesn't have a postmaster address (e.g., given an address of <foo@example.tld>, if "postmaster@example.tld" bounces as non-existent (on any of the valid MX servers for 'example.tld'), then example.tld would be listed.
• After careful consideration, there seemed to be a consensus among users that use of blacklists, etc., did not meet the "narrowly tailored" requirements for blocking mail to postmaster, but that it would be undesirable to list sites simply for employing the MAPS RBL and such on their postmaster address. It was decided that we wouldn't list folks if the rejection message for postmaster seemed to indicate the reason for denial ("{ip} rejected as listed on the MAPS RBL", etc.)
• Further, if a postmaster address is inbound-only, (i.e., it is never used in any of the following: SMTP Envelope From, RFC 2822 'From' Header, or the RFC 2822 'Sender' header), then it is permissible under our policy to reject mail to the postmaster address from the null-envelope ('<>'). It is acknowledged by RFC-Ignorant that there are plenty of legitimate reasons why '<>' would be sending a message to <postmaster>, but they are not that prevalent in the field. It is also noted that the RFC2822 headers have no bearing on DSN destinations (in a properly designed system), but (a) not all systems are properly designed in such a manner, and (b) we are simply using it to determine what an "inbound only" message is, and if it appears in that context on an outbound message, then it is clearly not "inbound only"
• In the interests of openness, this does allow sites which have local rejections on certain IP addresses to accidentally end up listed if a site gets a bounce from a "single-IP rejection" that is vague (e.g., "551 5.7.1 Message Rejected") - however, since this has happened only once, it is not at present something that generates undue concern for us.
• In the case of "temporary failures", where the MX returns a 4xx series response to e-mails under consideration, it shall be considered a "fatal error" if, after the default sendmail queue-return time, (5 days), the recipient MX fails to accept the mail. In the case of a fatal error, the domain shall be considered to meet the listing criteria.
• Further, if a postmaster address contains a "redirecting auto-acknowledgement", such that it is obvious that the message will not be received by a human (as specified in the RFCs), that shall also be considered a listable offense. Auto-acks suggesting "better places" to send e-mail are certainly useful and encouraged, however, it must be clear that the e-mail that generated the auto-ack will in fact be dealt with.

  So, for example, BIGISP.COM could include an autoresponse that says:

  Thanks for contacting the postmaster; in the future you might get faster service if you send the complaint to abuse@bigisp.com for mail abuse issues, support@bigisp.com for technical support issues, or billing@bigisp.com for billing issues.

  They could not say:

  Thank you for contacting bigisp.com. Please resend your question to one of the following addresses, based on the specific nature of the complaint.

• If any of the valid MX servers for a domain have private, reserved, or otherwise bogus IP addresses, then the domain would be listed. (E.g., given an address of <foo@example.tld>, if the MX for example.tld is mail.example.tld, and the A record listed in DNS for mail.example.tld is 127.0.0.1, then example.tld would be listed.)
• Likewise, if all of the given MX RRs for a domain are invalid, for example by all being IP addresses instead of hostnames, then that domain shall be considered "undeliverable", since an RFC-compliant MTA would be unable to find a valid MX to contact after invalidating the bogus MX RRs. Such undeliverable status would cause a domain to be subject to listing.