------------------------------
Solution trouvée en message réponse.
-----------------------
Bonjour, sans rentrer dans trop de détails inutiles:
- J'ai plusieurs site sur un hébergement mutualisé, un seul back end pour plusieurs frontend radicalement différents (contenu et template graphique)
- J'utilise des formulaires PHP, qui tournent sur l'un ou l'autre des deux options que j'ai intégrées: PHPMailer, ou un fichier php standalone en fail-over, fesant la croix sur les pieces jointes.
Ces formulaires utilisent comme email d'expéditeur, soit formulaire soit form, @monvrainomdedomaine.montld.
Ils envoient leur mails a une boite OVH, sous contact@monvrainomdedomaine.montld
Je n'ai pas touché à ces fichiers (ou quoi que ce soit qui pourrait influer dessus) depuis bien un an, ils ont fonctionné sans problème depuis bien un an et demi qu'ils sont en place.
J'avais pour habitude de recevoir, a défaut d'avoir un mail utile chaque jour, au moins 5 à 10 spams quotidiens.
Depuis le 21 octobre.... plus rien. Je ne m'en était pas rendu compte, mais silence complet sur la totalité des formulaires.
J'essaye d'utiliser les formulaires moi même? Ca ne retourne aucune erreur, rien dans les logs d'erreur de l'hebergement... et rien non plus dans la boite mail!
Je teste que la boite mail fonctione, manuellement. Elle envoit, elle reçoit, pas de soucis.
Je teste une boite mail externe comme destinataire du mail généré par les formulaires, rien.
Je teste un script complètement stand-alone, séparé de tout le reste de mon code:
$to = "n'importe_quel_email@adresse_que_j'ai_chez_OVH_ou_ailleur.tld";
$from = "formulaire@monvrainomdedomaine.montld";
ini_set("SMTP", "smtp.monvrainomdedomaine.montld");
$JOUR = date("Y-m-d");
$HEURE = date("H:i");
$Subject = "Test Mail - $JOUR $HEURE";
$mail_Data = "";
$mail_Data .= " \n";
$mail_Data .= " \n";
$mail_Data .= "
$mail_Data .= " \n";
$mail_Data .= " \n";
$mail_Data .= "Mail HTML simple : $Subject
\n";
$mail_Data .= "
\n";
$mail_Data .= "bla bla bla bla
\n";
$mail_Data .= "Etc.
\n";
$mail_Data .= " \n";
$mail_Data .= " \n";
$headers = "MIME-Version: 1.0 \n";
$headers .= "Content-type: text/html; charset=iso-8859-1 \n";
$headers .= "From: $from \n";
$headers .= "Disposition-Notification-To: $from \n";
$headers .= "X-Priority: 1 \n";
$headers .= "X-MSMail-Priority: High \n";
$CR_Mail = TRUE;
$CR_Mail = @mail ($to, $Subject, $mail_Data, $headers);
if ($CR_Mail === FALSE){
echo " ### CR_Mail=$CR_Mail - Erreur envoi mail
\n";
} else {
echo " *** CR_Mail=$CR_Mail - Mail envoyé
\n";
}
?>
Résultat?
Bah il me dit "Mail envoyé", mais jamais rien n'est reçu. Et du coup il semblerait que cela fait 2 semaine que tous les mails qui sont envoyés via les formulaires de mes sites partent silencieusement dans le néant sans le moindre message d'erreur.
J'ai testé sur php8.0 (le backend est sur 8.1 depuis décembre 2021), et exactement le même comportement.
Le fait que ça ai juste laché du jour au lendemain me fait penser que le problème serait peut être coté OVH eux même.
Possiblement un problème indépendant, mais j'ai eu aussi un problème avec un mail de la part de IONOS adressé directement à une de mes boites OVH pour lesquels j'ai appelé LEUR support technique qui me confirmait que le mail partait bien de leurs systèmes de leur coté, sans aucune erreur, même si je ne le recevais jamais. (on a essayé 5 fois sur 3 jours)
Même comportement, mais c'est peut être une coincidence.
Je suis sur à Graveline 1, sur le cluster 026, sur un plan perf2014x1.
145773 
13.02.2019 09:51
Bon, vu qu'il aura fallut 24heures entre le moment ou j'ai fais le post, et le moment ou il a été _autorisé_ a être affiché sur le forum, entre temps j'ai déjà réglé le problème.
Le problème avec IONOS semble avoir été une coincidence.
C'est ainsi que j'ai découvert une magnifique fonction de l'hébergement web d'OVH: Le filtre antispam pour les scripts à mails. (quand on voit la quantité de spam entrant, c'est comique.)
Si j'envoyaisdes mails automatisés vers l'exterieurs/d'autres personnes, ce serait effectivement une fonction interessante, au cas ou le site se ferait hijack par exemple.
Mais voila... mes sites envoient des mails automatisés uniquement VERS MOI.
AUCUN mail ne sort des noms de domaines de mes sites. JE suis le destinataire. Et je les veux TOUS, ces mails, ils sont filtrés à l'arrivée, mais je veux les recevoir TOUS, pas qu'ils partent dans le néant!
OVH a donc décidé de TUER le moyen de communication principal entre mes visiteurs et moi même via mes sites pour me protéger? Merci mais non merci.
J'ai donc purgé les mails pour débloquer un service qu'il n'y avait pas lieu de bloquer.
Je filtre mes mails entrants moi même.
Le jour ou je voudrais un filtre à spam en amont pour des mails entrants, JE le coderais dans mes pages/scripts.
SI j'envoyais des mails automatisés à d'autres personnes, avoir un filtre à spam serais ma première priorité, et surtout de pouvoir le CONTROLER.
Pas juste qu'il décide du jour au lendemain "ah, j'ai une super idée, je vais silencieusement stopper toute communication".
Quand on voit l'importance de la fonction php mail() dans le fonctionnement d'un site... je comprends pas qu'elle soit dans le creux d'un menu déroulant sous "More", n'ai pas comme valeur par défaut d'avoir l'email du compte comme adresse de destination d'un Error report, et ne déclenche pas une notification sur le tableau de bord OVH.
Salut,
Le mail de destination est chez OVH ? La protection anti-spam est elle réglé sur off ?
Moi aussi je préfère gérer mes spam tout seul et il me semble que je les reçois tous :)
Bonjour,
le mail va sortir de l'infra de OVH pour rentrer dans l'infra OVH (si mail destination chez OVH), perso je trouve ça normale que OVH est un minimum de protection car un site/mail qui envoie du spam ça fait partie des indices de compromission.
Les gros genre office365 font exactement pareil et ça permet de verrouiller un compte avant qu'il ne fasse "trop" de dégâts.
Et au passage OVH à prévenu :
[quote]
6. MESURES DE LUTTE CONTRE L’ENVOI DE SPAM DEPUIS LE RESEAU OVHCLOUD
6.1. OVHcloud se réserve le droit de mettre en place un système de mesures techniques destiné à lutter
contre les envois de courriels frauduleux ainsi que la pratique du SPAM émis depuis ses infrastructures.
6.2. OVHcloud se réserve le droit de suspendre sans préavis les services de messagerie du Client, lorsque des envois massifs de courriels depuis l'offre du Client portent atteinte à l'intégrité et/ou à la sécurité du réseau de OVHcloud.
6.3. OVHcloud se réserve également le droit de suspendre sans préavis les services de messagerie du Client en cas de plainte de quiconque (client ou non client) concernant un e-mail envoyé :
- à partir des installations chez OVHcloud, ou
- comportant les URL des sites hébergés chez OVHcloud.
6.4. En cas de non-respect de cet engagement, le Client reconnaît qu’OVHcloud est en droit de limiter, de restreindre, d’interrompre ou de suspendre définitivement tout ou partie du service mis en cause pendant une durée de cinq jours minimum sans préavis, voire rompre définitivement le présent contrat en cas de non-respect des avertissements pour spamming envoyés par e-mail au Client.
[/quote]
Cf : https://storage.gra.cloud.ovh.net/v1/AUTH_325716a587c64897acbef9a4a4726e38/contracts/9d38984-contrat_partWeb-FR-3.0.pdf
Cordialement, janus57
Le mail de destination est chez OVH... pire, sur le même nom de domaine et hébergement!
Et j'en suis le destinataire!
Et oui, les filtres à spam étaient désactivés. Mais comme expliqué dans mon auto-réponse, ça n'a pas empeché les scripts d'être bloqués silencieusement pour spam.
Bon, je tiens déjà a dire en premier lieu que mes scripts PHPmail ont en amont de l'envoi d'un quelconque des filtres MIME, histoire que les pieces éventuellement jointes soient pas complètement garbage, et des filtres de texte pour eviter d'envoyer du code executable dans le body des mails.
Même si je veux "tout" recevoir, je pose ma limite là.
Ensuite, concernant les conditions d'utilisation OVH:
* 6.2 Entre 10 et 100 mails par jour. Si les infra de OVH sont menacées par un tel traffic, je vais aller voir ailleur.
* 6.1&6.3 Certes, mais mes sites les envoient à moi même. Mon site est éméteur, et je suis le recepteur de 100% d'entre eux, sur le même nom de domaine. Il n'y a pas eu de plaintes de quiconque, et les mails générés sont tous plutot propres concernant les headers, l'identification de l'éméteur, etc.
* 6.4 "en cas de non-respect des avertissements pour spamming envoyés par e-mail au Client" Quels mails? J'ai fini par me rendre compte du problème quand j'ai percuté, après 2 malade au lit, que pendant toute la periode ou j'avais le cerveau cuit à la vapeur je n'avais reçu aucun mail de mes sites.
Il n'y a eu aucun avertissement, aucune alerte, aucun signalement.
Pire, le fait que pendant 1an et demi ces même scripts ai fait le même boulot quotidien sans problème, et que j'ai dû purger les mails pour rétablir le fonctionement de PHPmail fait qu'au final, je n'ai même aucun moyen de savoir POURQUOI.
Qu'est-ce qui au boud d'un an et demi a causé, un jour, random, que l'une des fonctionnalités critiques de mon hébergement se fasse tacler?
En bref, ils me motivent juste de plus en plus à envisager de bouger mes sites et boites mail vers le cluster kubernetes que j'ai dans le cloud. Je gardais l'hébergement web chez OVH pour l'aspect "set&forget" et ne pas avoir à le maintenir ou autre, mais ça commence a être cher payé, pas qu'en cout monétaire pour ce que c'est, mais aussi en temps... ce que je voulais éviter.
Merci néanmoins d'avoir pris le temps de faire une réponse construite et référencée.
Cordialement;
Bonjour,
Normalement c'est le mail présent dans le compte OVH qui est prévenu.
Mais que je recommande de garder en externe (avant pas hébergé chez OVH).
Cordialement, janus57
Quand je disais "Quels mails?", je disais juste que je n'avais reçu aucun email.
Et oui, je me serais attendu à ce que l'adresse email **par défaut** pour ce genre d'alerte soit l'email du compte OVH lui même (qui est externe à OVH, et la même depuis la création même du compte).
Eh oui... c'est aussi ce à quoi je me serais attendu.
Hors, dans cette catégorie "More"->"Emailscripts", le champ email pour Error report est, par défaut... **vide**.
Joie.
J'ai évidement rectifié ça quand je l'ai vu hier.