ts wrote:
> Vous avez choisi d'embêter vos utilisateurs, vous pouvez utiliser SPF :-)

Pour résumer, le propriétaire d'un domaine a le droit de demander à ce
que son domaine ne soit pas utilisé en émission sur autre chose que son
serveur.

Xavier Roche a écrit :
> ts wrote:
>> Vous avez choisi d'embêter vos utilisateurs, vous pouvez utiliser SPF
>> :-)
>
> Pour résumer, le propriétaire d'un domaine a le droit de demander à ce
> que son domaine ne soit pas utilisé en émission sur autre chose que son
> serveur.

Ts,

Je pense que nous n'avons pas la même utilisation du serveur smtp :

- Vous, vous mettez un outil en place permettant à des utilisateurs
(chercheurs ?) la possibilité de travailler à l'INRA de la même manière
que depuis chez eux ... vos règles doivent donc être 'un peu plus' laxistes.

- Nous nous mettons 'une adresse mail professionnelle' de notre domaine
à disposition des utilisateurs ... l'utilisation d'un autre domaine
expéditeur à partir de notre serveur SMTP n'a pas lieu d'être.

Samuel.

>>>>> "X" == Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:

X> Pour résumer, le propriétaire d'un domaine a le droit de demander à ce
X> que son domaine ne soit pas utilisé en émission sur autre chose que son
X> serveur.

Dans ce cas pouvez vous m'expliquer pourquoi la majorité des
enregistrements SPF ont un "softfail" ?

Gentils les propriètaires de hotmail (c'est un exemple) d'exercer son
droit mais il pourrait aussi assumer et surtout faire le ménage parmi ces
utilisateurs.

--

Guy Decoux

ts wrote:
> Dans ce cas pouvez vous m'expliquer pourquoi la majorité des
> enregistrements SPF ont un "softfail" ?

Justement pour permettre aux admins de ne PAS interdire une utilisation
exterieure.

On peut aussi (+all) autoriser le domaine à être utilisé depuis
n'importe où.

Bref tout est possible avec SPF ; ce n'est pas un système restrictif,
mais un système de contrôle (avec restrictions ou au contraire autorisation)

Xavier Roche <xroche@free.fr.NOSPAM.invalid> écrivait:

> Encore une fois, c'est une décision du gestionnaire du domaine, pas de
> celui qui filtre.
>
> AInsi les utilisateurs ayant des problèmes de mails rejetés par SPF ne
> suivent simplement pas l'utilisation qui est imposée (policy) par le
> gestionnaire du domaine au dessus. A charge pour eux:
> - d'en informer leur postmaster
> - de changer de méthode (utiliser les MX de son FAI)
>
> Mais en aucun cas le problème ne vient de celui qui *applique* cette
> "policy"

Mais si. Car c'est lui qui envoie à la poubelle le .forward qu'a mis
le destinataire conformément à ce qu'il avait le droit de faire.

--
Si vous embauchez, voici mon CV
http://www.rail.eu.org/cv/cv.pdf

Erwan David wrote:
> Mais si. Car c'est lui qui envoie à la poubelle le .forward qu'a mis
> le destinataire conformément à ce qu'il avait le droit de faire.

Pas si le gestionnaire du domaine en a décidé autrement, encore une
fois. (la policy est appliquée sur le return-path)

Xavier Roche <xroche@free.fr.NOSPAM.invalid> écrivait:

> Erwan David wrote:
>> Mais si. Car c'est lui qui envoie à la poubelle le .forward qu'a mis
>> le destinataire conformément à ce qu'il avait le droit de faire.
>
> Pas si le gestionnaire du domaine en a décidé autrement, encore une
> fois. (la policy est appliquée sur le return-path)

A envoie B qui forwarde sur C.

A utilise son adresse, B a le droit de forwarder, et C fout le mail à
la poubelle.

De quoi B est-il coupable ?

--
Si vous embauchez, voici mon CV
http://www.rail.eu.org/cv/cv.pdf

Xavier Roche <xroche@free.fr.NOSPAM.invalid> écrivait:

> Erwan David wrote:
>> Mais si. Car c'est lui qui envoie à la poubelle le .forward qu'a mis
>> le destinataire conformément à ce qu'il avait le droit de faire.
>
> Pas si le gestionnaire du domaine en a décidé autrement, encore une
> fois. (la policy est appliquée sur le return-path)

A envoie B qui forwarde sur C.

A utilise son adresse, B a le droit de forwarder, et C fout le mail à
la poubelle.

De quoi B est-il coupable ?

--
Si vous embauchez, voici mon CV
http://www.rail.eu.org/cv/cv.pdf

Erwan David wrote:
> A utilise son adresse, B a le droit de forwarder, et C fout le mail à
> la poubelle.
> De quoi B est-il coupable ?

D'avoir utilisé un return-path ne lui appartenant pas (relais).
Mais je suis d'accord que c'est un cas (enfin, le cas) chiant avec SPF.

Erwan David wrote:
> A utilise son adresse, B a le droit de forwarder, et C fout le mail à
> la poubelle.
> De quoi B est-il coupable ?

D'avoir utilisé un return-path ne lui appartenant pas (relais).
Mais je suis d'accord que c'est un cas (enfin, le cas) chiant avec SPF.

ts wrote:
> Je l'ai déjà dit, je ne vous fait pas confiance et ce n'est pas vous qui me
> direz ce que je suis autorisé à accepter ou refuser.

Personnellement je suis d'accord sur le "que je suis autorisé à
accepter", mais pas sur "que je suis autorisé à refuser".

Un domaine X qui me dit "je n'envoi jamais de mail autrement que via tel
serveur", si le serveur en question est pas reconnu, je refuse.

Ce qui ne m'empêche pas de continuer les tests après ça (spamassassin,
etc) et donc ne pas "accepter" directement même si SPF laisse passer.

