[Fermé] Problème avec Facteur et log phpstack PHPMailer

Dev
#1

Hello,
sur un site SPIP 4.1 fonctionnel depuis de nombreuses années et qui utilise Facteur 5.0.5 , les formulaires de contact se sont mis à présenter une erreur depuis environ un mois (plutôt moins je crois).

Les symptômes sont :

  • Une fois posté, un simple mot « erreur » s’affiche, sans message explicatif
  • Le mail est quand même expédié et arrive bien
  • L’internaute ne sachant pas que son mail est bien parti demande à le réenvoyer, etc

J’ai exploré et j’ai vu une cause possible : le reply-to est désormais censuré par PHPMailer::validateAddress car il est de la forme "prénom nom via nomdusite.ext" <dkdkdkdkd@nomdusite.ext>, alors que validateAddress n’accepte que les purs mails genre dkdkdkdk@nomdusite.ext.

Est-ce quelque chose a changé dans le plugin facteur qui expliquerait ça ?

J’ai voulu voir d’où venait ce format "nom" <email> inadapté ici et demandé à loger la phpstack (obtenue par ob_start (); debug_print_backtrace (); $stack = ob_get_contents (); ob_end_clean ();).
Mais si je loge la stack en cet endroit (ça marche très bien ailleurs), le fichier de log est systématiquement illisible, avec un contenu de la forme 〲㌲ㄭⴲ㈰ㄠ㨲㠵㐺′愲㄰挺ㅢ㩣愴㩦攳〰㜺㘹㨸搷ㅥ㠺㑣㨸戲摤⠠楰⁤㤴㈰⤳㨠.... Quelle serait une explication possible pour cette corruption ?

Par ailleurs, le site utilise le SMTP de mailjet

J’ai encore pas mal de choses à explorer car c’est au coeur d’une convergence d’outils et de paramétrages variés, mais vos avis sur les points évoqués ci dessus sont bienvenus.

#2

J’ai trouvé l’endroit d’où était issu ce format "nom" <email> (un code perso) et corrigé en ne laissant que email. J’ai aussi ajusté des réglages facteur… et peut être que ça va mieux.

#3

Si c’est bien le cas, je te laisse indiquer que le sujet est résolu :wink:

#4

Le 03/12/2023 à 20:14, b_b via Discuter de SPIP a écrit :

Si c’est bien le cas, je te laisse indiquer que le sujet est résolu

Malheureusement il y a toujours des problèmes d’envois de mail via le site
que j’ai toujours du mal à cerner.

Et pourquoi pas pouvoir utiliser "jolinom " ici ?
Il me semble que c’est possible ailleurs. Que ça l’était « avant » en tout cas.

Et les spip_logs d’une phpstack dans PHPMaileur sont encore illisibles.

Pour l’instant j’aimerais laisser ouvert, dans l’espoir d’un éclairage si jamais.

JL

#5

C’est intermittent alors difficile à reproduire et tester.
En cas d’échec initial, facteur réessaie jusqu’à 5 fois, avec des délais croissants à chaque fois, et jusqu’à présent je crois que tous les mails ont fini par partir, généralement au 2eme essai mais parfois au 4eme. Mais pour des mails « en direct » comme les rappels de mot de passe, c’est pas pratique.

Par contre, j’ai l’impression que le formulaire d’envoi du mail affiche une erreur quand le mail est en échec au 1er envoi, si bien que les internautes ré-envoient. Comme tous les mails finissent par arriver, une destinatrice m’a dit avoir reçu 40 copies d’un même mail !

Explorant le code de facteur je vois qu’on peut définir une constante pour obtenir les logs de PHPMailer. Avec par exemple define ('_FACTEUR_DEBUG_SMTP', 2); dans le fichier d’options. Les valeurs sont celles des constantes SMTP::DEBUG_OFF à SMTP::DEBUG_LOWLEVEL présentées sur la page Troubleshooting · PHPMailer/PHPMailer Wiki · GitHub mais il faut leur valeur numérique car elles sont pas encore définies à ce moment dans le fichiers d’options. Et il faut aussi define ('_LOG_FILTRE_GRAVITE', _LOG_DEBUG); car c’est un log de niveau _LOG_DEBUG.

Avec une valeur 2, le diagnostic a été que c’était un problème de connexion SMTP. Alors je suis passé à 3 pour avoir plus de précisions. À suivre.

#6

Pas besoin d’explorer le code pour ça :wink: => Facteur - SPIP-Contrib

#7

Alors je vais faire simple en mode bullet-point :

  1. avoir un formulaire qui déclenche immédiatement un envoi de mail c’est déjà une mauvaise pratique car sujet à SPAM (manuel ou par robot)
  2. la stack technique d’envoi d’emails est par nature non predictible : rien ne garantit que le serveur SMTP sur lequel on essaye d’envoyer va prendre le message immédiatement. Il est tout à fait normal et légitime que le serveur réponde « revient plus tard » par exemple, parce qu’il est occupé, ou à titre d’antispam etc.
  3. c’est pas parce qu’il y a eu une erreur à la première tentative d’envoi que le mail sera perdu
  4. si tu utilises la fonction mail() de PHP, tout ça est masqué, car la fonction mail() prends juste le mail pour le mettre dans une liste d’attente et côté PHP tu sais pas si/quand il est envoyé
  5. en conséquence de quoi ça n’a pas beaucoup de sens de signaler une erreur à l’utilisateur parce que le mail n’a pas été envoyé tout de suite
  6. du coup la bonne pratique c’est de toujours répondre « merci, votre mail a été envoyé » à l’utilisateur, et de laisser l’envoi se faire en asynchrone, soit en utilisant une job queue, ou mieux encore, une fonction nospam_confirm_action_html comme ici mailsubscribers/newsletter_subscribe.php at 86d2aa58d05dcaba5a27fbe73ea0cf799b0b1e2b - mailsubscribers - SPIP on GIT

Enfin, pour conclure, si tu as des soucis de mails qui partent pas tout de suite et des erreurs d’envoi intermittentes, ce n’est pas du côté du plugin Facteur qu’il faut chercher, mais du côté du serveur smtp sur lequel il essaye de délivrer, et de ton serveur/fournisseur d’envoi de mail ou de toute la chaine d’envoi, mais bon bonne chance.

Car encore une fois, même si « en général » les mails partent tout de suite et arrivent rapidement, ce n’est absolument pas garanti par toute l’archi smtp d’envoi et de routage des emails, qui est surtout faite pour faire de son mieux et être résiliente.

1 « J'aime »
#8

@cerdic merci pour ton regard et ces pistes.

Ayant « outillé » facteur en mode « logs pour debug », j’ai pu en effet préciser mon diagnostic à savoir que c’est un problème de connexion avec mailjet, que ce soit via SMTP ou via l’API V3. Incidemment, j’ai l’impression que ça coïncide plus ou moins, temporellement, avec le passage de GANDI « mail inclu » en mails « très chers » (je n’ai pas encore migré vers une autre solution). Ça pourrait il y avoir un rapport ?
À part ça mes diagnostics zones DNS, DKIM, SPF etc sont corrects.

Et puis j’ai pas eu le culot de mettre un message d’erreur « tout va bien » quand il y a une erreur d’envoi, mais je l’ai changé en (genre) « Oulala quel succès ! Ya de la queue au guichet mails alors votre message peut mettre du temps à arriver ».