Chers lecteurs de journaux,
Grace à vous, j'avais commencé à comprendre comment fonctionnent fetchmail et procmail
Mais j'ai une question et je ne trouve pas la réponse sur le net car bcp utilisent un serveur de mail type postfix pour contourner mon point (cf point 2 plus bas ou la ref à procmail est dans la conf de postfix).
Il est possible d'utilser fetchmail > procmail > boite mail > client mail
1. Où fetchmail stocke-t-il les mails par défaut ?
2. Le passage fetchtmail > procmail semble se faire en insérant dans .fetchmailrc la commande suivante : mda '/usr/bin/procmail -Y -d %T' mais doit il se mettre dans une ligne précise (ds la partie poll ... ?) ou bien n'importe ou ?
3. mbox vs maildir : quel est le mieux ? procmail gère-t-il les 2 ? peut-on mettre les 2 type de boite dans /home/$user/ (faut comprendre soit l'un soit l'autre) ?
Merci d'avance & bonne nuit,
Nicolas
# Re: Fetchmail / Procmail (suite)
Posté par Vivi (site web personnel) . Évalué à 3.
2. fetchmail essaye de contacter le port smtp (25) de la machine, s'il n'y arrive pas (pas de serveur en route) il utilise directement procmail il me semble
3. je sais pas
[^] # Re: Fetchmail / Procmail (suite)
Posté par NiCoS . Évalué à 2.
2. fetchmail essaye de contacter le port smtp (25) de la machine, s'il n'y arrive pas (pas de serveur en route) il utilise directement procmail il me semble
Oui mais bon comment il sait à qui faut le transmettre ?? Faut bien le définir qqpart ou il le sait tout seul ?
[^] # Re: Fetchmail / Procmail (suite)
Posté par lom (site web personnel) . Évalué à 3.
poll smtp.free.fr with protocol POP3:
user plop there with password ****** is coin here and wants mda "/usr/bin/procmail -d %T"
[^] # Re: Fetchmail / Procmail (suite)
Posté par GCN (site web personnel) . Évalué à 2.
poll pop.free.fr devrait mieux fonctionner AMHA :).
[^] # Re: Fetchmail / Procmail (suite)
Posté par lom (site web personnel) . Évalué à 1.
mea culpa.
merci d'avoir remarqué. ( (c) Bouriquet )
J'ai refais cette ligne de tete, et effectivement, ce n'est pas beau à voir.
Je vais de ce pas me flageller avec des orties fraiches.
[^] # Re: Fetchmail / Procmail (suite)
Posté par NiCoS . Évalué à 1.
Merci !!
# Re: Fetchmail / Procmail (suite)
Posté par jmfayard . Évalué à 2.
Je préfère personellement maildir, c'est plus propre : 1 mail == 1 fichier
Après, cela dépend de la sorte de mails que tu reçois : si tu reçois relativement peu de mails souvent gros (html, attachements, ...), il vaut nettement mieux les mettre chacun dans un fichier séparé.
Par contre, si tu es abonné à N mailing-lists à gros volume avec des gens civilisés qui font des mails en pur text, tu vas te retrouver avec des milliers de petits fichiers, ce qui peut rendre l'ensemble assez lent, comme c'était le cas pour moi avec mutt l'année dernière.
Mais maintenant, mutt utilise un cache, et ce dernier point n'est plus un problème.
procmail gère les deux :
#~/.procmailrc
DEFAULT=$HOME/Mail/inbox/
MAILDIR=$HOME/Mail
LOGFILE=$MAILDIR/procmail-log
VERBOSE=on
:0:
* ^Mailing-List.*vim-dev-help@vim.org
VIM/
:0:
* ^List-Id.*rhythmbox-devel.gnome.org
rhythmbox
Note le '/' procmail mettra certains courriers dans la mbox "$HOME/Mail/rhythmbox", d'autres dans le maildir "$HOME/Mail/VIM"
et par défaut dans le maildir "$HOME/Mail/inbox"
Pense à créer tes maildir avant de faire ça.
# Re: Fetchmail / Procmail (suite)
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
la ligne mda .. peut etre placée (comme toutes les options fetchmail d'ailleurs) en config globale au début du fichier ou en config locale apres un poll
man fetchmailrc
tu peut aussi utiliser le .forward pour spécifier ton mda:
|/usr/bin/procmail
3. mbox vs maildir : quel est le mieux ? procmail gère-t-il les 2 ? peut-on mettre les 2 type de boite dans /home/$user/ (faut comprendre soit l'un soit l'autre) ?
- ca dépend beaucoup de ton système de fichier, de la taille de ta mbox, ...
- oui (un recent quand meme)
- oui, tu peut meme stocker tes mails en double :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.