On Mon, Apr 26, 2004 at 03:22:53AM -0400, Rob Funk wrote:
Rob wrote:
Not having read the source I may be off base - but would the UIDL
support help any here (to avoid fetching already downloaded email)?
Hmm, possibly, but I don't really know the UIDL part of fetchmail.
I do notice that fetchmail is already sending the UIDL command to the
server, and that the server doesn't understand LAST.
The description of uidl in the man page does sound like it might help,
possibly even without my patch. Seems worth a try.
But the problem isn't to do with fetchmail using or not using uidl (clearly
*it is* using uidl from the transcript, although it tries to use the LAST
command first, and it is correctly able to work out whether it has seen a
message before or not)
The issue seems to be that the voicemail system is treating the message as
"heard" when the client has issued a RETR command via POP3. (Whether it also
does so if the user issues TOP instead remains to be seen, but is easily
tested using telnet)
That means there's some private sharing of state between the POP3 server and
the voicemail server. For example, maybe the POP3 server is adding a header
(e.g. Status:) after a RETR command, and the voicemail server is looking at
this header. Or maybe the voicemail server is accessing the message
directly, not using POP3 at all; e.g. if it were a Maildir then it might be
looking at flags on the filename (:2,S for Seen)
http://cr.yp.to/proto/maildir.html
But that doesn't help you much, since you can't control that internal state
by means of the POP3 protocol.
Regards,
Brian.