You certainly have found this web page because you had problems to send email to our Online.net customers. On this web page, you will get explainations and solutions to provide to your email solution in order to fight spam with us.

The blacklist period depends of the amount of spam we received from you. The maximal blacklist duration is 24 hours. After this period, your IP will be automaticaly removed from the blacklist.

Keep in mind that if your server continue to send spam, you will be blacklisted again. It will be useless to ask to be removed from the blacklist as long as your issue is not resolved.

The blacklisting is based upon statistics we manage in realtime about each IP that has made recently a connection to our MX servers and upon logs analysis. Once your issue is resolved, your IP may be blacklisted again in the following 24 to 48 hours ; this is usually the needed delay for old statistics to become negligibles.

We blacklist IP addresses for many reasons. Our servers send a specific error message for each reason. You will find thoses error messages in log files of your SMTP server or in DSN that your email relay sends back to you:

You get this error because your server have send too many spams to Online.net users. So, our servers took the decision to do not accept anymore connexions from your SMTP server.

Your IP address will be automaticaly removed from our blacklist within 24 hours.

• If you host your own SMTP server : while waiting this delay, we recommend you to set up a spam filter which should stop spam that you send, relay or forward

• If you are using an SMTP relay: please contact your service provider.

You get this error because your server has produce too many errors when it spokes with our servers (just like closed/timed-out connections before a mail is successfully transmitted). Your server behaviour may also let us think to be under a dictionnary attack (either mail verifications or a dictionnary spam). So, our servers took the decision to do not accept anymore connexions from your SMTP server.

• If you host your own SMTP server : while waiting this delay, we recommend you to verify your configuration (maybe you are an open relay ?). If you are using the “Sender Verify” method which make a connection to our servers to verify the validity of an email, we recommend you to disable it. Your server may also send automatic notices (undeliverable mails, autoreplies; etc.) when receiving spams. In this case, you should try to refuse a mail delivery the soonest possible (while receiving it) to avoid to have to deliver a delivery status notification and/or not to send an automatic reply on mails detected as spams.

• If you are using a SMTP relay: please contact your service provider.

Your IP address is not blocked, but we do not accept anymore emails from you temporarily due to too much errors generated by your server. If your server continue to generate a big amount of errors, you will be blacklisted for a while and get the "550 Too many errors from your IP" error.

• If you host your own SMTP server : while waiting this delay, we recommend you to verify your configuration (maybe you are an open relay ?). If you are using the “Sender Verify” method which make a connection to our servers to verify the validity of an email, we recommend you to disable it. Your server may also send automatic notices (undeliverable mails, autoreplies; etc.) when receiving spams. In this case, you should try to refuse a mail delivery the soonest possible (while receiving it) to avoid to have to deliver a delivery status notification and/or not to send an automatic reply on mails detected as spams.

• If you are using a SMTP relay: please contact your service provider.

No, we only use internal datas to generate our blacklist.

A maximum of 24 hours. You can use this tool to know if your IP address is blacklisted and how long it is.

Once upon a time, unsollicited mails (spams, virus, etc.) were mainly an annoyance for users as they had to manually seperate the wheat from the chaff. Nowdays, unsollicited mails volume is so huge it cause real and serious technical issues for mail hosters.

On december 2007, a study concludes unsollicited mails reached 97.13% of mails traffic. This means you had to oversize your mail platform by 34 times to be able to manage unsollicited mails just like regular mails and this is starting to become quite unmanageable. The volume hits all servers, whether they receive mails (MX servers), store them (both on disk capacity and on IO load) or deliver them to users (POP/IMAP servers).

On december 2006 and 2005, studies have concluded there were around 95% and 90% spams in mail traffic (as usual, mileage may vary). Spam traffic grows roughly twice as fast as regular mail (I meant sollicited mails, not spams) and it is more and more difficult to manage/host a mail cluster. Unsollicited mails traffic may be considered as a continuous DoS against mail hosters.

So, we had to filter out spams to protect our servers. Unfortunately, if this protection is quite efficient on storage and POP/IMAP servers (and, as a side effect on users mailboxes), incoming SMTP servers are still under spam overload and we would have had to increase by more-than-twice their capacity each years. Thus, we would still have to scale the incoming servers against unsollicited-mails traffic.

Moreover, the way spams are sent makes our incoming SMTP servers unreachables. As spam is mainly sent through trojaned/virused computers behind regular customer 'slow' links (ADSL, ISDN, cable) or through internationnal saturated links, average connection time is increasing and more simultaneous connections are openned. As spammers are openning aggressively new connections, our servers were quite unreachable for regular SMTP servers.

