Message Routing - IP Addresses and DNSBLs

This article contains information on DNSBL practices, highlighting the unethical requirement of fees for delisting IPs, contrary to RFC 6471 guidelines. It also outlines Mimecast's processes for monitoring, resolving, and delisting IPs from DNSBLs.

Whilst it is appropriate for a DNSBL to charge users for access to it, some demand fees or charitable donations from the listee to delist their IP address. This is contrary to the "Overview of Best Email DNS-Based List (DNSBL) Operational Practices" outlined in the RFC 6471 published by the Internet Research Task Force (IRTF). Section 2.2.5 of RFC 6471 states:

"Some DNSBLs used for blocking/negative reputation have had a practice of requiring fees or
donations to charities from the listee for delisting. It is generally considered entirely appropriate for a DNSBL
to charge for access to it by its users -- the definition of a commercial DNSBL."

However, the practice of requiring a listee to pay for delisting from a negative-connotation DNSBL steers perilously close to notions of extortion, blackmail, or a "protection racket". Even when such accusations are entirely unjustified, the practice causes uproar and damage to the DNSBL's reputation, if not the DNSBL mechanism as a whole. Therefore, negative-connotation DNSBLs MUST not charge fees or require donations for delisting or "faster handling", and it is RECOMMENDED that such DNSBLs that do charge fees or require donations not be used.

One such DNSBL provides IP-based blacklisting but doesn't provide feedback or reasoning as to why they've listed an IP address. IP addresses remain listed for seven days and require payment for immediate delisting. Our research shows they're listing 65,000+ IPs in the hope that ISPs pay for delisting. Despite our numerous attempts, we've been unable to make contact with a company representative.

Mimecast has a number of systems and processes in place to help prevent abusive messages being sent and to ensure our IP addresses maintain a good reputation. Our Messaging Security team has dedicated analysts tasked with ensuring our customers are not sending spam or abusing our outbound gateway. The systems and processes they deploy include:

• • • Automated monitoring of Mimecast IPs against RBLs.
    • Delivery/process queue alerting. This triggers an investigation if a delivery/processing queue grows beyond a specific threshold.
    • Rate-limiting high processing queues.
    • Alerting on specific mail characteristics commonly seen in outbound spam.
    • Feedback loops with many mail providers.
    • [e-mail] monitoring.
    • Spam trap identification that monitors and sends alerts when a message is sent to a known spam trap.
    • Customer intervention when our services are used for bulk mailing.

If Mimecast's Messaging Security team becomes aware of an IP address being listed, they:

1. Investigate why the IP is listed.
2. Resolve the issue.
3. Request the IP address is delisted with the RBL.

If an IP address is listed on a DNSBL, the issue can be resolved immediately with a call to Mimecast Support. The outbound IP range can also be changed. Contact Mimecast support if you've got any further questions.

See Also...

• • • Mimecast Data Centers and URLs