[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    Bug#1481: Same messages retrieved multiple times
From:       Mike Byrns <mike.byrns () technologist ! com>
Date:       1999-06-28 3:53:45
[Download RAW message or body]

Package: kmail
Version: 1.0.21

When I turn the "Delete Mail from Server" and "Retrieve All Mail from
Server" options OFF for some POP3 accounts I use,  the same messages
are retrieved over and over, ad infinitum.

In examining mail/kmacctpop.cpp I've noted that the mechanisms used to
determine both the first message to retrieve and which messages have
been read are based on non-standard POP3 conventions brought into play
chiefly by Qualcomm's Eudora package.  

The use of the POP3 LAST command as deprecated as of RFC1725 with the
current POP3 standard being RFC1939 (STD53).  RFC1725 removes the LAST
command and adds the UIDL command in it's place.  This is not to say
that the LAST command should never be used, only that the UIDL
mechanism is favored by the standards body and the majority of new and
updated server implementations.  If a server implements LAST but not
UIDL the current kmail implementation is first rate and should be used
by all means.

The use of the "Status:" header to determine whether a particular
message has been read is problematic for two reasons.  First, it is not
a standardized method.  Even those RFCs authored in part by Qualcomm
employees make no mention of it's use.  It is not mentioned in RFC 822
and as such violates the SMTP header extension mechanism requiring
bilaterally defined headers to be prefixed with "X-".  It may be said
that this restriction does not apply since this header is actually
added on the POP3 server and should never be transmitted as part of an
SMTP transmission.  Second, it is closely linked to the same concept of
"read" used with the LAST command, this being that a message read by
one user-agent should be treated as read by another user-agent in
subsequent examinations of the mail-drop.  

I suggest that kmail probe for the availability of the UIDL command
during each POP3 session.  If this command is available use it to
determine which messages should be retrieved by comparing the current
UID list to a list retrieved during the last session, if available.  
If the UIDL command is not available, I suggest that UIDs be
synthesized using the TOP command (if available)  to retrieve the
headers for each message and digesting them using an algorithm like
MD5.  Failing that,  fall back to LIST.  If that's not available the
user should be informed that leaving mail on the server is not
supported and modify the account properties in kind.  

An augmented approach is to use the mechanism described in RFC2449 to
determine whether mail can be left on the server.   The EXPIRE
extension, if implemented, is the definitive authority on the server's
policy.  

If these suggestions are implemented in kmail it should be noted to
users that the concept of "leaving mail on server" has changed.  No
longer is it "read-once, read-everywhere".   Read status is now kept on
a per-user-agent basis.

I volunteer my time to deliver a prototype version that implements
these changes.  I don't know if they are in-line with your vision of
how kmail should work but I'm willing to help if they are.  Please let
me know.

Michael S. Byrns
mike.byrns@technologist.com

[prev in list] [next in list] [prev in thread] [next in thread]