Pb INVALID HEADER

Je reçois ça, en provenance d’un forum que je gère. Je capte pas tout, c’est technique :

The message WAS NOT relayed to:
admin@bouteillesalarue.ouvaton.org:
554 5.6.3 Reject, id=88833-04 - BAD_HEADER: Non-encoded 8-bit data (char E9 hex): Subject: Notification de r\351ponse au sujet …

This nondelivery report was generated by the program amavisd-new at host
node2-1.ouvaton.local. Our internal reference code for your message is
88833-04/WjD-b7DwH2NJ

INVALID HEADER: INVALID 8-BIT CHARACTERS IN HEADER

Non-encoded 8-bit data (char E9 hex): Subject: Notification de r\351ponse au
sujet …

Ca doit être lié à la migration, car avant je n’ai jamais reçu ce genre de message en provenance de mon forum

Bonjour,

[quote=drÖne]Je reçois ça, en provenance d’un forum que je gère. Je capte pas tout, c’est technique :

The message WAS NOT relayed to:
admin@bouteillesalarue.ouvaton.org:
554 5.6.3 Reject, id=88833-04 - BAD_HEADER: Non-encoded 8-bit data (char E9 hex): Subject: Notification de r\351ponse au sujet …

This nondelivery report was generated by the program amavisd-new at host
node2-1.ouvaton.local. Our internal reference code for your message is
88833-04/WjD-b7DwH2NJ

INVALID HEADER: INVALID 8-BIT CHARACTERS IN HEADER

Non-encoded 8-bit data (char E9 hex): Subject: Notification de r\351ponse au
sujet …

Ca doit être lié à la migration, car avant je n’ai jamais reçu ce genre de message en provenance de mon forum[/quote]

J’ai été confronté au même problème il y a quelques heures.
La raison est que le sujet d’un message ne doit pas comporter des caractères de plus de 7 bits (http://tools.ietf.org/html/rfc2047 ).
(grosso-modo les caractères non accentués)
Il existe cependant une fonction php qui permet de convertir les autres : mb_encode_mimeheader
(http://fr.php.net/mb_encode_mimeheader)

(informations obtenues par la liste test-ouv3)

Christian.

c’est bizarre parce que le titre du message était “test”.

Salut,

;-)) pas teïÏÏst ?

Je faisais référence à l’erreur que tu signalais ci-dessus :

Non-encoded 8-bit data (char E9 hex): Subject: Notification de r\351ponse au
sujet …

Le sujet commence bien par : “Notification de réponse au…”

Christian.

Nön, c’êtaït bien “test”, säns la möîndë fïorîtüre drönésienne !

C"zst le massage automatique d’orange qui me répondait ça.

Bon, en fait ça n’arrête pas depuis la migration :

[quote]The message WAS NOT relayed to:
<***@***.org>:
554 5.6.3 Reject, id=04688-04 - BAD_HEADER: Non-encoded 8-bit data (char E9 hex): Subject: Un nouveau message priv\351 vous a \351t…

This nondelivery report was generated by the program amavisd-new at host
node2-1.ouvaton.local. Our internal reference code for your message is
04688-04/8DSVzxw+UoVp

INVALID HEADER: INVALID 8-BIT CHARACTERS IN HEADER

Non-encoded 8-bit data (char E9 hex): Subject: Un nouveau message priv\351
vous a \351t\351 envoy\351.\n

Return-Path: <***@***.fr>
Message-ID: <1e2467a814f793c2b94f5c379e9c54b6@***.org>
X-Mailer: PHP
Subject: Un nouveau message privé vous a été envoyé.

WHAT IS AN INVALID CHARACTER IN MAIL HEADER?

The RFC 2822 standard specifies rules for forming internet messages.
It does not allow the use of characters with codes above 127 to be
used directly (non-encoded) in mail header.

If such characters (e.g. with diacritics) from ISO Latin or other
alphabets need to be included in a header, these characters need
to be properly encoded according to RFC 2047. Such encoding is often
done transparently by mail reader (MUA), but if automatic encoding is
not available (e.g. by some older MUA) it is a user’s responsibility
to avoid using such characters in mail header, or to encode them
manually. Typically the offending header fields in this category are
’Subject’, ‘Organization’, and comment fields in e-mail addresses
of ‘From’, ‘To’ or ‘Cc’ header fields.

Sometimes such invalid header fields are inserted automatically
by some MUA, MTA, content checker, or other mail handling service.
If this is the case, that service needs to be fixed or properly
configured. Typically the offending header fields in this category
are ‘Date’, ‘Received’, ‘X-Mailer’, ‘X-Priority’, ‘X-Scanned’, etc.

If you don’t know how to fix or avoid the problem, please report it
to your postmaster or system manager.[/quote]

Je n’avais jamais eu ces problèmes avant. Chaque fois qu’un de mes forums phpbb envoie un mail (par exemple pour l’annonce de l’arrivée de msg privés), j’ai cette erreur de header : avant les accents étaient acceptés, plus maintenant. Sur une des listes ouvaton, on m’a parle de cette fonction :

La fonction PHP mb_encode_mimeheader
(http://fr.php.net/mb_encode_mimeheader)

Mais je ne sais pas où la mettre pour régler le problème, si il peut être réglé avec cette fonction.

Des idées ?

Toujours le même problème : chaque fois que mon forum phpbb envoie un mail de notification de réponse ou de réception de PM à un utilisateur, je récupère un mail d’erreur dans ma boîte perso, ce qui commence à être vraiment agaçant. Visiblement, depuis la migration, il y a quelque chose qui a changé, mais côté usager, pour cet aspect précis, ce n’est pas en mieux.

+A+

Bon, c’est réglé à la main. Pour ceux que ça intéresse, il faut et il suffit de modifier le fichier /lang_french/email/privmsg_notify.tpl en changeant la première ligne ainsi :

Subject: Un nouveau message =?ISO-8859-1?Q?priv=E9_vient_d=27arriver?=

En encodant l’accent, on permet à phpbb de respecter strictement la RFC 2047. Il reste qu’avant Ouvaton 3, on n’avait pas besoin de faire cette manip.

+A+

En revanche, cette technique est franchement pénible car il faut coder à la main tous les fichiers .tpl de phpbb qui utilisent des accents dans le champ Subject. Comme y’en a un paquet et que je ne connais pas le code ascii et la RFC 2047 par coeur, c’est vraaiiiiiiment pénible.

Ceci dit, dans les fichiers .tpl en question, les deux premières lignes sont (par exemple) :

Subject: Votre demande pour rejoindre un groupe a été approuvée. Charset: iso-8859-1
Ce que je ne comprends pas, c’est pourquoi la nouvelle plate forme n’interprète plus correctement Charset: iso-8859-1 (je suppose que c’est ça qui force le codage des accents ? En tout cas, avant ça fonctionnait sansd avoir besoin de se frapper des lignes à n’en plus finir dans les .tpl : si y’avait moyen de retrouver la souplesse d’Ouvaton 2 pour cet aspect, ce serait bien pratique, car sinon tous les possesseurs d’un forum phpbb vont devoir modifier leurs .tpl)

+A+

Youhou ? Toujours pas la moindre info ? Suis-je le seul à avoir ce problème et à recevoir pour chaque forum que je gère des tas de notifications de headers incorrects à causes de bêtes problèmes d’accents comme si on en était revenus en 1995 et à Telnet ? Gni ? Je craque un peu là… D’autant que les rares réponses que j’ai eu sur la liste étaient du genre “si tu connais rien à php, t’as qu’à mettre tes phpbb à jour”, bon, faut quand même pas exagérer, je les mets à jour systématiquement et ce n’est pas une réponse très pertinente !

Bonjour,

Tu ne dois pas être le seul.
Il doit bien y avoir un moyen de paramétrer phpbb pour éviter cet écueil : du style dire que tous les sujets des messages seront encodés de la manière qui va bien avec cette restriction conforme aux normes.
Mais personnellement, je n’en sais rien. Du côté des forums de phpbb (l’application) il ne se dit rien à ce sujet ?

Christian.

[quote=Christian Domec]Tu ne dois pas être le seul.
Il doit bien y avoir un moyen de paramétrer phpbb pour éviter cet écueil : du style dire que tous les sujets des messages seront encodés de la manière qui va bien avec cette restriction conforme aux normes.
Mais personnellement, je n’en sais rien. Du côté des forums de phpbb (l’application) il ne se dit rien à ce sujet ?

Christian.[/quote]

Je n’ai rien trouvé pour le moment. Mais je trouve quand même étrange qu’un changement de plate forme impose de modifier un système assez standard (phpbb) qui tourne sur des milliers (millions ?) de sites web dans le monde. A mon avis, c’est une très mauvaise opération pourOuvaton si chaque usager de phpbb doit bidouiller ses fichiers, et c’est loin d’être un progrès. Je crois sincèrement que c’est à Ouvaton de se débrouiller pour que phpbb fonctionne correctement sur ses plate forme, comme c’était le cas avant, sinon c’est un peu le monde à l’envers. Et sinon, quand je regarde les .tpl de phpbb, ils proposent bien un encidage iso-8859-1, mais le probème c’est, si je comprends bien, que la plate forme ne le reconnaît pas. Encore une fois : ça marchait parfaitement avant.

+A+

Bonjour,

A priori, sauf meilleure compréhension du problème, je suis d’accord avec toi. Ce qui m’étonne, c’est qu’il doit bien y avoir d’autres utilisateurs de phpbb parmi les “émigrés/immigrés” et je n’entends pour l’instant pas beaucoup d’écho de ce problème.
Si quelqu’un l’a résolu de manière élégante il serait intéressant de le savoir !

Christian.

PS : de mon côté je n’ai été que très peu touché par ce nouveau comportement (j’ai juste modifié deux/trois formulaires qui sont très peu utilisés).

Salut,

J’ai d’ailleurs parlé un peu trop vite… Un de mes formulaire semble couiner… Je n’y avais pas fait attention à celui-là. Il faudra que je revoie un peu tout ça :wink:

Christian.

Pourtant il y en a des phpbb hébergés chez Ouvaton, j’ai vérifié, mais ils n’ont peut-être pas migré. Ou alors, le problème ne leur est pas apparu s’il s’agit de forum peu actifs ou utilisant peu l’info par mail ? Ou alors ils râlent seuls dans leurs coin, ne sachant pas que ce forum existe. En fait, il faudrait comprendre comment une plate forme gère ces fameux envois de mails via phpbb, et comment sont pris en compte les encodages iso-8859-1 des fichiers .tpl

Mais là, ça me dépasse…

Salut,

[quote=drÖne]Pourtant il y en a des phpbb hébergés chez Ouvaton, j’ai vérifié, mais ils n’ont peut-être pas migré. Ou alors, le problème ne leur est pas apparu s’il s’agit de forum peu actifs ou utilisant peu l’info par mail ? Ou alors ils râlent seuls dans leurs coin, ne sachant pas que ce forum existe. En fait, il faudrait comprendre comment une plate forme gère ces fameux envois de mails via phpbb, et comment sont pris en compte les encodages iso-8859-1 des fichiers .tpl
Mais là, ça me dépasse…[/quote]

Oui moi aussi …
Je n’ai jamais testé phpbb… Et j’attends aussi d’autres échos à ce sujet.

Christian.

je m’arrache toujours les cheveux sur cette affaire. Quand j’encode les titres des headers dans les fichiers .tpl, que je le fasse en utf-8 ou en iso-8859-1, et en utilisant le codage suivant : =?ISO-8859-1?Q?privE9?= (pour le mot “privé”), c’est à dire en suivant scrupuleusement les RFC correspondant aux questions d’encodage des caractères, le résultat est que le message qui apparaît dans la boîte à mails de l’usager est : “privE9”, ce qui est idiot. J’ai vu que MySql est défini par défaut en utf-8, mais comme je viens de le dire, le codage ne fonctionne pas non plus en utilisant l’utf.

Bref, résultat des courses, la seule solution est de supprimer tous les accents dans les fichiers .tpl

Bonjour le progrès…

Cordialement

Bonsoir,

[quote=drÖne]je m’arrache toujours les cheveux sur cette affaire. Quand j’encode les titres des headers dans les fichiers .tpl, que je le fasse en utf-8 ou en iso-8859-1, et en utilisant le codage suivant : =?ISO-8859-1?Q?privE9?= (pour le mot “privé”), c’est à dire en suivant scrupuleusement les RFC correspondant aux questions d’encodage des caractères, le résultat est que le message qui apparaît dans la boîte à mails de l’usager est : “privE9”, ce qui est idiot. J’ai vu que MySql est défini par défaut en utf-8, mais comme je viens de le dire, le codage ne fonctionne pas non plus en utilisant l’utf.
Bref, résultat des courses, la seule solution est de supprimer tous les accents dans les fichiers .tpl
Bonjour le progrès…
Cordialement[/quote]

J’avoue que cette histoire (l’encodage ascii des caractères du sujet du message sortant, sinon le message est rejeté)
me laisse assez perplexe. J’ai bien peur, en effet, que de nombreuses personnes dans les semaines qui viennent soient enquiquinées avec ça…
Personnellement, n’utilisant la fonction mail() uniquement dans des scripts que j’ai moi-même écrits, cela ne me gêne pas trop. Je viens de mettre des $sujet=mb_encode_mimeheader($sujet) et tout va bien. Mais bon…
Je n’ai pas non plus pris le temps de fouiller plus avant sur ces problèmes d’encodage (c’est une question que je trouve vraiment complexe même si je m’y suis déjà frotté de nombreuses fois).
Juste une chose (voir là par exemple : http://fr.wikipedia.org/wiki/MIME#Mots_encod.C3.A9s)) : l’encodage du sujet (ou plus généralement des en-têtes du mail) c’est dire le jeu de caractère + le système d’encodage + la chaîne de caractères :

l’exemple donné sur wikipedia est Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?= est interprété comme “Subject: ¡Hola, señor!”. Avec comme jeu de caractères utf-8 et comme encodage “Q” comme Q-encoding.

Adapter ça facilement à phpbb, je ne sais pas faire (j’ai jamais téléchargé ce truc :wink:

Bon maintenant je me dis quand même que ce système devait bien être fait d’office sur l’ancienne plate-forme, non ?*

A suivre…

Christian.

  • paradoxalement, le fait qu’il ne soit pas fait d’office sur ouvaton 3 offre certainement plus de souplesse (liberté du choix du charset et de l’encodage)…

Oui, j’ai bien respecté le principe d’encodage, ça fait des jours que je mouline les RFC, c’est une lecture assez… hum… distrayante… Qu’on soit plus libre de choisir son encodage, certes, mais encore faudrait-il que la plate forme tienne compte de ces choix, ce qui ne semble pas être le cas. Pour phpbb, ça existe depuis pas mal d’années quand même, c’est pas un système ésotérique ou complètement en dehors des clous : je pense que 80% des forums sur le web doivent être en phpbb. Et en effet, tout fonctionnait parfiatement sur l’ancienne plate forme, c’est bien ce qui est ennuyeux.

+A+

Bon, j’ai envoyé ceci sur la liste test-ouv3 :


Bonjour,

Je reviens quand même sur ce message envoyé le 6 mars dernier :

Christian Domec a écrit :

Bonjour,

Hier soir et ce matin, j’ai testé quelques formulaires :

Je viens de recevoir ce retour de l’espace xxxxxxxx.roseau.org (ouvaton 3) :


Reporting-MTA: dns; node2-1.ouvaton.local
Received-From-MTA: smtp; node2-1.ocsa-data.net ([127.0.0.1])
Arrival-Date: Tue, 6 Mar 2007 10:26:17 +0100 (CET)

Final-Recipient: rfc822;xxxxxxxx(à)roseau.org
Action: failed
Status: 5.6.3
Diagnostic-Code: smtp; 554-5.6.3 Reject, id=18425-09 - BAD_HEADER: Non-encoded
554-5.6.3 8-bit data (char E9 hex): Subject: formulaire envoy\351 par le
554 5.6.3 roseau …
Last-Attempt-Date: Tue, 6 Mar 2007 10:26:17 +0100 (CET)


Je comprends que le caractère accentué “é” dans le sujet ne lui plaît pas beaucoup. J’ai donc corrigé le script.

Cependant, j’ai testé un formulaire similaire (mêmes caractères accentués dans le sujet) ce matin sur l’espace mais.ouvaton.org (ouvaton 3 aussi) et j’ai bien reçu les mails générés.

Pour parer à tout rejet, j’ai enlevé les accents.

Mais, n’est-il pas curieux que cela passe parfois et pas d’autres fois (une piste serait la différence entre les espaces, un en nom de domaine propre, l’autre en sous-domaine ouvaton.org) ?

Christian.

PS : si ces rejets se confirment, il faut soit avertir les coopérateurs d’éviter d’utiliser des caractères autres que sur 7 bits dans les sujets, soit les encoder (euh, je ne sais pas trop quel type de codage là).

Il me fut répondu :

  • Jean-Marie : > Si tu envoies un mail a un correspondant de chez altern.org tu auras le meme echec de distribution.

  • Mathieu :

Ce n’est pas nouveau : c’est contre la RFC 2047
(http://tools.ietf.org/html/rfc2047) de mettre autre chose que du 7
bit dans les en-têtes d’un mail. Faire autrement vous assure d’avoir
des problèmes un jour ou l’autre. La fonction PHP mb_encode_mimeheader
(http://fr.php.net/mb_encode_mimeheader) est là pour ça…

Pourtant ces deux réponses n’expliquaient pas pourquoi il y eût rejet à partir d’un formulaire et pas d’un autre, alors que les deux étaient sur ouvaton 3 et les deux sujets contenaient des accents.

Plus généralement, suite à un échange sur le forum : > http://forums.ouvaton.org/viewtopic.php?pid=632#p632

Je me posais ce soir la question, tout haut, (concernant l’encodage des “sujets”) : > Bon maintenant je me dis quand même que ce système devait bien être fait d’office sur l’ancienne plate-forme, non ?

J’ai d’ailleurs été voir le formulaire proposé sur http://aide.ouvaton.org/IMG/txt/formulaire.txt (à l’époque d’ouvaton 2) et la fameuse variable $sujet est récupérée comme suit :

$sujet = $_POST"sujet"] ;

sur ouvaton 3 actuel il faudrait au minimum le récupérer comme ceci :
$sujet=mb_encode_mimeheader($_POST"sujet"]); sinon un petit “é” dans le sujet provoquera un rejet du serveur.

Bref, il y a quelque chose qui me tarabusque avec cette histoire… Parce que franchement j’ai l’impression de ne rien piger à ce truc.

Christian.

PS : vous voyez beaucoup de scripts qui prévoient qu’il faut encoder le champ “sujet” des mail ???

PPS : le fameux mail de migration : “Subject: [gloux] Etape 2 : Migration de vos ressources pour votre compte coop=?iso8859-1?Q?=C3=A9?=rateur ouvaton” n’a manifestement pas été encodé par un script avant son traitement sinon il fut écrit comme suit : "Subject: =?iso8859-1?Q?[gloux] Etape 2 : Migration de vos ressources pour votre compte coop=C3=A9?=rateur ouvaton?="
d’autant que son corps était en base 64 !!

PPPS : une recherche sur google avec “BAD_HEADER: non-encoded” retourne, à l’instant, 12 réponses !!! dont un tiers venant d’ouvaton.