[Résolu] Message en provenance d'Orange

[jibe]

Salut Titofe,

Il serait intéressant que tu regardes dans le source du message généré par le webmail Orange si tu as ou non la date de création dans l'entête. Et aussi de voir dans les logs de qpsmtpd si tu as des erreurs 552 liées à des mails en provenance du webmail pro d'Orange.

Je pense que tu as la date et pas d'erreur 552, puisque le mail est finalement arrivé. Mais ça confirmerait si tu pouvais regarder...

[Titofe]

Re,

Voici les sources du mail reçu par ClearOS:

Code: Tout sélectionner

Return-Path: <Mon_Adresse_Test@wanadoo.fr>
Received: from localhost (localhost.localdomain [127.0.0.1]) by
email.Non_Domaine.fr (Cyrus v2.3.11) with LMTPA; Thu, 16 Dec 2010 19:50:11
+0100
X-Sieve: CMU Sieve 2.3
Received: from localhost (localhost.localdomain [127.0.0.1]) by
email.Non_Domaine.fr (Postfix) with ESMTP id A2953AFE9F8 for
<Moi@localhost.Non_Domaine.fr>; Thu, 16 Dec 2010 19:50:11 +0100 (CET)
X-Virus-Scanned: amavisd-new at Non_Domaine.fr
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-99 required=5
tests=[BAYES_00=-1.9, T_HK_NAME_MR_MRS=0.01] autolearn=ham
Received: from email.Non_Domaine.fr ([127.0.0.1]) by localhost
(email.Non_Domaine.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id
EH7omm8SWaNm for <Moi@localhost.Non_Domaine.fr>; Thu, 16 Dec 2010 19:50:05
+0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1]) by
email.Non_Domaine.fr (Postfix) with ESMTP id 4AED2AFEED7 for
<Moi@localhost.Non_Domaine.fr>; Thu, 16 Dec 2010 19:50:05 +0100 (CET)
Received: from email.Non_Domaine.fr (localhost.localdomain [127.0.0.1]) by
email.Non_Domaine.fr (Postfix) with ESMTP id 25031AFE9F8 for
<Moi@localhost>; Thu, 16 Dec 2010 19:50:05 +0100 (CET)
Received: from pop3.Prestataire.com [193.xxx.yyy.197] by email.Non_Domaine.fr
with POP3 (fetchmail-6.3.6) for <Moi@localhost> (single-drop); Thu, 16 Dec
2010 19:50:05 +0100 (CET)
Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr
[80.xxx.yyy.132]) by mail1.Prestataire.com (Postfix) with ESMTP id 7266A1EC1F6
for <Mon_Adresse@Non_Domaine.fr>; Thu, 16 Dec 2010 19:45:12 +0100 (CET)
Received: from wwinf1g30 ([10.232.37.104]) by mwinf5d20 with ME id
julC1f0022EpRBe03ulCPL; Thu, 16 Dec 2010 19:45:12 +0100
From: =?UTF-8?Q?Mr_zzz=C3=A9?= <Mon_Adresse_Test@wanadoo.fr>
Reply-To: =?UTF-8?Q?Mr_zzz=C3=A9?= <Mon_Adresse_Test@wanadoo.fr>
To: Mon_Adresse@Non_Domaine.fr
Message-ID: <7443405.20896.1292525112046.JavaMail.www@wwinf1g30>
Subject: Test
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [82.xxx.yyy.199]
X-Wum-Nature: EMAIL-NATURE
X-WUM-FROM: |~|
X-WUM-TO: |~|
X-WUM-REPLYTO: |~|
Date: Thu, 16 Dec 2010 19:45:12 +0100 (CET)
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Thu Dec 16 19:45:14 2010
X-DSPAM-Confidence: 0.9899
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: 4d0a5e3a309851624511763
X-Kolab-Scheduling-Message: FALSE
X-Evolution-Source: imap://Moi@192.168.23.101/

Test

Par contre pour celui reçu par SME il faudra attendre.

Cdt,

[Titofe]

Voila les sources du mail reçu par SME:

Code: Tout sélectionner

