Bonjour HFR
 
Je rencontre un petit souci avec l'envoi de mail depuis mes applications web (ASP .NET MVC) depuis quelques jours.
C'est le cas du service Rehost, par exemple, ce qui est un peu gênant
 
Ces applications comportent des fonctionnalités qui aboutissent à envois de mail aux utilisateurs.
J'ai écrit ça au plus simple : utilisation des classes MailMessage, SmtpClient et SmtpServer avec envoi SSL vers le server SMTP (port 587) de mon fournisseur (OVH).
 
Ca fonctionnait parfaitement en mode classique : serveur web VM unique, trafic HTTP/HTTPS en direct sur le serveur, certificats SSL Let's Encrypt, redirection des ports 80/443 vers la VM serveur web.
Mais j'ai voulu aller un peu plus loin en séparant les applications sur des serveurs séparés, pour réduire les impacts sur les perfs et la sécurité...
Je suis donc passé en configuration Reverse Proxy : serveurs web VM multiples (ports internes personnalisés), trafic HTTP/HTTPS via mon Reverse Proxy, certificat SSL unique Let's Encrypt centralisé sur mon Reverse Proxy, redirection des ports 80/443 vers mon Reverse Proxy.
 
Pour le moment, je n'utilise que le pare-feu des VM (côté OS donc), pas hardware (côté Reverse Proxy ou routeur).
Le reverse proxy est installé sur mon NAS Synology (DS918+ à jour).
 
J'ai l'impression que l'envoi de mail s'est perdu dans l'opération
Lorsque je debug en local (SMTP Orange / port 25 / mon compte perso) pas de souci, les mails passent.
Quand les applis tournent en prod (SMTP OVH / port 587 / comptes mails appli), rien de se passe.
Quand les applis tournent en prod (SMTP OVH / port 25 / comptes mails appli), j'ai une erreur timeout (normal : OVH bloque le trafic non SSL)
 
Je pense que la demande arrive bien chez OVH puisque je n'ai pas d'erreur de timeout, juste rien ne se passe
Lorsque je tente un envoi de mail à la main depuis le webmail de OVH, je reçois bien les tests envoyés !
 
Une idée de ce que j'aurai foiré ?
 
Je m'en vais poser la question dans la section Réseau aussi, on sait jamais.
N'étant pas expert infra, c'est peut être de ce côté là que ça bloque
 
Merci pour votre aide !

OVH fait pas un filtrage sur l'IP ? Genre que ton IP n'est pas autorisée à envoyer des mails ?
Par contre, tu fais communiquer tes VM entre elles comment : avec les urls du reverse proxy ou avec des IP locales et ports ?
A vu de nez, je dirais que c'est le SMTP qui te renvoie une réponse sur une url pas bonne. Du genre : si tu communiques entre les VM avec de l'IP locale, si ta VM envoie une requête au SMTP avec comme source une IP loocale de VP, le SMTP d'OVH va pas être capable de te renvoyer ses réponses. Je sais pas si je suis très clair.
Mais je pense que c'est plus un pb de conf infra que de dév.

Merci pour ta réponse
 
A priori, pas de filtrage IP côté OVH activé.
De toute façon, que la requête parte directement de mon serveur web (192.168.a.b) ou de mon NAS (192.168.a.c), l'IP publique reste la même (mon IP Orange 86.x.x.x), de ce côté, la config n'a pas changé.
 
Les VM dialoguent entre elles par des appels locaux (192.168.x.x), étant donné qu'Orange bloque le loopback, je ne peux pas appeler "vm1.diberie.com" depuis "vm2.diberie.com", par exemple.
En réalité si, je peux, en bidouillant mon fichier HOST pour forcer les appels locaux (vm1.diberie.com --> 192.168.a.b).
 
Mais plus j'y réfléchis, plus je pense que c'est une problématique réseau plutôt que dév, oui en effet

Ah oui, le loopback pas fait par la Livebox, ça m'en a fait perdre des heures à comprendre pourquoi un truc devrait marcher et que c'était pas le cas parce que je faisais mes tests depuis le LAN alors qu'en-dehors, ça marchait  

C'est ça.
 
Je pense que je vais devoir revoir un peu mes plans et me passer de reverse proxy...

Moi, le reverse proxy pour l'école de ma fille, je l'ai géré via le NAS Synology derrière la Livebox.

Ah bah c'est exactement cette installation que j'ai en place
 
