European ISP Archives - DeliverNow

Email domain voila.fr shutdowns

VoilaVoila.fr, the website created in 1998, which was once the 2nd largest search engine in use in France, just behind Yahoo!, has announced as of several weeks ago from now, the shutdown of its webmail as well as the utter suppression of all emails addresses in its domain.

The shutdown will come into effect as of January the 12th 2016: see the website about this (in French).

What to do if a voila.fr email address is found in your databases?

Even though voila.fr is part of Orange, email addresses in this webmail will not be automatically transferred to the latter. It is therefore impossible to run an automatized transfer of all email addresses towards a different domain.

The only possible action to be deployed is to contact all of your voila.fr-contacts requesting to for an update of their email addresses. When sending this email, it is important to split customers into 2 categories: the active ones and the prospect/inactive ones. It is likely that the massage aiming to redirect them to a email-update box must be edited accordingly in order to maximize impact and efficiency.

As of January 2016, all voila.fr addresses are to be disabled from your sending databases since they will be no longer active. Otherwise, you risk low-deliverability rates as well as high rates of invalid addresses.

Deliverability Alert: Orange implements Spam-report based Dynamic Filtering.

logo-orangeAs SFR did a few weeks ago, it seems that Orange follows the same path towards implementing an email dynamic filtering based on the volume of the generated complaints. This feature is indeed managed by VadeRetro, the anti Spam solution deployed by the main ISP’s and French Webmails, including Orange, SFR, Free and laposte.net.

Thanks to VadeRetro technologies, French ISP’s are adopting— just like the world’s well-known Webmails— a Spam filter based on sender’s reputation, hence aiming to protect their email infrastructure.

With this in mind, Orange implemented this feature as of yesterday, and it seems that several email senders are involved. It is important to remember that the complaint-rate volume is significantly relevant when filtering emails from either a specific IP address, a sender’s domain name, (FROM field), or a particular campaign.

The aforesaid is quite relevant if we consider that nowadays, ISP’s are fully capable of identifying a complaint-generating campaign from receivers, regardless of the ongoing routing platform.

Therefore, it is useless to reconvey filtered email traffic towards another router: the latter will be automatically identified and filtered alike.

Today, besides Orange and SFR, this feature has been also deployed by Laposte.net.

Deliverability update: SFR on his way to a stringent filtering process

logo_SFRThrough the last few days we have noticed — via our customer’s deliverability monitoring infrastructure — SFR’s enhancement of its filtering policies. For instance, we notice a bigger number of the ‘550.5.7.1 Message Content rejected’ messages after running the DATA command during SMPT dialogs.

As far we can see, this enhancement is based on the employment of ratios between qualitative and non-qualitative senders per IP address. Previously in our blog, we lured attention to the fact that SFR employed bounce rates and spam-report rates to lever when to block an IP address or not : this sheds light on an ongoing evolution of its filtering process. Within this framework, spam reports become an important mechanism when deciding if an email should fall into the spam folder or into the inbox. Based on our observations, the rate of acceptable reports remains the same as that of the industry’s standard.

It is important to remind that Signal Spam’s Feedback loop holds the only access to the SFR’s IP-generated reports figures.

SFR moves forward to follow the same path others in the field do: deliverability-threatening email flow must remain isolated from the rest of the strategical or more relevant emails. In practical terms, this means setting apart IP addresses and domain names operated by these flows.

It has been also noticed that the before-said ratios have not been utterly set by SFR, and that SFR is more likely to be currently setting up its employed thresholds. We will keep you informed as we get deeper in the subject.

Reminder: Below the list of the involved domain names : @sfr.fr, @neuf.fr, @9online.fr, @9business.fr, @cegetel.net, @club-internet.fr, @cario.fr, @guideo.fr, @mageos.com, @fnac.net, @waika9.com.

SFR Deliverability: Explaining error codes (GU_EIB) and the ongoing error threshold

logo_SFRBefore getting to the actual matter, it is important to brush upon a few relevant chronological events in the past regarding SFR. Even though SFR has been carrying this name since 1987, the many other departments on the group have changed quite a lot ever since. During the past 10 years, SFR has made the acquisition of other Internet providers (or reincorporating branches) such as Neuf Telecom, Club Internet and so on.

This background will help us to gather the email’s domain names employing SFR’s infrastructure. Some of them well-known, some others not that much. Below, the list of the domain names performing SFR emailing service. Hence, the same spam
filtering technologies:

  • @sfr.fr
  • @neuf.fr
  • @9online.fr
  • @9business.fr
  • @cegetel.net
  • @club-internet.fr
  • @cario.fr
  • @guideo.fr
  • @mageos.com
  • @fnac.net
  • @waika9.com