This is the reason why, to stop having to scale against unsolicited mails, we have started to blacklist IPs whose mail traffic was mainly composed by spam (right now, an IP is blocked when the spam/mail ratio is over 50%), whose behavior is unusual (many unfinished SMTP sessions, many unknown recipients, etc.) or abusive (sender-verify, mail-bombing, etc.).

Sender-Verify is, when a server is receiving a mail, connecting to the sender MX server to check if the sender exists (or, at least, if the server will accept a mail sent to him). It is usually used to filter spam (as spams are usually sent with a faked random sender). Unfortunately, we have a few issue with that kind of antispam tool.

Once upon a time (about ten years ago in fact), the SMTP command used to check emails ('VRFY') has been disabled to fight spam (to disallow spammers to check their emails lists). Thus, it looks like quite curious to see that kind of tool to be nowadays re-used to fight spams... Moreover and as 'VRFY' command has been disabled, Sender-Verify acts just like it sends a mail using 'RCPT TO' command (and it close the connection just after getting the result). This allows it to check if a mail may be send to the sender. If at first sight there is no real difference between both commands, there are a many differences in the daemon code. In the first case, you just have to check if an account exists, in the second case we really check if an mail may be delivered (to avoid to send any non deliverable notifications, we refuse the delivery as soon as possible) and this use much more ressources.

On a technical point of view, we just can not differ a Sender-Verify request if it comes from a spammer trying to check his list or from a server that simply do Sender-Verify. If checking sender looks like a good idea as most of mails are spams (with faked sender), you are using somebody else ressources to do it and we do not consider this as being respectful (specially when unsolicited mails traffic is around to 95 to 97% of all mails traffic) and you may be part of a massive DoS attack on a domain (if a massive spam is launched using a specific domain for sender entry).

Last but not the least, this kind of filter is easily bypassable. A spammer just need to use a verified email list for sender entry. Somes spammer are probably already using it : somes of our users are complaining to receive hundreds automatic notifications.

S'il est normal d'informer un utilisateur que son mail n'a pu être transmis à son destinataire ou que untel est en congé, il ne faut pas non plus en envoyer à tort et à travers. Alors que le traffic mail est composé dans sa quasi-totalité de spams (dont les emetteurs sont usurpés), envoyer une notification automatique est un exercice périlleux car les risques d'envoyer un mail non sollicité sont elevés (si l'emetteur est usurpé, la notification est envoyé à un destinataire qui n'a strictement rien demandé et se transforme donc en mail non sollicité au même titre que les spams). Il est donc souhaitable de refuser au plus tôt un mail (typiquement lors du dialogue SMTP sur le 'RCPT TO' dans le cadre où un destinataire serait inexistant ou ne pourrait recevoir de mail, sur la fin du 'DATA' dans le cas où vous décideriez de refuser le mail) voir s'abstenir d'envoyer de notification automatique si le mail semble être un spam. Ceci aurait en plus l'interet de réduire sensiblement le traffic mail puisque les spammeurs s'abstiennent généralement d'emettre des notifications lors des refus. Si les RFCs sont relativement peu verbeuses sur le sujet, on peut néanmoins y trouver les recommandations suivantes :

• RFC 2505 :
1.5. Where to block spam, in SMTP, in RFC822 or in the UA Our basic assumption is that refuse/accept is handled at the SMTP layer and that an MTA that decides to refuse a message should do so while still in the SMTP dialogue. First, this means that we do not have to store a copy of a message we later decide to refuse and second, our responsibility for that message is low or none - since we have not yet read it in, we leave it to the sender to handle the error.
• RFC 3834 :
2. When (not) to send automatic responses An automatic responder MUST NOT blindly send a response for every message received. In practice there are always reasons to refuse to respond to some kinds of received messages, e.g., for loop prevention, to avoid responding to "spam" or viruses, to avoid being used as a means to launder or amplify abusive messages, to avoid inappropriately revealing personal information about the recipient (e.g., to avoid an automatic indication that a recipient has not read his mail recently), and to thwart denial-of-service attacks against the responder. The criteria for deciding whether to respond will differ from one responder to another, according to the responder's purpose. In general, care should be taken to avoid sending useless or redundant responses, and to avoid contributing to mail loops or facilitating denial-of-service attacks.

SMTP (Simple Mail Transfer Protocol) is the protocol used to exchange emails. An SMTP server is a software designed to receive and send emails.

A DSN (Delivery Status Notification) is an email generated by an SMTP server when it cannot deliver an email. This email is sent to warn the user that the email has not been delivered. This email contains all the informations about the SMTP transaction.

This is an error sent by an SMTP server when you try to reach an email address that does not exist. Many spammers are genrating this error when they are doing a dictionnary attack.