Projet

Général

Profil

Development #24519

Vérifier que l'adresse email mise en From existe bien

Ajouté par Frédéric Péters il y a presque 6 ans. Mis à jour il y a environ 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
14 juin 2018
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

C'est important contre l'impression de spam; basiquement j'imagine faire le SMTP jusque RCPT TO:<...> et si ça répond en 5xx (ou != 250 ?), dire que ça ne va pas le faire.


Demandes liées

Lié à Hobo - Development #23823: Fournir une API de vérification de bon fonctionnementFermé14 mai 2018

Actions

Révisions associées

Révision 1b970474 (diff)
Ajouté par Christophe Siraut il y a environ 5 ans

add default_from_email checks (#24519)

Historique

#1

Mis à jour par Thomas Noël il y a presque 6 ans

Il faudra que ça soit optionnel, car les machines qui hébergent les appli n'ont pas toujours accès à Internet pour le mail (principalement en hébergement sur site).

#4

Mis à jour par Christophe Siraut il y a presque 6 ans

je ne comprends pas bien pourquoi ce ticket est dans hobo, à quelle moment aura lieu ce check?

par ailleurs on pourrait garder un cache de ces vérifications.

#5

Mis à jour par Benjamin Dauvergne il y a presque 6 ans

Je pense que l'idée est de vérifier lors de la configuration dans hobo de l'adresse source, pas besoin de faire du cache. Effectivement si l'adresse devient soudainement non routable ça ne résout rien (mais je ne sais pas si c'est le souci ici).

#6

Mis à jour par Christophe Siraut il y a presque 6 ans

oui déso pour ma bête question, j'ai compris entre-temps.

#7

Mis à jour par Christophe Siraut il y a presque 6 ans

  • Lié à Development #23823: Fournir une API de vérification de bon fonctionnement ajouté
#8

Mis à jour par Christophe Siraut il y a presque 6 ans

  • Assigné à mis à Christophe Siraut
#9

Mis à jour par Christophe Siraut il y a presque 6 ans

+ vérifier l'enregistrement SPF associé.

#11

Mis à jour par Christophe Siraut il y a environ 5 ans

  • Statut changé de Nouveau à Solution proposée

Vérification de l'existence de l'expéditeur + champ SPF.

C'est actuellement un check générique qui est repris dans le BO pour chacune des briques; peut-être trouver un moyen de ne l'exécuter et l'afficher que pour une brique?

#12

Mis à jour par Frédéric Péters il y a environ 5 ans

C'est actuellement un check générique qui est repris dans le BO pour chacune des briques; peut-être trouver un moyen de ne l'exécuter et l'afficher que pour une brique?

Perso j'imaginais plutôt que ça soit validé au moment où l'adresse email est posée, dans l'écran de configuration associé. (qu'il y ait ValidationError si jamais ça n'est pas bon).

#13

Mis à jour par Christophe Siraut il y a environ 5 ans

Déplacé la validation dans le formulaire de saisie sur /emails/. La validation du champs SPF est désactivée par défaut et dépend de settings.ALLOWED_MX_DOMAINS.

#14

Mis à jour par Frédéric Péters il y a environ 5 ans

email_domain = value.split('@')[1]

De manière anecdotique l'@ n'est pas formellement interdite dans la partie local part d'une adresse email. (→ [-1] pour être sûr de prendre le domaine).

validate_email_spf

Je ne pige pas trop le ALLOWED_MX_DOMAINS, je dirais que le paramétrage devrait plutôt être SPF_REQUIREMENTS, et dedans on mettrait une liste de possibilités, genre ["include:entrouvert.com", "ip4:5.135.221.10 ip4:5.135.221.25 ip4:..."].

Ensuite, dans la validation, il faut passer sur tous les TXT, pas juste le premier, et regarder si c'est un TXT qui déclare une règle SPF (startswith('v=spf1 '), si on est sur une règle SPF, alors regarder si une des entrées de SPF_REQUIREMENTS matche. (et s'il n'y a pas de règle SPF, ça valide).

#15

Mis à jour par Christophe Siraut il y a environ 5 ans

Implémenté ta logique, mais j'ai nommé le paramètre de configuration ALLOWED_SPF_RECORDS qui je trouve explicite mieux qu'il suffit d'un élément valide.

#16

Mis à jour par Frédéric Péters il y a environ 5 ans

