Bienvenue sur PEBKAC.fr, le site qui recense les anecdotes où l’on se moque des utilisateurs ne maîtrisant pas l’outil informatique. PEBKAC est un acronyme signifiant « Problem Exists Between Keyboard And Chair ».
Le problème se situe entre la chaise et le clavier : soumettez vos histoires, donnez votre avis !
Ce site n'est pas le site original pebkac.fr. Je publie ici la liste des PEBKAC que j'ai pu sauvegarder avant que le site original ne soit mis hors ligne.
Sur un célèbre groupware libre, si un utilisateur ajoute une nouvelle adresse à partir de laquelle il veut pouvoir envoyer des messages, un e-mail de validation est envoyé à cette adresse pour vérifier s'il la possède bien.

Sauf que cet e-mail est envoyé avec l'adresse de l'utilisateur dans le champ « From » et avec un « Return-Path » non nul.

Ce qui permet à l'utilisateur de valider n'importe quelle adresse qui n'existe pas (ou dont la boite est pleine), etc. juste en récupérant le code de validation dans le message de bounce. PEBKAC.
PEBKAC #9334 proposé par MilkEnd le 24/01/2014 | 30 commentaires | 👍🏽 👎🏽 -10
Y a-t-il un cap'tain Obvious dans la salle ^^ ?
Commentaire #126732 écrit par Mmm le 24/01/2014 à 17h41 | 👍🏽 👎🏽
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.
Commentaire #126733 écrit par Link le 24/01/2014 à 17h42 | 👍🏽 👎🏽
J'ai eu l'impression de lire l'interview des "Tranxen 200" des Inconnus.
Commentaire #126742 écrit par Liquid Brain le 24/01/2014 à 18h00 | 👍🏽 👎🏽
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...
Commentaire #126748 écrit par Acné le 24/01/2014 à 18h10 | 👍🏽 👎🏽
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.
Commentaire #126749 écrit par Youplà le 24/01/2014 à 18h10 | 👍🏽 👎🏽
... 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?
Commentaire #126750 écrit par Je crois que... le 24/01/2014 à 18h12 | 👍🏽 👎🏽
Kakamou kakamou kakamou...lox..
Commentaire #126751 écrit par ygnobl le 24/01/2014 à 18h13 | 👍🏽 👎🏽
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?
Commentaire #126753 écrit par Sécurité le 24/01/2014 à 18h14 | 👍🏽 👎🏽
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.
Commentaire #126764 écrit par OzoneGrif le 24/01/2014 à 18h36 | 👍🏽 👎🏽
Ouais, c'est complètement glucose.
Commentaire #126771 écrit par Belore le 24/01/2014 à 18h51 | 👍🏽 👎🏽
Mais le From et l'enveloppe sont identique dans ce cas, j'ai envoyé un message et ça marche.
Commentaire #126793 écrit par MilkEnd le 24/01/2014 à 21h56 | 👍🏽 👎🏽
Exactement ça, et je rajoute que ça marche aussi si un autoreply cite le message original.
Commentaire #126794 écrit par MilkEnd le 24/01/2014 à 21h57 | 👍🏽 👎🏽
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 .
Commentaire #126795 écrit par MilkEnd le 24/01/2014 à 22h00 | 👍🏽 👎🏽
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.
Commentaire #126796 écrit par MilkEnd le 24/01/2014 à 22h03 | 👍🏽 👎🏽
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.
Commentaire #126797 écrit par MilkEnd le 24/01/2014 à 22h05 | 👍🏽 👎🏽
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 !
Commentaire #126799 écrit par MilkEnd le 24/01/2014 à 22h11 | 👍🏽 👎🏽
Bon j'allait poster un autre PEBKAC de mailadmin, mais du coup j'hésite.
Commentaire #126801 écrit par MilkEnd le 24/01/2014 à 22h29 | 👍🏽 👎🏽
Ma question est donc la suivante :
Quel est l'intérêt d'ajouter une adresse e-mail bidon ?
Commentaire #126812 écrit par Youplà le 24/01/2014 à 23h40 | 👍🏽 👎🏽
@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 ?
Commentaire #126816 écrit par MilkEnd le 25/01/2014 à 00h14 | 👍🏽 👎🏽
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).
Commentaire #126817 écrit par Youplà le 25/01/2014 à 00h35 | 👍🏽 👎🏽
@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.
Commentaire #126820 écrit par MilkEnd le 25/01/2014 à 02h30 | 👍🏽 👎🏽
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.
Commentaire #126824 écrit par Link le 25/01/2014 à 08h30 | 👍🏽 👎🏽
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 !
Commentaire #126969 écrit par Aaargh!!! le 26/01/2014 à 10h25 | 👍🏽 👎🏽
Je relance de 3 tartes à la crème antirides et je croise un fer blanc.
Commentaire #126970 écrit par Aaargh!!! le 26/01/2014 à 10h29 | 👍🏽 👎🏽
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é ?
Commentaire #126972 écrit par Aaargh!!! le 26/01/2014 à 10h30 | 👍🏽 👎🏽
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.
Commentaire #126974 écrit par Aaargh!!! le 26/01/2014 à 10h32 | 👍🏽 👎🏽
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.
Commentaire #127017 écrit par ygnobl le 26/01/2014 à 12h21 | 👍🏽 👎🏽
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.
Commentaire #127249 écrit par shanathehutt le 27/01/2014 à 14h19 | 👍🏽 👎🏽
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.
Commentaire #127299 écrit par Cartman34 le 28/01/2014 à 07h31 | 👍🏽 👎🏽
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.
Commentaire #127966 écrit par MilkEnd le 01/02/2014 à 20h29 | 👍🏽 👎🏽