Salut,

> Reverse DNS :
> C'est la base d'en avoir un (donc bannir ceux qui n'en présentent pas) ,
> mais baser une vérification dessus (genre HELO = reverse), c'est juste
> aller au casse pipe.

Non je ne suis pas d'accord.  D'ailleurs même google impose un reverse DNS en 
IPv6 si tu veux causer avec eux.
Donc, ca permet aux "gens" de se responsabiliser.

> RBL (les listes étant nombreuses) :
> Particulièrement efficace, à utiliser selon le contexte, si par exemple
> on ne veut pas que des personnes/entreprises qui hébergent leur propre
> serveur mail derrière une connexion résidentielle passent à la trappe
> (cas fréquemment rencontré).

Les RBL -> Out, c'est n'importe quoi, trop de faux positifs.
A utiliser dans Spam Assassin et polcyweight.

> SPF :
> Plutôt sympa dans le principe, si tant que les DNS des domaines
> expéditeurs soient correctement configurés.

Ca fait plus de bien que de mal.

> Amavis (couplé à clamav, spamassassin, ou autre)
> Trop rien à redire, et très rares ont été les faux-positifs dans ce cas.

Idem.

> 
> Vérifications sur les champs From et le return-path des e-mails recus :
> Sur le From , ca fonctionne plutôt bien.
> Sur le return-path c'est à utiliser avec prudence.
> 
> Si je prend un exemple récent : Si vous êtes client OVH et que vous
> faites cette vérification , ca donne lieu à certaines déconvenues .
>> From: supp...@ovh.com
>> Return path: xxx-...@nichandle.ovh.net
> (nichandle.ovh.net n'est pas en mesure de recevoir de mails ... et donc
> impossible de vérifier que le return-path est correct)

Effectivement trop dangereux. Sans compter les ml.

> 
> DKIM et DMARC :
> Gros sujet de polémique ces derniers temps, particulièrement en ce qui
> concerne les messages en provenance des mailing lists : les entêtes et
> contenus étant la majorité du temps modifiés au cours du transit par le
> moteur de ML.

Je sens que ca va être le standard.
DKIM est déjà méga facile a implémenter avec amavisd-new.
Quand a DMARC... Wait & see pour ma part.

> Sender ID:
> Existe t'il des implémentations libres à ce sujet ?

Hein ? :)

> Greylist :
> Sympa aussi dans le principe et particulièrement efficace, mais
> susceptible d'apporter d'autres soucis, si on est, dans l'urgence, en
> attente d'un mail envoyé par un client alors qu'on est au téléphone avec
> ce dernier (ou inversement).
> (jusqu'à présent, j'ai fait sans, mais je vois bien ce qu'il se passe
> dans le `postqueue -p̀  quand on envoie ... ).

Alors dans les postfix récents il y a un postcreen. Ca marche très bien. 
Beaucoup mieux que du greylisting que j'ai pour ma part simplement dégagé car 
... Trop des gens pensent que le mail est une messagerie instantanée...


> Je suis bien conscient que tout ceci est question de compromis, et de
> contexte.
> 
> J'aimerais toutefois avoir vos avis, sur ce qui selon vous est une
> configuration "acceptable" à l'heure actuelle.

Done.

> D'un point de vue légal (moins simple) :
> 
> Si tant est qu'une adresse mail qui reçoit du spam n'a été inscrite que
> sur un seul et unique service sur un nom de domaine "privé", (à
> comprendre, pas du gmail, ou tout autre service ouvert au public),
> est-on en mesure de porter plainte contre le service concerné pour
> "fuite/revente d'informations" et/ou "atteinte à la vie privée" ?
> 

Je suis pour le mail jetable. Donc pour des gens comme sncf / edf / gdf / .. 
ils ont le droit a leur mail personnalisé.

Si jamais je reçois la moindre saloperie (c'est arrivé une fois pour ma part), 
un certain mail + spam au tel leur a bien fait comprendre que au second mails 
de pub, il avaient droit a une plainte à la CNIL...

Après, déjà : ne pas ecrire dans une mailing liste archivée en public permet de 
régler le pb.

Autre détail : les auto-respondeur = a proscrire... C'est extrêmement dangereux 
et aident les spammeurs a tester si les mails existent. Sans compter le social 
engineering qui peux en découdre...

Xavier

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

Répondre à