Ce matin en arrivant, je trouve dans ma boite aux lettres 4 messages
qui font semblant d'etre des bounces (2 exemples suivent); ca ressemble
aux bons vieux "faux bounce" de SWEN mais c'est pas tout à fait le même
texte; le deuxieme exemple en particulier est bien plus crédible...
Une nouvelle version de swen ? Un nouveau virus sur le même principe ?
Trois des 4 prétendent venir de wanadoo Toulon...
JF
----------------------- exple 1 ------------------------------
Return-Path: <xxx@infini.com>
Received: from mwinf0101.wanadoo.fr (mwinf0101.wanadoo.fr)
by mwinb0203 (SMTP Server) with LMTP; Tue, 27 Jan 2004 17:48:46
+0100
X-Sieve: Server Sieve 2.2
Received: from infini.com (AToulon-201-1-20-209.w81-249.abo.wanadoo.fr
[81.249.200.209])
by mwinf0101.wanadoo.fr (SMTP Server) with ESMTP id
825D6C000262
for <moi@wanadoo.fr>; Tue, 27 Jan 2004 17:48:39 +0100 (CET)
From: xxx@infini.com
To: moi@wanadoo.fr
Subject: Test
Date: Tue, 27 Jan 2004 17:48:35 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0002_4798AC66.76E40DD4"
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <20040127164839.825D6C000262@mwinf0101.wanadoo.fr>
Mail transaction failed. Partial message is available.
et une piece jointe "document.zip"
---------------------------------------------------------------------
Return-Path: <>
Received: from mwinf0305.wanadoo.fr (mwinf0305.wanadoo.fr)
by mwinb0203 (SMTP Server) with LMTP; Tue, 27 Jan 2004 19:47:23
+0100
X-Sieve: Server Sieve 2.2
Received: from mwinf0301.wanadoo.fr (mwinf0301 [172.22.134.23])
by mwinf0305.wanadoo.fr (SMTP Server) with ESMTP id
A98A260CA658
for <wfr400001fa31280359ca08b76e@back02-mail01-02.me-
wanadoo.net>; Tue, 27 Jan 2004 19:00:45 +0100 (CET)
Received: from pop.nmmn.net (pop.nmmn.net [195.124.48.14])
by mwinf0301.wanadoo.fr (SMTP Server) with ESMTP id
7677F18000AA
for <moi@wanadoo.fr>; Tue, 27 Jan 2004 19:00:45 +0100 (CET)
Received: by pop.nmmn.net (Postfix)
id B956BBA2EA; Tue, 27 Jan 2004 18:59:48 +0100 (CET)
Date: Tue, 27 Jan 2004 18:59:48 +0100 (CET)
From: MAILER-DAEMON@pop.nmmn.com (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: moi@wanadoo.fr
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="38566BA38A.1075226388/pop.nmmn.net"
Message-Id: <20040127175948.B956BBA2EA@pop.nmmn.net>
This is the Postfix program at host pop.nmmn.net.
I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the message returned below.
Final-Recipient: rfc822; xxx@logas.de
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; unknown user: "ray"
Received: from mail.nmmn.net (mail.nmmn.net [195.124.48.17])
by pop.nmmn.net (Postfix) with ESMTP id 38566BA38A
for <xxx@logas.de>; Tue, 27 Jan 2004 18:58:47 +0100 (CET)
Received: from gw.nmmn.net (gw.nmmn.net [195.124.48.12])
by mail.nmmn.net (Postfix) with ESMTP id 50F76CA03C
for <xxx@logas.de>; Tue, 27 Jan 2004 18:58:44 +0100 (CET)
Received: from wanadoo.fr (AToulon-201-1-20-209.w81-249.abo.wanadoo.fr
[81.249.200.209])
by gw.nmmn.net (Postfix) with ESMTP id 872C09A89C
for <xxx@logas.de>; Tue, 27 Jan 2004 18:58:42 +0100 (CET)
From: moi@wanadoo.fr
To: xxx@logas.de
Subject: hi
Date: Tue, 27 Jan 2004 18:58:41 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0014_4AD15FC4.A882FEFE"
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <20040127175842.872C09A89C@gw.nmmn.net>
The message contains Unicode characters and has been sent as a binary
attachment.
Je viens de mettre le greylisting en place sur mes serveurs à partir d'une version modifiée (mysql) du script de Wietse Venema. Ca fait une heure que ça tourne, seuls 2 MyDoom sont passés pendant ce temps au lieu des 400 habituels. En plus ce sont des bounces (numericable et ovh).
Si tu es sur Postfix, le script d'example ne marche pas à grosse échelle (les vérous n'ont pas vraiment d'effet avec Berkeley DB 1.x, "perldoc DB_File" l'explique).
J'en ai fait un propre qui utilise MySQL4 et les transactions, je peux te le passer si tu veux tester, mais je n'ai pas fait de doc.
Un autre problème avec Postfix, c'est que la liste grise se déclanche avant la vérification de la destination dans les tables locales. Ça rempli inutilement les bases.
Pendant une période de tests, j'ai fixé ce délai à 5 minutes. Je l'ajusterais par la suite, mais pour l'instant, c'est suffisement efficace sans trop retarder les correspondances.
Attention quand même, il y a des réactions hostiles. C'est plus facile de constater que du courrier arrive en retard que la baisse du taux de spams et de virus.
Stephane Locatelli <locat@freesurf.fr> écrit:
Je viens de mettre le greylisting en place sur mes serveurs à partir
d'une version modifiée (mysql) du script de Wietse Venema. Ca fait une
heure que ça tourne, seuls 2 MyDoom sont passés pendant ce temps au lieu
des 400 habituels. En plus ce sont des bounces (numericable et ovh).
Si tu es sur Postfix, le script d'example ne marche pas à grosse
échelle (les vérous n'ont pas vraiment d'effet avec Berkeley DB 1.x,
"perldoc DB_File" l'explique).
J'en ai fait un propre qui utilise MySQL4 et les transactions, je peux
te le passer si tu veux tester, mais je n'ai pas fait de doc.
Un autre problème avec Postfix, c'est que la liste grise se déclanche
avant la vérification de la destination dans les tables locales. Ça
rempli inutilement les bases.
Pendant une période de tests, j'ai fixé ce délai à 5 minutes. Je
l'ajusterais par la suite, mais pour l'instant, c'est suffisement
efficace sans trop retarder les correspondances.
Attention quand même, il y a des réactions hostiles. C'est plus facile
de constater que du courrier arrive en retard que la baisse du taux de
spams et de virus.
Je viens de mettre le greylisting en place sur mes serveurs à partir d'une version modifiée (mysql) du script de Wietse Venema. Ca fait une heure que ça tourne, seuls 2 MyDoom sont passés pendant ce temps au lieu des 400 habituels. En plus ce sont des bounces (numericable et ovh).
Si tu es sur Postfix, le script d'example ne marche pas à grosse échelle (les vérous n'ont pas vraiment d'effet avec Berkeley DB 1.x, "perldoc DB_File" l'explique).
J'en ai fait un propre qui utilise MySQL4 et les transactions, je peux te le passer si tu veux tester, mais je n'ai pas fait de doc.
Un autre problème avec Postfix, c'est que la liste grise se déclanche avant la vérification de la destination dans les tables locales. Ça rempli inutilement les bases.
Pendant une période de tests, j'ai fixé ce délai à 5 minutes. Je l'ajusterais par la suite, mais pour l'instant, c'est suffisement efficace sans trop retarder les correspondances.
Attention quand même, il y a des réactions hostiles. C'est plus facile de constater que du courrier arrive en retard que la baisse du taux de spams et de virus.
Laurent Wacrenier
Xavier écrit:
Si tu es sur Postfix, le script d'example ne marche pas à grosse échelle (les vérous n'ont pas vraiment d'effet avec Berkeley DB 1.x, "perldoc DB_File" l'explique).
Est-il vraiment nécessaire d'utiliser DB. Un simple fichier hashé (accés par postmap encadré par un lockfile ) ne serait-il pas suffisant, pour un petit site ?
Postmap utilise DB :)
Une liste grise utilised des clefs composées de trois éléments. C'est trop compliqué pour les dictionnaires et les règles de Postfix.
Pour un petit site, les problèmes de vérous de DB1 sont moins visibles. On peut aussi fermer et ouvrir sa DB à chaque usage sans que ça impacte les performances globales.
Sinon, il vaut mieux utiliser DB3 ou DB4 qui gèrent les vérous et les transactions.
J'en ai fait un propre qui utilise MySQL4 et les transactions, je peux te le passer si tu veux tester, mais je n'ai pas fait de doc.
Moi, ça m'intéresse, merci
Bon, faut que fasse une petite doc.
Un autre problème avec Postfix, c'est que la liste grise se déclanche avant la vérification de la destination dans les tables locales. Ça rempli inutilement les bases.
Tu peux toujours le faire à la main dans le corps de ton filtre, et de là renvoyer un EX_TEMPFAIL, non ? En fait, on pouvait l'implémenter soi-même depuis longtemps, fallait juste y penser....
C'est pas comme ça que ça marche, mais effectivement on peut faire la vérification dans la liste grise et rejeter le courrier. Mais comme Postfix va la refaire derrière, c'est du gaspillage.
Xavier <xavier@groumpf.org> écrit:
Si tu es sur Postfix, le script d'example ne marche pas à grosse
échelle (les vérous n'ont pas vraiment d'effet avec Berkeley DB 1.x,
"perldoc DB_File" l'explique).
Est-il vraiment nécessaire d'utiliser DB. Un simple fichier hashé (accés
par postmap encadré par un lockfile ) ne serait-il pas suffisant, pour
un petit site ?
Postmap utilise DB :)
Une liste grise utilised des clefs composées de trois éléments. C'est
trop compliqué pour les dictionnaires et les règles de Postfix.
Pour un petit site, les problèmes de vérous de DB1 sont moins
visibles. On peut aussi fermer et ouvrir sa DB à chaque usage sans que
ça impacte les performances globales.
Sinon, il vaut mieux utiliser DB3 ou DB4 qui gèrent les vérous et les
transactions.
J'en ai fait un propre qui utilise MySQL4 et les transactions, je peux
te le passer si tu veux tester, mais je n'ai pas fait de doc.
Moi, ça m'intéresse, merci
Bon, faut que fasse une petite doc.
Un autre problème avec Postfix, c'est que la liste grise se déclanche
avant la vérification de la destination dans les tables locales. Ça
rempli inutilement les bases.
Tu peux toujours le faire à la main dans le corps de ton filtre, et de
là renvoyer un EX_TEMPFAIL, non ? En fait, on pouvait l'implémenter
soi-même depuis longtemps, fallait juste y penser....
C'est pas comme ça que ça marche, mais effectivement on peut faire la
vérification dans la liste grise et rejeter le courrier. Mais comme
Postfix va la refaire derrière, c'est du gaspillage.
Si tu es sur Postfix, le script d'example ne marche pas à grosse échelle (les vérous n'ont pas vraiment d'effet avec Berkeley DB 1.x, "perldoc DB_File" l'explique).
Est-il vraiment nécessaire d'utiliser DB. Un simple fichier hashé (accés par postmap encadré par un lockfile ) ne serait-il pas suffisant, pour un petit site ?
Postmap utilise DB :)
Une liste grise utilised des clefs composées de trois éléments. C'est trop compliqué pour les dictionnaires et les règles de Postfix.
Pour un petit site, les problèmes de vérous de DB1 sont moins visibles. On peut aussi fermer et ouvrir sa DB à chaque usage sans que ça impacte les performances globales.
Sinon, il vaut mieux utiliser DB3 ou DB4 qui gèrent les vérous et les transactions.
J'en ai fait un propre qui utilise MySQL4 et les transactions, je peux te le passer si tu veux tester, mais je n'ai pas fait de doc.
Moi, ça m'intéresse, merci
Bon, faut que fasse une petite doc.
Un autre problème avec Postfix, c'est que la liste grise se déclanche avant la vérification de la destination dans les tables locales. Ça rempli inutilement les bases.
Tu peux toujours le faire à la main dans le corps de ton filtre, et de là renvoyer un EX_TEMPFAIL, non ? En fait, on pouvait l'implémenter soi-même depuis longtemps, fallait juste y penser....
C'est pas comme ça que ça marche, mais effectivement on peut faire la vérification dans la liste grise et rejeter le courrier. Mais comme Postfix va la refaire derrière, c'est du gaspillage.
Stephane Locatelli
Le Fri, 30 Jan 2004 17:50:12 +0100, Xavier tapotait:
Tu peux toujours le faire à la main dans le corps de ton filtre, et de là renvoyer un EX_TEMPFAIL, non ? En fait, on pouvait l'implémenter soi-même depuis longtemps, fallait juste y penser....
Il n'y a pas si longtemps que l'on peut intervenir dans le process smtpd
pour exécuter son code. check_policy_service est apparu en juillet 2003.
-- Stephane Locatelli
Le Fri, 30 Jan 2004 17:50:12 +0100, Xavier tapotait:
Tu peux toujours le faire à la main dans le corps de ton filtre, et de
là renvoyer un EX_TEMPFAIL, non ? En fait, on pouvait l'implémenter
soi-même depuis longtemps, fallait juste y penser....
Il n'y a pas si longtemps que l'on peut intervenir dans le process smtpd
pour exécuter son code. check_policy_service est apparu en juillet
2003.
Le Fri, 30 Jan 2004 17:50:12 +0100, Xavier tapotait:
Tu peux toujours le faire à la main dans le corps de ton filtre, et de là renvoyer un EX_TEMPFAIL, non ? En fait, on pouvait l'implémenter soi-même depuis longtemps, fallait juste y penser....
Il n'y a pas si longtemps que l'on peut intervenir dans le process smtpd
pour exécuter son code. check_policy_service est apparu en juillet 2003.
-- Stephane Locatelli
Erwan David
Thierry Schollier écrivait :
Michel Guillou nous disait ici-même:
Je vais finir par filtrer sur le corps aussi...
Ça fonctionne toujours. Attention quand même : mes échantillons de fichiers zip légitimes sont tous générés sous Windows, dont probablement 90 % avec Winzip connaissant mes correspondants. C'est un peu court pour être affirmatif quant à l'universalité de la chaîne donnée.
Oui mais là ça fait des en-têtes contenant des 0 dans des champs pas prévus pour a priori...
Faudrait que je reprenne le format zip et base64 pour décoder tout ça.
Ça fonctionne toujours. Attention quand même : mes échantillons de fichiers
zip légitimes sont tous générés sous Windows, dont probablement 90 % avec
Winzip connaissant mes correspondants.
C'est un peu court pour être affirmatif quant à l'universalité de la chaîne
donnée.
Oui mais là ça fait des en-têtes contenant des 0 dans des champs pas
prévus pour a priori...
Faudrait que je reprenne le format zip et base64 pour décoder tout ça.
Ça fonctionne toujours. Attention quand même : mes échantillons de fichiers zip légitimes sont tous générés sous Windows, dont probablement 90 % avec Winzip connaissant mes correspondants. C'est un peu court pour être affirmatif quant à l'universalité de la chaîne donnée.
Oui mais là ça fait des en-têtes contenant des 0 dans des champs pas prévus pour a priori...
Faudrait que je reprenne le format zip et base64 pour décoder tout ça.
-- Erwan
Laurent Wacrenier
Erwan David écrit:
Faudrait que je reprenne le format zip et base64 pour décoder tout ça.
N'oublie pas le uuencode avec des entités HTML (déjà vu)
Erwan David <erwan@rail.eu.org> écrit:
Faudrait que je reprenne le format zip et base64 pour décoder tout ça.
N'oublie pas le uuencode avec des entités HTML (déjà vu)