(et s'il n'y a pas de règle SPF, ça valide).

Ça n'est pas encore le cas.

#17

Mis à jour par Christophe Siraut il y a environ 5 ans

Je comprends que tu préfères un paramètre SPF_REQUIREMENTS plutôt que ALLOWED_SPF_RECORDS? (Ok pour moi)

Sinon dans test_kown_address() il n'y a rien de défini au niveau SPF et ça passe, parce que par défault on a posé ALLOWED_SPF_RECORDS = ['*'], et que validate_email_spf() ne valide rien dans ce cas.

#18

Mis à jour par Frédéric Péters il y a environ 5 ans

Sinon dans test_kown_address() il n'y a rien de défini au niveau SPF et ça passe, parce que par défault on a posé ALLOWED_SPF_RECORDS = ['*'], et que validate_email_spf() ne valide rien dans ce cas.

Je veux dire au niveau du DNS, genre si on configure la fonctionnalité, qu'il n'y a en face aucun enregistrement TXT spf, ça dit que ce n'est pas bon.

#20

Mis à jour par Frédéric Péters il y a environ 5 ans

Dans quel cas d'usage veut-on avoir la validation qui n'échoue pas quand l'enregistrement TXT est absent ?

Dans tous les cas. S'il n'y a pas de SPF sur un domaine, il n'y a pas d'indication qui va faire qu'un message s'annonçant de ce domaine devrait être rejeté.

Et ça me fait en même temps affirmer que s'il doit y avoir une valeur par défaut, c'est ["+all"], qui indiquerait un domaine déclarant du SPF autorisant les messages de n'importe où.

#21

Mis à jour par Christophe Siraut il y a environ 5 ans

J'ai adapté le patch:
  • ALLOWED_SPF_RECORDS est vide par défaut
  • ça valide correctement quand il n'y a pas de champ SPF ou quand il y en a un qui contient +all
  • ajouté un mode strict au validateur SPF pour usage interne qui ne valide pas quand il n'y a pas de champs SPF (=comportement défaillant de certain fournisseurs antispam, on peut appeler ça autrement que "strict", genre "abusive")
#22

Mis à jour par Nicolas Roche il y a environ 5 ans

Il manque la prise en compte d'une exception suite à un nom de domain bidon dans validate_email_address :

    dns.resolver.query('nom.bidon.org') -> dns.resolver.NXDOMAIN

(ça fait planter le serveur au lieu d'ajouter un message au dessus du formulaire comme pour les autres exceptions)

Et peut-être si tu peux compléter, il manques quelques tests des cas d'erreurs dans validate_email_address :
https://jenkins2.entrouvert.org/job/hobo-wip/job/wip%252F24519-Verifier-que-l-adresse-email-mise-en-From-existe-bien/9/cobertura/emails/validators_py/

#23

Mis à jour par Nicolas Roche il y a environ 5 ans

  • Statut changé de Solution proposée à En cours
#24

Mis à jour par Christophe Siraut il y a environ 5 ans

  • Statut changé de En cours à Solution proposée

J'ai ajouté l'exception sur un nom bidon et les tests manquants.

#25

Mis à jour par Nicolas Roche il y a environ 5 ans

  • Statut changé de Solution proposée à En cours

Lors du troisième appel à validate_email_address, l'exception reçue est encore NXDOMAIN
et donc on ne passe jamais par les lignes concernées par une erreur de socket.

Peut-être éclater le test test_validate_email_address en 3, ou alors introduire du contexte.

#26

Mis à jour par Christophe Siraut il y a environ 5 ans

Bien vu, j'ai corrigé.

#27

Mis à jour par Nicolas Roche il y a environ 5 ans

  • Statut changé de En cours à Solution validée

Désolé, j'ai mis le temps je voulais comprendre pourquoi il manquait un test sur le retour de smtp_helo().
Rien de bien méchant et compliqué à tester en l'état.
Ack.

#28

Mis à jour par Christophe Siraut il y a environ 5 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit 1b9704742fc539a471b54da3a829c0015e933fda (HEAD -> master, origin/master, origin/HEAD)
Author: Christophe Siraut <csiraut@entrouvert.com>
Date:   Fri Mar 29 10:17:59 2019 +0100

    add default_from_email checks (#24519)
#29

Mis à jour par Frédéric Péters il y a environ 5 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF