I. Bounce Handling:
1. Bounce Handling Policy: senders should mark an address as "dead",
meaning the sender should remove the address from the delivery list and
not attempt to deliver to the address until the sender has reason to
believe that delivery rejection would not occur, if the following two
conditions are both met:
A. Three (3) consecutive delivery rejections have occurred; AND
B. The time between the most recent consecutive delivery rejection and
the initial consecutive delivery rejection is greater than fifteen days.
A sender should have the capability to manage delivery rejections
differently between ISPs, whether based on previous agreements or
explicit requests from these ISPs.
2. Reply Coding Standards: receiving systems should comply with RFC
and DSN codes. RFC 821, DSN or RFC 1894 are relevant standards. For
example, ISPs can use RFC 550 5.7.1 "Go Away" to indicate that the ISP
is intentionally rejecting the delivery of an email that is thought to
be in violation of the list hygiene policies indicated herein.
Link to white paper
Link to PowerPoint
presentation
II. Publication of Email Permissions Policies for Sending and Receiving of
Email
Both receivers (ISPs and spam filtering companies) and senders (such as email
service providers, email campaign provders, and email service bureaus)
should publish clear, publicly accessible requirement as to what they
require for receipt and transmission of email, and sending of email,
respectively. These requirements should be applied consistently.
Receivers
1. Establish, implement, and post requirements for acceptance and
delivery of e-mail (including first line contact information for
delivery issue reporting) clearly on website, and apply consistently.
2. Establish, implement and publish uniform processes for complaint
feedback loop clearly on website and apply consistently.
Senders
1. Establish, implement, and post a policy prohibiting the sending of
unsolicited commercial e-mail (spam) clearly on website and enforce the
policy consistently.
2. Implement automated system to process complaints, requests to
unsubscribe, and delivery failure notifications. Additionally, honor
all requests from recipients to modify permission preferences.
Link to Publication of Email
Permissions Policies for Sending
and Receiving Email PowerPoint presentation
III. Unsubscribe Request Handling
1. List managers should endeavor to provide an unsubscribe process
which requires the fewest number of "clicks" possible. A "1-click"
unsubscribe process is the ideal; it is understood that in some minority
of instances, a 2-click process may be necessary for security reasons.
Subscribers should not have to go through the process of having to
provide a password or to surmount other obstacles to removing themselves
from mailings they no longer wish to receive.
2. An unsubscribe request should result in the subscriber being
immediately removed from the mailing list, and subscribers should not be
required to continue to receive, and should not continue to receive,
certain types of mailings from the sending site once they have submitted
their unsubscribe request. An exception to the latter is understood for
free sites which as part of their terms and conditions require
users to receive promotional mailings in exchange for free services.
3. If the ongoing receipt of certain types of email is required in
order for a user to participate and continue to participate in a
program, this should be made very clear and explicit during the sign-up
process, and before the user concludes the sign-up process.
IV. Multiple Addresses in Mailing List Mail
All mailing list mail should be sent "one address per piece", meaning
that each piece should be addressed only to the primary recipient, and should not be cc:ed or bcc:ed to additional addresses. If there are 100 users on the list, 100 individual pieces
of email should be sent.
V. Communication Between Senders and Receivers (EDDB)
Senders and receivers should participate in an inter-industry
communications facilitation program to help ensure that they can
communicate effectively and in a timely manner when an email delivery
problem occurs. This can be ISIPP's Email Deliverability Database, or another such program.
ISIPP has developed the Email Deliverability Database
("EDDB") in order to support this standard. The objective of EDDB is to facilitate communications between
sending and receiving systems regarding email transmission. This helps
to ensure that users get the email they want, that legitimate email gets
delivered, that spam does not get through, and that delivery issues are
resolved quickly.
EDDB allows participants to have immediate access to contact information
for organizations in the sending and receiving industries. Access is
set up such that one can only access information about one's analog
at the other organization. So, for example, someone at a help desk at a
sending organization can contact someone at the abuse desk at a
receiving site, or vice versa, while a manager at either organization
would be able to access contact information for both management and the
desk at the other organization, and the CEO of one organization would
have access to the contact information for everyone from the CEO on down
at the other organization.
A flash overview of how EDDB works is available here, and sign-up information is available here. You can apply to participate in
EDDB here.
