Freesurf.fr vient d'intégrer un antispam à son service de messagerie
électronique (gratuit/100Mo/POP/SMTP/Webmail)
Probablement basé sur spamassasin, les spams seront marqués dans le sujet
par ajout de ****SPAM****, ainsi que dans les en-têtes via les champs
X-Spam-Flag: et X-Spam-Level:
ils pourront être supprimés directement ou déplacés par filtrage coté
serveur.
l'effacement automatique sera réalisé au bout de 4 semaines pour des spams
restés dans la boîte de réception et au bout de deux semaines s'ils ont été
déplacés dans une boîte nommée SPAM.
Je trouve cela assez judicieux, et vous ?
d'autres fournisseurs de messagerie gratuite proposent-ils déja ce service?
Question conne: pourquoi? C'est trop lourd à gérer en live? (charge CPU?)
Erwan David
Xavier Roche écrivait :
Laurent Wacrenier wrote:
On ne le fait pas sur SMTP mais à la livraison
Question conne: pourquoi? C'est trop lourd à gérer en live? (charge CPU?)
Laurent l'a dit : chaque utilisateur gère ses filtres, donc si un mail a 2 destinataires différents il faut un traitement séparé. Ce traitement est séparé dans le MDA (agent de livraison) et pas dans le MTA.
Question conne: pourquoi? C'est trop lourd à gérer en live? (charge CPU?)
Laurent l'a dit : chaque utilisateur gère ses filtres, donc si un mail
a 2 destinataires différents il faut un traitement séparé. Ce
traitement est séparé dans le MDA (agent de livraison) et pas dans le
MTA.
Question conne: pourquoi? C'est trop lourd à gérer en live? (charge CPU?)
Laurent l'a dit : chaque utilisateur gère ses filtres, donc si un mail a 2 destinataires différents il faut un traitement séparé. Ce traitement est séparé dans le MDA (agent de livraison) et pas dans le MTA.
Laurent Wacrenier
Xavier Roche écrit:
Laurent Wacrenier wrote:
On ne le fait pas sur SMTP mais à la livraison
Question conne: pourquoi? C'est trop lourd à gérer en live? (charge CPU?)
Avec SMTP, par utilisateur on ne peut filtrer que sur des infos connues au momment de la présentation d'une adresse destinataire (adresses IP de l'emeteur, chaîne HELO, adresse expediteur, éventuelle taille estimée, etc.). Celà permet des RBL par utilisateur, des listes grises, etc.
Un filtre sur le message lui même n'est possible qu'après avoir reçu ce message et ce messsage peut être envoyé à plusieurs utilisateur alors que le serveur ne peut renvoyer qu'un seul code de retour.
Quant à la charge CPU, elle n'est pas si importante que celà. On fait tourner un antivirus sur 250000 messages par jour. Celà ajoute une latence de entre un et deux dizièmes de seconde, à peine moins que Spamassassin. L'antivirus peut tourner sur un nombre variable de serveurs (actuellement deux pentiums 750). La vérification se fait à la livraison.
Si la vérification se faisait à la réception, il serait possible que le client pense que le délai de réponse est dépassé si l'analyse dure trop longtemps. Le message serait alors rééxpédié, on verrait alors duplicats et il n'y aurait que peu de chance que la situation s'améliore.
Question conne: pourquoi? C'est trop lourd à gérer en live? (charge CPU?)
Avec SMTP, par utilisateur on ne peut filtrer que sur des infos
connues au momment de la présentation d'une adresse destinataire
(adresses IP de l'emeteur, chaîne HELO, adresse expediteur, éventuelle
taille estimée, etc.). Celà permet des RBL par utilisateur, des listes
grises, etc.
Un filtre sur le message lui même n'est possible qu'après avoir reçu
ce message et ce messsage peut être envoyé à plusieurs utilisateur
alors que le serveur ne peut renvoyer qu'un seul code de retour.
Quant à la charge CPU, elle n'est pas si importante que celà. On fait
tourner un antivirus sur 250000 messages par jour. Celà ajoute une
latence de entre un et deux dizièmes de seconde, à peine moins que
Spamassassin. L'antivirus peut tourner sur un nombre variable de
serveurs (actuellement deux pentiums 750). La vérification se fait à
la livraison.
Si la vérification se faisait à la réception, il serait possible que
le client pense que le délai de réponse est dépassé si l'analyse dure
trop longtemps. Le message serait alors rééxpédié, on verrait alors
duplicats et il n'y aurait que peu de chance que la situation
s'améliore.
Question conne: pourquoi? C'est trop lourd à gérer en live? (charge CPU?)
Avec SMTP, par utilisateur on ne peut filtrer que sur des infos connues au momment de la présentation d'une adresse destinataire (adresses IP de l'emeteur, chaîne HELO, adresse expediteur, éventuelle taille estimée, etc.). Celà permet des RBL par utilisateur, des listes grises, etc.
Un filtre sur le message lui même n'est possible qu'après avoir reçu ce message et ce messsage peut être envoyé à plusieurs utilisateur alors que le serveur ne peut renvoyer qu'un seul code de retour.
Quant à la charge CPU, elle n'est pas si importante que celà. On fait tourner un antivirus sur 250000 messages par jour. Celà ajoute une latence de entre un et deux dizièmes de seconde, à peine moins que Spamassassin. L'antivirus peut tourner sur un nombre variable de serveurs (actuellement deux pentiums 750). La vérification se fait à la livraison.
Si la vérification se faisait à la réception, il serait possible que le client pense que le délai de réponse est dépassé si l'analyse dure trop longtemps. Le message serait alors rééxpédié, on verrait alors duplicats et il n'y aurait que peu de chance que la situation s'améliore.
Xavier Roche
Laurent Wacrenier wrote:
Un filtre sur le message lui même n'est possible qu'après avoir reçu ce message
Certes - juste après le "." final. Mais c'est à ce moment là que l'on répond "2XX" ou "5XX"
et ce messsage peut être envoyé à plusieurs utilisateur
Si le filtrage est différent par utilisateur, c'est certes chiant. Mais cela doit représenter moins de 1% des mails, non ?
Dans la plupart des cas, une analyse à la volée serait possible (un seul destinataire) ; sinon un "2XX" et un post-bounce adéquat
Si la vérification se faisait à la réception, il serait possible que le client pense que le délai de réponse est dépassé
Euhh même spamassassin ne prend pas plus de 1 ou 2 secondes (je trouve déja cela très long!) ; en cas de RBL à la masse le timeout peut être réglé (et les résolutions RBL sont lancées en parallèle, donc elles ne d'ajoutent pas)
Laurent Wacrenier wrote:
Un filtre sur le message lui même n'est possible qu'après avoir reçu
ce message
Certes - juste après le "." final. Mais c'est à ce moment là que l'on
répond "2XX" ou "5XX"
et ce messsage peut être envoyé à plusieurs utilisateur
Si le filtrage est différent par utilisateur, c'est certes chiant.
Mais cela doit représenter moins de 1% des mails, non ?
Dans la plupart des cas, une analyse à la volée serait possible (un seul
destinataire) ; sinon un "2XX" et un post-bounce adéquat
Si la vérification se faisait à la réception, il serait possible que
le client pense que le délai de réponse est dépassé
Euhh même spamassassin ne prend pas plus de 1 ou 2 secondes (je trouve
déja cela très long!) ; en cas de RBL à la masse le timeout peut être
réglé (et les résolutions RBL sont lancées en parallèle, donc elles ne
d'ajoutent pas)
Un filtre sur le message lui même n'est possible qu'après avoir reçu ce message
Certes - juste après le "." final. Mais c'est à ce moment là que l'on répond "2XX" ou "5XX"
et ce messsage peut être envoyé à plusieurs utilisateur
Si le filtrage est différent par utilisateur, c'est certes chiant. Mais cela doit représenter moins de 1% des mails, non ?
Dans la plupart des cas, une analyse à la volée serait possible (un seul destinataire) ; sinon un "2XX" et un post-bounce adéquat
Si la vérification se faisait à la réception, il serait possible que le client pense que le délai de réponse est dépassé
Euhh même spamassassin ne prend pas plus de 1 ou 2 secondes (je trouve déja cela très long!) ; en cas de RBL à la masse le timeout peut être réglé (et les résolutions RBL sont lancées en parallèle, donc elles ne d'ajoutent pas)
Laurent Wacrenier
Xavier Roche écrit:
et ce messsage peut être envoyé à plusieurs utilisateur
Si le filtrage est différent par utilisateur, c'est certes chiant.
C'est pire que chiant, ça invalide le processus.
Mais cela doit représenter moins de 1% des mails, non ?
Pas sur les serveurs où des utilisateurs sont abonnés à des listes.
Dans la plupart des cas, une analyse à la volée serait possible (un seul destinataire) ; sinon un "2XX" et un post-bounce adéquat
Et si le courrier est envoyé à 100 personnes ? Il faut le scanner deux fois. La première pour voir si on l'accepte et la seconde pour voir à qui il faut envoyer des bounces. Ce n'est pas raisonnable.
Si la vérification se faisait à la réception, il serait possible que le client pense que le délai de réponse est dépassé
Euhh même spamassassin ne prend pas plus de 1 ou 2 secondes (je trouve déja cela très long!) ; en cas de RBL à la masse le timeout peut être réglé (et les résolutions RBL sont lancées en parallèle, donc elles ne d'ajoutent pas)
0,3 seconde (sans options réseau ni auto apprentissage) fois 100 destinataires = 30 secondes. Timeout. Le client renvoie le message l'heure d'après etc. Compter plus si la machine est chargée, ce qui risque de ne pas tarder.
Dans le pire des cas, le serveur doit s'arreter de recevoir du courrier, pas s'emballer, comme ça se passe ici.
et ce messsage peut être envoyé à plusieurs utilisateur
Si le filtrage est différent par utilisateur, c'est certes chiant.
C'est pire que chiant, ça invalide le processus.
Mais cela doit représenter moins de 1% des mails, non ?
Pas sur les serveurs où des utilisateurs sont abonnés à des listes.
Dans la plupart des cas, une analyse à la volée serait possible (un seul
destinataire) ; sinon un "2XX" et un post-bounce adéquat
Et si le courrier est envoyé à 100 personnes ? Il faut le scanner deux
fois. La première pour voir si on l'accepte et la seconde pour voir à
qui il faut envoyer des bounces. Ce n'est pas raisonnable.
Si la vérification se faisait à la réception, il serait possible que
le client pense que le délai de réponse est dépassé
Euhh même spamassassin ne prend pas plus de 1 ou 2 secondes (je trouve
déja cela très long!) ; en cas de RBL à la masse le timeout peut être
réglé (et les résolutions RBL sont lancées en parallèle, donc elles ne
d'ajoutent pas)
0,3 seconde (sans options réseau ni auto apprentissage) fois 100
destinataires = 30 secondes. Timeout. Le client renvoie le message
l'heure d'après etc. Compter plus si la machine est chargée, ce qui
risque de ne pas tarder.
Dans le pire des cas, le serveur doit s'arreter de recevoir du
courrier, pas s'emballer, comme ça se passe ici.
et ce messsage peut être envoyé à plusieurs utilisateur
Si le filtrage est différent par utilisateur, c'est certes chiant.
C'est pire que chiant, ça invalide le processus.
Mais cela doit représenter moins de 1% des mails, non ?
Pas sur les serveurs où des utilisateurs sont abonnés à des listes.
Dans la plupart des cas, une analyse à la volée serait possible (un seul destinataire) ; sinon un "2XX" et un post-bounce adéquat
Et si le courrier est envoyé à 100 personnes ? Il faut le scanner deux fois. La première pour voir si on l'accepte et la seconde pour voir à qui il faut envoyer des bounces. Ce n'est pas raisonnable.
Si la vérification se faisait à la réception, il serait possible que le client pense que le délai de réponse est dépassé
Euhh même spamassassin ne prend pas plus de 1 ou 2 secondes (je trouve déja cela très long!) ; en cas de RBL à la masse le timeout peut être réglé (et les résolutions RBL sont lancées en parallèle, donc elles ne d'ajoutent pas)
0,3 seconde (sans options réseau ni auto apprentissage) fois 100 destinataires = 30 secondes. Timeout. Le client renvoie le message l'heure d'après etc. Compter plus si la machine est chargée, ce qui risque de ne pas tarder.
Dans le pire des cas, le serveur doit s'arreter de recevoir du courrier, pas s'emballer, comme ça se passe ici.
Xavier Roche
Laurent Wacrenier wrote:
Et si le courrier est envoyé à 100 personnes ? Il faut le scanner deux fois.
Non, non. Il suffit de compter le nombre de RCPT TO.
0,3 seconde (sans options réseau ni auto apprentissage) fois 100 destinataires = 30 secondes.
Mais comme dans le cas de "multiple destinataires" on passe en mode temporisé, c'est pas grave ?
Laurent Wacrenier wrote:
Et si le courrier est envoyé à 100 personnes ? Il faut le scanner deux
fois.
Non, non. Il suffit de compter le nombre de RCPT TO.
0,3 seconde (sans options réseau ni auto apprentissage) fois 100
destinataires = 30 secondes.
Mais comme dans le cas de "multiple destinataires" on passe en mode
temporisé, c'est pas grave ?
Et si le courrier est envoyé à 100 personnes ? Il faut le scanner deux fois.
Non, non. Il suffit de compter le nombre de RCPT TO.
0,3 seconde (sans options réseau ni auto apprentissage) fois 100 destinataires = 30 secondes.
Mais comme dans le cas de "multiple destinataires" on passe en mode temporisé, c'est pas grave ?
Laurent Wacrenier
Xavier Roche écrit:
Laurent Wacrenier wrote:
Et si le courrier est envoyé à 100 personnes ? Il faut le scanner deux fois.
Non, non. Il suffit de compter le nombre de RCPT TO.
Patcher le serveur ? C'est beaucoup de magouille pour un spam.
0,3 seconde (sans options réseau ni auto apprentissage) fois 100 destinataires = 30 secondes.
Mais comme dans le cas de "multiple destinataires" on passe en mode temporisé, c'est pas grave ?
C'est quoi le mode temporisé ? Si les 99 premiers rejetent le courrier et le dernier l'accepte ? ou le contraire ? Tu es obligé de lancer 100 fois le filtre pour savoir quoi répondre.
Et si le courrier est envoyé à 100 personnes ? Il faut le scanner deux
fois.
Non, non. Il suffit de compter le nombre de RCPT TO.
Patcher le serveur ? C'est beaucoup de magouille pour un spam.
0,3 seconde (sans options réseau ni auto apprentissage) fois 100
destinataires = 30 secondes.
Mais comme dans le cas de "multiple destinataires" on passe en mode
temporisé, c'est pas grave ?
C'est quoi le mode temporisé ? Si les 99 premiers rejetent le courrier
et le dernier l'accepte ? ou le contraire ? Tu es obligé de lancer 100
fois le filtre pour savoir quoi répondre.
Et si le courrier est envoyé à 100 personnes ? Il faut le scanner deux fois.
Non, non. Il suffit de compter le nombre de RCPT TO.
Patcher le serveur ? C'est beaucoup de magouille pour un spam.
0,3 seconde (sans options réseau ni auto apprentissage) fois 100 destinataires = 30 secondes.
Mais comme dans le cas de "multiple destinataires" on passe en mode temporisé, c'est pas grave ?
C'est quoi le mode temporisé ? Si les 99 premiers rejetent le courrier et le dernier l'accepte ? ou le contraire ? Tu es obligé de lancer 100 fois le filtre pour savoir quoi répondre.
Sylvain
rm wrote:
Je trouve cela assez judicieux, et vous ?
Seul problème pour SA: il bouffe vraiment trop de CPU pour le mettre en prod sur un gros volume AMHA.
Mon entreprise reçoit 500 à 700 mels par jour. J'ai installé SA sur un celeron 400 avec 256 Mo, c'est en production depuis 10 jours, et je ne vois pas la charge CPU dépasser 1%
Pour un *tres* gros volume, faut bien sur dimensionner le serveur en concéquence, mais la notion de gros volume est relative.
rm wrote:
Je trouve cela assez judicieux, et vous ?
Seul problème pour SA: il bouffe vraiment trop de CPU pour le mettre en
prod sur un gros volume AMHA.
Mon entreprise reçoit 500 à 700 mels par jour.
J'ai installé SA sur un celeron 400 avec 256 Mo,
c'est en production depuis 10 jours,
et je ne vois pas la charge CPU dépasser 1%
Pour un *tres* gros volume, faut bien sur dimensionner le serveur en
concéquence, mais la notion de gros volume est relative.
Seul problème pour SA: il bouffe vraiment trop de CPU pour le mettre en prod sur un gros volume AMHA.
Mon entreprise reçoit 500 à 700 mels par jour. J'ai installé SA sur un celeron 400 avec 256 Mo, c'est en production depuis 10 jours, et je ne vois pas la charge CPU dépasser 1%
Pour un *tres* gros volume, faut bien sur dimensionner le serveur en concéquence, mais la notion de gros volume est relative.
Laurent Wacrenier
Sylvain écrit:
Mon entreprise reçoit 500 à 700 mels par jour. J'ai installé SA sur un celeron 400 avec 256 Mo, c'est en production depuis 10 jours, et je ne vois pas la charge CPU dépasser 1%
700 scans par jour, ce n'est pas grand chose, moins d'un par minute et demi en moyenne.
Pour un *tres* gros volume, faut bien sur dimensionner le serveur en concéquence, mais la notion de gros volume est relative.
Pour bien faire, il faut une architecture qui permet de rajouter d'autres serveurs de calcul en cas de besoin.
Sylvain <nospam@pouet.net.invalid> écrit:
Mon entreprise reçoit 500 à 700 mels par jour.
J'ai installé SA sur un celeron 400 avec 256 Mo,
c'est en production depuis 10 jours,
et je ne vois pas la charge CPU dépasser 1%
700 scans par jour, ce n'est pas grand chose, moins d'un par minute et
demi en moyenne.
Pour un *tres* gros volume, faut bien sur dimensionner le serveur en
concéquence, mais la notion de gros volume est relative.
Pour bien faire, il faut une architecture qui permet de rajouter
d'autres serveurs de calcul en cas de besoin.
Mon entreprise reçoit 500 à 700 mels par jour. J'ai installé SA sur un celeron 400 avec 256 Mo, c'est en production depuis 10 jours, et je ne vois pas la charge CPU dépasser 1%
700 scans par jour, ce n'est pas grand chose, moins d'un par minute et demi en moyenne.
Pour un *tres* gros volume, faut bien sur dimensionner le serveur en concéquence, mais la notion de gros volume est relative.
Pour bien faire, il faut une architecture qui permet de rajouter d'autres serveurs de calcul en cas de besoin.
Xavier Roche
Laurent Wacrenier wrote:
Pour bien faire, il faut une architecture qui permet de rajouter d'autres serveurs de calcul en cas de besoin.
Ouais, remarque au pire 10 bécannes "standard" (PC) en frontal, qui redirigent vers une seule machine pour le stockage, le tout avec N entrées DNS "tournantes". Quand je vois la vitesse des PC "bas de gamme" (<500¤) que l'on peut avoir hummm, pas besoin de serveur coûteux finalement.
Mais je reste persuadé qu'on peut traiter la plupart des mails entrants à la volée sans post-traitement :)
Laurent Wacrenier wrote:
Pour bien faire, il faut une architecture qui permet de rajouter
d'autres serveurs de calcul en cas de besoin.
Ouais, remarque au pire 10 bécannes "standard" (PC) en frontal,
qui redirigent vers une seule machine pour le stockage, le tout
avec N entrées DNS "tournantes".
Quand je vois la vitesse des PC "bas de gamme" (<500¤) que l'on
peut avoir hummm, pas besoin de serveur coûteux finalement.
Mais je reste persuadé qu'on peut traiter la plupart des mails
entrants à la volée sans post-traitement :)
Pour bien faire, il faut une architecture qui permet de rajouter d'autres serveurs de calcul en cas de besoin.
Ouais, remarque au pire 10 bécannes "standard" (PC) en frontal, qui redirigent vers une seule machine pour le stockage, le tout avec N entrées DNS "tournantes". Quand je vois la vitesse des PC "bas de gamme" (<500¤) que l'on peut avoir hummm, pas besoin de serveur coûteux finalement.
Mais je reste persuadé qu'on peut traiter la plupart des mails entrants à la volée sans post-traitement :)
