Y a-t-il un cap'tain Obvious dans la salle ^^ ?

Ca me parait pourtant clair.

Il suffit d'intégrer le bounce dans le return-path pour valider le groupware... en fait non, j'ai rien compris non plus.

J'ai eu l'impression de lire l'interview des "Tranxen 200" des Inconnus.

Si un serveur SMTP utilise le From pour signaler une erreur de destinataire inconnu, son auteur doit être fusillé sur le champ !

Un destinataire inconnu est signalé au niveau de l'enveloppe, pas sur le contenu. Si le groupware en question valide sur un échec d'envoi, il ne me reste plus qu'à aller rechercher une boîte de balles...

J'essaie:

L'utilisateur ajoute une nouvelle adresse e-mail. Le soft s'occupant de "vérifier" la validité de cette adresse envoie un e-mail à cette dernière, avec comme expéditeur (et adresse de réponse) l'ancienne adresse e-mail dudit utilisateur.
Si la nouvelle boite e-mail n'existe pas, l'utilisateur reçoit alors dans son ancienne boite e-mail un "bounce-message" (en l'occurrence un "Non-Delivery Report").
Du coup, il a accès au contenu de l'e-mail envoyé par le soft de "vérification", et peut donc utiliser le lien qui permet de valider la nouvelle adresse.

C'est ce que j'ai compris, mais je ne promets pas que ma traduction soit fidèle à l'idée de l'auteur.

... que le posteur est un PEBKAC, qui pense pouvoir abuser la vérification de son adresse mail dans le cas où son mail serait refusé, en lisant un autre mail sur cette même adresse. Oups.

D'ailleurs, cette histoire de champ from me paraît un moyen très bon marché pour le groupware d'éviter d'être spammé de messages "Undelivered mail returned to sender" pour les adresses invalides?

Kakamou kakamou kakamou...lox..

De toute façon, si je comprends bien cette sécurité, le but n'est pas de se protéger contre les adresses qui n'existent pas, mais contre les gens qui inscriraient un copain (ou un inconnu) à son insu, non?

La subtilité est dans la phrase : "si un utilisateur ajoute une nouvelle adresse"

Le FROM est donc l'ancienne adresse, et le TO la nouvelle adresse.
Dans ce cas, on peut effectivement récupérer le bounce SMTP dans l'adresse FROM (l'ancienne) et donc valider n'importe quoi comme nouvelle adresse.

Subtil ! Mais bel et bien un PEBKAC.

Ouais, c'est complètement glucose.

Mais le From et l'enveloppe sont identique dans ce cas, j'ai envoyé un message et ça marche.

Exactement ça, et je rajoute que ça marche aussi si un autoreply cite le message original.

Mettre le From sur noreply@<domain> qui devrait être routé vers /dev/null, ou, comme dans le patch proposé ,permettre à l'admin de spécifier l'adresse d'envoi. À lui de voir si'il veut recevoir ces bounces pour contrôle ou non .

Exactement,

Autre bizarrerie, si l'utilisateur n'a pas d'adresse "actuelle" (ou les a toutes supprimés) le mail est envoyé à l'adresse de destination avec cette même adresse de destination en From.

Le but est de permettre à un utilisateur d'envoyer des mails uniquement à partir d'adresses qu'il "possède". GMail pratique ce genre de contrôle par exemple.

Bon, j'aurait pu éviter de de parler du return-path, c'est vrai.
Mais un return-path vide indique que le serveur n'a pas reçu d'adresse From sur l'enveloppe, donc pas de bounce.

Exactement comme à La Poste !

Bon j'allait poster un autre PEBKAC de mailadmin, mais du coup j'hésite.

Ma question est donc la suivante :
Quel est l'intérêt d'ajouter une adresse e-mail bidon ?

@Youplà pas forcement bidon (autoreply, quota)...

Et puis cette fonctionnalité est là pour contrôler que l'utilisateur possède bien l'adresse qu'il veut enregistrer, quel intérêt si elle est contournable ?

Mouais, enfin la contourner ne dérangera (au pire) que l'utilisateur qu s'amuse à la contourner, du coup, je ne vois pas le problème...
Pour moi ce n'est pas vraiment un PEBKAC (mais ça ne mérite pas non-plus un CTLP).

@Youplà Pour moi c'est un PEBKAC car ça n'a aucune raison d'avoir cette faiblesse.

Le développeur a dû juste copier le code à partir d'une autre partie du programme (genre la notification de l'agenda, qui utilises le mail de l'utilisateur sans que cela pose problème) et ne s'est pas posée la question des implications dans le contexte de destination. Un petit PEBKAC pas très méchant, mais quand-même.

D'autres parties du code utilisent une adresse spécifiée par l'administrateur (pour la récupération de mot de passe par ex), donc aucune raison de ne pas faire pareil ici.

La seule raison possible est de permettre au destinataire de connaitre rapidement le compte à l'origine de la demande, mais dans ce cas autant le spécifier dans le corps du mail sans introduire de faille dans le système.

Le vrai problème ici, c'est qu'il y a une tonne de termes que pas grand monde comprends. Si tu arrives à le tourner de manière claire, ça devrait mieux passer.

Et tu insistes en plus !

Bon, je pense avoir compris que le serveur ne vérifiait pas l'expéditeur, s'il était légitime ou non, c'est ça ? Mais dans ce cas, essaie de ne pas utiliser trop de jargon technique pour ceux qui ne connaissent pas... surtout quand on te dit qu'on ne comprend pas !

Je relance de 3 tartes à la crème antirides et je croise un fer blanc.

Ouais, curieux, il a dû se tromper en faisant son code, et vu que c'est loin d'être bloquant, aucune erreur générée notamment, il n'a même pas dû s'apercevoir de sa bévue.

Tu le lui as signalé ?

Si tu l'écris en français, pas de soucis. Le domaine des mails est très intéressant, mais très compliqué aussi, et avec des termes abscons... Ne décourage pas tes lecteurs.

En effet, j'utilise des tournures vieillies ou autres bizarreries linguistiques dans mes PEBKAC, et je me fait parfois expliquer l'horripilation que cet manie peut causer. Pour autant, il s'agit de formules que tout un chacun est en mesure de comprendre apès quelqu'effort. Là je t'ai noté non sur la qualité de l'anecdote ( je me serais abstenu de voter jusqu'àplus ample informé ) mais sur celle de la rédaction qui m'apparut défaillante en ce qu'elle était par trop spécialisée.

Perso, j'ai rien compris, même en lisant les explications plus haut... Mais je considère que c'est moi le boulet puisqu'apparemment c'est clair pour les autres. Donc dans le doute, je ne me prononce pas... C'est sûrement moi le PEBKAC.

Non, je traite les emails depuis des années, je me suis fortement renseigné sur le protocole mail mais je n'ai rien bité.
Quand tu valides une adresse, il y a qu'une seule chose qui importe : le code de validation; le From, le Return-Path, on s'en cogne les poneys.

En cas du bounce du mail le code de validation est renvoyé à la personne qui tente de valider l'adresse.

Tu voit mieux le problème ?

Le Return-Path null indique un MAIL FROM vide donc pas de bounce possible.