[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sobre fetchmail.

N0K dijo:
> fetchmail a procmail con mda "/usr/bin/procmail -d user".

¿Que ventajas tiene esto frente a usar un MTA de toda la vida?

> Pero tengo otra cuenta en un servidor que no es mio del que me
> gustaria bajar tambien. El caso es que cuando bajo, la primer a vez me
> lo baja todo bien, pero la segunda (tengo configurado keep en
> fetchmail para que no me los borre del server) los mismos mensajes que
> me bajo antes, que ya los borre de mutt, me los baja todos menos uno,
> si borro este, la toma con otro que no vuelve a bajar.

Esto puede ser por la implementacion concreta del servidor POP3 al que
te conectas... me parece haber leido algo en la doc de fetchmail.
Haz tu mismo un telnet al 110 de ese servidor y por lo menos sabras que
demonio usan.

       When forwarding to an MDA, however, there is more possibility of error.
       Some MDAs are `safe' and reliably return a nonzero status on any deliv-
       ery  error,  even one due to temporary resource limits.  The well-known
       procmail(1) program is like this; so are most programs designed as mail
       transport  agents,  such  as  sendmail(1), and exim(1).  These programs
       give back a reliable positive acknowledgement and can be used with  the
       mda  option with no risk of mail loss.  Unsafe MDAs, though, may return
       0 even on delivery failure.  If this happens, you will lose mail.

       The normal mode of fetchmail is to try to download only `new' messages,
       leaving  untouched  (and  undeleted)  messages  you  have  already read
       directly on the server (or fetched with a previous  fetchmail  --keep).
       But  you  may  find that messages you've already read on the server are
       being fetched (and deleted) even when you don't specify  --all.   There
       are several reasons this can happen.

       One  could  be  that  you're using POP2.  The POP2 protocol includes no
       representation of `new' or `old' state in messages, so  fetchmail  must
       treat  all messages as new all the time.  But POP2 is obsolete, so this
       is unlikely.

       Under POP3, blame RFC1725.  That version of the POP3 protocol  specifi-
       cation  removed  the  LAST command, and some POP servers follow it (you
       can verify this by invoking fetchmail -v to the mailserver and watching
       the  response to LAST early in the query).  The fetchmail code tries to
       compensate by using POP3's UID feature, storing the identifiers of mes-
       sages  seen  in  each  session until the next session, in the .fetchids
       file.  But this doesn't track messages seen with other clients, or read
       directly with a mailer on the host but not deleted afterward.  A better
       solution would be to switch to IMAP.

       Another potential POP3 problem might be servers that insert messages in
       the  middle  of mailboxes (some VMS implementations of mail are rumored
       to do this).  The fetchmail code assumes that new messages are appended
       to  the end of the mailbox; when this is not true it may treat some old
       messages as new and vice versa.  The only real fix for this problem  is
       to  switch to IMAP.

¿Podria ser esto?

 .''`. Somewhere on this globe, every ten seconds, there is a woman giving
: :' :   birth to a child. She must be found and stopped -- Sam Levenson
`. `'         Proudly running Debian GNU/Linux Sid (2.4.18 + Ext3)     
  `-        www.amayita.com  www.malapecora.com  www.chicasduras.com   

Reply to: