On Mon, Apr 26, 2004 at 03:05:40PM -0400, Rob Funk wrote:
Mailboxes DO have a concept
of a "seen flag" which many servers use. (See the current voice mail
example.)
Absolutely. But there's a difference between:
- wanting to leave the 'seen' flag unset for POLICY reasons (e.g. the
voicemail example)
- wanting to leave the 'seen' flag unset so that we continue in the right
place after an interrupted download (which is what fetchmail does now)
The second case can only apply to LAST. This is because any 'seen' flag
stored on the server is invisible to a POP3 client (well, there might be a
header like 'Status: RO' or 'X-Message-Flags:' but not in any standard way)
Note that fetchmail only tries to leave the 'seen' flag unset if you are not
using 'keep' or 'fetchall'. And if you're not using 'keep' then you're going
to delete the message from the mailbox anyway, in which case you don't care
about preserving its state (except for the case of LAST and interrupted
transfers).
So far, all servers I know of that support both TOP and a seen
flag in the mailbox do not set the seen flag for TOP but do set it for
RETR.
Sure. But that's not an argument for why and when you'd want to try to keep
the message in the 'unseen' state.
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.
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, 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)
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.
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?
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)
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.
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)
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.
Regards,
Brian.