Journal Fetchmail / Procmail (suite)

Posté par  .
Étiquettes : aucune
0
20
nov.
2003
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  (site web personnel) . Évalué à 3.

    1. ils ne les stocke pas, il les transmet à un autre programme (sendmail, postfix, procmail ...)

    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  . Évalué à 2.

      1. ils ne les stocke pas, il les transmet à un autre programme (sendmail, postfix, procmail ...)

      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  . Évalué à 2.

    3) mbox VS maildir
    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  (site web personnel) . Évalué à 1.

    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 ?


    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.