Rateliff.net E-Mail Policies
All systems sending email to Rateliff.net and its hosted domains are responsible for reading and understanding the below policies. Sending e-mail to any Rateliff.net mail server implies acceptance to all policies listed here. This page is subject to change at any time and Rateliff.net is not obligated to make announcements of any such changes. Questions may be emailed to postmaster@rateliff.net
Introduction to Rateliff.net E-Mail Policies Added 14-Dec-2003
Rateliff.net is a privately owned and operated set of servers providing a variety of services including the transport, delivery, and storage of e-mail. As a privately owned system, we exercise our rights to protect our property, investments, and resources against undue abuses. As private property, our rights of privacy, security, and protection far outweigh the privilege of expectation of free speech within the confines of said property. On the outset, at the very most perimeter of our property we have placed “NO TRESPASSING” and “NO SOLICITING” signs in the form of e-mail access lists, block lists, and other filtering. Anyone violating these missives will be dealt with in an appropriate manner. Unlike bulk commercial postal mail, unsolicited e-mail levies a cost against the target systems and the end-users. As with most service providers, Rateliff.net has a finite availability of resources such as processing capability, storage space, and bandwidth. These resources are fairly, delicately, and deliberately allocated, and abuses such as unsolicited e-mail steal these resources from those for whom they are provided. We do not take the theft of our resources lightly, and will take whatever action is necessary, whether proactive or reactive, to prevent such thievery. This document outlines the E-Mail Delivery and Acceptance Policies (EMDAP) in force on all Rateliff.net operational and associate servers. All users, clients, and customers of Rateliff.net services have agreed to, requested, or in some cases even helped formulate, the policies defined within. Users of Rateliff.net services who may disagree with these policies are welcome to, at any time, contact Rateliff.net administrative staff to arrange for the quick transfer of their services to another provider.1. Relaying Updated 13-Oct-2002
Only authorized users of Rateliff.net services may use Rateliff.net SMTP servers to relay mail. The use of SMTP AUTH is required. Systems attempting unauthorized relay of email are subject to a charge of $100 per incident.2. Unsolicited E-Mail Updated 15-Dec-2003
Rateliff.net does not condone nor promote the use of unsolicited e-mail. As such, Rateliff.net users may not use Rateliff.net servers to send unsolicited e-mail, may not use unsolicited e-mail to advertise e-mail addresses or websites hosted by Rateliff.net, or receive the fruits of unsolicited e-mail. Users are subject to usage and disciplinary policies listed in the Rateliff.net Terms of Service. Rateliff.net maintains a highly restrictive policy against unsolicited e-mail. All e-mail transactions are logged. User complaints of incoming unsolicited e-mail messages are investigated. Any system implicated in the transmission of unsolicited e-mails (commercial or otherwise) will be, at the discretion of Rateliff.net administrators, denied access and/or notified to cease such activity. Afterwards, a running account will be activated and all connection attempts will be billed at the rate of $250 per attempt, including all previous connections and deliveries, and additionally $250 per recipient when delivery is successful. Systems or companies which circumvent blocking or dodge notification by using alternate mailservers, whether wholy or partially owned by themselves, another party, or an associate party, will still be subject to these billing policies, as well as additional research charges. At Rateliff.net, we do not believe in the usefulness of “single-opt-in” or so-called “opt-out” marketing philosophies and efforts. Rateliff.net requires that all marketing firms and mailing lists provide an interactive confirmed method of subscription and abide by the mailing list practices outlined at the Spamhaus Project. In regards to “opt-out” marketing practices, it should be noted immediately that all e-mail addresses hosted on Rateliff.net servers are to be considered opted-out of any and all mass marketing campaigns, unless otherwise indicated and sufficiently documented otherwise. To this end, Rateliff.net may also require that mass e-mail marketers, whether a firm or individual, reveal the source(s) of target e-mail addresses that reside on Rateliff.net hosting services. Rateliff.net reserves the right at all times to extend these policies to the the entities advertised within such unsolicited e-mails, including, but not limited to, websites, website operators, website hosts, registered website owners, businesses, individuals, or any other entity which may be implicated within unsolicited e-mails.3. Acceptance of Relay Testing
All mailservers which connect to Rateliff.net mailservers are subject to being tested for possible open relay. This testing is not done by Rateliff.net, and therefore we have no control over which servers get tested and which servers do not. By delivering email to Rateliff.net mailservers, you agree to accept these delivery tests, and agree to hold Rateliff.net free from liability from any problems or damages that these tests cause to improperly updated or configured mailservers, or the results thereof.4. Blocklists Updated 10-Jul-2023
As a small operation we rely upon the work, efforts, and research provided by outside sources in the struggle against the theft and abuses of e-mail resources. To this end, Rateliff.net uses DNS-based blocklists to protect its users from unsolicited email by ways not limited to direct spam sources, direct-to-MX spammers, open relays, domains or providers which do not follow established Internet policies, mailservers or machines which allow unrestricted mail relay, webservers that host unsecured mail forms or scripts, dynamic IP pools such as those used for dialup or broadband access, and other undesirable sources. Currently, MX1, MX2, and MX3 subscribe to the following DNSRBLs: Barracuda Central SpamCop Spamhaus Project: SBL Advisory Spamhaus Project: XBL Advisory Mail Spike THE SERVICES LISTED ABOVE DO NOT BLOCK E-MAIL! They only maintain lists of IP addresses of servers or Internet Service Providers from which unsolicited e-mail originates. As such, if you have a complaint or to protest your listing, DO NOT CONTACT THE OPERATORS OF THE SERVICES LISTED ABOVE. Instead, you should direct your complaint to your Internet Service Provider and inquire why it does not enforce its Acceptable Usage Policies and allows senders of unsolicited e-mail to continue operations. If you are a issuer of legitimately requested e-mail and have found yourself blocked by any of the lists above, then you owe it to yourself and your Internet neighbors to move to a responsive and responsible Internet Service or Hosting Provider. ISP's and IHP's which find themselves on these lists are listed because they have demonstrated a depraved indifference to the security of your INBOX, and the sanctity of your own personal resources, instead choosing to trade them for a quick buck. By continuing to patronize such services, you are continuing to subsidize the abuse and theft of others' resources. To maintain the effectiveness of these services, Rateliff.net does not subscribe to the practice of whitelisting servers which are blocked by these lists. Additionally, Rateliff.net maintains its own internal database of domains and IP addresses which are guilty of such trespasses and an automated blocklist fed by a literally infinite number of email addresses which exist only to catch spammers. In some cases these listings may become "stale," in which case the listings will be eligible for removal. If using our block removal page does not satisfy your concerns, contacting the Rateliff.net postmaster will quickly resolve the issue.5. Direct-to-MX Prohibition Added 01-Aug-2004
"Direct-to-MX" can be defined as the attempted delivery of email from an IP address assigned dynamically by the owning ISP/IHP directly to the designated MX for a domain. The delivery of email from IP blocks or IP addresses known to contain, or defined by the owner as, dynamically assigned to customers is prohibited from delivering to our email system. Blocking Direct-to-MX delivery is not an exact science, and in many cases delivery may actually succeed, and in some cases delivery from legitimate static IP mail servers may be blocked. The later happens because the ISP/IHP reallocates its IP blocks without notifying list maintainers, updating obvious naming conventions, updating ARIN/WHOIS information, or otherwise updating designations of IP block purpose. This prohibition is the unfortunate result of ISPs/IHPs lack of responsiveness in situations of email abuse from dynamic customers. In some cases, in so many words, certain ISPs have completely absolved themselves of responsibility. In practice, there are fewer mail servers attempting legitimate email delivery than spam and viruses behind dynamically assigned IP addresses. It is important to understand that mail servers operating behind dynamically assigned IP addresses are often in violation of ISP terms of service. This case or not, we recommend that mail servers behind dynamic IPs use a "smart host" such as the ISP/IHP outgoing SMTP server, or other static IP mail server. We maintain a local list of IP addresses known to be dynamically assigned, as defined either by the ISP/IHP itself to list maintainers, ARIN/WHOIS identification, or obvious DNS naming schemes. Entries in the locally maintained list are thouroughly scrutinized before being added, although the potential exists for entries to become stale or aged. Once identified, outdated entries are removed as quickly as possible, and these changes are propagated to all backup servers.6. Matching reverse and forward DNS resolution Added 29-Jun-2014
All servers must have a matching reverse and forward DNS resolution. This process, sometimes referred to as matching rDNS/fDNS, checks that the IP address of the connecting server has a name (DNS PTR record,) and that name resolves back to the same IP address immediately (DNS A record) or eventually (DNS CNAME record or records.) This process helps to ensure that the operators of a system have either direct or otherwise legitimate control of the IP address. Servers which lack a forward resolution will experience delivery delays (SMTP 400-series temporary errors.) Servers which lack reverse reso- lution will be out-right rejected (SMTP 500-series permanent errors.) The implentation of this requirement matches those of some notable major ISPs and will not be withdrawn. Since implementing this configuration, spam traffic has been satisfactorily abated: the number of messages rejected at the SMTP phase has tripled while the number of spam messages known or reported has decreased by 85%. This is significant enough to be considered a success and well worth the occassional "false-positive" caused by the poorly-behaved admins, or the honest errors, of our neighbors. While seemingly uncharacteristic to our standard you-fix-your-problem policies, we make efforts to notify the administrators of systems which attempt to deliver what appears, or is known, to be legitimate email but lack matching rDNS and fDNS. Systems which have difficult to reach administrators, require additional forms, or simply have no clue are ignored. We will whitelist those who understand the issue while it is being corrected, thus accomodating what may be a hierarchical process of resolution.7. Valid SPF Added 13-Feb-2025
All senders must publish valid SPF (Sender Policy Framework) TXT records for the sending domain. For successful acceptance, SPF results must be "pass", "neutral", or "softfail". Any other results, including errors in the SPF records, will cause the SMTP session to terminate. The implentation of this requirement matches those of some notable major ISPs and will not be withdrawn.8. TLD blocks Added 13-Feb-2025
With the explosion of TLDs (top level domains) and their subsequent adoption by spammers, scammers, and the like, we maintain a list of problem TLDs from which emails are not accepted. Rejection notices include contact information for legitimate senders to reach out and appeal the block of their domain. This practice has been in place since the beginning of Rateliff.net services, though only codified on the date given for this section.9. Personally Identifiable Information prohibition Added 29-Jun-2014
Emails are scanned for numbers which match the patterns of credit card account numbers and social security account numbers (SSANs,) both pieces of information commonly used for credit or identity fraud. Messages which contain matches for these patterns are subject to being rejected.10. Logging Updated 29-Jun-2014
Rateliff.net mail servers maintain mail logs solely for troubleshooting and statistical purposes. These logs contain the source server IP address, purported source email address, SPF look-up results, virus, credit card, SSAN, phishing, and spoof website scan results, destination server IP address, recipient email address(es,) status codes and responses from remote servers, relay authentication information, SSL state information, message IDs, bounce or NDR information, message size, message receipt, storage, and delivery delay times, and potentially other service-state information. Logs do not include message subjects, headers, or body contents. Logs are kept for periods ranging between several days to no more than two months. In some cases, excerpts of our mail server logs may be kept indefinitely for internal historical or legal purposes. This practice has been in place since the beginning of Rateliff.net services, though only codified for posterity as of May of 2012.11. Law enforcement and legal cooperation Added 16-May-2012
Rateliff.net complies with all properly submitted and formatted requests for information from law enforcement agencies and legal entities, such as warrants and subpoenas. These must be delivered in-person or via certified mail. We cannot submit information which does not exist at the time of request, and we do not maintain information for the sole purpose of potential value as future evidence -- until such a request is received, our logs are nothing but data and therefore subject to destruction at our discretion and whims. This practice has been in place since the beginning of Rateliff.net services, though only codified on the date given for this section. No order of any type to relinquish user data has ever been received, and any order of extraordinary scope would be challenged.12. Changes in policy or wording Updated 16-May-2012
Rateliff.net may occassionally change these policies in format, structure, wording, or content. The bottom of this page shows the last time this document was updated, and Rateliff.net is at no time obligated to announce changes to this policy. All persons, companies, servers, etc. whom attempt to deliver email, whether successful or not, are responsible for monitoring this page, which is announced in Rateliff.net SMTP banners, DNS TXT records at the domain and MX host levels, and in SMTP reject returns. None the less, as a courtesy, major changes will be announced in reasonable manners. For instance, should we decide that we shall mine message contents for marketing or such pursuit, as this would constitute a complete reversal of our own ethical compass, we would make such a change public and known to our customers.
Document last modified: February 13 2025 05:29:31 PM EST