R Hannes Beinert <argovela(_at_)yahoo(_dot_)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