SFR’s deliverability error code explanation: GU_EIB_02 and GU_EIB_04

Using our experience and our deep analyze of the SMTP routing logs, DeliverNow attempts to provide better SFR-based mailing deliverability thanks to its clear insight of the MTA process.

When your IP address is blocked, SFR’s bounces are sent, allowing you to find out the reason of your actual blocking. Below you will find the two examples we are concerned about:

  • GU_EIB_02 : “5.7.1 <example.com[xxx.xxx.xxx.xxx]>: Client host rejected: Abus detecte GU_EIB_02”
  • GU_EIB_04 : “5.7.1 <example.com[xxx.xxx.xxx.xxx]>: Client host rejected: Abus detecte GU_EIB_04”

Which are the different indicators?

There are two major SFR-analyzed indicators. They will help at deciding when to block an IP address or not.

The fist one is the spam rate (GU_EIB_04). If a great deal of your mails is filtered as spam, it is likely that your IP addresses are blocked during a certain amount of time. It is worth to know that SFR, as well as Orange and Free, employs the French Vade Retro filtering technologies in order to sort legitimate email from spam.

The second indicator is the invalid email address rate generated by your sent emails (GU_EIB_02). This last one takes into account your data management quality. As we can confirm, maintaining a clean list is a key factor to profit from good deliverability.

Facing a threshold matter.

Email rejecting is the result of high rates of invalid email addresses, as well as abnormal spam rates. In both scenarios, when 20 emails or more have been sent, SFR establishes the threshold at 25%. If we take hold to the idea that the invalid-address rate considered by the industry as valid (less than 3 or 4%) we realize that SFR-generated threshold will not aim clean-listed senders.

Length

One must consider two kinds of length.

Sampling Window: It lasts for around 5 minutes. It means that if 25% of spam reporting or bounces
is exceeded for more than 5 minutes, your emailing will be blocked temporarily.

Blocking duration: Once the threshold catastrophe is reached, your email sending will be blocked
for about 20 minutes. However, if the emailing criteria are not complied, you will be blocked for
another 20 minutes, and so on. This may relevantly slow-down the speed of email sending.

Briefing the topic.

  • GU_EIB_02
    • Indicator: Invalid email-address rate
    • Threshold: 25%
    • Sampling Window: 5 minutes
    • Blocking duration: 20 minutes
  • GU_EIB_04
    • Indicator: Spam sorting
    • Threshold: 25%
    • Sampling window: 5 minutes
    • Blocking duration: 20 minutes

Technical implementation

In order to ensure proper management of this situations, it is imperative to employ a SMTP server enabling identification of this sort of feedback (GU_EIB_02 et GU_EIB_04 codes) simultaneously adapting itself in real time.

Unfortunately, Postfix, Qmail or Sendmail opensource servers do not empower built-in management facing this kind of behavior. With this in mind, DeliverNow encourages our customers to actively employ PowerMTA. This last one enhances a backoff mode and connectivity management. If you want to learn more about PowerMTA, do not hesitate to contact DeliverNow.

It is comments time

Are you affected by GU_EIB_02 even though you are cleaning your lists on a regular basis?

In this case, it is highly possible that you are not the sole person employing this blocked IP address. This is the case, for instance, of mails sent from your own web server. The only likely solution is to utilize an specific IP address or an specialized SMTP bridging. Please feel free to contact DeliverNow if you want to implement personalized SMTP solutions.

What about Numericable?

As you certainly know, Numericable has recently become a SFR acquisition. For now, deliverability has not been affected. Numericable remains to employ the same MX servers they did before. DeliverNow will keep you informed about the every update on this issue.

SFR incoming email authentication

