Filtrage des mails à l'émission ou à la réception


Contrôles des spams : tout repose sur le MTA destinataire

mardi 21 juillet 2009 par Sophie

Dans l’immense majorité des cas, la détection des spams est effectuée sur le dernier MTA avant le destinataire final du mail. Cela peut poser des problèmes considérables, et quelques pistes existent pour alléger cette charge.

La plupart des systèmes antispam actuels reposent sur un principe post-acceptation, c’est-à-dire que le MTA (Mail Transfer Agent) reçoit les messages et les stocke dans une file d’attente avant de les livrer aux destinataires. Ce traitement fait peser un risque de retard et de perte des emails légitimes en cas de trafic important conduisant à une surcharge du système. Il faut dire que toute la charge de la détection des spams repose quasi-uniquement sur les destinataires. L’immense majorité des spams est pourtant envoyée par des systèmes automatisés, le plus souvent des PC zombies.

Si tous les FAI, les fournisseurs de courriers électroniques ou encore les réseaux d’entreprise décidaient de contrôler leurs emails sortants afin de neutraliser ces zombies, le volume de spams en circulation se réduirait considérablement. Cela aurait pour conséquence d’alléger la charge des MTAs finaux (et donc de ne plus entraîner de pertes ou de retards dans la livraison du courrier), d’éviter que des domaines entiers soient mis sur listes noires parce qu’un ou quelques zombies émettent massivement du spam sur quelques uns de leurs IPs, voire éviterait qu’un domaine ait mauvaise presse (qui n’a pas entendu les critiques sur tel FAI ou tel hébergeur qui est incapable de neutraliser des zombies présents sur son réseau et qui arrosent le reste de l’Internet ?). Malheureusement, détecter et traiter les spams dans les messages sur le MTA expéditeur a un coût, qui vient s’ajouter au coût de détection des spams entrants. Aucune organisation ou entité ne se lance donc dans une telle pratique, d’autant plus qu’elle n’est pas la première victime des spams sortants.

Des solutions sont donc mises en œuvre afin d’alléger la charge du MTA destinataire et garantir la qualité de son service. Parmi celles-ci, on a imaginé d’affecter une priorité de traitement différenciée aux mails : les mails légitimes sont traités prioritairement et les spams sont analysés après. De cette manière, même en cas de charge importante, les mails légitimes risqueraient moins de se perdre ou d’être retardés. Cette technique a toutefois l’inconvénient de n’être applicable qu’après que les mails soient reçus par le MTA, ce qui ne diminue pas le nombre de mails mis en attente au total. Le MTA n’a en effet d’autre choix que d’accepter tous les messages entrants avec le même niveau de priorité parce qu’il est incapable de faire la discrimination à cette étape-là du processus.

Une autre technique possible consiste à se servir d’un proxy MTA pour effectuer la classification des e-mails en cas de charge importante avant que le MTA final ne prenne uniquement en charge la distribution. La charge est donc essentiellement déplacée sur le MTA proxy, mais il n’empêche que ce dernier a lui aussi recours à une réception/reconstitution totale des mails avant de pouvoir les analyser.

Une configuration de proxy MTA en post-acceptation est liée à la problématique de gestion des bounces vus dans notre article : gestion des utilisateurs et call-out . Pour contourner ces difficultés et maîtriser les actions à engager en fonction de la nature des emails, nous recommandons fortement l’analyse pendant la transaction dans le protocole SMTP (cf article analyse des spams dans le protocole SMTP).

Votez...

  • del.icio.us
  • Twitter
  • Facebook
  • LinkedIn
  • RSS
  • StumbleUpon
  • Digg


Tags : , , , ,


Articles similaires:
- La vigilance est l’arme fatale contre les pourriels (51.7%)
- Comment mettre fin au règne des spams ? (51.7%)
- Les réseaux sociaux et le spam (51.7%)
- Le spam et son coût pour les entreprises (51.7%)
- Les bons réflexes face aux spams (51.7%)

Laisser un commentaire

*


English Espa?ol Italiana Deutsche

Copyright © 2002-2014 OKTEY - Tous droits réservés - Accessibilité - Mentions légales - Plan du site - Google+   Flux RSS