Return-Path: <Mon_Adresse_Test@wanadoo.fr>
Delivered-To: Moi@serveur.Domaine.ath.cx
Received: (qmail 3774 invoked by alias); 16 Dec 2010 19:30:11 -0000
Delivered-To: alias-localdelivery-Moi@Domaine.ath.cx
Received: (qmail 3771 invoked by uid 453); 16 Dec 2010 19:30:11 -0000
X-Virus-Checked: Checked by ClamAV on Domaine.ath.cx
X-Spam-Level: *
X-Spam-Status: No, hits=0.0 required=5.0
tests=RCVD_IN_DNSWL_NONE,T_HK_NAME_MR_MRS,UNPARSEABLE_RELAY
X-Spam-Check-By: Domaine.ath.cx
Received: from Unknown (HELO localhost) (127.0.0.200) by Domaine.ath.cx
(qpsmtpd/0.83) with ESMTP; Thu, 16 Dec 2010 20:30:05 +0100
Received: from pop.free.fr by localhost with POP3 (fetchmail-6.2.5) for
Moi@Domaine.ath.cx (single-drop); Thu, 16 Dec 2010 20:30:05 +0100 (CET)
Received: from zimbra10-e2.priv.proxad.net (LHLO
zimbra10-e2.priv.proxad.net) (172.20.243.160) by
zimbra10-e2.priv.proxad.net with LMTP; Thu, 16 Dec 2010 20:20:28 +0100 (CET)
Received: from smtp.smtpout.orange.fr (mx21-g26.priv.proxad.net
[172.20.243.91]) by zimbra10-e2.priv.proxad.net (Postfix) with ESMTP id
39609ACEB1 for <Moi@free.fr>; Thu, 16 Dec 2010 20:20:28 +0100 (CET)
Received: from smtp.smtpout.orange.fr ([80.xxx.yyy.127]) by mx1-g20.free.fr
(MXproxy) for Moi@free.fr ; Thu, 16 Dec 2010 20:20:28 +0100 (CET)
X-ProXaD-SC: state=HAM score=49
Received: from wwinf1j12 ([10.232.42.55]) by mwinf5d28 with ME id
jvLR1f0051BQzfu03vLRz9; Thu, 16 Dec 2010 20:20:25 +0100
From: =?UTF-8?Q?Mr_xxx=C3=A9?= <Mon_Adresse_Test@wanadoo.fr>
Reply-To: =?UTF-8?Q?Mr_xxx=C3=A9?= <Mon_Adresse_Test@wanadoo.fr>
To: Moi@free.fr
Message-ID: <25198217.13140.1292527225082.JavaMail.www@wwinf1j12>
Subject: Test
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [82.227.240.199]
X-Wum-Nature: EMAIL-NATURE
X-WUM-FROM: |~|
X-WUM-TO: |~|
X-WUM-REPLYTO: |~|
Date: Thu, 16 Dec 2010 20:20:28 +0100 (CET)
X-Evolution-Source: imap://Moi@192.168.11.100/

Test

Je confirme aussi deux chose:
- pas d'erreur dans les logs qpsmtpd le jour ou j'ai reçu le mail,
- par contre en cherchant sur d'autre jour, j'ai moi aussi des mail refusé venant du webmail d'orange.

Cdt,

[bethebeast]

Même si je connais tes qualités rédactionnelles jibé, je pencherai plus pour la deuxième option qui me plait bien

Je crains que mes soi-disant qualités rédactionnelles soient un peu trop virulentes (on m'a eu rassuré en me disant que je n'étais pas violent, mais virulent ). Je pense que, dans un premier temps tout au moins, des propos calmes mais très déterminés seraient préférables.

Il est vrai qu'à lire ton post sur le forum d'orange, la fin est vraiment virulente

Je vous invite tous à faire en sorte que le post sur Orange soit bien pris en considération (up, vote, commentaires supplémentaires etc.)

C'est fait !

En tout cas, je te remercie jibe pour l'initiative, un post (forum orange) clair et précis comme d'hab

J'espère que cela aboutira à quelque chose (ça doit aboutir).

