Message perdu par serveur SMTP

Comment je pourrais m'assurer que les messages soient transmis s'il vous plaît

Le mail internet ne donne jamais aucune garantie que le message sera transmis, réceptionné, lisible, et lu.
Tout au plus on fait des efforts pour que ça fonctionne au mieux, et dans un temps raisonnable.
Si OVH avait des techniciens qui ont du temps libre, les serveurs derrière l'adresse smtp.dsl.ovh.net contiennent certainement des logs qui pourraient établir
- si tu as bien envoyé ces mails, car parfois le client qui réclame est fautif
- si le serveur les a identifiés comme spam et les a éliminés (et même peut-être la cause)
- si le serveur les a correctement traités et retransmis au serveur du destinataire (et donc ce n'est plus son problème)

Mais voilà ça prend du temps, beaoucoup de temps, surtout avec des serveurs qui traitent des millions de mails, et je crois entendre qu'on manque de personnel pour répondre aux tickets.

- si le serveur les a identifiés comme spam et les a éliminés (et même peut-être la cause)

Bonsoir et merci pour ta réponse,

Oui, il les a éliminés. Mais je ne sais pas pourquoi. Et j'aimerais bien connaître la cause.

et je crois entendre qu'on manque de personnel pour répondre aux tickets.

Je reçois beaucoup de réponses du support technique, mais elles n'ont aucun rapport avec le problème. Je pense qu'il y a assez de personnel, mais sans compétences.

Le véritable problème : le serveur répond
"relay=smtp.dsl.ovh.net[178.32.228.17]:25 status=sent (250 2.0.0 Ok: queued as 3BB6F18C953)"
ce qui est faux, puisque le message n'est pas transmis.

Il est donc impossible, de savoir, si un message passe ou non...

Pour l'instant je ne vois que 2 options :
OVH corrige le problème, ou je dois installer un serveur SMTP moi même...

Bonne soirée, Peter

... 178.32.228.17]:25 status=sent (250 2.0.0 Ok: queued as 3BB6F18C953)

Avec ces infos et la date et l'heure, idéalement une adresse d'expéditeur et de destinataire, l'administrateur de ce serveur doit pouvoir retrouver le statut de ce mail. Le n° de transaction 3BB6F18C953 a été fourni par le serveur d'OVH.

Ce qui se passe derrière ? Je n'en sais rien. la "déontologie" veut que si un serveur accepte un mail, il DOIT le remettre à son destinataire ou générer un "non-delivery receipt" s'il ne peut le traiter.

Un possible problème est la gestion du spam injecté par des clients OVH (véreux ou victimes de hack). Si le serveur SMTP n'a pas la performance et la fonctionnalité de scanner le flux entrant en temps réel dès la soumission d'un mail, alors il accepte les mer*es dans un premier temps et donne un n° de transaction, puis détecte dans un deuxième temps que c'est du spam. Il fait quoi ? Renvoyer des messages d'erreur pour du spam serait une mauvaise idée. Renvoyer un rapport quotidien serait une bonne idée. Rejeter en temps réel durant la transaction SMTP est la meilleure solution mais il faut des machines costaudes car la détection de spam et virus est consommatrice en CPU et mémoire.
Je pense que OVH gomme purement et silencieusement le spam détacté à tort ou à raison, et ça c'est mal.

Question: tes mails "disparus" portent-ils une caractéristique commune, telle qu'un pied de page (footer/signature) contenant du code HTML, des liens qui pourraient causer un faux positif ?

Avec ces infos et la date et l'heure, idéalement une adresse d'expéditeur et de destinataire, l'administrateur de ce serveur doit pouvoir retrouver le statut de ce mail.

Oui, j'ai tout fourni à OVH. Mais ces clowns me demandent de redémarrer le routeur ADSL...

il DOIT le remettre à son destinataire ou générer un "non-delivery receipt" s'il ne peut le traiter.

Exact, je pense aussi.

Je pense que OVH gomme purement et silencieusement le spam détacté à tort ou à raison, et ça c'est mal.

Très mal. Normalement le serveur devrait seulement ajouter une entête de style "X-OVH-spam-detected: yes"
Après c'est au destinataire de filtrer ou non.

Question: tes mails "disparus" portent-ils une caractéristique commune, telle qu'un pied de page (footer/signature) contenant du code HTML, des liens qui pourraient causer un faux positif ?

Pas vraiment, mais je peux provoquer la disparation d'un message avec 2 caractéristiques :
- message crypté avec PGP
- entête "To:" sans nom, seulement l'adresse : "To: xxx@yyy.com"

MOI >> Je pense que OVH gomme purement et silencieusement le spam détacté à tort ou à raison, et ça c'est mal.

Peter>> Très mal. Normalement le serveur devrait seulement ajouter une entête de style "X-OVH-spam-detected: yes"
Après c'est au destinataire de filtrer ou non.

Là je ne suis pas du tout d'accord.
A aucun moment OVH ne peut laisser sortir du spam, même taggué visible ou "invisible pour les humains" dans les headers. Ca conduirait juste à un blacklistage de ses serveurs d'envoi, ce qui arrive déjà trop souvent.

message crypté avec PGP

(mode lol) alors si les grandes zoreilles peuvent pas le lire c'est *censuré* (/mode lol)
Par contre l'adresse e-mail sans display name, ce n'est assurément pas un indicateur de spam.

A aucun moment OVH ne peut laisser sortir du spam, même taggué visible ou "invisible pour les humains" dans les headers. Ca conduirait juste à un blacklistage de ses serveurs d'envoi, ce qui arrive déjà trop souvent.

Ok. Néanmoins, la classification pourrait être nettement plus intelligente : si le nombre de messages est faible (une douzaine par jour) et la source des messages est clairement identifiée (modem ADSL d'OVH), il n'y a aucune raison de les filtrer.

Par contre l'adresse e-mail sans display name, ce n'est assurément pas un indicateur de spam.

En effet, et quand on répond à un message de type "From: xxx@yyy.com", on obtient automatiquement un destinataire sans display name.

En principe, je n'ai vraiment pas envie d'installer mon propre serveur SMTP, mais je n'ai pas encore trouvé de serveur qui fonctionne correctement. Orange se comporte comme OVH.

Bonjour,

Je viens d'avoir un problème équivalent après avoir installé Thunderbird et mon compte OVH en IMAP : paramètres OVH bien configurés, SSL activé et connexion au serveur affichée, mais messages n'arrivent jamais.
De plus, le message est archivé dans le dossier Envoyé sur le PC... et aussi dans le dossier envoyé du serveur !!!! (Ce qui après réflexion est normal, car IMAP assure la synchronisation des dossiers sans intervenir sur le processus de distribution).

Après une forte prise de tête, quelques recherches sur Internet et de nombreux essais, j'ai enfin trouvé la solution : c'est l'analyse AVG (Version gratuite) des messages sortants qui est en cause et non apparemment OVH... ce qui exonérerait notre hébergeur préféré ;-).

En décochant dans les paramètres AVG l'analyse des messages sortant, tout est rentré dans l'ordre !

Par contre, si quelqu'un savait où trouver les messages bloqués par AVG, cela me serait utile, car je n'ai bien sûr aucun message d'avertissement et rien n'est stocké dans la quarantaine.