Road Runner Security
security.rr.com


Page 3

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Road Runner Spam Control Policy

The purpose of this webpage is to provide information regarding Road Runner's Spam Control Policy and the steps Road Runner will take to try to prevent unsolicited email from reaching its customers. General questions regarding Road Runner's spam blocks or blocking policies can be directed to blockinfo@security.rr.com.


This page is designed to be read from top to bottom, in order to best present the full picture of Road Runner's efforts to control the flow of mail into our network. The links here are provided so that you may visit a specific section, if you so choose.


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 Block List Policy

To control the flow of unsolicited inbound email, Road Runner utilizes multiple lists of networks and IP addresses from which its inbound servers will refuse all email messages:

The upshot of all this is that if someone sends an email message and the IP address of the sender's SMTP (mail) server (or the network in which it resides) is on one of these lists, or has a poor reputation, then the incoming email is refused.

Road Runner's internal list is mostly comprised of addresses and networks gleaned from spam complaints from our customers. The fact that our customers complain about unsolicited email from a given source does not, in and of itself, guarantee that a source will be blocked from sending future email to Road Runner customers; instead, these complaints provide Road Runner Security with candidates for blocking. These candidate IP addresses are further investigated thusly before a blocking decision is made:

  • If the IP address is part of a network space that Road Runner has reason to believe is another provider's dynamic space, we will block the encompassing network. For example, if we get complaints about spam from IP address 1.2.3.4, and we have reason to beleive that this is dynamic space, we will put in a block to refuse all connections from any IP address that starts with 1.2.3.
  • If the IP address is not part of another provider's dynamic space, Road Runner will use an objective scoring system, based on a reputation built from available public information about the IP address, to make a decision as to whether or not to block the IP address.

This scoring system is used as a defensive mechanism to make sure that the blocking decisions we make will hopefully not have an adverse impact on a large number of Road Runner customers. Our spam complaint processing method is an automated one, it is designed to err on the side of caution. Our customers sometimes mistakenly forward spam complaints to us about email that is either not really unsolicited or email that was unsolicited but was sent to an address they have on another system, one that is setup to automatically forward all email to their Road Runner account. If we were to block every server that passed into our mail system a message that a customer complained about, we would likely cut off mail that many of our customers want to receive from other legitimate ISPs, businesses, educational institutions, and the like.

In addition to this objective scoring system, if the IP address has no valid reverse DNS (i.e., queries for its PTR record return "NXDOMAIN") the IP address will be blocked regardless of its rating in our objective scoring system. Removal requests for IP addresses blocked due to their having no valid PTR record will not be honored until a valid PTR record has been created.

The parts of Road Runner's internal list that are not comprised of servers and networks that have sent unsolicited mail to our customers are one of the following:

  • Network space that is known by Road Runner to be in another provider's dynamic space; our confirmation source for such space would be the other provider itself. This space may be identified by either number (i.e., the IP address of the connecting mail server) or name (i.e., the PTR record of the connecting IP address).
  • Network space that is believed by Road Runner to be in another provider's dynamic space. This space would be identified by name as matching generic naming patterns culled from our own server logs. Road Runner believes that such generic names indicate dynamic space.
  • Domain name-based patterns that match domains which have in the past had a reputation for sending signifcant volumes of unsolicited email; this reputation may continue to the present day.
  • Network-based patterns for space that was known at one time to be occupied by senders with reputations for sending significant volumes of unsolicited email; this reputation may continue today, as may the presence of those senders in the specified networks.

In all cases, Road Runner tries to return an error message that is descriptive enough to let the sender know the reason that his mail has been rejected by our servers, so that he may proceed appropriately regarding possibly requesting that the block be lifted.

As to the third-party lists, while they are by Road Runner, their content is not controlled by Road Runner; addresses and networks appearing on those lists are there based on criteria set by the organizations that manage those lists.

Note: It is possible, under certain criteria, for Road Runner to override a listing of either of these services; those criteria would include, but are not necessarily limited to:

  • A demand from a sufficient number of our own customers to lift the block.
  • Evidence from the listee's provider of a good-faith effort to get the listing removed.
  • A willingness on the part of the listee and the listee's provider to accept any complaints about the space in question from Road Runner and to take action based on those complaints.
If you feel that you meet these criteria, please contact us at blockinfo@security.rr.com


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, and IPs accepted into our feedback loop will typically enjoy rate limits that are generous enough to meet most mailers' expectations.

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. 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

Road Runner realizes that utilizing any blocklist may result in the loss of requested and wanted email.

In an effort to alleviate this, and to ensure that our subscribers receive mail that they have legitimately requested, Road Runner subscribes to multiple services listing senders who have certified, via some pre-defined mechanism, that all mail that they send is confirmed as having been requested by the recipient.

The lists that Road Runner currently subscribes to are:

Road Runner does not require that a given entity certify itself with this reputation service; we will accept email from any server or network which is not currently listed on any of the lists we use to determine from where we will accept email. If, however, a given entity is found to have sent unsolicited bulk or commercial mailings to our role accounts or subscribers, as described on our Mail Block page, they will be subject to the removal criteria specified therein. This policy extends to our use of MAPS and Spamhaus ZEN lists.

If a given entity does not "come onto the radar screen" of either Road Runner, or the lists that Road Runner utilizes, then Road Runner will take neither positive nor negative action in regards to mailings from that entity.

 

©2005 Road Runner Security
All Worldwide Rights Reserved