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
Reply to: