[fetchmail]Observations of a new user

[Matthias Andree]

R Hannes Beinert <argovela@yahoo.com> writes:

> 1) In the process of configuring FM I used MyRealBox.com as an IMAP
>    testbed.  In looking over the protocol exchanges between FM and
>    the server, it appears at first blush that the server is being
>    quite non-conformant to the RFC's.  I've not worked extensively
>    with IMAP, but there does seem to be some serious bizarritude.
>    I'm pleased and surprised that FM works!  Does anyone know whether
>    the MyRealBox.com IMAP server uses the Novell "GroupFoolish" server
>    described in the FAQ?

I can't say anything about this.

>
> 2) The documentation for FM is excellent, and sets a high bar for other
>    OSS projects!  One small detail caused me to trip, initially, although
>    (he says apologetically) this may have had more to do with the reader
>    than the writer.  I found it might've helped me initially if there had
>    been an explicit discussion of the "singledrop" versus "multidrop" mode
>    of operation early in the man page.  Then, it might additionally have
>    helped if each option had been explicitly labeled as having
>    applicability for single- vs multidrop.  It wasn't clear to me on first
>    read that FM had these two different modes, or, at minimum, the 
>    differences between them weren't obvious to me.  Then again, I
>    frequently need that second whak with the proverbial cluestick.

Well, the single- vs. multidrop issue is difficult; fetchmail implicitly
derives this information from the "is ... here" stuff, and that is
pretty unclear from the documentation.

If you can suggest better wordings, perhaps even a patch, that would be
most welcome - we have a fetchmail-devel list for such things, see
http://developer.berlios.de/projects/fetchmail/

> 3) On the subject of logging - I find myself missing MTA-style logging,
> ie,
>    timestamp, mailserver, MAIL FROM, RCPT TO, message size, and receiving
>    MTA queueid.  This would make tracking email through the various logs
>    much easier.  The standard FM log is too terse to include this
>    information, yet while the "single-v" logging contains the information
>    in question, it is probably more intended for debugging than logging of
>    the sort I'm looking for.  Also, in the non-v logging, I miss having
>    information on when a server with no messages was polled.  I do
> realize,
>    though, that the non-v logging was intended to be very economical. 
> I've
>    been using -v logging, and I'm happy.  Disks are cheap.  ;-)

If you can offer a scheme what information exactly should be printed,
that would help. MTA-style logging might be useful for fetchmail indeed.

> 4) Closely releted to item #3, I also found it might be useful to be able
>    to control logging from the fetchmailrc file, so that system start-up
>    scripts wouldn't need to be touched.  So, eg, one could conceivably
>    use global options such as "set verbose 2", or "set logging-level 1"
>    in one's FMrc configuration to change the logging verbosity.

Hm. That should be doable for the release after the next. The next one
is for bugfixes, since we've had it pending for over a year now.

Again, detailed suggestions on fetchmail-devel (see above) will be
appreciated. Patches even more so. :)

Thanks for your comments,

-- 
Matthias Andree