Guidelines for senders of mass e-mails
Warning
The objective of this section is to inform senders of mass e-mails of the behaviour they are advised to adopt when sending e-mails towards the servers of a service provider who is a member of the AFA.
The application of most of these guidelines is essential for a good communication of their servers with those of all recipient service providers. However, compliance with these guidelines, in no case guarantees that their messages will be taken care of, particularly because of possible technical incidents and regulations providing for the safety of networks.
In the event of failure of an SMTP connection, the sender is requested to contact the remote teams using the usual channels, in the case where the error code he has received would not be sufficient for him to understand the causes of the problem. Prior to that, the sender should ensure that he has this error code at his disposal, as well as a copy of one of the messages which could not be sent, and the full header of this message. The sender must still have control of his server. Otherwise, he is requested to contact his own service provider, who is the only one authorized to get in touch with the technical teams of the remote e-mail service provider.
The application of these guidelines does not guarantee either the receipt of the e-mails by their recipients, due to the anti-Spam filters that the latter may use on their e-mail service. The application of all the "other good practices encouraged", proposed at the end of this document, can however facilitate this receipt.
Technical recommendations
Senders are requested to abide by all the RFCs in force, in particular RFC 821 relating to the SMPT protocol. Some elements of these documents are also mentioned below and must more particularly draw their attention.
1. Configuration
2. DNS Records
3. Behaviour
Guidelines for message writing
Other good practices encouraged
Document posted on-line on: June 30, 2005
Warning
The objective of this section is to inform senders of mass e-mails of the behaviour they are advised to adopt when sending e-mails towards the servers of a service provider who is a member of the AFA.
The application of most of these guidelines is essential for a good communication of their servers with those of all recipient service providers. However, compliance with these guidelines, in no case guarantees that their messages will be taken care of, particularly because of possible technical incidents and regulations providing for the safety of networks.
In the event of failure of an SMTP connection, the sender is requested to contact the remote teams using the usual channels, in the case where the error code he has received would not be sufficient for him to understand the causes of the problem. Prior to that, the sender should ensure that he has this error code at his disposal, as well as a copy of one of the messages which could not be sent, and the full header of this message. The sender must still have control of his server. Otherwise, he is requested to contact his own service provider, who is the only one authorized to get in touch with the technical teams of the remote e-mail service provider.
The application of these guidelines does not guarantee either the receipt of the e-mails by their recipients, due to the anti-Spam filters that the latter may use on their e-mail service. The application of all the "other good practices encouraged", proposed at the end of this document, can however facilitate this receipt.
Technical recommendations
Senders are requested to abide by all the RFCs in force, in particular RFC 821 relating to the SMPT protocol. Some elements of these documents are also mentioned below and must more particularly draw their attention.
1. Configuration
- The senderÕs hardware must be secure and should not relay spam. In particular, it should also not relay messages which are neither emitted by one of their authorised users, nor addressed to one of their authorised users (open configuration).
- It is recommended that the sender domain, mentioned in the headings of mass messages sent, has an incoming mail server (MX), which is available and aware of any connection request. Otherwise, the sender will not be able to receive and process error messages generated on the invalid or expired addresses of recipients.
- Senders are recommended not to emit their messages directly from the residential IP which may have been allocated to them by a general service provider, but to use the servers of their e-mail service providers in this case.
2. DNS Records
- Senders are recommended to have a reverse DNS record for each IP at the source of the dispatching of e-mails, showing the name of the server in a Fully Qualified Domain Name (FQDN).
- SPF records and Sender ID are also strongly encouraged.
3. Behaviour
- Senders are advised to delete from their message recipient list any e-mail address which has generated a permanent error return, which is at the origin of a Spam complaint or which hinders the subsequent receipt of their mails. In particular, RFC 2142 requires that any domain must have a valid abuse@domain address, unsaturated and processed (ideally as of receipt, with treatment of request confirmation, whether automatic or not).
- Senders are advised not to initiate too many simultaneous connections, to split their message transmission and to avoid peak hours (15h - 22h) for their mass mails, and to use the low period rather (00h00 - 7h00).
They can also, on the AOL platform, request a registration in white list.
Guidelines for message writing
- Senders are advised not to send messages whose headings are falsified or invalid or whose "from" or "reply to" fields contain an invalid domain name.
- Senders are advised not to try to falsify the real source or the course of the sent message.
- Senders are advised not to try to falsify the URLs inserted in their messages, in particular by replacing the "host" part by an IP, and to encode them in accordance with the RFCs in force.
Other good practices encouraged
- Senders of mass e-mails are recommended to have their own SMPT server, under colocation at a professional host. This practice in fact enables a better authentication of the sender.
- Senders are advised to always use the same sender e-mail address for a given service, to mention it to the recipient at the receipt of his consent and to encourage the latter to add it to his address book.
- The sender is advised to display his name before his email address display as well as in the left-hand part of this same email address. Alternatively, he can mention his name in the "from" field of the header and insert a less explicit email address in the "reply to" field , if so required by him.
- Senders gathering addresses through forms are encouraged to use a procedure which enables the owners of these addresses to confirm their desire to be registered on the said list (this procedure is sometimes known as "double opt-in"). Such a procedure ensures the real consent of the user and the absence of error or fraud when the latter inputs his address.
- Senders are also encouraged to mention, for example in an additional field on the header of their message, the date and the time at which the recipient has given his consent to receive their messages, as well as the IP address used for that purpose.
- It is advised to clearly mention the subject of the message sent as well as the person on whose behalf the advertisement is carried out. Irrespective of this messageÕs subject, it is strongly advised to systematically offer the recipient an express and unambiguous possibility to decline the receipt of future emails, through a simple and effective procedure, irrespective of the browser being used, including when the recipient no longer has his specific access codes.
- Mass e-mail senders are advised to use an IP address and a different ÒfromÓ field depending on the nature of the message sent (commercial offer, confirmation of an order, customer service...). Such a precaution prevents that a potential distribution problem encountered by one of these IPs affects the entire services offered by the message sender.
Document posted on-line on: June 30, 2005