Matthias Andree <ma(_at_)dt(_dot_)e-technik(_dot_)uni-dortmund(_dot_)de>:
Generally, we need to remove all assumptions that fetchmail is the only
client accessing the mailbox, because both aren't true and can cause
mail loss, therefore, we need to find alternatives for server-side
"seen" tracking.
I question this assumption. Why are you trying to use fetchmail as one
quasi-user-agent among others when its job is to be an MTA-like
protocol gateway?
1. POP3 variants: UIDL and emulation thereof must be the only supported
mode for POP3/APOP/KPOP/variants. It's OK to fall back to TOP and
build the SHA1 sum of all Received: and the Message-ID: headers, but
anything short of that or forcing "--all" WILL LOSE mail.
Note that, when emulating UIDL, checking the Message-ID alone is
_NOT_ sufficient, because it will then lose messages Cc:'d for
example to a mailing list and the user.
2. The IMAP code is broken by design, because it relies on the
server-side \Seen flag, which MUST FAIL: As soon as I've read mail
with Mozilla or Sylpheed, the mail will not be retrieved. That's not
what I'd call reliable mail fetching.
So, either the IMAP code uses a custom \Fetchedmail flag or a unique
identifier. I'm not very acquainted with IMAP, so I don't know if it
has the equivalent of POP3's "UIDL". (I wonder what all that UID and
UIDVALIDITY stuff is, might be related.)
Both these features seem directed at the case where fetchmail is one of
several programs mining the same mailbox. Why are you doing this? It's
not what the program is designed for. If you want yet another user agent,
you know where to find them.
3. The "mda" option still isn't working. It cannot bounce mail and it
doesn't handle multiple recipients in multidrop unless the configured
"mda" is actually /usr/sbin/sendmail.
As I have previously remarked, the right fix for the second issue is
not to complicate the fetchmail code, but rather to have fetchmail
call a wrapper script that takes multiple addresses. I would take
a patch to enable the MDA code to send bounces.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>