Opération de maintenance

Sat, 26 Jun 2010 10:21:00 GMT

Une opération de maintenance a eu lieu le 26 juin 2010, de 11:00 à 12:30

Veuillez nous excuser de ce désagrément

Imatech.

Opération de maintenance

Fri, 05 Mar 2010 16:14:39 GMT

Une opération de maintenance aura lieu dans la nuit du 05 mars 2010 au 06 mars 2010.
Les services seront perturbés à partir de 21:00 le 05/03/2010

Veuillez nous excuser de ce désagrément

Imatech.

Maintenance prévue sur le serveur de messagerie (ReliGo!)

Thu, 04 Jun 2009 06:00:00 GMT

Une mise à jour matériel aura lieu ce jour de 18:15 à 18:45 (30 minutes) sur le serveur principal utilisé pour ReliGo!

La durée maxi prévue est de 30 minutes.

Tous les clients des services de messagerie seront impactés durant la période prévue.

Imatech

Mise à jour de la plate-forme Windows

Fri, 15 May 2009 07:25:42 GMT

http://support.imatech.net/News/10/mise-jour-de-la-plate-forme-windows.aspx Fri, 15 May 2009 07:25:42 GMT newsitem10 Mise à jour de la plate-forme Windows.

La plate-forme principale d'hébergement sous Windows est en cours de mise à jour.
Les sites utilisant la technologie .NET seront perturbés (asp.NET, DotNetNuke) pendant quelques minutes de manière aléatoire entre 9:00 et 10:00

Imatech

Problème éléctrique

Tue, 21 Apr 2009 06:33:32 GMT

le 21/04/2009 : 4:45

Suite à un problème électrique sur un onduleur de la plate-forme, les serveurs reliés à cet équipement ont été automatiquement arrêtés, conformément au scénario de protection retenu, afin de préserver les équipements.

L’onduleur étant en défaut, celui-ci n’a pu réalimenter les serveurs qu’après une procédure d’auto diagnostique.

Tous les services fonctionnent correctement maintenant.

L’incident est en cours d’analyse.

Imatech

Mise à jour de ReliGo!

Wed, 08 Apr 2009 10:41:54 GMT

Maintenance sur le serveur de messagerie ReliGo!

Le 08/04/2009

Les services de messagerie seront non disponibles de 12:40 à 12:50 et de 13:05 à 13:15

Veuillez nous excuser de cette interruption

Imatech

Maintenance sur les serveurs de messagerie

Fri, 03 Apr 2009 06:00:00 GMT

Une opération de maintenance des serveurs de messagerie aura lieu le vendredi 3 avril 2009 de 15:00 à 15:15.

Cette opération concerne tous les clients dont la messagerie est hébergée sur les serveurs Imatech (messagerie classique et ReliGo!).

Entre 15:00 et 15:15, les serveurs d'Imatech seront momentanément non-joignables de l’internet et seront donc dans l’incapacité de pouvoir recevoir ou envoyer des messages.

But de l'opération : basculement d'environ 1400 comptes de messagerie du système actuel vers ReliGo! pour les clients non encore migrés.

