Re: sven (pour changer)
le Fri, 10 Oct 2003 23:35:44 +0200, Jacques L'helgoualc'h
[EMAIL PROTECTED] s'exprima en ces termes:
Nicolas Rueff a écrit, vendredi 10 octobre 2003, à 22:27 :
Salut
bonsoir.
après analyse de quelques tirs de sven, j'ai vu le champs suivant
revenir souvent ces derniers temps:
Date-warning: Date header was inserted by {machin-truc.com}
J'ai greppé un peu dans mes archives (environ 26000 mails, je sais,
je devrais faire le ménage),
mais non, c'est pratique pour les statistiques et les tests (les
headers devraient suffire, mais bon).
et je n'ai vu ce header que 9 fois (donc
0.03%) sur la totalité de mon pool, et apparaissant toujours soit
dans des spams, soit dans des vrais mails publicitaires _presque_
spam(Borland par exemple, chez qui je suis inscrit).
J'en ai un comme ça :
,
| Received: from owekim ([207.144.223.112])
| by SMTP00.InfoAve.Net (PMDF V6.1-1IA5 #30771)
| with SMTP id [EMAIL PROTECTED]; Fri,
| 19 Sep 2003 04:55:57 -0400 (EDT)
| Date: Fri, 19 Sep 2003 04:55:54 -0400 (EDT)
| Date-warning: Date header was inserted by SMTP00.InfoAve.Net
`
et six iPlanet :
,
| Received: from liuol ([148.110.94.233])
| by mail.etat.lu (iPlanet Messaging Server 5.2 HotFix 1.14\
| (built Mar 18 2003))
| with SMTP id [EMAIL PROTECTED]; Thu,
| 18 Sep 2003 23:43:23 +0200 (MEST)
| Date: Thu, 18 Sep 2003 23:43:13 +0200 (MEST)
| Date-warning: Date header was inserted by mail.etat.lu
`
Tous des swens, ou son petit frère de 14K.
Après invocation de Google, pas moyen de savoir si cet entête est
farfelu ou non. Le champ Date: inséré semble lui parfaitement
valide.
Le champ Date: manque assez souvent dans les spams ... On trouve
aussi des « Message-ID: [EMAIL PROTECTED] added by », tous des spams,
sauf
exception. Dans ma boîte à spams, il y a 17% de message-id manquant.
Je me posais la question de la fiabilité de l'ajout d'un règle style
DENY=^Date-warning: Date header was inserted by au fichier de conf
de ce bon vieux mailfilter. Si quelqu'un pouvait me rassurer ...
9 exemplaires seulement, c'est encore faible ... et peu rentable.
Nan, je me suis mal exprimé: _hors sven_, je n'ai que 9 mails sur 26000
comportant ce champ. Par contre une bonne partie des sven que je n'ai
pu éliminer (i.e environ 10/jour encore) par
DENY_CASE=^(FROM|TO|SUBJECT): contenaient ce champ.
/N
__
Nicolas Rueff [EMAIL PROTECTED]
http://rueff.tuxfamily.org
+33 6 77 64 44 80
--
It would be illogical to assume that all conditions remain stable.
-- Spock, The Enterprise Incident, stardate 5027.3
__
pgp7vYBUF4Ns6.pgp
Description: PGP signature
sven (pour changer)
Salut
après analyse de quelques tirs de sven, j'ai vu le champs suivant
revenir souvent ces derniers temps:
Date-warning: Date header was inserted by {machin-truc.com}
J'ai greppé un peu dans mes archives (environ 26000 mails, je sais, je
devrais faire le ménage), et je n'ai vu ce header que 9 fois (donc
0.03%) sur la totalité de mon pool, et apparaissant toujours soit dans
des spams, soit dans des vrais mails publicitaires _presque_ spam
(Borland par exemple, chez qui je suis inscrit).
Après invocation de Google, pas moyen de savoir si cet entête est
farfelu ou non. Le champ Date: inséré semble lui parfaitement valide.
Je me posais la question de la fiabilité de l'ajout d'un règle style
DENY=^Date-warning: Date header was inserted by au fichier de conf de
ce bon vieux mailfilter. Si quelqu'un pouvait me rassurer ...
/N qui a peur du gros sven
__
Nicolas Rueff [EMAIL PROTECTED]
http://rueff.tuxfamily.org
+33 6 77 64 44 80
--
Over the shoulder supervision is more a need of the manager than the
programming task.
__
pgp2JOQ8K7R9R.pgp
Description: PGP signature
Re: sven (pour changer)
Nicolas Rueff a écrit, vendredi 10 octobre 2003, à 22:27 :
Salut
bonsoir.
après analyse de quelques tirs de sven, j'ai vu le champs suivant
revenir souvent ces derniers temps:
Date-warning: Date header was inserted by {machin-truc.com}
J'ai greppé un peu dans mes archives (environ 26000 mails, je sais, je
devrais faire le ménage),
mais non, c'est pratique pour les statistiques et les tests (les headers
devraient suffire, mais bon).
et je n'ai vu ce header que 9 fois (donc
0.03%) sur la totalité de mon pool, et apparaissant toujours soit dans
des spams, soit dans des vrais mails publicitaires _presque_ spam
(Borland par exemple, chez qui je suis inscrit).
J'en ai un comme ça :
,
| Received: from owekim ([207.144.223.112])
| by SMTP00.InfoAve.Net (PMDF V6.1-1IA5 #30771)
| with SMTP id [EMAIL PROTECTED]; Fri,
| 19 Sep 2003 04:55:57 -0400 (EDT)
| Date: Fri, 19 Sep 2003 04:55:54 -0400 (EDT)
| Date-warning: Date header was inserted by SMTP00.InfoAve.Net
`
et six iPlanet :
,
| Received: from liuol ([148.110.94.233])
| by mail.etat.lu (iPlanet Messaging Server 5.2 HotFix 1.14\
| (built Mar 18 2003))
| with SMTP id [EMAIL PROTECTED]; Thu,
| 18 Sep 2003 23:43:23 +0200 (MEST)
| Date: Thu, 18 Sep 2003 23:43:13 +0200 (MEST)
| Date-warning: Date header was inserted by mail.etat.lu
`
Tous des swens, ou son petit frère de 14K.
Après invocation de Google, pas moyen de savoir si cet entête est
farfelu ou non. Le champ Date: inséré semble lui parfaitement valide.
Le champ Date: manque assez souvent dans les spams ... On trouve aussi
des « Message-ID: [EMAIL PROTECTED] added by », tous des spams, sauf
exception.
Dans ma boîte à spams, il y a 17% de message-id manquant.
Je me posais la question de la fiabilité de l'ajout d'un règle style
DENY=^Date-warning: Date header was inserted by au fichier de conf de
ce bon vieux mailfilter. Si quelqu'un pouvait me rassurer ...
9 exemplaires seulement, c'est encore faible ... et peu rentable.
Mon swendeleter bricolé détecte tous les swens sur From:, To:, Subject:
et Content-Type:
/N qui a peur du gros sven
Ah, dans quelques années, on spammera avec des images iso de DVD :-/
--
Jacques L'helgoualc'h
Re: sven (pour changer)
Le Vendredi 10 Octobre 2003 22:27, Nicolas Rueff a écrit :
Salut
après analyse de quelques tirs de sven, j'ai vu le champs suivant
revenir souvent ces derniers temps:
Date-warning: Date header was inserted by {machin-truc.com}
J'ai greppé un peu dans mes archives (environ 26000 mails, je sais, je
devrais faire le ménage), et je n'ai vu ce header que 9 fois (donc
0.03%) sur la totalité de mon pool, et apparaissant toujours soit dans
des spams, soit dans des vrais mails publicitaires _presque_ spam
(Borland par exemple, chez qui je suis inscrit).
Après invocation de Google, pas moyen de savoir si cet entête est
farfelu ou non. Le champ Date: inséré semble lui parfaitement valide.
Je crois comprendre que c'est une indication ajoutée par le serveur smtp
suivant dans la chaine.
En fait, le protocol utilisé pour distribuer le courrier (smtp) est assez
restrictif et chaque serveur smtp est obligé d'indiqué de où vient le message
(adresse IP), qui l'a reçu (adresse IP du serveur) et à quelle heure.
C'est comme ça que les champs Received from... by... permettent de tracer
l'itinéraire du mail.
Sauf que certains serveurs smtp sont bidouillés à ce niveau là (fausses
adresse IP et/ou date erronée/manquante) pour brouiller les pistes lors de
l'envoi de courriers anormaux : spams, virus et pub. Mais en général, c'est
le premier serveur smtp, du coup, le second serveur de la chaine ajoute
l'heure et/ou les adresses.
Y a-t-il des spécialistes pour confirmer ou infirmer ce que je viens d'écrire
?
Je me posais la question de la fiabilité de l'ajout d'un règle style
DENY=^Date-warning: Date header was inserted by au fichier de conf de
ce bon vieux mailfilter. Si quelqu'un pouvait me rassurer ...
/N qui a peur du gros sven
__
Nicolas Rueff [EMAIL PROTECTED]
http://rueff.tuxfamily.org
+33 6 77 64 44 80
--
ultimateclem
Debian user
Re: sven (pour changer)
Bonsoir, On Sat, Oct 11, 2003 at 12:14:55AM +0200, Ultimateclem wrote: [ à propos du champ Date: ] Je crois comprendre que c'est une indication ajoutée par le serveur smtp suivant dans la chaine. En toute rigueur il doit être présent dès le départ. C'est l'un des 2 champs obligatoires d'après la RFC 822 (l'autre est le From:). C'est certainement la raison du warning de la part du serveur intermédiaire qui l'a rajouté. C'est, du coup, au moins une indication que le machin qui a composé ce message ne respecte pas les consignes. Ca doit être un bon indicateur de spamitude comme tu le dis plus bas... En fait, le protocol utilisé pour distribuer le courrier (smtp) est assez restrictif et chaque serveur smtp est obligé d'indiqué de où vient le message (adresse IP), qui l'a reçu (adresse IP du serveur) et à quelle heure. C'est comme ça que les champs Received from... by... permettent de tracer l'itinéraire du mail. C'est bien la première fois que je vois quelqu'un qualifier SMTP de restrictif ! :-)) En fait non, SMTP n'est absolument pas restrictif. Les champs Received: sont rajoutés par les MTAs qui font bien leur boulot, mais n'apportent aucune certitude quant au chemin pris par le courrier. Certains en-têtes sont même carrément fabriqués par certains outils de spam, pour faire croire que le courrier a transité par tel ou tel relais, alors que c'est totalement faux. Ca reste cependant souvent vrai, pour les courriers normaux, mais ce sont rarement ceux-là qu'on chercher à tracer (sauf pour déterminer l'origine d'un problème). :-) Sauf que certains serveurs smtp sont bidouillés à ce niveau là (fausses adresse IP et/ou date erronée/manquante) pour brouiller les pistes lors de l'envoi de courriers anormaux : spams, virus et pub. Mais en général, c'est le premier serveur smtp, du coup, le second serveur de la chaine ajoute l'heure et/ou les adresses. Vrai pour la date/heure, mais faux pour les adresses IP des serveurs traversés... Le seul champ Received: auquel on peut vraiment faire confiance est celui rajouté par votre propre relais (ou celui de votre FAI). Y a-t-il des spécialistes pour confirmer ou infirmer ce que je viens d'écrire ? Je ne me prétends pas spécialiste, mais j'espère avoir répondu à tes questions... Cordialement, Bruno -- -- Service Hydrographique et Oceanographique de la Marine --- EPSHOM/CIS/MIC -- 13, rue du Chatellier --- BP 30316 --- 29603 Brest Cedex, FRANCE --Phone: +33 2 98 22 17 49 --- Email: [EMAIL PROTECTED]
Re: sven (pour changer)
Le Samedi 11 Octobre 2003 00:36, Bruno Treguier a écrit : Bonsoir, On Sat, Oct 11, 2003 at 12:14:55AM +0200, Ultimateclem wrote: [ à propos du champ Date: ] Je crois comprendre que c'est une indication ajoutée par le serveur smtp suivant dans la chaine. En toute rigueur il doit être présent dès le départ. C'est l'un des 2 champs obligatoires d'après la RFC 822 (l'autre est le From:). C'est certainement la raison du warning de la part du serveur intermédiaire qui l'a rajouté. C'est, du coup, au moins une indication que le machin qui a composé ce message ne respecte pas les consignes. Ca doit être un bon indicateur de spamitude comme tu le dis plus bas... C'est ce qui est indiqué souvent sur les quelques mails swen que j'ai gardés : X-Comment: Sending client does not conform to RFC822 minimum requirements En fait, le protocol utilisé pour distribuer le courrier (smtp) est assez restrictif et chaque serveur smtp est obligé d'indiqué de où vient le message (adresse IP), qui l'a reçu (adresse IP du serveur) et à quelle heure. C'est comme ça que les champs Received from... by... permettent de tracer l'itinéraire du mail. C'est bien la première fois que je vois quelqu'un qualifier SMTP de restrictif ! :-)) En fait non, SMTP n'est absolument pas restrictif. Les champs Received: sont rajoutés par les MTAs qui font bien leur boulot, mais n'apportent aucune certitude quant au chemin pris par le courrier. Certains en-têtes sont même carrément fabriqués par certains outils de spam, pour faire croire que le courrier a transité par tel ou tel relais, alors que c'est totalement faux. Ca reste cependant souvent vrai, pour les courriers normaux, mais ce sont rarement ceux-là qu'on chercher à tracer (sauf pour déterminer l'origine d'un problème). :-) Euh, mouai... disons que le terme restrictif est (vachement) mal choisi. Merci de m'avoir corrigé. J'avais absolument pas pensé que des champs received pourraient être forgés avant l'envoi du courrier. Mais après réflexion, rien ne l'empêche... Sauf que certains serveurs smtp sont bidouillés à ce niveau là (fausses adresse IP et/ou date erronée/manquante) pour brouiller les pistes lors de l'envoi de courriers anormaux : spams, virus et pub. Mais en général, c'est le premier serveur smtp, du coup, le second serveur de la chaine ajoute l'heure et/ou les adresses. Vrai pour la date/heure, mais faux pour les adresses IP des serveurs traversés... Le seul champ Received: auquel on peut vraiment faire confiance est celui rajouté par votre propre relais (ou celui de votre FAI). Est-ce qu'on pourrait dire qu'on peut faire confiance aux indications des serveurs smtp à partir de celui qui a rajouté does not conform to RFC822 minimum requirements ? Je suppose que les serveurs smtp bidouillés ne sont pas public et que donc une fois que le message est tombé sur un serveur public, il ne passe plus par des serveurs bidouillés. Je ne me prétends pas spécialiste, mais j'espère avoir répondu à tes questions... Merci en tout cas pour les corrections. -- ultimateclem Debian user
