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