[jibe]

Salut,

Merci à Titofe. Je regarderai ça à tête reposée. J'ai fait de mon côté un essai avec le webmail pro, et j'ai bien le même problème, avec une notification de non-distribution pour erreur 552. Il faut juste que je recommence pour la bonne règle : on m'a envoyé deux fois le même mail, une fois sur SME et une autre fois sur une BAL externe au lieu de m'envoyer une seule fois, avec les deux adresses. Le problème est que j'ai une date dans le mail. Il s'agit probablement d'une date ajoutée lors de la réception, mais je voudrais m'en assurer en comparant avec l'heure de refus par SME, et donc il faut bien que ce soit le même mail.

Il est vrai qu'à lire ton post sur le forum d'orange, la fin est vraiment virulente

C'est bien là mon problème : j'ai toujours peur de ne pas en dire assez, et du coup j'en dis trop ! Raison pour laquelle je voudrais bien que, si une lettre est nécessaire pour appuyer mon post (je crains, vu le peu de réactions), quelqu'un d'autre la rédige...

J'espère que cela aboutira à quelque chose (ça doit aboutir).

Oui, ça doit absolument aboutir : c'est quand même grave que des mails puissent se perdre ainsi. Malheureusement, à part toi, il n'y a toujours aucune réaction en plus de 24h. Orange semble rester fidèle à sa politique habituelle : ignorance, puis probablement lorsque ça ne sera plus possible, négation de toute responsabilité de leur part.

Tu as bien fait de parler d'un niveau de sécurité inacceptable si le mail passe : c'est la réalité, et ça évitera peut-être qu'ils se rabattent sur le fait que "presque tous" les (ou "tous les autres") serveurs acceptent leurs mails et donc qu'il n'y a aucun problème...

Bon, je crois qu'il va falloir qu'on se bouge le c** si on veut obtenir une mise aux normes du webmail d'Orange ! Donc, j'insiste sur la nécessité pour tous ceux qui ont constaté au moins un mail orange refusé pour erreur 552 de réagir sur le forum Orange en insistant sur la nécessité pour le webmail de celui qui prétend être le plus grand des FAI de respecter les RFC !

[sibsib]

Hello,

Bien que fort peu concerné par ce problème (pas de relations "Orange") un colistier que je ne nommerais pas par discrétion (JiBé, le boulot que tu me donnes ) m'a demandé mon avis "d'expert"
Alors première précision : le fait que je joue avec Sendmail depuis plus de 15 ans et que je connecte des messageries au net depuis presque aussi longtemps ne fait pas de moi un expert, juste un vieux !!!
J'ai donc tenté de relire ce post que j'avais tout de même suivi, et je me permets ces deux ou trois remarques.
Certaines personnes se sont demandés si le problème pouvait être lié au serveur SMTP initial. Le champ Date: qui manque fait partie du corps du message, pas de l'enveloppe. En d'autres termes, j'espère que les serveurs SMTP d'Orange respectent suffisamment les RFC pour ne *jamais* modifier le corps du message. Sans pouvoir le prouver, je pense donc bien que le problème se situe dans le logiciel émetteur (le webmail d'Orange, semble-t-il)
Pour les logs : en effet, il faut bien lire les logs de qpsmtpd, puisque c'est ce process qui gère le port 25 (ou, en termes plus logiques, puisque c'est ce process qui 'reçoit' les mails, et les passe éventuellement à qmail s'il ne voit pas d'incohérence).
l'adresse IP 127.0.0.200 : Pour des raisons historiques, l'interface de loopback, qu'on associe classiquement à 127.0.0.1 accepte en fait n'importe quelle IP commençant par 127. Il y a quelques années, SME a ressenti le besoin d'avoir un filtrage QPSMTPD différents pour les mails 'fetchés' que pour les mails arrivant directement sur le port 25. QPSMTPD a donc été configuré avec deux séries de règles, une générale, et une un peu moins restrictive (je ne connais plus les détails, mais on en a parlé sur ce forum à l'époque. JE crois qu'il s'agissait de ne pas tester les IP sources : en effet, même si le message provient d'une source non autorisée, si c'est fetchmail qui l'envoie, c'est qu'il est déjà trop tard). Bref, fetchmail envoie les mails à l'adresse 127.0.0.200 pour passer par ces règles adaptées.

