Have you heard of RFC 2142? Let me explain what it is and how it relates to Deliverability.
The Internet Engineering Task Force (IETF) issues more than 100 Request For Comments (RFCs) a year. Since April 1969, when the first RFC was published, RFCs have defined how devices exchange information on the Internet.
Email Address RFCs
There are a number of RFCs containing recommendations of email addresses that must exist and some that are useful to effectively operate a mail system. For instance, every mail server must have a ‘postmaster’ mailbox, manned by a human (RFC 821 and RFC 822). Every web site must have a ‘webmaster’ mailbox too (RFC 2068) and every domain must have a ‘hostmaster’ mailbox (RFC 1033 to RFC 1035). As you can imagine, it becomes rather tedious to track all the email address related specifications spread across all of these RFCs.
Enter RFC 2142. Officially titled “Mailbox Names for Common Services, Roles and Functions”, RFC 2142 was written by Dave Crocker and published in May of 1997. RFC 2142 consolidates all of the email address related specifications in one document. It defines the mailboxes a system should have, including convenience mailboxes such as info, sales, noc, and abuse. All the email addresses annotated in RFC-2142 are extremely important but for this post we’ll focus on those that relate to email deliverability.
From RFC 822:
The local-part “Postmaster” has been reserved, so that users can be guaranteed at least one valid address at a site.
It is amazing how many organizations do not have a system administrator reading emails sent to the ‘postmaster’. The role of the ‘postmaster’ mailbox is to alert the administrator that there are some issues with the mail server, or simply to request information where to send some specific emails. The mail server, if properly configured, will also send to the postmaster mailbox any alert and a copy of non delivered reports. The postmaster mailbox is essential for keeping your mail servers fully operational.
From RFC 2142:
if an Internet service provider’s domain name is COMPANY.COM, then the >ABUSE@COMPANY.COM< address must be valid and supported
In the deliverability business, the second most important mailbox is the ‘abuse’ mailbox. This is where you will receive any complaints related to the emails that have been sent from your network or mail servers; ignoring such complaints is dangerous and could lead to your IPs being blacklisted. The Messaging Anti-Abuse Working Group (MAAWG), provides excellent resources to explain how an abuse desk should be operated and manned.
It’s amazing that some commercial email lists include addresses such as ‘abuse’, ‘security’, ‘noc’ (Network Operating Centre), ‘postmaster’, ‘hostmaster’. These mailboxes are normally read by network professionals who easily identify and report unsolicited messages so that the originating IPs are registered in common blocking lists. At Genius.com, we disallow sending to such email addresses so as to protect our own reputation as well as to adhere to the spirit of the RFC and to avoid sending to obviously suspect lists.
Why is RFC 2142 relevant to Deliverability?
While RFC 2142 does not define which mailboxes should not receive any commercial emails, it should be common practice to filter out many mailbox names listed in RFC 2142 since they serve very clear and specific administrative purposes. What about ‘info’, ‘sales’, and ‘marketing’ which are often used to send commercial emails; should they be included in such lists? What if the address has been double-opted in? Every domain is administered differently and RFCs, by design, are not strictly enforced. Is it advisable to create blanket policies to enforce the intended use defined by an RFC? How does this relate to the Robustness Principle?
I’m curious to hear your thoughts and recommendations on this subject.