Brian Candler wrote:
If you said:
"We want to try to maintain the 'unseen' flag on the server, so that
other clients (e.g. IMAP) do not believe that we have downloaded the
message"
then there could be an argument.
Other than the "(e.g. IMAP)" part, this is part of where I'm coming from,
and exactly what I mean when I refer to the voicemail issue.
Actually I'm thinking more about the internal state of the mailbox rather
than "other clients"; there are so many ways of accessing mailboxes that
saying "other clients" is too limiting and misleading.
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.
True, but writing it into an RFC doesn't make it happen. Not all
servers support UIDL, and I know ESR isn't really comfortable with the
UIDL code in fetchmail.
Most POP3 servers support UIDL and not LAST. Some support both UIDL and
LAST. You'd be very, very hard pushed to find one which supports LAST
but not UIDL (i.e. RFC1460, not RFC1725 or RFC1939)
If it supports LAST at all, or if the mailbox is accessible outside of POP
in a way that has a concept of seen/unseen, then it's relevent to the
seen/unseen discussion.
This means that if the UIDL code in fetchmail is bad, then most of us
have to live with it. The solution there is to fix the code.
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. I am too, but due to lack of experience with that code rather than
due to bad experience with it.
This might, however, be a good argument for using TOP instead of RETR
if the server supports UIDL, even if the keep flag is set.
Didn't follow that. Which argument is "This" referring too?
Your item 4:
(4) "marking the seen flag is the only way to prevent the message from
being re-fetched on subsequent runs" is untrue. UIDL prevents the
message from being re-fetched on subsequent runs. That's been the case
since RFC1725.
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.
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).
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.
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.
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.
--
==============================| "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"