Envoi d'email - adresse destinataire fausse

[TheoLechemia]

Aucune erreur n'est levée lorsque l'email de l'utilisateur n'existe pas. Vérifier s'il est possible d'attraper une erreur par un autre moyen ?

[jpm-cbna]

L'envoie d'email dans GeoNature s'appui sur une bibliothèque qui les envoie via un serveur SMTP. Attraper l'exception qu'elle peut déclencher est déjà une bonne avancée.

Concernant le repérage des adresses destinataire fausse, cela me semble plus difficile car il faudrait un mécanisme asynchrone qui soit déclenché au retour d'email du serveur distant indiquant que l'adresse du destinataire n'existe pas. Encore faut il que l'on reçoive cet email car si un mécanisme de "catch-all" est actif sur le serveur email distant rien ne sera renvoyé...

Les solutions envisageable pour s'assurer de la validité d'un email :

1. une expression régulière lors de sa saisie qui vérifie que sa forme est valide (déjà en place dans l'inscription)
2. une vérification par envoie d'un email qui contient un lien vers GeoNature permettant de confirmer ainsi que l'email existe réellement.

Pour la solution 2, il vaut mieux ajouter cette possibilité sans qu'elle soit bloquante lors de l'inscription... Elle doit pouvoir être réalisé après l'inscription. Le fonctionnement de la vérification d'email de Github est un bon exemple.

[camillemonchicourt]

Dans notre cas (GINCO-DEPOBIO), les emails ne sont pas saisis, car on récupère les adresses emails des utilisateurs depuis le webservice des utilisateurs de l'INPN.

[bouttier]

Une gestion correcte des e-mails n’est pas trivial …

• L’utilisation d’une expression régulière est dangereuse : 99% des regexp que l’on trouve sur le net sauf fausses, tous simplement car la regexp correspondant à la RFC fait à peut près 20 lignes. Du coup il vaut mieux utiliser une regexp simple mais « trop » permissive. D’autre part, un format d’adresse e-mail correcte ne garantie pas que l’e-mail existe bien.
• Confirmer l’email c’est déjà vraiment pas mal, mais ce n’est pas suffisant pour savoir si un e-mail a été bien envoyé : il peut se poser des problèmes tel qu’un serveur down ou un filtre anti-spam qui blacklist geonature, et ce après la vérification de l’e-mail.

Globalement, de mon point de vue, il faut :

• Monitorer la file d’envoi du serveur SMTP et s’inquiéter lorsqu’elle est trop élevée.
• Envoyer des e-mails avec une envelope-from correspondant à une boite e-mail qui existe bien (généralement no-reply@…), de manière à pouvoir aller consulter les rapports d’erreurs (bounce) au besoin.

À noter également qu’envoyer des e-mails qui soient acceptés par les serveurs e-mails nécessite une configuration assez poussé (DKIM, DMARC, …) et de régulièrement faire des demande de dé-blacklistage à droite à gauche … Il est aussi possible de passer par des serveurs relais payant s’occupant de cela.

[camillemonchicourt]

Là je suis pas certain que l'on soit concerné par les problèmes de blacklistage, car on s'appuie sur le SMTP de sa structure pour les envois d'email. Dans notre cas, un email en "@ecrins-parcnational.fr".

[bouttier]

Effectivement, dans ce cas ce genre de soucis est du ressors de la structure :-) Ceci dit, c’est quand même à nous de gérer les bounces. D’autre part, je pense qu’il est bien d’avoir un smtp local sur la machine geonature qui relais vers le smtp de la structure, de manière à ce qu’en cas de problème réseau entre geonature et la structure, ou d’interruption de service du smtp de la structure, geonature ne génère pas des 500 mais que les mails arrivent dans la file d’attente locale.