Rob MacGregor wrote:
Sadly the experts don't seem to live here any more. I've not seen a
posting from any of the maintainers in a few months and directed email
seems to be ignored.
Hmm, whenever someone mentions plural "maintainers" in the context of
fetchmail, I have to assume I'm one of those being referenced.
Despite what you may think from the wording of the fetchmail web page, Eric
Raymond is really the only fetchmail maintainer. Anyone else mentioned is
as a "backup maintainer" in case ESR disappears entirely (IMO not really a
necessary precaution in open source), which I don't think he has. Though
I'm listed as a backup maintainer, I don't even use fetchmail these days
(I use IMAP through Kmail), and haven't paid any attention to the code in
quite a while. I can help with historical issues though. I suppose I could
be considered a senile elder in the fetchmail world.
However, as for the original problem - AFAIK a work around was posted
some time ago. I have vague memories of it having to do with "fetch
all" or similar, but it was some time back. A trawl of the archive may
bring it to light.
"fetchall" forces fetchmail to use RETR instead of TOP. The FAQ mentions
it in a few places, just not in the Comcast entry.
And as for whether fetchmail is doing the right thing by using TOP....
well, if the maintainer didn't think so then it wouldn't do it. On the
other hand, quite a few server implementations seem to implement TOP
improperly, apparently with a limited concept of how it will be used.
Whether that's ultimately a server bug, a fetchmail bug, or a bug in the
spec is to some extent a matter of opinion and philosophy. Obviously the
fetchmail side of things is that the bug is with the server, but I can see
an argument being made that fetchmail should accomodate servers with
broken TOP. (There are quite a few server workarounds in the code.) In
this case, though, fetchall is the obvious workaround.
The spec (http://www.faqs.org/rfcs/rfc1939.html) is clear though:
# Note that if the number of lines requested by the POP3
# client is greater than than the number of lines in the
# body, then the POP3 server sends the entire message.
Part of the problem is that UIDL was added to (and LAST removed from) POP3
relatively late in the lifetime of POP3 (1994), and after fetchmail's
design was established. Most of us who were active with fetchmail at the
time never liked UIDL and had fundamental problems with it, and ESR never
really got along with the UIDL part of the fetchmail code. (See FAQ O9.)
So there's still an effort in the code to properly support LAST by using
TOP when it's desirable to avoid changing what LAST reports.
A related issue may be that the more a person works with fetchmail trying
to make POP3 work properly on all the various servers out there that
weren't necessarily designed for what fetchmail tries to provide, the more
a person tends to try to ignore POP3 breakage in favor of IMAP.
I take serious issue with the Comcast assertion that "POP 3 was created in
May 1996 and has not been revised since." I was using POP3 around three
years before that. The earliest POP3 spec is RFC 1081 from 1988; 1996 was
just the last revision of POP3 (RFC1939). And POP3 is obviously a
revision of POP2 (RFC937 in 1985) and the original POP (RFC918 in 1984);
anyone who actually reads RFC1939 knows this.
As for the rest of that Comcast sentence, "despite the many changes in
computer hardware and software related to handling of email since that
time," someone needs to introduce the Comcast person to IMAP, which by the
late 90s was generally recognized among Internet mail people as a
replacement far superior to POP3. If Comcast is looking for an update to
POP3 appropriate to "the many changes in computer hardware and software"
since 1996, they should look at IMAP4, which was last revised a year ago
in RFC3501.
Comcast's preference for supporting Microsoft breakage rather than adhering
to the POP3 spec and pressing MS to fix their code speaks volumes about
the havoc Microsoft has wrought. It also shows that they don't understand
TOP, since TOP is always supposed to return the full headers along with as
much of the message as requested. Comcast's use of the phrase "technical
business decision" also makes no sense at all to me.
BTW Rob, I'm always impressed with the amount of effort you put into
supporting fetchmail on this list. You deserve a lot of credit for that.
--
==============================| "A slice of life isn't the whole cake
Rob Funk <rfunk(_at_)funknet(_dot_)net> | One tooth will never make a full
grin"
http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind"