GNOME.org
 

Re: [Evolution] options on download

Jeffrey Stedfast wrote:


I assume that it remembers the UID of the message? Because the assigned
number to each message obviously changes if the other messages are deleted

Okay, so I understand that much, but a lot of POP providers have messed up
UID system.


Your homework assignment is to read all the revisions of the POP3 RFC,
notice which features are optional, which were once manditory and were
*later* converted to optional (yes, really!) and then meditate on
http://lxr.mozilla.org/classic/source/network/protocol/pop3/mkpop3.c


How, then, does this work? The only way I see this as being possible
(correct me if I'm wrong) is to download the header again and check the
"Message-Id" header field, is this the way Netscape does/did it?

And then, at this point, I assume that the message should be downloaded via
RETR and then overwrite the partial message in the mbox file?


Basically.  For some value of "overwrite" equivalent to "mark the old
one as deleted," as I said earlier.


I'm not 100% sure how Netscape saves it's messages, but this might not
easily work in an mbox file, in something like MH it would be easy
though (doesn't that format have a separate file for each message? or
am I thinking of a different format?)


Well, you *should* be 100% sure how Netscape saves its messages, because
before you write a mail reader, you should be 100% familiar with the
other mail readers that exist, because those are the ones your users are
converting from.

I'm happy to offer advice on how to do this stuff, but come on, man.
Go become informed.  It's important.

-- 
Jamie Zawinski
jwz jwz org             http://www.jwz.org/
jwz dnalounge com       http://www.dnalounge.com/
--- Begin Message --- 
Rupesh Kapoor wrote:


Hi,

I am writing a pop client. Does anyone have suggestions on how to
fetch only the new messages if the user doesn't want the client to
delete them on server? I could do it using UIDL, but many servers
don't support it.


The real answer is, give up on POP3 and use IMAP instead.  None of
the kludges that attempt to make POP3 function in a mode other than
"download all the mail, then delete it from the server" really work
very well, and are *very* hard to implement portably.

POP3 must be destroyed.


The netscape mail client seems to do a "TOP <mesgnum> 0" ..., but even
TOP is non-portable.


UIDL is by far the easiest way.  If you can get away with it, use that,
and tell your users that they can only do "keep on server" if they have
a POP3 server that supports UIDL (which RFC1725 calls "optional".)
ftp://ftp.qualcomm.com/quest/unix/servers/popper/ is one such free
server (qpop2.1.4-r3 or newer.)

We tried that, and couldn't get away with it.  So here's what we do 
in Netscape 3.0 and newer.

We keep a list of messages-that-have-been-seen-and-explicitly-left-
on-the-server in a private client-side file.  Anything not in that
list is assumed to be new.

So we need some unique identifier for each message, so that we can keep
track of which ones we have downloaded and which ones we have not (so
that we can avoid downloading messages twice, and so that we can find
them again when the time finally comes to delete them from the server.)  

The message number (index in the spool) is not such an identifier.

Neither is the Message-ID (since two messages can easily have the same
ID, even if they have different headers -- for example when one message
reached you by two different paths.)

The token that UIDL returns is exactly what we need.

So we try UIDL, and if that works, we're done.

If it doesn't, then we fall back on using the Message-ID as the unique
identifier.  This is unreliable, of course, but it's better than
nothing, and *probably* won't lose too badly *most* of the time (you 
can tell why I hate this approach.)

Finding the Message-ID of the messages is also hard.  First, we try
using the "XTND XLST Message-ID" command.  That usually doesn't work,
because most servers that don't support UIDL also don't support XLST.

If that failed, then we try using "TOP 0".  We extract the message-ID
from a message by downloading all of the headers of that message, and
then parsing them.

But to avoid having to download all the headers of every message in the
spool every time (probably close to 30% of the data on average), we
optimize this by walking backwards, from higher message numbers to
lower, examining the Message IDs of messages in the spool in reverse
order.  We stop when we reach a message that we already knew about,
under the (quite-possibly-incorrect) assumption that the spool has not
been reordered since the last time we looked.  (And also under the
assumption that a new message has not come in that has the same message
ID as one that we had already seen.)


Basically, it's a world of hurt.

Do not go there if you can possibly avoid it.

Use IMAP.

-- 
Jamie Zawinski    jwz netscape com   http://www.netscape.com/people/jwz/
``The hateful :-) means `just kidding' and is used by people who would
  dot their i's with little circles and should have their eyes dotted
  with Drano.''   -- Penn Jillette

--- End Message ---
--- Begin Message --- 
Neil Berkman wrote:


In article <32E13D19 6EF netscape com>,
  Jamie Zawinski <jwz netscape com> wrote:


[description of how Netscape determines a unique ID for messages on a POP3
 server, where UIDL is tried first and TOP 0 is tried as a last resort]


OK, but since TOP is also optional, what if the server doesn't support either
UIDL or TOP?  Do you then just give up on providing this functionality?


Yes, in that case, you're screwed.

Fortunately, I don't know of any POP3 servers that don't support TOP,
and nobody has ever complained about this (which is good, because even
if lots of people were complaining about it, there's simply no solution
other than "upgrade your POP3 server.")

POP3 sucks.  Use IMAP.

-- 
Jamie Zawinski    jwz netscape com   http://www.netscape.com/people/jwz/
``The hateful :-) means `just kidding' and is used by people who would
  dot their i's with little circles and should have their eyes dotted
  with Drano.''   -- Penn Jillette

--- End Message ---
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]