Ca y'est ... mon provider s'y est mis aussi :-( désormais le port 25
est bloqué pour tout autre serveur mail :-(
dès lors se pose un
problème dans gnus : comment puis-je faire que gnus essaie plusieurs
serveur avant d'abandonner ? vu que j'accède à internet par plusieurs
providers , je ne sais pas faire autrement :-( ou alors y a-t-il un
moyen de configurer le serveur smtp en fonction d'une var qui
indiquerait le provider utilisé ? et quelle serait cette var ?
Ca y'est ... mon provider s'y est mis aussi :-( désormais le port 25
est bloqué pour tout autre serveur mail :-(
dès lors se pose un
problème dans gnus : comment puis-je faire que gnus essaie plusieurs
serveur avant d'abandonner ? vu que j'accède à internet par plusieurs
providers , je ne sais pas faire autrement :-( ou alors y a-t-il un
moyen de configurer le serveur smtp en fonction d'une var qui
indiquerait le provider utilisé ? et quelle serait cette var ?
Ca y'est ... mon provider s'y est mis aussi :-( désormais le port 25
est bloqué pour tout autre serveur mail :-(
dès lors se pose un
problème dans gnus : comment puis-je faire que gnus essaie plusieurs
serveur avant d'abandonner ? vu que j'accède à internet par plusieurs
providers , je ne sais pas faire autrement :-( ou alors y a-t-il un
moyen de configurer le serveur smtp en fonction d'une var qui
indiquerait le provider utilisé ? et quelle serait cette var ?
"sk" == Sébastien Kirche writes:
"ef" == Flatman writes:
"sk" == Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
"ef" == Flatman <flatman@swing.be> writes:
"sk" == Sébastien Kirche writes:
"ef" == Flatman writes:
Bof , c'est pas vraiment ce que cherche ...
Bof , c'est pas vraiment ce que cherche ...
Bof , c'est pas vraiment ce que cherche ...
sk> Aïe. Mauvais FAI, changer FAI ?
au contraire, si on regarde la quantité de pourriels qui proviennent
de machines en ADSL résidentiel (infectées par des virus etc.), je
pense que c'est un système qui devrait être généralisé. </hors-sujet>
ef> je voudrais néanmoins savoir si le script Perl pourrait être écrit
ef> en EmacsLisp ? J'avais essayé avec (shell-command-to-string) ou un
ef> truc comme cela , mais là Emacs se met à attendre que traceroute à
ef> complètement terminé son truc et ça prend un temps dingue :-(
le mécanisme des « process filter » intégré à Emacs permet de
traiter la sortie d'un programme externe de façon asynchrone (au fur
et mesure que le programme génère des résultats). Voici une
illustration:
(defun ecm-guess-network-process-filter (process output)
(cond ((string-match ".routers.proxad.net" output)
(setq smtpmail-smtp-server "smtp.free.fr")
(kill-buffer (process-buffer process))
(kill-process process))
((string-match ".cssi.renater.fr" output)
(setq smtpmail-smtp-server "mail.enseeiht.fr")
(kill-buffer (process-buffer process))
(kill-process process))))
(defun ecm-guess-network () (let* ((output (get-buffer-create "
*traceroute*")) (process (start-process "traceroute" output
"traceroute" "www.apple.com"))) (set-process-filter process
'ecm-guess-network-process-filter)))
sk> Aïe. Mauvais FAI, changer FAI ?
au contraire, si on regarde la quantité de pourriels qui proviennent
de machines en ADSL résidentiel (infectées par des virus etc.), je
pense que c'est un système qui devrait être généralisé. </hors-sujet>
ef> je voudrais néanmoins savoir si le script Perl pourrait être écrit
ef> en EmacsLisp ? J'avais essayé avec (shell-command-to-string) ou un
ef> truc comme cela , mais là Emacs se met à attendre que traceroute à
ef> complètement terminé son truc et ça prend un temps dingue :-(
le mécanisme des « process filter » intégré à Emacs permet de
traiter la sortie d'un programme externe de façon asynchrone (au fur
et mesure que le programme génère des résultats). Voici une
illustration:
(defun ecm-guess-network-process-filter (process output)
(cond ((string-match "\.routers\.proxad\.net" output)
(setq smtpmail-smtp-server "smtp.free.fr")
(kill-buffer (process-buffer process))
(kill-process process))
((string-match "\.cssi\.renater\.fr" output)
(setq smtpmail-smtp-server "mail.enseeiht.fr")
(kill-buffer (process-buffer process))
(kill-process process))))
(defun ecm-guess-network () (let* ((output (get-buffer-create "
*traceroute*")) (process (start-process "traceroute" output
"traceroute" "www.apple.com"))) (set-process-filter process
'ecm-guess-network-process-filter)))
sk> Aïe. Mauvais FAI, changer FAI ?
au contraire, si on regarde la quantité de pourriels qui proviennent
de machines en ADSL résidentiel (infectées par des virus etc.), je
pense que c'est un système qui devrait être généralisé. </hors-sujet>
ef> je voudrais néanmoins savoir si le script Perl pourrait être écrit
ef> en EmacsLisp ? J'avais essayé avec (shell-command-to-string) ou un
ef> truc comme cela , mais là Emacs se met à attendre que traceroute à
ef> complètement terminé son truc et ça prend un temps dingue :-(
le mécanisme des « process filter » intégré à Emacs permet de
traiter la sortie d'un programme externe de façon asynchrone (au fur
et mesure que le programme génère des résultats). Voici une
illustration:
(defun ecm-guess-network-process-filter (process output)
(cond ((string-match ".routers.proxad.net" output)
(setq smtpmail-smtp-server "smtp.free.fr")
(kill-buffer (process-buffer process))
(kill-process process))
((string-match ".cssi.renater.fr" output)
(setq smtpmail-smtp-server "mail.enseeiht.fr")
(kill-buffer (process-buffer process))
(kill-process process))))
(defun ecm-guess-network () (let* ((output (get-buffer-create "
*traceroute*")) (process (start-process "traceroute" output
"traceroute" "www.apple.com"))) (set-process-filter process
'ecm-guess-network-process-filter)))
Une solution simple serait de fournir le service smtp et de bloquer *par
défaut* le port smtp sortant vers ailleurs que le serveur du fournisseur
mais de pouvoir l'ouvrir *sur demande*. Àma, un client qui est capable
de formuler cette demande (soit sans doute moins de 1% de la clientèle)
est capable d'avoir un smtp qui ne soit pas un relais ouvert, ni un nid
à virus.
Une solution simple serait de fournir le service smtp et de bloquer *par
défaut* le port smtp sortant vers ailleurs que le serveur du fournisseur
mais de pouvoir l'ouvrir *sur demande*. Àma, un client qui est capable
de formuler cette demande (soit sans doute moins de 1% de la clientèle)
est capable d'avoir un smtp qui ne soit pas un relais ouvert, ni un nid
à virus.
Une solution simple serait de fournir le service smtp et de bloquer *par
défaut* le port smtp sortant vers ailleurs que le serveur du fournisseur
mais de pouvoir l'ouvrir *sur demande*. Àma, un client qui est capable
de formuler cette demande (soit sans doute moins de 1% de la clientèle)
est capable d'avoir un smtp qui ne soit pas un relais ouvert, ni un nid
à virus.
"sk" == Sébastien Kirche writes:
"ef" == Flatman writes:
sk> Aïe. Mauvais FAI, changer FAI ?
au contraire, si on regarde la quantité de pourriels qui proviennent
de machines en ADSL résidentiel (infectées par des virus etc.), je
pense que c'est un système qui devrait être généralisé. </hors-sujet>
"sk" == Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
"ef" == Flatman <flatman@swing.be> writes:
sk> Aïe. Mauvais FAI, changer FAI ?
au contraire, si on regarde la quantité de pourriels qui proviennent
de machines en ADSL résidentiel (infectées par des virus etc.), je
pense que c'est un système qui devrait être généralisé. </hors-sujet>
"sk" == Sébastien Kirche writes:
"ef" == Flatman writes:
sk> Aïe. Mauvais FAI, changer FAI ?
au contraire, si on regarde la quantité de pourriels qui proviennent
de machines en ADSL résidentiel (infectées par des virus etc.), je
pense que c'est un système qui devrait être généralisé. </hors-sujet>
N'importe quoi, tu fais quoi des boites sur xDSL ? Le problème est
dans les merdes zombifiées, toutes sous OS microsoft. Une solution
nettement plus efficace serait d'interdire de se conencter à internet
depuis un windows.
N'importe quoi, tu fais quoi des boites sur xDSL ? Le problème est
dans les merdes zombifiées, toutes sous OS microsoft. Une solution
nettement plus efficace serait d'interdire de se conencter à internet
depuis un windows.
N'importe quoi, tu fais quoi des boites sur xDSL ? Le problème est
dans les merdes zombifiées, toutes sous OS microsoft. Une solution
nettement plus efficace serait d'interdire de se conencter à internet
depuis un windows.
Quand bien même... il suffit alors de les monitorer un peu et de les
fermer sans préavis au cas où l'admin amateur ne serait pas à la
hauteur... la méthode me plaît bien.
Mais cela suppose quand même une bonne équipe côté FAI et je ne suis
pas persuadé qu'ils en aient tous une :)
Quand bien même... il suffit alors de les monitorer un peu et de les
fermer sans préavis au cas où l'admin amateur ne serait pas à la
hauteur... la méthode me plaît bien.
Mais cela suppose quand même une bonne équipe côté FAI et je ne suis
pas persuadé qu'ils en aient tous une :)
Quand bien même... il suffit alors de les monitorer un peu et de les
fermer sans préavis au cas où l'admin amateur ne serait pas à la
hauteur... la méthode me plaît bien.
Mais cela suppose quand même une bonne équipe côté FAI et je ne suis
pas persuadé qu'ils en aient tous une :)
Erwan David writes:N'importe quoi, tu fais quoi des boites sur xDSL ? Le problème est
dans les merdes zombifiées, toutes sous OS microsoft. Une solution
nettement plus efficace serait d'interdire de se conencter à internet
depuis un windows.
Efficace pour se saborder, oui.
Erwan David writes:
N'importe quoi, tu fais quoi des boites sur xDSL ? Le problème est
dans les merdes zombifiées, toutes sous OS microsoft. Une solution
nettement plus efficace serait d'interdire de se conencter à internet
depuis un windows.
Efficace pour se saborder, oui.
Erwan David writes:N'importe quoi, tu fais quoi des boites sur xDSL ? Le problème est
dans les merdes zombifiées, toutes sous OS microsoft. Une solution
nettement plus efficace serait d'interdire de se conencter à internet
depuis un windows.
Efficace pour se saborder, oui.
