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: