Discussion :

[Hermite]

Bonjour à tous.

Je sollicite votre aide sur un sujet un peu long à expliquer, et qui probablement ne concerne pas que Delphi.

J'ai choisi de créer ce message dans cette section parceque le problème que je vais exposer est rencontré à partir d'une application écrite en Delphi 2010 avec les composants Indy.
Si ce n'est pas la bonne question, n'hésitez pas à le déplacer.

Voici donc la situation :
- l'application en question est hébergée sur un serveur. Il s'agit d'une application VCL classique que l'on pourrait comparer à un client mail lourd (comme Outlook quoi)
- les utilisateurs se connectent de toute la France à ce serveur en RDP pour utiliser cette application
- l'application permet d'envoyer des mails en utilisant le paramétrage des boîtes mail des utilisateurs (adresse d'expéditeur / compte mail / serveur SMTP cohérents)
- la connexion internet du serveur est chez Orange Business, les boîtes mails des utilisateurs sont chez des fournisseur variés (hotmail, office365, sfr, orange...)
- les adresses mail utilisées ont des domaines personnalisés (mail envoyé avec un compte contact@domaine.fr par smtp.orange.fr par exemple)

Le problème rencontré est le suivant :
- les mails envoyés à partir de l'application hébergée, vers certains destinataires passent systématiquement en indésirable, alors que les mails envoyés à partir du client de messagerie de l'utilisateur ne le sont pas.
- les mails envoyés à partir de l'application hébergée, vers certains autres destinataires ne sont jamais réceptionnés, sans message d'erreur en retour, alors que les mails envoyés à partir du client de messagerie de l'utilisateur arrivent bien.

Pour être un peu plus clair, voici un exemple de situation :
- sur le PC de l'utilisateur, j'envoi un mail à partir d'Outlook, expéditeur @domaine.fr via smtp.office365.com, avec l'authentification qui va bien (compte de messagerie sur le même domaine) => le mail arrive sans problème au destinataire
- sur l'application hébergée sur notre serveur, j'envoi ce même mail, avec les mêmes paramètres => le mail peut arriver aussi sans problème... mais régulièrement il arrive en indésirable, voire il n'arrive pas du tout.

Ce n'est pas vraiment aléatoire, a priori cela dépend essentiellement du destinataire. Tous les mails envoyés à un destinataire donné vont passer en indésirable par exemple.

Il n'est pas envisageable de dire au destinataire que le soucis vient de chez lui et qu'il doit vérifier son anti-spam par exemple.
D'autant que de leur point de vue, il reçoivent correctement une partie des mails envoyés.

Le fait est que je ne sais plus où chercher. J'ai donc besoin d'aide pour m'orienter vers certaines vérifications, que ce soit de paramétrage niveau réseau (enregistrement MX, configuration compte de messagerie), mais aussi au niveau du code de l'application et de l'utilisation des composants INDY.

Donc voilà, je sais qu'il manquera très certainement de précision, mais ne sachant plus où chercher...

Merci d'avance.

[Paul TOTH]

le problème des "mails indésirables", c'est que chaque serveur décide de la nature indésirable du mail

si ce serveur centralise l'envoie de mails de différents utilisateurs vers des tas de destinations, ce peut être en soit un critère de détection de spam

[Hermite]

Je comprends bien que ce qui a été mis en place de notre côté n'est pas la seule cause du problème.

Par contre, ce serveur n'est pas un serveur SMTP. C'est comme si on avait un simple PC avec un Outlook sur lequel on avait configuré une trentaine de boîte de messagerie de fournisseurs variés.

Ce qui me gêne dans tout ça, c'est qu'avec un même compte mail et vers un même destinataire, un mail envoyé du PC de l'utilisateur par Outlook ne sera pas bloqué alors qu'un mail avec le même contenu sera bloqué lorsqu'il est envoyé du serveur d'application (et jamais l'inverse).

J'ai du mal à croire que ça ne vienne que de l'antispam du destinataire.


A défaut d'une solution, ou même d'une simple piste de recherche, existe-t-il une marche à suivre (des bonnes pratiques en fait) pour notre cas ?
Pour rappel :
- application hébergée sur un serveur
- chaque utilisateur doit pouvoir envoyer des mails avec sa propre adresse de messagerie (noms de domaine différents et non modifiables) et ce à partir de la-dite application
- le but étant, lorsque le destinataire répond au mail, que ce dernier soit envoyé à l'adresse de l'utilisateur. Ces mails ne sont pas récupérés par l'application (elle ne fait que l'envoi), mais par les clients de messagerie des utilisateurs, sur leur PC local.

[Paul TOTH]

Je comprends bien que ce qui a été mis en place de notre côté n'est pas la seule cause du problème.

Par contre, ce serveur n'est pas un serveur SMTP. C'est comme si on avait un simple PC avec un Outlook sur lequel on avait configuré une trentaine de boîte de messagerie de fournisseurs variés.

je dirais "justement", comme c'est un serveur qui centralise l'envoie de mail, il serait plus pertinent d'en faire un serveur SMTP correctement configuré (notamment déclaré comme tel au niveau DNS) s'il ne veux pas passer pour un robot/Virus installé sur un poste d'utilisateur lambda qui véhiculerait des spams....ça n'empêche pas un autre serveur de le blacklister si ça lui chante, mais c'est une configuration plus adaptée à cet usage.

l'autre solution étant de transmettre les mails directement au serveur SMTP de chaque boîte émettrice ce qui nécessite probablement un accès SSL avec identification, sauf pour ceux qui ont le même FAI que le serveur.

au fait, est-ce que des mails envoyés par Outlook depuis le serveur sont également bloqués ? car cela peut aussi venir de l'entête SMTP de Indy qui est probablement différente de celle de Outlook (ou autre).

Ce qui me gêne dans tout ça, c'est qu'avec un même compte mail et vers un même destinataire, un mail envoyé du PC de l'utilisateur par Outlook ne sera pas bloqué alors qu'un mail avec le même contenu sera bloqué lorsqu'il est envoyé du serveur d'application (et jamais l'inverse).

J'ai du mal à croire que ça ne vienne que de l'antispam du destinataire.


A défaut d'une solution, ou même d'une simple piste de recherche, existe-t-il une marche à suivre (des bonnes pratiques en fait) pour notre cas ?
Pour rappel :
- application hébergée sur un serveur
- chaque utilisateur doit pouvoir envoyer des mails avec sa propre adresse de messagerie (noms de domaine différents et non modifiables) et ce à partir de la-dite application
- le but étant, lorsque le destinataire répond au mail, que ce dernier soit envoyé à l'adresse de l'utilisateur. Ces mails ne sont pas récupérés par l'application (elle ne fait que l'envoi), mais par les clients de messagerie des utilisateurs, sur leur PC local.

[Hermite]

Merci pour ces informations.

l'autre solution étant de transmettre les mails directement au serveur SMTP de chaque boîte émettrice ce qui nécessite probablement un accès SSL avec identification, sauf pour ceux qui ont le même FAI que le serveur.

C'est exactement ce qui est fait.

au fait, est-ce que des mails envoyés par Outlook depuis le serveur sont également bloqués ?

Ça je n'ai aucun moyen de le savoir. Il n'y a pas d'envoi effectué par Outlook à partir du serveur. Si l'utilisateur veut envoyer par Outlook, il le fait à partir de son PC, et dans ce cas, ce n'est pas bloqué.

car cela peut aussi venir de l'entête SMTP de Indy qui est probablement différente de celle de Outlook (ou autre).

Voici l'enregistrement d'un mail généré par l'application avant son envoi :

From: "utilisateur@hotmail.fr" <utilisateur@hotmail.fr>
Subject: test message
To: destinataire@free.fr
Content-Type: text/plain; charset=UTF-8
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Reply-To: utilisateur@hotmail.fr
Date: Wed, 4 Oct 2017 09:06:22 +0200

dGVzdCBtZXNzYWdlDQo=
.

[Hermite]

il serait plus pertinent d'en faire un serveur SMTP correctement configuré (notamment déclaré comme tel au niveau DNS) s'il ne veux pas passer pour un robot/Virus installé sur un poste d'utilisateur lambda qui véhiculerait des spams

Je pensais qu'un serveur SMTP qui envoi des mails avec des adresses d'expéditeur présentant des noms de domaines variés aurait plus de risque d'être blacklisté.

[Paul TOTH]

Merci pour ces informations.


C'est exactement ce qui est fait.

donc si tu as un client toto@orange.fr qui veux écrire à titi@free.fr tu passes par smtp.orange.fr, et si c'est titi qui veux écrire, tu passes par smtp.free.fr ?

Voici l'enregistrement d'un mail généré par l'application avant son envoi :

je ne parlais pas de l'entête du mail mais de l'échange SMTP: EHLO Indy, etc...

[Hermite]

C'est bien ça, le smtp utilisé est toujours celui qui correspond à l'expéditeur.

Pour ce qui est de la communication entre les composants INDY et le serveur SMTP, je ne sais pas trop comment contrôler ça...

Cependant, et là ça devient étonnant, pour l'un des utilisateur particulièrement impacté, j'ai fini par passer par un autre SMTP.
Les mails de cet utilisateur sont donc envoyés avec une adresse d'expéditeur d'un domaine qui ne correspond pas du tout au SMTP utilisé... et ça passe.

Je pense proposer aux décideurs de passer par une plateforme externe. J'imagine qu'une telle plateforme sera plus à même de fournir une solution, ou à défaut une explication à ce genre de problème.

[Paul TOTH]

C'est bien ça, le smtp utilisé est toujours celui qui correspond à l'expéditeur.

Pour ce qui est de la communication entre les composants INDY et le serveur SMTP, je ne sais pas trop comment contrôler ça...

Cependant, et là ça devient étonnant, pour l'un des utilisateur particulièrement impacté, j'ai fini par passer par un autre SMTP.
Les mails de cet utilisateur sont donc envoyés avec une adresse d'expéditeur d'un domaine qui ne correspond pas du tout au SMTP utilisé... et ça passe.

Je pense proposer aux décideurs de passer par une plateforme externe. J'imagine qu'une telle plateforme sera plus à même de fournir une solution, ou à défaut une explication à ce genre de problème.

il faudrait comparer le "source du message" entre le mail classé indésirable et l'autre. Notamment dans ce source on retrouve le chemin emprunté par le mail via des lignes "Received: from " où peut figurer Indy, ou des "SPAMSCORE" qui indiquent en général qui a classé, et vaguement pourquoi, le mail en indésirable.

exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
Received: from localhost (HELO queue)
Received: from output5.mail.ovh.net 
X-Ovh-Remote: xxxx
X-Ovh-Tracer-Id: ...
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: ...
X-Ovh-Spam-Status: OK
X-Ovh-Spam-Reason: vr: OK; dkim: disabled; spf: disabled
X-Ovh-Message-Type: OK

[Hermite]

Je vois.
Je vais avoir beaucoup de mal à récupérer un exemple de mail bloqué, du fait du nombre d'intermédiaires et aussi parce que les destinataires sont bien souvent loin d'être réceptifs à la résolution des problèmes informatiques.

Lors des différents tests effectués, j'ai récupérés les entêtes de mails envoyés par Outlook et par l'application pour comparer.

Sur les mails envoyés par l'application, il n'y a aucune mention permettant d'identifier l'application d'origine. Je sais que certaines versions d'INDY ajoutaient un enregistrement X-Mailer spécifique dans l'entête et que cela posait problème avec les anti-spam, mais ce n'est pas le cas de la version que j'utilise (il n'y a pas d'enregistrement X-Mailer du tout).

J'ai aussi eu un cas avec ceci :

X-Backend: vm-mx-sophos-mta42
X-Backend: vm-mx-sophos-mta46
X-PMX-Backend: PMX 6.3.1.2588712, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.10.3.93017 running on vm-mx-sophos-mta42
X-PMX-Backend: PMX 6.3.1.2588712, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.10.3.93017 running on vm-mx-sophos-mta46
X-PMX-VirusScan: no virus found
X-PMX-VirusScan: no virus found
X-PFSI-Info: PMX 6.3.1.2588712, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.10.3.93017 (no virus found)
X-Spam-Flag: NO
X-PMX-Spam: Probability=8%
X-PMX-Spam: Probability=8%
X-PMX-SpamScan: NO 8%
X-PMX-SpamScan: NO 8%

J'ai dans ce cas effectivement une petite différence puisque le mail envoyé par l'application indique un taux de 9% au lieu de 8 pour l'envoi par Outlook.

[Paul TOTH]

oui mais si à 9% c'est considéré comme du spam y'a plus grand chose à faire

[Hermite]

C'est un peu le bilan de tout ça... On peut pas y faire grand chose.

Pour le moment le fait de passer par le SMTP de notre prestataire règle 99% des blocages.
Dans la mesure où on (je) n'arrive pas à identifier un éventuel problème dans l'application, je vais passer le relais à... bah en fait, je sais pas qui. J'aviserai à la prochaine remontée du problème.

En tout cas merci d'avoir pris de ton temps pour tenter de m'aider.