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

This form will tell you if you are listed. Please note that this lookup tool is based only on IP addresses, it does not use IP ranges, host or domain names.

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 receive this refusal message when one mail was detected as a spam by our antispam filter and the delivery was rejected. The non delivery report has been sent by the SMTP server you have used or, if you did not send this mail, by the SMTP server who have relayed a mail spoofing your email.

If you did send the mail, you should at first check your mail to make sure it should not be missdetected as a spam, either by using an antispam softwate or by checking if the mail is syntaxically correct and if you do not use any mecanism that are known to be used by spammers.

You get this error because your server have send too many spams to Free.fr 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.

If it may be considered to be useful to notify one user his mail could not be delivered or his recipient is off, you just can not send notification in any case. As nowadays mail traffic is mostly composed of spams (whose senders are faked), sending notifications is tricky as you are likely to send a unsollicited mails (notification to faked-from mails are unsollicited). Thus, you should consider to reject mails as soon as possible instead of bouncing them and to drop bounces when the mails are detected as spams. You may find the following information in a few RFCs :

• 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.

There are several reasons for which we may reject an email. For each of these reasons, our servers return a specific rejection message (see below). You may find these messages either in received DSN or in log files (depending on the software you use).

In all cases you should not unblock the SMTP port of your ADSL modem. This is useful when you host your own mail servers (to send mails) on your ADSL link. If any devices on your network would be compromised, unblocking the SMTP port would allow spams to be sent from your ADSL link.

You receive this refusal message when one mail was detected as a spam by our antispam filter and the delivery was rejected. The non delivery report has been sent by the SMTP server you have used or, if you did not send this mail, by the SMTP server who have relayed a mail spoofing your email.

If you did send the mail, you should at first check your mail to make sure it should not be missdetected as a spam, either by using an antispam softwate or by checking if the mail is syntaxically correct and if you do not use any mecanism that are known to be used by spammers.

Reason

Solution

Reason

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.

If you are one of the server admins and if the issue has been solved or if you need additionnal informations, you may send an email to postmaster@proxad.net including our servers error message, your server IP and, of course, your request.

If you are a regular user ou if you do not administer the blacklisted server(s), there is no use to contact us : we would only confirm the blacklisting. We invite you to contact the server admins/provider to signal the issue.

The following instructions are only usable for mails rejected with a message starting with "550 spam detected".

The purpose is to patch the antispam filters so that regular emails are not rejected. There is no use to send us a sample when you have a different issue, when your mail may look like a spam (do not match RFCs, use some spammers techniques, etc.) or when the mail is just a test/debug/etc.

To be able to correct a false positive, we have to find out why the email is rejected and we need to receive an email that is detected as a spam. Therefore, this email has to be as identical as the mail that was rejected. That means it may be necessary to send it using the same software through the same servers. In fact, sending it to the same recipients (with a BCC to the account nospam@nospam.proxad.net) may allow us to have the best working content.

Thus, we ask you to send samples of rejected mails should be sent to nospam@nospam.proxad.net :

• to the same recipients (when it is possible)
• to nospam@nospam.proxad.net mailbox using BCC
• as identical as possible (no "test" samples, no modified subject, no forward, attachment, etc.)
• using the same mailing tools through the same relay servers

So that we should receive the sample exactly the way the mail was received when rejected.

Once sent, please warn postmaster@proxad.net and include :

• the sender
• the subject
• the refusal message

If you do not receive an answer from us and if the issue is not resolved, please wait a few days before remailing us.