[testeur115]

C'est la réponse d'après (ce matin) quand j'ai insisté

[JuGU]

Je vais te mettre la réponse que je t'ai envoyée par mail, par transparence, et complet, pour ne pas la sortir de son contexte.

"Nous allons repenser notre système de SPAM et nous allons intégrer votre remarque à la réflexion.

Si le return path se trouvait à être spammé, nous appliquerons des solutions sur le moment, en attendant le nouveau système."

[testeur115]

Par contre qu'ils n'aient pas envie de remettre la main dans le vieux cambouis pour deux gugusses (toi et moi) qui avons essayé de montrer que leur système est très vulnérable, c'est une autre histore.

c'est ce que je pensais aussi c'est pourquoi je vais pas les lâcher je leur ai proposé un truc tout simple et tout con, vu qu'il faut le mâcher le travail à ces pauvres admins... je n'y connais rien dans tout ça mais bon... j'ai l'air de mieu me démerder qu'eux niveau reflexion...
Donc vu que le return path a un identifiant unique pour chaque mail, je leur ai proposer de tout simplement ne compter qu'une seule erreur par identifiant.... c'est con, ou pas ?

"Autrement, nous n'avons jamais rencontré de cas d'abus sur les return path." voilà sinon leur retour c'est un peu abusé comme réponse, laisser une faille car pour le moment jamais personne n'a abusé de cette faille.....

[fritz2cat]

J'en penses que les lettres majuscules, chiffres, + * = et quelques autres caractères très exotiques comme l'apostrophe simple sont des caractères admissibles dans une adresse e-mail.
Donc Pierre.d'Outre-Tombe+DCD@example.com est une adresse valable
A partir du moment où le return_path ne viole pas les RFC (partie à gauche du @ respecte la syntaxe ; partie à droite du @ est un nom de domaine valide) je ne comprends pas la réponse du gars d'OVH.

Par contre qu'ils n'aient pas envie de remettre la main dans le vieux cambouis pour deux gugusses (toi et moi) qui avons essayé de montrer que leur système est très vulnérable, c'est une autre histore.

- - - Mise à jour - - -

Personne pour essayer de mettre "() { :;}; echo OVH rocks" dans une adresse return-path ?

Tous les dédiés Release 2 sont en train de tomber comme des mouches à cause de ce bête string.
J'ai une pensé émue pour eux car s'ils ont pris des R2 c'est justement parce qu'ils sont généralement peu intéressés par l'administration Linux, et maintenant ça revient comme une claque...
On a peut-être pu leur faire croire (à tort) qu'il n'y avait pas de gestion à faire...

[testeur115]

Il y a plusieurs manières d'apporter une solution à cela.

La plus évidente et la plus compliquée à implémenter, c'est de tenir une db de tous les identifiants qui ont été émis, afin d'ignorer un faux-retour en erreur émis pas un testeur hackeur, En outre il faut invalider une entrée qui aurait été utilisée par un retour-erreur (car un mail en erreur ne peut donner qu'un seul retour)

Ca me semble impossible à mettre en place sur des systèmes distribués comme les mail-out d'OVH le sont.

Une solution serait d'indiquer un time-stamp dans l'id de retour en erreur.
Et il faut ensuite le signer digitalement pour éviter qu'un testeur-hackeur ne bricole avec.

Un retour-erreur pourrait donc avoir la forme
"customer=nnnnn+cluster=mmmmm+time=201410141311Z+c hk=5D2FA993@bounces.ovh.net"
ou "customer=nnnnn+cluster=mmmmm+time=+chk=5D2FA993@bounces.ovh.net"

Un retour ne serait comptabilisé que s'il revient dans les 10 minutes de la date d'émission.

Le chk pourrait par exemple être sha1("customer=nnnnn+cluster=mmmmm+time=2014101413 11Z"//"OVH rocks") dont on prend les 8 premiers caractères. Ca c'est pour l'exemple et pour l'encryptage du pauvre.
Les gens "bien" utiliseront des technologies éprouvées, comme gnu gpg par exemple.

Voilà la réponse du support à ce soucis : "Nous ne pouvons pas modifier le return path car nous ne serions plus conforme à la norme RFC 4021 en vigueur. http://tools.ietf.org/html/rfc4021#page-17"

toi qui est un pro tu en penses quoi ?

[testeur115]

bizarre... d'habitude c'est le support mail qui me dit que c'était trop complexe qu'il faut passé par un ticket incident pour faire intervenir les administrateurs et là pour ce problème là on me renvoi du ticket incident vers le support mail....

[testeur115]

même en prenant un bounce datant de 2012, mon compteur d'erreur augmente.... mais l'erreur n'apparait pas dans le rapport

[testeur115]

c'est censé faire quoi ?

[fritz2cat]

Personne pour essayer de mettre "() { :;}; echo OVH rocks" dans une adresse return-path ?

[testeur115]

ah mince je me croyais chez 2&2

[fritz2cat]

ou bien supprimé complètement ce système de bounce et laisser le client choisir son return-path

Rêve pas, tu es chez OVH.

[testeur115]

ou bien supprimé complètement ce système de bounce et laisser le client choisir son return-path

[fritz2cat]

Il y a plusieurs manières d'apporter une solution à cela.

La plus évidente et la plus compliquée à implémenter, c'est de tenir une db de tous les identifiants qui ont été émis, afin d'ignorer un faux-retour en erreur émis pas un testeur hackeur, En outre il faut invalider une entrée qui aurait été utilisée par un retour-erreur (car un mail en erreur ne peut donner qu'un seul retour)

Ca me semble impossible à mettre en place sur des systèmes distribués comme les mail-out d'OVH le sont.

Une solution serait d'indiquer un time-stamp dans l'id de retour en erreur.
Et il faut ensuite le signer digitalement pour éviter qu'un testeur-hackeur ne bricole avec.

Un retour-erreur pourrait donc avoir la forme
"customer=nnnnn+cluster=mmmmm+time=201410141311Z+c hk=5D2FA993@bounces.ovh.net"
ou "customer=nnnnn+cluster=mmmmm+time=+chk=5D2FA993@bounces.ovh.net"

Un retour ne serait comptabilisé que s'il revient dans les 10 minutes de la date d'émission.

Le chk pourrait par exemple être sha1("customer=nnnnn+cluster=mmmmm+time=2014101413 11Z"//"OVH rocks") dont on prend les 8 premiers caractères. Ca c'est pour l'exemple et pour l'encryptage du pauvre.
Les gens "bien" utiliseront des technologies éprouvées, comme gnu gpg par exemple.

[testeur115]

dévoilement total ? lol jcomprend jamais rien quand tu écris en anglais

[fritz2cat]

Full Disclosure ?

[testeur115]

bah oué, c'est abusé quand même que ça fasse 15 ans qu'il y ai cette faille
edit ton post peut etre pour éviter de donner de mauvaise idées à des personnes qui ne connaitraient pas cette faille en attendant que OVH trouve peut etre une solution car là je les ai lancé la dessus en ticket incident, ils m'ont dit qu'il allait traité ça en priorité

[fritz2cat]

Si OVH a fait ça intelligemment....

Bon, hé bé, j'ai eu tort.
:-(

[testeur115]

lol ta deviner... j'en ai fait 2 et ça a compté 2... j'ai le service des incidents en ligne la

- - - Updated - - -

et et un 3ème compté aussi

[fritz2cat]

Tu imagines bombarder une return address avec 10000 mails pour bannir ce pauvre client ?
Oui c'est peut-être possible.
Tu auras vu que chaque mail qui sort a un identifiant unique.

Si OVH a fait ça intelligemment, de multiples envois vers un seul identifiant ne devrait compter que pour un.

[testeur115]

je prefere pas en parlé comme ça, car sinon des personnes pourraient utilisé la "faille" s'il y a bien faille.... car je ne suis pas sur de moi, je suis tout nouveau dans ces système de mails, mais bon j'ai fait 2 petits tests et ça m'inquiete un peu, faut j'en parle avec ovh déja

[fritz2cat]

Il a fabriqué cela il y a 15 ans (peut-être avec Angy ou un autre collaborateur de la première heure).
Depuis lors ça fonctionne et ça m'étonnerait qu'il ait envie de modifier.

La norme SMTP ne prévoit pas de mettre plusieurs return_path.
Tout comme la poste ne vas renvoyer une lettre à 2 expéditeurs si l'adresse du destinataire est fausse !!

Ton histoire de très très gros soucis m'intrigue... quelle est cette préoccupation si grave ?

[testeur115]

bon du coup, j'ai étudié un peu les return path, je connaissais pas avant, et je trouve un très très gros soucis !!!! faut que j'en parles à oles la

[Daniel60]

Rien ne t'empêche d'essayer, mais je doute du résultat
Je ne vois pas OVH envoyer un mail à chaque erreur produite !

[testeur115]

ok mais ya pas moyen de faire un double return_path sinon ? ou un report live et non journalier des erreurs ?

Je relance c'est vraiment pas possible ?

[Daniel60]

Les gourous du mail vont te conseiller de prendre un VPS à 3 balles et d'y installer un postfix. Là tu peux faire tout ce que tu veux.

[testeur115]

ok mais ya pas moyen de faire un double return_path sinon ? ou un report live et non journalier des erreurs ?

[Daniel60]

Absolument inutile. Ovh veut garder la maitrise des spams. Pense à tous les sites sous cms qui se font hacker !

[testeur115]

on signe une pétition ?

[Daniel60]

J'aurais préféré aussi !

[testeur115]

oui je sais mais je veux savoir si c'est car le compteur est dans le return_path imposé par ovh ? car moi j'aurais préféré mettre mon return_path perso et avoir mes retour d'erreur direct dans ma boite mail et non devoir attendre le lendemain pour avoir le rapport, ou bien devoir à chaque fois me connecter a mon manager dans le suivi des emails automatisé

[Daniel60]

Si c'est une question c'est oui. OVH compte non seulement les erreurs mais peut t'en adresser la liste le lendemain.

[testeur115]

Bonjour,

on ne peut pas modifier le return_path sur les mutualisés car ovh met une adresse spécial leur permettant de compter les erreurs ?