Produits Entr'ouvert » Hobo

Pour ce qui est de ta première objection, le rejet greylisting (4xx) est retourné après la commande data; ici nous quittons avant.

Christophe Siraut a écrit :

Pour ce qui est de ta première objection, le rejet greylisting (4xx) est retourné après la commande data; ici nous quittons avant.

Le greylist c'est aussi possible plus tôt ; exemple sur un postgrey:

220 smtp.fr.auf.org ESMTP Postfix (Debian/GNU AUF Paris)
HELO coucou
250 smtp.fr.auf.org
MAIL FROM: tnoel@entrouvert.com
250 2.1.0 Ok
RCPT TO: abuse@auf.org
450 4.2.0 <abuse@auf.org>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/auf.org.html
QUIT

J'ajoute une couche: ça marchera pas sur les machines qui n'ont pas accès à smtp (celles qui doivent passer par un mta local pour envoyer des mails, cas fréquent en hébergement sur site)

Tant qu'à faire autant virer tout 1b9704742f. (Une autre option est de ne pas lever d'erreur au moment de la modification de l'adresse, et d'ajouter un v/x indicatif à sa droite si l'adresse peut être validée, mais la valeur ajoutée de cette modif est faible)

1b9704742f (qui est l'unique commit de #24519, donc tout ce qui touche la vérification d'email) contient également la vérification SPF et cette vérification est pour moi importante.

À noter dans la description de #24519 : "et si ça répond en 5xx" (avec oui une hésitation entre parenthèse derrière dans une suggestion d'aller plus loin).

Bref, pour moi, #24519 reste valide, il faut juste se limiter à 5xx (vraie erreur définitive), et faire ça avec un timeout court, et gérer la présence de plusieurs MX, et pouvoir débrayer pour les situations d'hébergement sur site nous refusant un accès au port 25 d'un serveur extérieur.

Pour le greylisting, je dirai qu'on peut rien faire à part être permissif (mais voir le point suivant).

Donc on doit tester tous les MX autant que faire se peut, si un est ne répond pas tant pis, si un seul refuse, on refuse. En gros :

ok = True
for mx in mxs:
  test with mx:
    if greylisted :
        ok = None
    elif unavailable:
        ok = None
    elif mail not accepted:
        ok = False
        break
    elif mail accepted and ok is None:
        ok = True

Si None on peut toujours mettre une alerte (je ne sais pas trop comment avec la logique de validation) qu'on est pas bien sûr, si ok=True ça va, si ok=False on refuse fermement.

Pour les cas où on a pas accès au port 25 en sortie, faut juste un setting HOBO_VALIDATE_EMAIL_WITH_SMTP = False,

On pourrait aussi imposer l'envoi d'un mail de validation avec un jeton et ne garder que la validation de syntaxe et SPF, le mail ne sera accepté que si on le rentre accompagé du jeton.

on doit tester tous les MX autant que faire se peu

Pourquoi n'est-ce pas correct de s'adresser au MX qui a la priorité la plus haute?

Christophe Siraut a écrit :

on doit tester tous les MX autant que faire se peu

Pourquoi n'est-ce pas correct de s'adresser au MX qui a la priorité la plus haute?

Si si, c'est ce qu'il faut faire. Les MX secondaires ne peuvent en général pas savoir si l'adresse existe réellement (ce sont souvent juste des spool d'attente du mx principal)

Christophe Siraut a écrit :

Voici les correctifs:

• s'adresser au serveur MX principal

Le principe des MX veut qu'on s'adresse à tous les MX, pas seulement au premier, non ?

En fait j'ai du mal à faire le lien avec ce fonctionnement et la remarque de Thomas comme quoi au milieu de tout ça on peut avoir de simples relais avec possiblement la même priorité que les autres et qui vont toujours dire OK, on est vraiment pas sûr que ce soit configuré comme nous on aimerait, je ne vois pas d'autre solution que de s'adresser à tout le monde et d'ignorer les 4xx/erreur de connection. Et en même temps je ne sais pas si on peut faire la différence entre un refus de relai permanent (parce que le SMTP n'est plus un MX pour ce domaine mais c'est mal configuré) et un refus de relai parce que l'email n'est pas bonne.

À la fin la bonne vieille vérité c'est que le seul moyen de savoir qu'une email existe c'est encore de lui envoyer un mail.

• 0002-emails-validators-address-preferred-mx-server-32435.patch : ok (bon si on était des supermen, le test ajouterait un mx bidon avec un coût de 20 en premier dans la liste, genre [mx20, mx10])
• 0003-emails-validators-set-connection-timeout-32435.patch : ok
• 0004-emails-validators-do-not-raise-validation-error-on-t.patch : il faut poser le smtp.quit() juste après le smtp.rcpt(value), puisqu'on le fait de toute façon. Pour la condition "status >= 500" on écrit plus souvent "status // 100 == 5", mais après tout >=500 ça va aussi attraper les erreurs 600 et 700 alors c'est bon ;) (je ne retrouve plus la blague sur les faux status genre 747 = trop gros message, etc)
• 0005-emails-validators-add-option-to-bypass-smtp-validati.patch : ok (on pourrait aussi avoir un autre flag qui permette de bypasser le check SPF sur les hébergements où les requêtes DNS hors zones locales ne marchent pas (c'était le cas au cd14 du temps de l'hébergement sur site... mais bon, on peut attendre que ça revienne ailleurs, jamais revu ça))

• et aussi ajouter aussi un patch "except dns.exception.DNSException as e:" lors de l'appel à dns.resolver, qui remplacera les except sur NXDOMAIN et NoAnswer (dans le code actuel par exemple on gère pas dns.resolver.NoNameservers = domaine qui n'existe pas... autant catcher toutes les exception et afficher le message et zou).

Benjamin Dauvergne a écrit :

Le principe des MX veut qu'on s'adresse à tous les MX, pas seulement au premier, non ?

Nope, un par un, dans l'ordre de coût (du moins cher au plus cher). Ici on s'adresse au premier, si ça foire on laisse béton, c'est normalement un cas très rare alors j'accepte qu'il se produise (sinon on peut ré-écrire un client mail, mais merci)

Thomas Noël a écrit :

Benjamin Dauvergne a écrit :

Le principe des MX veut qu'on s'adresse à tous les MX, pas seulement au premier, non ?

Nope, un par un, dans l'ordre de coût (du moins cher au plus cher). Ici on s'adresse au premier, si ça foire on laisse béton, c'est normalement un cas très rare alors j'accepte qu'il se produise (sinon on peut ré-écrire un client mail, mais merci)

Ok.