Pour "votre" problème avec Orange (je suis désolé de ne pas me sentir plus investi que çà), je pense qu'il y a trois actions dans le discours :
* Rappeler qu'en terme de communications (et pas seulement électronique !) il faut "être très strict avec ce qu'on émet et très tolérant avec ce qu'on reçoit"
Si vous donnez cet argument à Orange, ils vont vous demander d'être tolérant, bien sûr ! Mais comme (par définition) ils ne sont pas en mesure de connaitre tous les destinataires pour leur demander d'être tolérants, ils va bien falloir qu'ils acceptent d'être stricts à l'émission...
* Se peler tous les RFC 'SMTP', mais je suis quasi sûr de mémoire que l'obligation du champs Date était déjà dans la première version du RFC ! De toutes façons, si vous commencez à vous référer à des repères précis dans les RFC, j'ai tendance à penser qu'ils n'iront pas vérifier . En général, çà marche
* Vérifier que l'absence de ce champ "date : " ne bloque pas les serveurs de mail d'Orange ! Je m'explique : Il me parait fort peu vraisemblable que les serveurs SMTP d'usage interne de Orange ne soient pas équipés de plateformes anti spam/antivirus. Par contre, il est tout à fait possible que les règles pour les mails d'origine Orange soient assez laxistes.
Il serait intéressant d'envoyer des mails à l'intérieur d'Orange avec des champs date erronés ou inexistant pour voir ce qu'il leur arrive. Le problème, c'est que çà demande d'avoir une taupe sur place : même si le message est refusé, il n'y a peut-être pas de retour (le message peut être 'gommé' sans avertissement).

Quelqu'un a des relations chez Orange ?

Bon courage,

A plus,
Pascal

[jibe]

Salut,

JiBé, le boulot que tu me donnes

Sorry... J'espère n'avoir pas gâché ton week-end !
Mais bon, je ne t'ai pas mis le couteau sous la gorge, et je pense que si cela t'avait posé le moindre problème, tu te serais abstenu ou tu aurais été plus expéditif
Merci en tous cas pour ton intervention très intéressante

le fait que je joue avec Sendmail depuis plus de 15 ans et que je connecte des messageries au net depuis presque aussi longtemps ne fait pas de moi un expert, juste un vieux !!!

Je n'ai pas relu mon mail, mais de mémoire il me semble avoir parlé d'expérience, pas d'expert
quant à l'adjectif "vieux", il me semble inadapté : je ne crois pas qu'il soit synonyme d'expérimenté

Le champ Date: qui manque fait partie du corps du message, pas de l'enveloppe. En d'autres termes, j'espère que les serveurs SMTP d'Orange respectent suffisamment les RFC pour ne *jamais* modifier le corps du message.

Heu... Il va peut-être falloir que je (re)lise les RFC...
Je pensais qu'un mail avait trois parties : le corps, l'entête et l'enveloppe (je devrais peut-être dire "les enveloppes", mais après il devient difficile de compter les parties ). Et que l'entête pouvait être complétée, par exemple par les logiciels anti-spam qui peuvent y mettre leurs annotations ? Confonds-je avec l'enveloppe ?

Je me pose cette question à cause d'une date, présente dans un mail que j'ai reçu dans ma BAL Orange alors que le même mail a été refusé par SME pour date manquante, date qui est postérieure au refus par SME (mail unique envoyé à deux destinataires)... Je referai des essais plus précis, mais il me semble que j'ai cette date lorsque je récupère les mails dans ma BAL Orange avec thunderbird, et que je ne l'ai pas lorsque je consulte les mails par le webmail...

Sans pouvoir le prouver, je pense donc bien que le problème se situe dans le logiciel émetteur (le webmail d'Orange, semble-t-il)

Je ne sais pas si c'est une preuve suffisante, mais je n'ai jamais constaté de refus pour les mails envoyés par thunderbird via le SMTP d'Orange, et systématiquement pour les mails envoyés par leur webmail...

fetchmail envoie les mails à l'adresse 127.0.0.200 pour passer par ces règles adaptées.

Ok, je ne savais pas et n'ai pas dû y faire attention dans les logs

Donc, les tests de sweepy ont été faits sur des mails fetchés, cela expliquerait-il qu'ils passent ? Mais en ce qui me concerne, les mails fetchés en provenance d'Orange ne passent pas mieux que les directs... Bon, il va falloir que je regarde mieux les logs : c'est vrai que je ne les ai pas trop épluchés pour ce qui est des mails fetchés. Il faut que je regarde si la cause de non-distribution est différente.

En tous cas, les mails fetchés me posent un gros problème : ils arrivent bien dans la BAL externe, mais ne sont pas récupérés par SME et supprimés de la BAL externe. L'expéditeur n'a pas d'avis de non-distribution, et moi rien qui m'indique qu'un mail m'était adressé et a disparu...

très tolérant avec ce qu'on reçoit

Effectivement. Mais d'un autre côté, hormis ceux en provenance d'Orange, tous les mails non conformes (et en particulier sans date) sont du spam... Autant les éliminer le plus vite possible !

Vérifier que l'absence de ce champ "date : " ne bloque pas les serveurs de mail d'Orange ! Je m'explique : Il me parait fort peu vraisemblable que les serveurs SMTP d'usage interne de Orange ne soient pas équipés de plateformes anti spam/antivirus. Par contre, il est tout à fait possible que les règles pour les mails d'origine Orange soient assez laxistes.
Il serait intéressant d'envoyer des mails à l'intérieur d'Orange avec des champs date erronés ou inexistant pour voir ce qu'il leur arrive. Le problème, c'est que çà demande d'avoir une taupe sur place : même si le message est refusé, il n'y a peut-être pas de retour (le message peut être 'gommé' sans avertissement).

Heu... J'ai mis trop de vin dans les diots ? Pas bien compris quel test tu voudrais faire...
Il faudrait qu'un abonné Orange envoie un mail à un autre, et vérifier si le mail arrive et sinon s'il y a notification de non distribution ? Si c'est ça, je pense que :
- Ça passe entre Orange et Free (testé par mes soins) et avec d'autres FAI, alors, pourquoi pas entre Orange et Orange ?
- Si ça ne passait pas entre abonnés Orange (même si ça ne concerne que l'envoi par webmail), je pense que ça se saurait...
Mais bon, ai-je bien tout compris à propos de ce test ?

[cilor]

Bonjour,

Il serait intéressant d'envoyer des mails à l'intérieur d'Orange avec des champs date erronés ou inexistant pour voir ce qu'il leur arrive. Le problème, c'est que çà demande d'avoir une taupe sur place : même si le message est refusé, il n'y a peut-être pas de retour (le message peut être 'gommé' sans avertissement).

Si on considère qu'un message émis à partir d'un compte webmail Orange ( donc avec champ de date érroné ) vers un compte interne à la messagerie Orange arrive bien à destination, est-ce que le test est suffisant ?

Cordialement.

La taupe .

[jibe]

Salut,

Si j'ai pris la peine d'exposer le problème sur le forum Orange, après avoir pris le temps de faire des tests complets, c'est pour essayer de faire bouger les choses. J'aimerais donc bien que ceux qui ont constaté le problème le signalent et donnent du poids à mon post ! Pour l'instant, seuls bethebeast et Fraedhrim l'ont fait (merci à eux )... Il serait bien également de voter afin que ce fil soit jugé utile par un maximum

J'attends aussi au moins une ébauche de lettre à envoyer à la direction d'Orange... C'est un peu pénible d'avoir l'impression d'être presque le seul à se bouger le c** pour un problème qui nous concerne tous

En fouinant, j'ai trouvé quelques infos intéressantes que j'ai rassemblées dans ce post.

[sibsib]

Hello,

Je réponds ici pour cette partie, mais JiBé à posé environ la même question :

Bonjour,

Il serait intéressant d'envoyer des mails à l'intérieur d'Orange avec des champs date erronés ou inexistant pour voir ce qu'il leur arrive. Le problème, c'est que çà demande d'avoir une taupe sur place : même si le message est refusé, il n'y a peut-être pas de retour (le message peut être 'gommé' sans avertissement).

Si on considère qu'un message émis à partir d'un compte webmail Orange ( donc avec champ de date érroné ) vers un compte interne à la messagerie Orange arrive bien à destination, est-ce que le test est suffisant ?

En fait, comme taupe, je cherche un employé Orange. J'imagine que les serveurs Mails des employés d'Orange ne sont pas les mêmes que ceux des clients, et que les employés Orange sont protégés par un anti spam. Il serait donc intéressant de connaitre un employé Orange (appelons le 'la taupe')
1) envoyer à cet employé un mail complètement conforme depuis une machine hors réseau Orange.
2) Envoyer à ce même employé un message avec le champ date manquant.
Et voir le résultat.

Remarque : Un simple telnet client permet de générer le mail 'témoin', il doit y avoir un bout d'explication chez moi pour faire çà (dans la section MX-Backup)

A+,
Pascal

[sibsib]

HEllo,

Le champ Date: qui manque fait partie du corps du message, pas de l'enveloppe. En d'autres termes, j'espère que les serveurs SMTP d'Orange respectent suffisamment les RFC pour ne *jamais* modifier le corps du message.

Heu... Il va peut-être falloir que je (re)lise les RFC...
Je pensais qu'un mail avait trois parties : le corps, l'entête et l'enveloppe (je devrais peut-être dire "les enveloppes", mais après il devient difficile de compter les parties ). Et que l'entête pouvait être complétée, par exemple par les logiciels anti-spam qui peuvent y mettre leurs annotations ? Confonds-je avec l'enveloppe ?

Bon, là, c'est peut-être moi qui n'utilise pas les bons termes. L'analogie avec la lettre et l'enveloppe est la suivante :
Quand tu rédiges un message, il y a dans le message un certain nombre de champs qui sont renseignés par le client de messagerie. Tous ne sont pas obligatoires, je dirais de mémoire que le champ Date et un autre (trou de mémoire : émetteur ? Destinataire sans doute pas, puisqu'on peut écrire uniquement a des bCC) sont les seuls obligatoires. Ces champs, bien que non directement dans le corps du message, sont liés au corps du message, et sont en quelque sorte mis "dans l'enveloppe".
De plus, le client de messagerie reproduit un certain nombre d'informations sur l'enveloppe, afin que le facteur puisse acheminer la lettre (sans regarder dedans, évidemment). Il est intéressant de noter que la lettre arrivera bien au destinataire mentionné sur l'enveloppe, même si le destinataire dans l'enveloppe est différent (testé et "approuvé"). Il est important de noter qu'a chaque fois que la lettre change de facteur (de serveur SMTP, en fait), celui ci ajoute des coups de tampons dessus, notamment la date et l'heure du traitement chez lui. Donc oui, un message arrivé comprend toujours au moins une date et heure, puisqu'il est passé en principe par au moins un serveur SMTP !
Mais le champ Date: recherché par qpsmtpd est bien celui qui se trouve dans l'enveloppe, celui fourni par le client de messagerie initial.

Ouf ! Pas très doué pour la synthèse
A+,
Pascal

[cilor]

Bonjour,

sibsib

Je travaille pour Orange et je peux dire que les sysadmin ne sont pas tès accessibles. Il faut déjà savoir où les trouver (pas évident dans une grande entreprise comme celle-la). Mais je ne désespère pas. Si j'ai du neuf, je ne manquerais pas de vous en faire part.


Cordialement.

Cilor

En gros, c'est mon adresse pro que tu veux ?

[jibe]

Salut,

@cilor : Si tu veux bien, oui, il faudrait que quelqu'un (éventuellement toi si tu as une autre BAL non Orange) puisse t'envoyer les mails-test comme décrits par sibsib, et nous faire part de ce que tu reçois.

Par contre, je ne sais pas comment sibsib pensait s'y prendre pour faire le test avec date manquante ? Par le webmail Orange ?

Un simple telnet client permet de générer le mail 'témoin', il doit y avoir un bout d'explication chez moi pour faire çà (dans la section MX-Backup)

Le fait de générer le mail par telnet est une bonne idée, puisqu'on est vraiment certain de la manière dont il a été composé.
Il y a bien un bout d'explication sur le site de sibsib, on peut aussi s'inspirer de celle-la ou encore des exemples donnés en annexe F de la RFC 821.

Seul petit problème, on ne maitrise pas le champ "date :" même par telnet...

Ces champs, bien que non directement dans le corps du message, sont liés au corps du message, et sont en quelque sorte mis "dans l'enveloppe".

toutafé, comme dirait quelqu'un que tu connais bien
Ce sont ces champs qui forment ce que j'appelle l'entête du message, comme la lettre qui est rédigée sur du papier à entête donnant un certain nombre de renseignements sur l'expéditeur, et qui comporte aussi la date, le nom et l'adresse du destinataire... D'ailleurs, la notification de non-distribution parle bien de "date header", de même que la RFC 821 :

Please note that the mail data includes the memo header items such as Date, Subject, To, Cc, From [2].

(la note 2 renvoie à la RFC 822 qui définit le format des champs)

Si j'ai bien compris ce qu'en dit la RFC 821, un mail comprend obligatoirement une partie DATA (la lettre en elle-même), et un header formé lors de la connexion SMTP par les commandes MAIL (qui permet la mise en place du champ FROM) et RCPT qui permet de positionner les champs TO, CC et BCC dont au moins un est obligatoire.

Là où j'ai un peu plus de mal à faire la relation avec le webmail Orange, c'est que le champ DATE, toujours d'après ce que j'ai cru comprendre des RFC, est mis en place automatiquement par le serveur SMTP. Or, cette date est bien présente lors d'un envoi par un client mail (donc, le SMTP met bien la date), mais pas lors d'un envoi par le webmail... Mais bon, je ne sais pas du tout comment fonctionne le webmail, se pourrait-il qu'il comporte son propre SMTP intégré, ou qu'il utilise un SMTP différent de celui utilisé par les MUA ? Toujours est-il que les faits sont là : la date manque lors de l'emploi du webmail !

Mais le champ Date: recherché par qpsmtpd est bien celui qui se trouve dans l'enveloppe, celui fourni par le client de messagerie initial.

Oui. Mais là où j'ai du mal, si je n'ai pas à disposition les logs du SMTP "de départ" pour comparer la date et l'heure d'envoi avec celle du refus, c'est pour faire la distinction entre cette date "dans l'enveloppe" et la ou les dates situées sur l'enveloppe.

Prenons le cas de ce mail-test de Titofe. J'appellerai "enveloppe" les différents coups de tampon des facteurs successifs, "header" les renseignements figurant à l'intérieur de l'enveloppe, et "data" le texte de la lettre :

Code: Tout sélectionner

[color=#FF0000]Return-Path: <Mon_Adresse_Test@wanadoo.fr>[/color]
[color=#0000FF]    Received: from localhost (localhost.localdomain [127.0.0.1]) by
    email.Non_Domaine.fr (Cyrus v2.3.11) with LMTPA; Thu, 16 Dec 2010 19:50:11
    +0100
    X-Sieve: CMU Sieve 2.3
    Received: from localhost (localhost.localdomain [127.0.0.1]) by
    email.Non_Domaine.fr (Postfix) with ESMTP id A2953AFE9F8 for
    <Moi@localhost.Non_Domaine.fr>; Thu, 16 Dec 2010 19:50:11 +0100 (CET)
    X-Virus-Scanned: amavisd-new at Non_Domaine.fr
    X-Spam-Flag: NO
    X-Spam-Score: -1.89
    X-Spam-Level:
    X-Spam-Status: No, score=-1.89 tagged_above=-99 required=5
    tests=[BAYES_00=-1.9, T_HK_NAME_MR_MRS=0.01] autolearn=ham
    Received: from email.Non_Domaine.fr ([127.0.0.1]) by localhost
    (email.Non_Domaine.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id
    EH7omm8SWaNm for <Moi@localhost.Non_Domaine.fr>; Thu, 16 Dec 2010 19:50:05
    +0100 (CET)
    Received: from localhost (localhost.localdomain [127.0.0.1]) by
    email.Non_Domaine.fr (Postfix) with ESMTP id 4AED2AFEED7 for
    <Moi@localhost.Non_Domaine.fr>; Thu, 16 Dec 2010 19:50:05 +0100 (CET)
    Received: from email.Non_Domaine.fr (localhost.localdomain [127.0.0.1]) by
    email.Non_Domaine.fr (Postfix) with ESMTP id 25031AFE9F8 for
    <Moi@localhost>; Thu, 16 Dec 2010 19:50:05 +0100 (CET)
    Received: from pop3.Prestataire.com [193.xxx.yyy.197] by email.Non_Domaine.fr
    with POP3 (fetchmail-6.3.6) for <Moi@localhost> (single-drop); Thu, 16 Dec
    2010 19:50:05 +0100 (CET)
    Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr
    [80.xxx.yyy.132]) by mail1.Prestataire.com (Postfix) with ESMTP id 7266A1EC1F6
    for <Mon_Adresse@Non_Domaine.fr>; Thu, 16 Dec 2010 19:45:12 +0100 (CET)
    Received: from wwinf1g30 ([10.232.37.104]) by mwinf5d20 with ME id
    julC1f0022EpRBe03ulCPL; Thu, 16 Dec 2010 19:45:12 +0100[/color]
[color=#FF00BF]    From: =?UTF-8?Q?Mr_zzz=C3=A9?= <Mon_Adresse_Test@wanadoo.fr>
    Reply-To: =?UTF-8?Q?Mr_zzz=C3=A9?= <Mon_Adresse_Test@wanadoo.fr>
    To: Mon_Adresse@Non_Domaine.fr
    Message-ID: <7443405.20896.1292525112046.JavaMail.www@wwinf1g30>
    Subject: Test
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: 7bit
    X-Originating-IP: [82.xxx.yyy.199][/color]
[color=#804000]    X-Wum-Nature: EMAIL-NATURE
    X-WUM-FROM: |~|
    X-WUM-TO: |~|
    X-WUM-REPLYTO: |~|
    Date: Thu, 16 Dec 2010 19:45:12 +0100 (CET)
    X-DSPAM-Result: Innocent
    X-DSPAM-Processed: Thu Dec 16 19:45:14 2010
    X-DSPAM-Confidence: 0.9899
    X-DSPAM-Probability: 0.0000
    X-DSPAM-Signature: 4d0a5e3a309851624511763
    X-Kolab-Scheduling-Message: FALSE
    X-Evolution-Source: imap://Moi@192.168.23.101/
[/color]
[color=#408000]    Test[/color]

1° partie rouge : ne s'agit-il pas d'un champ facultatif du header ?
2° partie bleue : enveloppe
3° partie violette : header
4° partie marron : est-ce le header ou l'enveloppe ?
5° partie verte : data.

Mon découpage est-il bon ? Et surtout :
- Si la partie 4 (marron) est une partie de l'enveloppe, comment savoir exactement ce qui est header et ce qui est enveloppe ?
- Si la partie 4 (marron) est une partie du header, comment savoir quelle est la date de départ (s'il y en a plusieurs), que c'est bien la date de départ ou qu'elle manque (s'il n'y en a qu'une) ?

[cilor]

Hi,

J'ai testé depuis @orange.fr en webmail vers @orange-ftgroup.com et les messages passent sans problème. Je te transmets mon @ pro par MP si tu veux pousser plus loin car je n'ai pas d'autre BAL.

Cordialement.

Cilor.

[jibe]

Comme dit par mail, je ferai un test par telnet.

Peux-tu poster les sources des messages-test STP ? Le but est aussi de voir si le champ "date :" est positionné ou non