Note :
"Cette migration annoncée en janvier dernier a été minutieusement préparée et tous les moyens sont mis en oeuvre pour minimiser au maximum le temps d'indisponibilité des services de messagerie qui devrait être inférieur à 15 minutes.
L'opération consiste à activer les 1462 comptes de messagerie restant encore sur le serveur historique d'Imatech.
Ainsi, tous les Clients bénéficieront des nouvelles fonctionnalités de ReliGo! (http://www.religo.fr)."

David Thomas, Imatech.

Lutter contre les messages non sollicités

Fri, 16 May 2008 06:15:25 GMT

http://support.imatech.net/News/2/lutter-contre-les-messages-non-sollicits.aspx Fri, 16 May 2008 06:15:25 GMT newsitem2

Tout d’abord, comment doit-on définir ce qu’est un message non sollicité ou SPAM ?

Il ne faut pas confondre les Emails utilisés à des fins marketings tels que définis par la loi sur l’économie numérique et les SPAMs. En effet, la loi française encadre et permet l’envoi de « publicité » par le biais de la messagerie sous deux conditions principales : le destinataire doit avoir la possibilité de se désinscrire pour ne plus être sollicité, l’adresse utilisée pour remettre le message doit être celle d’une personne dite « morale », c'est-à-dire utilisée dans le cadre de sa profession.

Dès lors, il est difficile pour un fournisseur de services de messagerie de faire le tri entre les publicités « légales » et les SPAMs.

Nous avons choisi de lutter contre les SPAMs d’un point de vue technique : pour qu’un client puisse recevoir un Email, ce dernier doit être transmis à nos serveurs en respectant les normes en vigueur (RFC).

Première analyse : le serveur qui communique avec le notre doit disposer d’un enregistrement inverse sur son adresse IP et d’une entrée MX en DNS.
Traduction : les serveurs SMTP disposent de leur propre enregistrement afin d’être reconnus comme tel. Si le serveur qui tente de communiquer avec le notre n’est pas répertorié en DNS, il est plus que probable que ce soit une machine servant exclusivement à la remise de messages souvent non sollicités.

Deuxième analyse : l’adresse IP utilisée par le serveur ne doit pas être en liste noire (blacklist). Si tel est le cas, le serveur incriminé a été répertorié comme représentant une menace. Nos serveurs mettent immédiatement fin aux communications avec ces serveurs.

Troisième analyse : la technique dite du GreyListing qui permet de déterminer avec une fiabilité proche de 95 % si le serveur qui communique avec le notre est conforme aux opérations demandées à un serveur de messagerie (SMTP). Lors de la communication avec nos serveurs, une application forme un triplet composé :

de l’adresse IP du serveur de l’expéditeur.

de l’adresse Email de l’expéditeur.

de l’adresse Email du destinataire.

Le triplet est daté puis stocké dans une base de données puis notre serveur met fin à la communication, invitant le serveur de l’expéditeur à réitérer sa tentative de remise du message*.

Cas numéro 1 : le serveur ne représente pas le message. Il est probable dans 99% des cas qu’il s’agissait d’un serveur utilisé par des SPAMEURS, ceux-ci ne procédant pas au stockage des messages pour une remise ultérieur, dans le but de ne pas être reconnus trop rapidement.

Cas numéro 2 : le serveur représente le message après quelques instants**. Nos serveurs accepteront le message pour la remise au destinataire.

Notez que tous les messages formés par le même triplet seront acceptés sans délais d’attente et ce pour une période d’au moins 30 jours entre deux messages formant des triplets équivalents.

Quatrième analyse : le dictionnaire. Quelques termes précis sont récurant dans les messages (viagra, vi@gra, vi@gr@, etc….) et les messages les contenant sont immédiatement refusés.

Ces dispositions permettent de ne pas générer de faux positifs ou de les limiter aux serveurs « mals » configurés.

Notes :

* TOUS les serveurs SMTP doivent être configurés pour permettre une mise en file d’attente de leur message pour les cas suivants : ils n’ont plus accès à l’internet (ligne coupée), le serveur avec lequel ils tentent de communiquer est temporairement indisponible (maintenance ou surcharge), un problème est survenu lors de la transmission.

** Dans certains cas, le temps d’attente entre deux remises de messages peut être supérieur à 15 minutes, voir plusieurs heures ! La raison incombe à l’administrateur DU SERVEUR DE L’EXPEDITEUR dont la durée de file d’attente est beaucoup trop longue. Nous ne sommes dès lors pas responsable de cette configuration qui ralenti la remise du message.

D'autres informations sur :
Le Greylisting
http://fr.wikipedia.org/wiki/Greylisting
http://www.greylisting.org

Les RFC
http://fr.wikipedia.org/wiki/RFC

SMTP
http://fr.wikipedia.org/wiki/SMTP

Maintenance terminée

Wed, 07 May 2008 11:29:14 GMT

Le service "Support.imatech.net" est à nouveau opérationnel

Recent News

Opération de maintenance

Opération de maintenance

Maintenance prévue sur le serveur de messagerie (ReliGo!)

Mise à jour de la plate-forme Windows

Problème éléctrique

Mise à jour de ReliGo!

Maintenance sur les serveurs de messagerie

Lutter contre les messages non sollicités

Maintenance terminée