Une Livebox v4 (routeur / serveur DHCP / pare feu / NAT...) et le Synology derrière (NAS, Reverse Proxy, DynDNS...)
 
Je sais que c'est très amateur, mais c'est simplissime à mettre en oeuvre.

Moi, ça fait depuis 7 ans que c'est comme ça, ça marche très bien. On a même ajouté une Overthebox pour agréger la Livebox avec un routeur 4G pour passer de 5-6 Mbps à 40 Mbps

Euh là tu confonds un peu tout et il y a plusieurs problèmes dans ton cas.
Le reverse proxy ne s'occupe que de la redirection HTTP/HTTPS, ton SMTP sortant il est complètement indépendant. Il faut que ta VM/container ait une connectivité à internet pour envoyer des mails. Ca a l'air d'être le cas vu qu'elle arrive à joindre le SMTP d'Orange.
 
Ensuite tu sembles confondre SMTP 25 = non chiffré, SMTP 587 = chiffré, mauvaise nouvelle encore une fois ça n'a rien à voir. Les 2 peuvent être chiffrés, suffit juste d'envoyer la commande STARTSSL au début de l'échange. SMTP 25 est normalement utilisé pour faire communiquer 2 serveurs SMTP entre eux et SMTP 587 pour faire communiquer un client avec un serveur.
Orange bloque toutes les connexions sur le port 25 qui ne sont pas à destination de son propre serveur SMTP d'où le timeout. https://lafibre.info/orange-les-new [...] ez-orange/
 
Tu as pas les logs des connexions au SMTP OVH sur le port 587 ? Tu fais de l'authentification au moins ?

Merci pour ces éléments de réponse Je@nb.
 
Oui, la VM est connectée.
 
Je faisais en effet à tort le parallèle SMTP // HTTP, pensant bêtement que le trafic sur le port 25 était implicitement non chiffré (comme le 80) et celui sur les 465/587 chiffré (comme le 443).
 
Pour mes appels SMTP, évidemment oui, j'utilise l'authentification (credentials) fournis par OVH (ou Orange, en localhost)
D'ailleurs je confirme aussi faire un mail.Enablessl = true sur les environnements de prod (où je vise donc le port 587), et false sur mon localhost, où je passe par le port 25.
 
Je n'ai pas encore creusé côté OVH, pensant que c'était ma façon de paramétrer mon envoi qui était mauvaise. Je vais aller voir de ce côté-là

En fait pour faire du SSL/TLS sur SMTP tu as 2 moyens, soit c'est implicite parce que le port fait que tu es en SSL par définition (port 465 pour SMTP), ça ressemble à ce que tu as avec HTTP/HTTPS entre le 80 et 443, soit tu es en mode expicite où tu commences la communication en claire et après que le serveur ait annoncé qu'il sait faire du TLS, le client va demander à passer en mode chiffré en envoyant la commande STARTTLS (plus moderne ).
La classe SmtpClient ne sait pas faire le premier protocole de base d'après la doc : https://docs.microsoft.com/en-us/do [...] ew=net-5.0
Faut donc voir si OVH permet sur son port 587 de faire du STARTTLS ou pas mais vu que leurs docs sont à chier j'ai pas trouvé

Merci beaucoup Je@nb.
Je regarde ça dans la journée

Ok, alors là je suis un peu perplexe

Voici le code issu de Rehost, ASP .NET MVC :

Voici le code issu d'un projet de test Winforms :

Le code est "identique"
Juste un peu personnalisé dans le premier cas, posé en vrac dans le 2e, mais les appels sont les mêmes, les credentials aussi (le texte habillement caché en jaune dans le cas 2 provient des clés de config même du cas 1).

Je vous le donne en 1000 : l'appli MVC n'envoie rien, mais l'appli Winforms oui !

Les 2 applis tournent sur ma même machine de dev, ici, en local.
Elles ciblent (du coup) bien le même serveur mail OVH.
L'une en direct (Winforms), l'autre en passant (je suppose) par IIS Express.
Aucune exception de levée dans les 2 cas. Mes points d'arrêt dans les catch() ne se déclenchent pas.

J'en conclue donc que, en effet, mon Reverse Proxy n'a RIEN à voir dans cette histoire, déjà.
J'ai pas trouvé de quoi consulter les logs côté OVH, donc j'ai ouvert un ticket pour demander de l'aide. pas encore de réponse.

EDIT : Sur chacune de mes machines d'où l'appli est exécutée (mon poste de dev, ma VM de "test" et ma VM de "prod" ), un telnet vers le serveur OVH est pourtant bien fonctionnel :

A ce stade, je pense qu'on peut donc conjecturer qu'il y a vraiment un truc qui bloque côté IIS Express / IIS, non ?

et le code est bien exécuté au moins ?
Tu peux tjr faire un wireshark ou autre pour capturer le flux même en SSL tu verras que le début de l'échange
 
ou le mail part bien mais il y a qqch qui plait pas au destinataire et qui le met en quarantaine côté serveur ou spam côté boite de réception

Si t'as pas de timeout ni d'exception c'est probablement que le mail part, possible qu'il se fasse choper par autre chose ? (anti spam, etc ?)
Tu es en quelle version de .net ? Pour être sûr de bien faire du tls 1.2.
Pas possible de tester ca avec une lib moins antique que SmtpClient ?

Merci pour vos réponses les gars.
 

Ouais ça c'est bon
Le point d'arrêt en entrée dans la méthode pope bien, le pas à pas passe bien, le mail.send() passe et on sort de la méthode pépère... mais rien ne se passe après.
J'ai essayé de sniffer avec Fiddler, mais effectivement, j'arrivais pas à capturer la trame puisqu'elle était chiffrée.
 

Je suis presque convaincu qu'il part de mon serveur oui, mais que quelque chose bloque derrière, puisqu'en Winforms ça passe nickel.
Du coup, je penche vraiment pour une config IIS
Pour l'appli web : ASP .NET MVC sur du .NET Framework 4.8 --> envoi KO
Pour l'appli winforms : .NET Framework 4.7.2 --> envoi OK
Le tout essayé sur 3 machines différentes (Windows 10, Windows Server 2012 R2, Windows Server 2019).
Si je précise bien que je souhaite utiliser SSL, c'est vrai que j'impose pas la version de TLS en place.
Si ça se trouve, il y a une différence implicite à ce niveau-là entre Winforms et ASP .NET MVC
Je me renseigne

Fiddler ça capture aussi des flux non HTTP/HTTPS ?
Wireshark je te dis tu verras au moins la connexion jusqu'au STARTTLS et tu verras si elle casse ou pas.
 
Oui le niveau de TLS peut être différent.
Tu peux pas essayer un mail "à la con" genre juste "Ceci est un test" plutôt que ton parsing d'un email template ?

J'ai capturé un essai avec Wireshark.
J'ai essayé de faire un peu de tri dans les trames, désolé si c'est un peu brouillon.
Je tâcherai par la suite de supprimer ces infos personnelles ...

Echange 1 : envoi de mail depuis l'appli MVC, depuis mon poste de dev (192.168.1.132) : mail jamais reçu

On voit l'initiation de la communication, le SMTP répond bien, accepte mon authent, on passe en TLS rapidement, et des données sont échangées (probablement le corps du mail).

Plus tard (~+4s) d'autres trames TLS 1.2 puis TCP sont échangées avec la même machine :

Je ne saurai pas interpréter le contenu, si il y a erreur ou pas, mais l'enchainement de trames me laisse penser que le contenu part bien chez OVH.
Malheureusement, ce qu'il se passe après et ce que OVH décide de faire avec ces trames, je n'ai pas la main dessus

Je vais tenter de capturer le même échange depuis l'appli Winforms, voir si quelque chose saute aux yeux.

EDIT : Ah bah j'ai croisé ton message
Oui bien sûr, l'appli Winforms envoie "<p>Coucou !</p>"

Echange 2 : envoi de mail depuis l'appli Winforms, depuis mon poste de dev (192.168.1.132) : mail reçu dans la minute

Les trames ignorées concernaient d'autres appareils.

Le séquencement est quasiment identique au précédent : échange TCP (authent) > passage TLS 1.2 > transmission de données > rebascule en TCP > idle
Le contenu est un peu plus court ici parce que le mail est plus court.
Pour moi, rien ne flashe

P*TIN  arrêtez-tout !
 

 
-->
 

 
C'est donc bien ma superbe transfo template HTML qui pose problème
 
Bon bah au moins je sais où chercher....

haha told you

Désolé
Effectivement, la transfo HTML de "<p>Coucou</p>" passe chez OVH, mais mes trucs complexes non. Je corrigerai ça quand j'aurai (plus) de temps à passer dessus. Pour le moment, une transfo en texte plein m'ira très bien
 
Merci à votre aide en tout cas