Bonsoir,
ce n'est pas un probl=E8me 100% emacs, mais peut-=EAtre avez-vous une
id=E9e.
J'avais un probl=E8me avec sendmail qui marchait sans arr=EAt et occupait
toute ma m=E9moire vive.
J'ai donc tout enlev=E9 et r=E9-install=E9.... et =E7a ne marche plus.
Je peux envoyer des courriers, fetchmail les t=E9l=E9charge mais j'ai =E7a =
=E0
la fin
fetchmail: 6.3.2 interroge pop.free.fr (protocole POP3) =E0 mer 21 f=E9v
2007 20:21:48 CET : r=E9cup=E9ration en cours
fetchmail: POP3< +OK <941.1172085708@pop4-g25.free.fr>
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR authorization first
fetchmail: authorization first
fetchmail: Re-r=E9cup=E9ration imm=E9diate sur gconnan@pop.free.fr
fetchmail: POP3< +OK <19118.1172085708@pop5-g25.free.fr>
fetchmail: POP3> USER gconnan
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK
fetchmail: POP3> STAT
fetchmail: POP3< +OK 193 9487987
fetchmail: POP3> LAST
fetchmail: POP3< +OK 0
193 messages pour gconnan dans pop.free.fr (9487987 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 3095
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 3095 octets
lecture du message gconnan@pop.free.fr:1 parmi 193 (3095 octets)
fetchmail: =C9chec de connexion SMTP avec localhost
fetchmail: POP3> QUIT
fetchmail: POP3<
fetchmail: erreur Transaction SMTP durant la r=E9ception de
gconnan@pop.free.fr et l'envoi vers le serveur SMTP localhost
fetchmail: 6.3.2 interroge pop.free.fr (protocole POP3) =E0 mer 21 f=E9v
2007 20:21:49 CET : interrogation finie
fetchmail: =C9tat de la requ=EAte=3D10 (SMTP)
fetchmail: terminaison normale, =E9tat 10
et mon fetchmailrc
# G=E9n=E9ral
# set syslog
set bouncemail
set no spambounce
set properties ""
poll pop.free.fr with proto POP3
user gconnan there with password ** is moi-bur here
options keep
et mon procmailrc
PATH=3D/usr/bin:/bin:/usr/local/bin:.
MAILDIR=3D/home/moi/.mail-gnus # You'd better make sure it exists
DEFAULT=3D$MAILDIR/inbox
LOGFILE=3D/home/moi/.from_procmail
LOCKFILE=3D/home/moi/.lockmail
SHELL=3D/bin/sh
# Tous les autres courriers iront dans $DEFAULT,
# c'est-=E0-dire inbox.
Et comme c'est une liste de méthodes, ce serait plutôt (setq gnus-secondary-select-methods '((nntp "news.free.fr")))
Arg... Trop bête : merci S?bastien (car c'est comme ça que tu apparaîs dans le buffer summary) J'ai remarqué depuis qu'un autre buffer a un encodage bizarre : le shell (obtenu avec M-!), mais là ce n'est pas seulement des ? à la place des lettres accentuées, mais les trucs bizarres genre utf8. Il n'y a pas unicité de l'encodage des buffers ?
-- Guillaume Connan
http://gconnan.free.fr
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> vient d'envoyer ce message :
Et comme c'est une liste de méthodes, ce serait plutôt
(setq gnus-secondary-select-methods '((nntp "news.free.fr")))
Arg... Trop bête : merci S?bastien (car c'est comme ça que tu
apparaîs dans le buffer summary)
J'ai remarqué depuis qu'un autre buffer a un encodage bizarre : le
shell (obtenu avec M-!), mais là ce n'est pas seulement des ? à
la place des lettres accentuées, mais les trucs bizarres genre
utf8.
Il n'y a pas unicité de l'encodage des buffers ?
Et comme c'est une liste de méthodes, ce serait plutôt (setq gnus-secondary-select-methods '((nntp "news.free.fr")))
Arg... Trop bête : merci S?bastien (car c'est comme ça que tu apparaîs dans le buffer summary) J'ai remarqué depuis qu'un autre buffer a un encodage bizarre : le shell (obtenu avec M-!), mais là ce n'est pas seulement des ? à la place des lettres accentuées, mais les trucs bizarres genre utf8. Il n'y a pas unicité de l'encodage des buffers ?
-- Guillaume Connan
http://gconnan.free.fr
Sébastien Kirche
Le 22 février 2007 à 13:18, Guillaume Connan s'est exprimé ainsi :
Sébastien Kirche vient d'envoyer ce message :
> Et comme c'est une liste de méthodes, ce serait plutôt > (setq gnus-secondary-select-methods '((nntp "news.free.fr")))
Arg... Trop bête : merci S?bastien (car c'est comme ça que tu apparaîs dans le buffer summary)
:)
J'ai remarqué depuis qu'un autre buffer a un encodage bizarre : le shell (obtenu avec M-!), mais là ce n'est pas seulement des ? à la place des lettres accentuées, mais les trucs bizarres genre utf8. Il n'y a pas unicité de l'encodage des buffers ?
De façon générale, si avec set-language-environment ou prefer-coding-system mais ensuite tu peux avoir un hook ou un mode qui peut changer l'encodage général pour un autre dans un buffer. Comme nxml qui change l'encodage en fonction de l'entête d'un fichier xml.
Peut-être que M-x describe-coding-system RET RET pourra t'apporter quelques infos ? -- Sébastien Kirche
Le 22 février 2007 à 13:18, Guillaume Connan s'est exprimé ainsi :
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> vient
d'envoyer ce message :
> Et comme c'est une liste de méthodes, ce serait plutôt
> (setq gnus-secondary-select-methods '((nntp "news.free.fr")))
Arg... Trop bête : merci S?bastien (car c'est comme ça que tu
apparaîs dans le buffer summary)
:)
J'ai remarqué depuis qu'un autre buffer a un encodage bizarre : le
shell (obtenu avec M-!), mais là ce n'est pas seulement des ? à
la place des lettres accentuées, mais les trucs bizarres genre
utf8.
Il n'y a pas unicité de l'encodage des buffers ?
De façon générale, si avec set-language-environment ou
prefer-coding-system mais ensuite tu peux avoir un hook ou un mode qui
peut changer l'encodage général pour un autre dans un buffer. Comme nxml
qui change l'encodage en fonction de l'entête d'un fichier xml.
Peut-être que M-x describe-coding-system RET RET pourra t'apporter
quelques infos ?
--
Sébastien Kirche
Le 22 février 2007 à 13:18, Guillaume Connan s'est exprimé ainsi :
Sébastien Kirche vient d'envoyer ce message :
> Et comme c'est une liste de méthodes, ce serait plutôt > (setq gnus-secondary-select-methods '((nntp "news.free.fr")))
Arg... Trop bête : merci S?bastien (car c'est comme ça que tu apparaîs dans le buffer summary)
:)
J'ai remarqué depuis qu'un autre buffer a un encodage bizarre : le shell (obtenu avec M-!), mais là ce n'est pas seulement des ? à la place des lettres accentuées, mais les trucs bizarres genre utf8. Il n'y a pas unicité de l'encodage des buffers ?
De façon générale, si avec set-language-environment ou prefer-coding-system mais ensuite tu peux avoir un hook ou un mode qui peut changer l'encodage général pour un autre dans un buffer. Comme nxml qui change l'encodage en fonction de l'entête d'un fichier xml.
Peut-être que M-x describe-coding-system RET RET pourra t'apporter quelques infos ? -- Sébastien Kirche
Guillaume Connan
Sébastien Kirche vient d'envoyer ce message :
Peut-être que M-x describe-coding-system RET RET pourra t'apporter quelques infos ?
Apparemment, c'est normal ?
Coding system for saving this buffer: = -- binary (alias of no-conversion) Default coding system (for new files): u -- mule-utf-8 (alias: utf-8) Coding system for keyboard input: nil Coding system for terminal output: nil Defaults for subprocess I/O: decoding: u -- mule-utf-8 (alias: utf-8) encoding: u -- mule-utf-8 (alias: utf-8)
Other coding systems cannot be distinguished automatically from these, and therefore cannot be recognized automatically with the present coding system priorities.
The followings are decoded correctly but recognized as iso-2022-7bit-lock: iso-2022-7bit-ss2 iso-2022-7bit-lock-ss2 iso-2022-cn iso-2022-cn-ext iso-2022-jp-2 iso-2022-kr
Particular coding systems specified for certain file names:
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> vient d'envoyer ce message :
Peut-être que M-x describe-coding-system RET RET pourra t'apporter
quelques infos ?
Apparemment, c'est normal ?
Coding system for saving this buffer:
= -- binary (alias of no-conversion)
Default coding system (for new files):
u -- mule-utf-8 (alias: utf-8)
Coding system for keyboard input:
nil
Coding system for terminal output:
nil
Defaults for subprocess I/O:
decoding: u -- mule-utf-8 (alias: utf-8)
encoding: u -- mule-utf-8 (alias: utf-8)
Other coding systems cannot be distinguished automatically
from these, and therefore cannot be recognized automatically
with the present coding system priorities.
The followings are decoded correctly but recognized as iso-2022-7bit-lock:
iso-2022-7bit-ss2 iso-2022-7bit-lock-ss2 iso-2022-cn iso-2022-cn-ext iso-2022-jp-2 iso-2022-kr
Particular coding systems specified for certain file names:
Peut-être que M-x describe-coding-system RET RET pourra t'apporter quelques infos ?
Apparemment, c'est normal ?
Coding system for saving this buffer: = -- binary (alias of no-conversion) Default coding system (for new files): u -- mule-utf-8 (alias: utf-8) Coding system for keyboard input: nil Coding system for terminal output: nil Defaults for subprocess I/O: decoding: u -- mule-utf-8 (alias: utf-8) encoding: u -- mule-utf-8 (alias: utf-8)
Other coding systems cannot be distinguished automatically from these, and therefore cannot be recognized automatically with the present coding system priorities.
The followings are decoded correctly but recognized as iso-2022-7bit-lock: iso-2022-7bit-ss2 iso-2022-7bit-lock-ss2 iso-2022-cn iso-2022-cn-ext iso-2022-jp-2 iso-2022-kr
Particular coding systems specified for certain file names:
Coding system for saving this buffer: Not set locally, use the default. Default coding system (for new files): 0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0) Coding system for keyboard input: 0 -- latin-9 (alias of iso-latin-9) Coding system for terminal output: 0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0) Defaults for subprocess I/O: decoding: 0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0) encoding: 0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0)
Priority order for recognizing coding systems when reading files: 1. iso-latin-9 (alias: iso-8859-15 latin-9 latin-0) 2. iso-latin-1 (alias: iso-8859-1 latin-1)
Mais utf8 n'apparaît plus dans cette liste : comment le mettre en 3eme choix ?
-- Guillaume Connan
http://gconnan.free.fr
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> vient d'envoyer ce message :
Coding system for saving this buffer:
= -- binary (alias of no-conversion)
C'était le buffer contenant le summary ?
En fait, j'avais ça dans summary :
Coding system for saving this buffer:
Not set locally, use the default.
Default coding system (for new files):
u -- mule-utf-8 (alias: utf-8)
Donc, tu es en utf-8 sur ton système et pour tous les nouveaux documents
sauf contre-ordre.
Coding system for saving this buffer:
Not set locally, use the default.
Default coding system (for new files):
0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0)
Coding system for keyboard input:
0 -- latin-9 (alias of iso-latin-9)
Coding system for terminal output:
0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0)
Defaults for subprocess I/O:
decoding: 0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0)
encoding: 0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0)
Priority order for recognizing coding systems when reading files:
1. iso-latin-9 (alias: iso-8859-15 latin-9 latin-0)
2. iso-latin-1 (alias: iso-8859-1 latin-1)
Mais utf8 n'apparaît plus dans cette liste : comment le mettre en
3eme choix ?
Coding system for saving this buffer: Not set locally, use the default. Default coding system (for new files): 0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0) Coding system for keyboard input: 0 -- latin-9 (alias of iso-latin-9) Coding system for terminal output: 0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0) Defaults for subprocess I/O: decoding: 0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0) encoding: 0 -- iso-latin-9 (alias: iso-8859-15 latin-9 latin-0)
Priority order for recognizing coding systems when reading files: 1. iso-latin-9 (alias: iso-8859-15 latin-9 latin-0) 2. iso-latin-1 (alias: iso-8859-1 latin-1)
Mais utf8 n'apparaît plus dans cette liste : comment le mettre en 3eme choix ?
-- Guillaume Connan
http://gconnan.free.fr
Benoit Izac
Bonjour,
le 22/02/2007 à 11:50, Sébastien Kirche a écrit dans le message :
La solution de Sébastien c'est : 1) fetchmail récupère le message sur le serveur POP 2) fetchmail le passe à un MDA
Tu devrais vraiment lire la page man de fetchmail avant de faire ça en particulier l'option -m.
En effet, je passe la main directement au MDA (procmail) au lieu de le faire transiter par le MTA (postfix) qui le transmettra de toutes façons à procmail.
Pas chez moi car amavisd-new passe derrière pour faire le ménage avant procmail.
Je trouve que dans le cas de la récupération par pop le trajet « normal » est inutilement tortueux.
Si un jour tu veux utiliser un ~/.forward par exemple, il ne sera pas pris en compte pour les mails relevé via fetchmail.
Il faut juste être conscient de toutes ces subtilités.
-- Benoit Izac
Bonjour,
le 22/02/2007 à 11:50, Sébastien Kirche a écrit dans le message
<87tzxexy7u.fsf@petisuix.seki.fr> :
La solution de Sébastien c'est :
1) fetchmail récupère le message sur le serveur POP
2) fetchmail le passe à un MDA
Tu devrais vraiment lire la page man de fetchmail avant de faire ça
en particulier l'option -m.
En effet, je passe la main directement au MDA (procmail) au lieu de le
faire transiter par le MTA (postfix) qui le transmettra de toutes
façons à procmail.
Pas chez moi car amavisd-new passe derrière pour faire le ménage avant
procmail.
Je trouve que dans le cas de la récupération par pop le trajet
« normal » est inutilement tortueux.
Si un jour tu veux utiliser un ~/.forward par exemple, il ne sera pas
pris en compte pour les mails relevé via fetchmail.
Il faut juste être conscient de toutes ces subtilités.
le 22/02/2007 à 11:50, Sébastien Kirche a écrit dans le message :
La solution de Sébastien c'est : 1) fetchmail récupère le message sur le serveur POP 2) fetchmail le passe à un MDA
Tu devrais vraiment lire la page man de fetchmail avant de faire ça en particulier l'option -m.
En effet, je passe la main directement au MDA (procmail) au lieu de le faire transiter par le MTA (postfix) qui le transmettra de toutes façons à procmail.
Pas chez moi car amavisd-new passe derrière pour faire le ménage avant procmail.
Je trouve que dans le cas de la récupération par pop le trajet « normal » est inutilement tortueux.
Si un jour tu veux utiliser un ~/.forward par exemple, il ne sera pas pris en compte pour les mails relevé via fetchmail.
Il faut juste être conscient de toutes ces subtilités.
-- Benoit Izac
Sébastien Kirche
Le 22 février 2007 à 17:18, Guillaume Connan s'est exprimé ainsi :
Priority order for recognizing coding systems when reading files: 1. iso-latin-9 (alias: iso-8859-15 latin-9 latin-0) 2. iso-latin-1 (alias: iso-8859-1 latin-1)
Mais utf8 n'apparaît plus dans cette liste : comment le mettre en 3eme choix ?
Cette liste contient 14 éléments chez moi et utf-8 est bien le 3ème derrière latin-9 et latin-1. Mais j'utilise emacs22 via emacs-snapshot donc c'est peut-être normal ?
Je ne me rappelle plus de la manip pour ajouter un encodage à la liste de ceux à tester par ordre décroissant à l'ouverture d'un fichier.
-- Sébastien Kirche
Le 22 février 2007 à 17:18, Guillaume Connan s'est exprimé ainsi :
Priority order for recognizing coding systems when reading files:
1. iso-latin-9 (alias: iso-8859-15 latin-9 latin-0)
2. iso-latin-1 (alias: iso-8859-1 latin-1)
Mais utf8 n'apparaît plus dans cette liste : comment le mettre en
3eme choix ?
Cette liste contient 14 éléments chez moi et utf-8 est bien le 3ème
derrière latin-9 et latin-1. Mais j'utilise emacs22 via emacs-snapshot
donc c'est peut-être normal ?
Je ne me rappelle plus de la manip pour ajouter un encodage à la liste
de ceux à tester par ordre décroissant à l'ouverture d'un fichier.
Le 22 février 2007 à 17:18, Guillaume Connan s'est exprimé ainsi :
Priority order for recognizing coding systems when reading files: 1. iso-latin-9 (alias: iso-8859-15 latin-9 latin-0) 2. iso-latin-1 (alias: iso-8859-1 latin-1)
Mais utf8 n'apparaît plus dans cette liste : comment le mettre en 3eme choix ?
Cette liste contient 14 éléments chez moi et utf-8 est bien le 3ème derrière latin-9 et latin-1. Mais j'utilise emacs22 via emacs-snapshot donc c'est peut-être normal ?
Je ne me rappelle plus de la manip pour ajouter un encodage à la liste de ceux à tester par ordre décroissant à l'ouverture d'un fichier.
