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
Questions may be emailed to email@example.com
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
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
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 22-May-2013
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:
Alligate MX Rate
Spamhaus Project: SBL Advisory
Spamhaus Project: XBL Advisory
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. 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
8. 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.
9. 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.
10. 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 6 2015 12:32:22 PM EST