fetchmail-friends
[Top] [All Lists]

[fetchmail] Re: 6.3.0 TODO

2003-08-23 04:00:44
Quoting from Matthias Andree's mail on Sun, Aug 17, 2003 at 02:28:47PM +0200:
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.)

For custom \Fetchedmail flag:

I had asked for such a feature of using an available (but unused) flag
for IMAP. You may refer to it under the thread
"fetchmail and email clients" at:

<http://lists.ccil.org/pipermail/fetchmail-friends/2002-March/001773.html>

The response then was not very encouraging :-(

Note that imap servers do not allow adding custom flags.

For unique identifier:

Yes, it is possible to use and save these UIDs. For that,
"UID SEARCH 1:n" instead of "SEARCH UNSEEN" has to be used. The
remaining transaction need not change.

A minor issue: The UIDVALIDITY number should be saved separately per
mailbox. If it changes across sessions, the saved UIDs should be
discarded!

Another minor issue: Should the \Seen flag be set on such mails?

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.

I recall Sunil wanted to look into #3, but haven't heard updates. Did I
miss the patch? :-)

No patch submitted for this :-(

I have done the splitting of the code (I have to still merge it with
6.2.4, but that is a side issue).

However, I had uncovered some bugs (which are also present in the
current version) which I was hoping I could fix before releasing the
patch. However, this is taking longer than I hoped and I am not able
to devote much time to it. Here is a description of the bugs:

1) Socket error from mail server during readbody() is not handled
correctly for MDA and BSMTP. On socket error,

[for MDA]
the MDA pipe is closed. The MDA then delivers the incomplete mail!

The only solution would be to kill the MDA first before closing the
MDA pipe (this may not work if the MDA is a setuid program and has
changed its uid, but this is a side issue). However, the problem is
that the pid is not known currently as popen() does not return the pid
of the child. This means that a modified version of popen() which
returns both the fd and the pid should be used.

[for BSMTP]
the BSMTP file is closed! Since the terminating .<CR><LF> has not been
sent, the next mail which will be appended in the next session will
get merged into this mail!

The only solution is to save the whole mail into a separate file
first. Only after receiving the complete mail should the mail be
appended to the bsmtp file.

[for SMTP (the only case where the incomplete mail is discarded)]
the socket is closed causing the smtp server to abort the mail.

2) Early exit of MDA is not handled by fetchmail correctly. This is
more visible in multidrop mode when the sender/recipient address is
rejected outright by an MDA like /usr/sbin/sendmail even before the
mail headers are written to the pipe. Typically, this leads to a
SIGPIPE causing the whole mail transaction to be aborted.

The current code deals with SIGCHLD only during close_sink(). SIGCHLD
handler should be established before popen() and the exit status
should be handled as soon as the child exits.

3) Errors during bouncing of mails are not being handled correctly. If
a mail is rejected, fetchmail tries to send a bounce mail. If the
bounce mail is rejected by the smtp server, fetchmail

a) deletes the mail silently causing the user to not know of which
mails have been deleted without notification to sender, or 
b) keeps the mail leading to unnecessary traffic during each run.

The only sane solution is to send a double bounce to the postmaster.
Then, if the double bounce fails (this should never occur), keep the
mail, else delete the mail.

Apart from fixing the above bugs, a host of options will have to be
added like bouncemda, bouncesmtphost, mta, bouncemta, options for
doublebounce, etc. Whether adding so many options is going to make it
easier or difficult to use fetchmail is an important issue.

I am wary of submitting an incomplete patch as it may cause too many
inconsistencies.

Please suggest some ways to go about this task.

-- 
Sunil Shetye.

<Prev in Thread] Current Thread [Next in Thread>