Rob Funk <rfunk(_at_)funknet(_dot_)net>:
Anyway, it's pretty clear to me that the comments in the source imply
that the 'seen' state has an effect on a subsequent fetchmail run; and
that would only have been true for servers where we are using 'LAST' and
not 'UIDL' to determine which messages are fresh.
True.
Yes, the seen state does have an effect on later runs.
I wasn't exactly saying that the UIDL code is bad. ESR has said that every
time he touches it it seems to break, so he is uncomfortable with touching
it.
That's right.
If the server supports UIDL, then the only reason for using TOP rather
than RETR is if you wish to make the POP3 server not set its 'seen' flag
*for some reason other than those listed in the source* (i.e. for policy
reasons; not because this somehow makes the download more "reliable" in
the presence of connections drops)
OK, I see what you're saying.
In defense of those comments, I believe that part was written before
fetchmail had UIDL support.
Right. And is still there because I don't really trust the UIDL code.
Now, there certainly may be valid policy reasons why you might wish to
use the TOP trick. In that case, there should be an explicit flag for
it:
--unseen Try to not set the 'seen' flag on the message when
downloading. In the case of POP3, the message is
downloaded using TOP instead of RETR. (This may not
work on some buggy POP3 servers). In the case of
imap ...etc
In that case, --unseen could be applied in addition to --keep (where it
might actually make sense, e.g. in the voicemail case, where you want
the message to remain on the server but remain in the 'unheard' section
of the inbox).
Hmmm...possible, though I'm resistent to adding new options.
If you have probed the server and found that it implements LAST but not
UIDL, then it might also make sense to try the TOP trick. But if you are
using UIDL then you may as well just use RETR in the first place. Then
life will be happy for the majority.
All this makes sense, except that the unreliable connection issue still
exists in a different form if the user wants messages marked as seen
normally, but not if fetchmail tries and fails to get a message. This is
a corner case that I hope ESR might weigh in on.
That is in fact the case fetchmail's TOP logic was designed to handle
correctly, whether due to line drop or any other reason. (Bear in mind
that when fetchmail was in most active development in '96-'97, polls
over flaky dialup links were morte common than they are now.)
So, a solution which makes everyone happy might be:
- add an 'unseen' switch
- use TOP if unseen is set
OR (we are using LAST to manage this session [not uidl]
AND keep is not set AND fetchall is not set)
- otherwise use RETR
- update the comments to explain which bits only apply when using LAST
Then:
- sessions where UIDL is active use RETR by default to fetch messages,
and do not tickle bugs in TOP
- the voicemail person is happy because he can leave his messages in the
'unseen' state (probably)
Actually I might change the "we are using LAST" part to "the server
supports LAST". Also I might change the name of the "unseen" flag. Maybe
"preserveseen", but that's a bit long.
Other than that I think I could tentatively support this.
The logic described conforms to the design philosophy behind the existing code
in a way some other proposals to address this problem have not.
That's an easy patch. I'd even be happy to do it, *if* I thought there
was a chance of it getting committed into the source tree. At present,
unfortunately, it doesn't look very likely.
Actually I think it's possible. Eric last appeared on the list in
February, and last commented on patches in January. It may take time, but
I believe you'll at least get a response. I think the fact that the
TOP/RETR code doesn't take UIDL into account is due to be remedied.
I'm CCing ESR on this just in case it helps get his attention.
You have it.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>