Brian Candler wrote:
On Mon, Apr 26, 2004 at 03:22:53AM -0400, Rob Funk wrote:
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.
_______________________________________________
Fetchmail-friends mailing list
Fetchmail-friends(_at_)lists(_dot_)ccil(_dot_)org
http://lists.ccil.org/cgi-bin/mailman/listinfo/fetchmail-friends
I wrote a patch to implement client side UID tracking using IMAP. POP3
will not allow for maintaining the Seen flag on messages reliably, but
IMAP does. This patch implements the POP3 UIDL code in the IMAP
driver. Sorry it took so long to respond, this has been sitting in my
inbox for a while obviously. Comments welcome on the patch for
improvements as it went mainly unnoticed when I posted it.
http://lists.ccil.org/pipermail/fetchmail-friends/2004-March/008445.html
Clint