J'espère effectivement que vous utilisez tous ces moyens pour assurer que votre réseau n'est pas utilisé pour nuire aux autres utilisateurs d'Internet. Pour le numéro 4 c'est assez simple; vous surveillez les status 451 dans les logs de vos serveurs SMTP sortants. Pour le numéro 1, vous demandez à vos clients, lors de l'établissement du contrat, s'ils souhaitent faire tourner un serveur SMTP sur leur machine. Si oui, votre serveur SMTP sortant refuse de relayer les messages depuis cet adresse (puisque vous ne voulez pas vous rendre complice d'éventuels problèmes de relayage multihop). Si non, vous fournissez les services IMAP/POP3 + relai SMTP, et vous bloquez le trafic sur le port 25 pour cet adresse. Et vous fournissez une procédure pour basculer entre ces deux modes.
En définitive, il suffit de faire comme la majorité des FAI dans les autres pays.
> Et donc il faut blacklister les serveurs qui ne font pas d'Open Relay ? C'est d'une stupidité affligeante de blacklister un serveur SMTP qui fait son boulot, à savoir relayer les courriers de ses abonnés.
j'ai l'impression que tu n'as pas compris ce qu'est du relayage multihop. Essaye de lire la deuxième référence attachée à l'article; elle en explique bien les principes.
Si le FAI n'accepte pas de faire smarthost pour un client qui souhaite faire tourner son propre serveur SMTP, le problème ne sera pas le même (c'est l'adresse IP du client qui sera blacklisté, plutôt que celui du serveur SMTP du FAI).
Si le FAI tient absolument à fournir le service smarthost à tout le monde (je ne vois pas quelle en serait l'utilité), il a une intervalle de temps entre l'envoi du message teste-mon-relai-ouvert par son client malveillant, et le moment ou un trusted user va venir faire le test; pendant cette période, il lui est possible de détecter le relai SMTP ouvert (certes à condition d'utiliser des tests actifs).
> Ou bien a demander que tous les FAI refusent les serveurs SMTP perso derrière leur ligne (comme cela se fait au canada). Mais ce n'est pas comme ca que Nerim voit Internet, moi non plus, ni même wanadoo d'ailleurs.
non, simplement demander que les FAI ne fassent pas smarthost pour leurs clients qui font tourner des serveurs SMTP. Ainsi, si un de leurs clients a un relai ouvert, le serveur SMTP du FAI ne sera pas boycotté puis dans une chaine de relayage multihop.
Wanadoo c'est toute une autre histoire; par exemple, ils n'acceptent pas les emails adressés à postmaster@<serveur-smtp-sortant>.wanadoo.fr, ce qui est strictement interdit par les RFCs.
> Comme le dit Raphaël (de Nerim), ils n'ont pas le droit de scanner les ports des machines à la recherche des personnes qui hébergent les serveurs SMTP (et c'est normal encore une fois).
c'est pas en scannant des ports qu'on détecte un relai SMTP ouvert, c'est en tentant d'envoyer en email qui devrait être refusé. S'il était précisé dans le document décrivant les Conditions de Service Nerim qu'ils utilisent ce type de technique pour détecter les problèmes de configuration des machines de leurs clients, qu'ils expliquent que c'est dans le but de limiter l'utilisation abusive de la bande passante de leur réseau par des utilisateurs malveillants, je crois que ça serait très bien compris par leurs clients.
D'ailleurs, il ne leur est même pas nécessaire de vérifier eux-mêmes la présence de relais SMTP ouverts, puisque des structures comme DSBL.org le font pour eux.
> Ne serait-il pas normal de prévenir abus@nerim.net avec le host temporaire du client et l'heure associée plutôt que de blacklister un relais de FAI ?
> N'importe quel client peut, volontairement ou non, ajouter les serveurs de son propre FAI à cette liste.
C'est faux: les listes de boycott list et multihop de la DSBL ne contiennent que des adresses IP qui ont été ajoutés par des sources fiables (les trusted users qui ont un compte chez DSBL). Le risque d'abus est donc très faible (et c'est pas ça qui pose problème chez Nerim -- ils permettent réellement à des relais SMTP ouverts sur leur réseau d'utiliser leur smarthost, donc ils ont un rôle actif dans un chemin potentiel d'émission de pourriels). C'est la liste unconfirmed qui contient les adresses IP soumis par n'importe qui, et cette liste n'est pas utilisée par le serveur du CULTe dont il est question ici.
Eric Marsden (l'un des administrateurs du serveur)
[^] # Re: Le serveur SMTP de Nerim blackliste.
Posté par Eric Marsden . En réponse à la dépêche Le serveur SMTP de Nerim blackliste.. Évalué à 1.
J'espère effectivement que vous utilisez tous ces moyens pour assurer que votre réseau n'est pas utilisé pour nuire aux autres utilisateurs d'Internet. Pour le numéro 4 c'est assez simple; vous surveillez les status 451 dans les logs de vos serveurs SMTP sortants. Pour le numéro 1, vous demandez à vos clients, lors de l'établissement du contrat, s'ils souhaitent faire tourner un serveur SMTP sur leur machine. Si oui, votre serveur SMTP sortant refuse de relayer les messages depuis cet adresse (puisque vous ne voulez pas vous rendre complice d'éventuels problèmes de relayage multihop). Si non, vous fournissez les services IMAP/POP3 + relai SMTP, et vous bloquez le trafic sur le port 25 pour cet adresse. Et vous fournissez une procédure pour basculer entre ces deux modes.
En définitive, il suffit de faire comme la majorité des FAI dans les autres pays.
[^] # Re: Le serveur SMTP de Nerim blackliste.
Posté par Eric Marsden . En réponse à la dépêche Le serveur SMTP de Nerim blackliste.. Évalué à 1.
j'ai l'impression que tu n'as pas compris ce qu'est du relayage multihop. Essaye de lire la deuxième référence attachée à l'article; elle en explique bien les principes.
[^] # Re: Le serveur SMTP de Nerim blackliste.
Posté par Eric Marsden . En réponse à la dépêche Le serveur SMTP de Nerim blackliste.. Évalué à 1.
Si le FAI tient absolument à fournir le service smarthost à tout le monde (je ne vois pas quelle en serait l'utilité), il a une intervalle de temps entre l'envoi du message teste-mon-relai-ouvert par son client malveillant, et le moment ou un trusted user va venir faire le test; pendant cette période, il lui est possible de détecter le relai SMTP ouvert (certes à condition d'utiliser des tests actifs).
[^] # Re: Le serveur SMTP de Nerim blackliste.
Posté par Eric Marsden . En réponse à la dépêche Le serveur SMTP de Nerim blackliste.. Évalué à 1.
non, simplement demander que les FAI ne fassent pas smarthost pour leurs clients qui font tourner des serveurs SMTP. Ainsi, si un de leurs clients a un relai ouvert, le serveur SMTP du FAI ne sera pas boycotté puis dans une chaine de relayage multihop.
Wanadoo c'est toute une autre histoire; par exemple, ils n'acceptent pas les emails adressés à postmaster@<serveur-smtp-sortant>.wanadoo.fr, ce qui est strictement interdit par les RFCs.
[^] # Re: Le serveur SMTP de Nerim blackliste.
Posté par Eric Marsden . En réponse à la dépêche Le serveur SMTP de Nerim blackliste.. Évalué à 1.
c'est pas en scannant des ports qu'on détecte un relai SMTP ouvert, c'est en tentant d'envoyer en email qui devrait être refusé. S'il était précisé dans le document décrivant les Conditions de Service Nerim qu'ils utilisent ce type de technique pour détecter les problèmes de configuration des machines de leurs clients, qu'ils expliquent que c'est dans le but de limiter l'utilisation abusive de la bande passante de leur réseau par des utilisateurs malveillants, je crois que ça serait très bien compris par leurs clients.
D'ailleurs, il ne leur est même pas nécessaire de vérifier eux-mêmes la présence de relais SMTP ouverts, puisque des structures comme DSBL.org le font pour eux.
> Ne serait-il pas normal de prévenir abus@nerim.net avec le host temporaire du client et l'heure associée plutôt que de blacklister un relais de FAI ?
La FAQ de la DSBL explique pourquoi ils ne le font pas: http://dsbl.org/faq-help.html(...)
Eric Marsden
[^] # Re: Le serveur SMTP de Nerim blackliste.
Posté par Eric Marsden . En réponse à la dépêche Le serveur SMTP de Nerim blackliste.. Évalué à 1.
C'est faux: les listes de boycott list et multihop de la DSBL ne contiennent que des adresses IP qui ont été ajoutés par des sources fiables (les trusted users qui ont un compte chez DSBL). Le risque d'abus est donc très faible (et c'est pas ça qui pose problème chez Nerim -- ils permettent réellement à des relais SMTP ouverts sur leur réseau d'utiliser leur smarthost, donc ils ont un rôle actif dans un chemin potentiel d'émission de pourriels). C'est la liste unconfirmed qui contient les adresses IP soumis par n'importe qui, et cette liste n'est pas utilisée par le serveur du CULTe dont il est question ici.
Eric Marsden (l'un des administrateurs du serveur)