Xavier Roche <xroche@free.fr.NOSPAM.invalid> écrivait:

> Erwan David wrote:
>> A utilise son adresse, B a le droit de forwarder, et C fout le mail à
>> la poubelle.
>> De quoi B est-il coupable ?
>
> D'avoir utilisé un return-path ne lui appartenant pas (relais).
> Mais je suis d'accord que c'est un cas (enfin, le cas) chiant avec SPF.

C'est le moyen *normal* d'utiliser le .forward, pour que l'expéditeur
soit prévenu en cas de problème.

--
Si vous embauchez, voici mon CV
http://www.rail.eu.org/cv/cv.pdf

>>>>> "X" == Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:

X> Un domaine X qui me dit "je n'envoi jamais de mail autrement que via tel
X> serveur", si le serveur en question est pas reconnu, je refuse.

Encore faut il lui faire confiance : je ne dirais pas que le DNS est
particulièrement fiable.

Personne n'a encore essayé de mettre un serveur en liste noire, en
changeant ses enregistrements DNS ?


--

Guy Decoux

ts wrote:
> Encore faut il lui faire confiance : je ne dirais pas que le DNS est
> particulièrement fiable.

Ah ? Je vois pas comment spoofer un serveur déclaré comme root server
sur la registry ; sauf à attaquer un serveur non autoritaire en dessous
(mais dans ce cas on peut faire des choses beaucoup plus marrantes :p)

> Personne n'a encore essayé de mettre un serveur en liste noire, en
> changeant ses enregistrements DNS ?

Ben cela perturbera *son* réseau, c'est tout

ts wrote:
> Encore faut il lui faire confiance : je ne dirais pas que le DNS est
> particulièrement fiable.

Ah ? Je vois pas comment spoofer un serveur déclaré comme root server
sur la registry ; sauf à attaquer un serveur non autoritaire en dessous
(mais dans ce cas on peut faire des choses beaucoup plus marrantes :p)

> Personne n'a encore essayé de mettre un serveur en liste noire, en
> changeant ses enregistrements DNS ?

Ben cela perturbera *son* réseau, c'est tout