With the growing strength of phishing campaigns, incoming message authentication has become an important issue for ISPs to protect their users.
As written previously, various standards exist to authentify outgoing email messages.
Since September 2011, SFR has decided to verify the authenticity of incoming emails according to SPF standard and might be thinking of an upcoming implementation of DKIM.
SPF standard allows domain owners to specify, with a DNS record, which are the authorised servers able to use their domain to send email messages.
Let see, with two practical examples, how SFR processes and filters incoming emails using SPF:

  • For a start, lets try to send an email to SFR from the IP 82.165.131.171 with the domain dlnw01.com for which we set the following strict SPF record v=spf1 ip4:82.165.131.172 -allIt results in a delivery refusal because of the SPF hardfailed:
    HELO dlnw01.com
    250 msfrf2207.sfr.fr
    MAIL FROM:<dlnw@dlnw01.com> 554 5.7.1 <dlnw@dlnw01.com>: Sender address rejected: Please%see%http://spf.pobox.com/why.html?sender=dlnw%40dlnw01.com&ip=82.165.131.171&receiver=msfrf2207 : Reason: mechanism
  • Now, lets try to send SFR an email from IP 82.165.131.171 and domain dlnw01.com with the following flexible SPF record setting v=spf1 ip4:82.165.131.172 ~allThe result is the delivery of the email in the spam box with the following header appearing in the header:
    X-tag-spam: SPF SoftFail

To protect its identity, it is important for the advertiser to authentify its domains, but the example above shows that it is crucial to do it properly in order to avoid a connection rejection or a delivery in spam box.
In addition, even though authentication should ensure sender authenticity, emails are not guaranteed to get to the main reception box.

Orange Protects Its Messaging Infrastructure With Cloudmark Antispam Solution

Since November 15th, Orange has implemented Cloudmark solutions in order to protect its messaging infrastructure.
As quoted on Cloudmark site, Sylvain Causse of France Telecom/ Orange points out:

« We selected Cloudmark considering their expertise and experience in the message security industry, and the high performance and flexibility level of the solutions they provide. We look forward to working with Cloudmark to continue providing the best messaging protection for our customers. »

Like most ISPs and webmail services, the main concerns for Orange are to protect its messaging infrastructure and satisfy its customers.

For email senders, the router rules to be applied to Orange MX have changed and it is necessary to adapt the connectivity on Orange platform in order to avoid temporary or permanent rejections.

Here are some useful guidelines that should be applied when sending emails to Orange:

– The maximum number of simultaneous connections is limited to 3 per MX

Orange manage both @orange.fr and @wanadoo.fr addresses with the same MX servers but sometimes SMTP servers only accept one setting per delivery domain. Therefore, the 3 authorised simultaneous connections have to be shared between these 2 domains; for example: 2 for Orange.fr domain and 1 for wanandoo.fr.

A bad setting can be verified when the following message appears in the sending log file :
421 xxxxxxxxx ME, Too many connections, slow down. Check your settings.

– Do not request more than a 1000 connections per hour

On a day to day basis, everyone knows that you shouldn’t bother someone who is busy and doesn’t have time to answer your question; it is better to come back when this person is free. The same applies to connections: an SMTP dialog has to be polite and respectful. If a connection happens to be denied by an ISP, it is useless to insist on connecting because you might experience more rejections and for longer periods of time.

– Send over a 100 emails per open connection

When you want to send several emails to the same domain, opening and closing a connection to send a single email is quite a bad practice. It is resource consuming and neither the ISPs nor the senders have resources to spare. Once the connection request is accepted by the Orange server, you should use the same session to transmit up to a 100 emails.

If a problem occurs, Orange has a responsive, competent and efficient abuse desk that solves all the questions related to email deliverability on its infrastructure. You just need to write to abuse@orange.fr describing exactly what the problem is and giving the following information as precisely as possible:

  • The date of occurrence of the problem
  • The concerned machine IP
  • The machine Host name
  • The email sending domain
  • The SMTP code sent by Orange

Generally, messaging infrastructure departments are extremely busy. Therefore, it is very important to have performed the first diagnostic level by analysing the sending logs before seeking their help. Your request should be as clear and precise as possible and you should be able to answer all the technical questions they might have to ask you.

You have to strictly avoid the “I am blocked, what can I do?” type of email.

The ISPs operators are not supposed to solve sender’s problems and, most of the time, you will find yourself the answer to your questions in the SMTP log file.

All these major changes were necessary in order to protect Orange messaging infrastructure, even though, the fact of switching from a very traditional screening system to a more efficient one, partly based on reputation, unhinges part of the senders of the French messaging ecosystem. Whereas, for a number of years, you could send email easily to French ISPs without being afraid to experience rejection (like for the big webmail services), you will now have to perform a more detailed job improving transparency during the email collection and showing more respect for the internet users and their desire to receive only emails they want in their mail box.

Orange Abuse Desk :
http://assistance.orange.fr/la-cellule-abuse-1260.php

For further information on Cloudmark solutions for ISPs:
http://www.cloudmark.com/en/industries/isps/index