Road Runner Inbound Sending Policy


Like all other ISPs, Road Runner is interested in making sure that its customers receive all of the email that they want, while minimizing the amount of unsolicited email that gets to their mailboxes. Road Runner therefore defines the following guidelines, hereafter referred to as our "Inbound Sending Policy" for other sites wishing to send email to Road Runner customers:

Technical Guidelines:

  • All email must comply with the relevant RFCs which define the protocols for exchanging email between two sites connected to the public Internet.
  • All email servers connecting to Road Runner's inbound email servers must have valid reverse DNS entries (i.e., all sending IP addresses must have active corresponding domain names in DNS).
  • All email servers connecting to Road Runner's inbound email servers must be secured to prevent unauthorized use (may not be an open proxy, router, or relay).
  • Connections from dynamically assigned IP addresses (dial-up accounts) will be refused by Road Runner's inbound email servers.
  • Organizations may not hardcode Road Runner's MX records into their configuration files.
  • Organizations must immediately unsubscribe any Road Runner email addresses that receive a permanent failure email bounce from Road Runner's inbound email servers.

Email formatting Guidelines:

  • Organizations must not do anything that tries to hide or forge the sender of the email and sending site of email.
  • Each mailing must specifically state how each Road Runner customer email addresses were obtained (i.e. purchase from Acme tools, sign up for Travel discounts, etc.) and must state whether this is a one-time mailing or a recurring mailing. Additionally, such details as the date and time when each email address was obtained, along with supporting documentation such as the Internet headers from email messages requesting signup, or web server logs from addresses collected from signup forms, etc.
  • All mailings should contain simple and obvious unsubscribe mechanisms. While we recommend that this be in the form of a (working!) link to a one-click unsubscription system, a "reply to:" address may also be used; in this case, we require that the address receiving those replies be valid. Requests from Road Runner customers to unsubscribe from mailings shall be honored without undue delay.
  • All email must have valid non-electronic contact information for the sending organization in the text of each email (phone number, physical mailing address, etc.). If this is not readily feasible, there must be a link in each email to such information on the sending organization's website.

Policy & Procedural Guidelines:

  • All email to Road Runner's member base must be solicited (i.e., there is an existing and provable relationship between the email recipient and the sender).
  • If an organization generates complaints, bounces 20% or more of the total recipients on its mailings, or has difficulty accepting those bounces, the Road Runner Security Operations group may implement blocks until a reconfirmation mailing is sent.
  • In no way does the posting of these guidelines imply any affiliation, membership, sponsorship or endorsement of business or activities/practices of an organization by Road Runner.
  • Road Runner reserves the right to discontinue delivery of email from an Internet sender if Road Runner's service is impaired or for other reasons at its sole discretion.

Road Runner's efforts to control the flow of unsolicited email into our networks could be correctly typified as reactive, rather than proactive. This means that in general, a site must violate our Inbound Sending Policy before we will start to refuse email from its servers or networks; we typically do not refuse email from sites for which we have neither direct evidence of violations of our Inbound Sending Policy nor complaints from our customers about email received.

It is also worth noting that Road Runner's efforts to control the flow of unsolicited email into our system focus on servers and networks, and not on sender addresses. This can mean that we will occasionally block legitimate or wanted email from persons who are trying to send email from a server or network from which we are currently refusing email. Unfortunately, we cannot make exceptions for individual senders using these blocked servers and networks, but we will listen to removal requests from our customers and the owners of these servers and networks, and grant those that, in our judgement, will not cause further harm to befall our network.

While the criteria we use for blocking or rejecting mail is based solely on the source of the email (i.e., the IP address of the server attempting to send the mail), our servers are also now equipped to filter email based on spam-like characteristics in the body of the mail message. The default behavior for this filtering is to place messages deemed to be spam in the customer's Junkmail folder, a folder accessible only through our Webmail product offering. Customers can change this behavior to have such mail placed in their Inboxes (with or without the subject prepended with the tag "SPAM:") or to have such mail deleted from our servers without its being read.


Road Runner Inbound Rate Limiting Policy

Road Runner imposes several rate limits on inbound mail from any given IP address. These limits include:

  • Number of simultaneous connections allowed
  • Number of recipients allowed per message
  • Number of recipients allowed per connection
  • Number of recipients allowed per hour

These steps were taken so that Road Runner could better protect its email system from abuse from malicious, compromised, or improperly configured systems. Sending systems who are affected by our rate limits will receive a 4xx series message during the SMTP transaction. This message is designed to instruct the sending system to temporarily stop sending email to Road Runner; the expectation is that the sending system in response to this 4xx message will try again at a later time to deliver its email to Road Runner. This message includes a URL directing the sender to this section of this website.

This rate limiting allows Road Runner to manage the flow of inbound email through its systems. Its intent is not to block email, but rather to control the rate at which email enters our system. If a sending system generates a volume of email during a given hour that is sufficient to trigger Road Runner's rate limits, Road Runner's inbound email systems will begin to return a 4xx series message to the sending system during the SMTP transaction (i.e., temporary failure, try again later). These limits are imposed on a per-IP basis, meaning that rate limiting will affect all inbound email received from a given IP address, regardless of the domain or domains of the senders of the messages in question.

All but the number of recipients allowed per message will vary depending on the IP's Return Path Sender Score Reputation Rank (http://www.senderscore.org/) and on whether the IP passes a Full Circle reverse DNS (FCrDNS) check. (Road Runner requires that the sending server's reverse DNS entry and forward DNS entry match; that is, the IP address connecting to our servers should resolve to a hostname that resolves back to the IP address. Should an IP address's reverse DNS, or PTR, record resolve to a hostname whose A record does not resolve back to the connecting IP, then the connection is considered to be suspect, and the rate is limited accordingly.)

If you're finding that your server is being rate limited (and the reason is not due to too many recipients per message), the most likely solution available to you will be to have the party responsible for your server apply for enrollment in our feedback loop: http://feedback.postmaster.rr.com/ Enrollment in our feedback loop costs nothing.
Two things to note here:

  1. Our feedback loop is not a whitelist; this is made clear in the Terms of Service to which enrolling parties must agree when applying for enrollment. This means that servers enrolled in our whitelist are still subject to being blocked and/or having their mail routed to our customers' Junkmail folders
  2. .
  3. The limitation on number of recipients per *message* is imposed system-wide, is independent of the sending server, and cannot be overridden by enrollment in our feedback loop or any other means. If your problem is that you're attempting to send mail addressed to more recipients than we allow for a given message, structure your mailings so that there are more messages, each with fewer recipients.

While our rate limits are not being published at this time (and we will not commit to publishing them) we are constantly reviewing their settings. Our goal is to have in place rate limits based around the simple theory that we want to reward IPs that tend to send mail that our customers want.


Road Runner Whitelist Policy

Senders frequently request having their IPs added to our whitelist; if you're a sender who's interested in being whitelisted here, it's important that you read this section to understand what it is that we mean by whitelisting and what benefits you might gain from whitelisting.

First, it is not necessary to be whitelisted here in order to send mail to our customers. So long as your server's IP has valid reverse DNS and is not listed on any blocklist we use, mail from your server will be accepted here.

Next, whitelisting here just means that the rate at which we will accept mail from your server will be among the highest we offer;whitelisting does not mean guaranteed delivery to the Inbox here. Moreover, since our rate limits are based on an IP's previous history and reputation sending mail here, if your IP already enjoys a good reputation here, whitelisting may offer you no benefits in excess of what you already enjoy.

Last, management of our whitelist is handled by Return Path; we use their Certified program as the source of our whitelist, so if you believe you want to be whitelisted here, you should contact Return Path.