his is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
Timo Sirainen writes:
I don't see how CONDSTORE will help the client to resynchronize. The client
will know if someone else messed with the message, but it won't know that
until it tries to mess with it itself.
And what if the client doesn't want to mess with any message in the folder?
How exactly would it know which messages' flags were changed?
I reopened a folder. I know what the folder used to have. Now, how exactly
will CONDSTORE tell me which messages' flags have changed, and which
messages have been expunged?
It saves a round trip back to the server, the first time the message is
read. 99% of the time this is the desired behavior, and now you have a
trivial option that saves a frequent round trip.
What I'm not sure, exactly, is what's to be gained by imposing what
essentially is a specific implementation of a transaction identifier.
Your old transaction id was 50. You reopened the folder. What conclusion
can you make if you now see that the new transaction id is 70, or if it's
100? What does it get you?
In either case, your next step is to ask for a list of changes between
either 50 and 70, or 50-100. Then you set the current transaction id to
either 70 or 100, and you're done.
So, what exactly was the difference between receiving 70, or 100?
This is exactly the same thing as MIME identifier structure. The only
argument for a counter-based transaction id is because it's consistent with
the rest of IMAP. Counters for MIME sections. Counters for UID. Counters
for UIDVALIDITY. Other than overall consistency, there's not much to be
gained from that.
I expect to be around 2038, and I expect to still have most of my mental
faculties intact. I'm looking forward to seeing what happens to IMAP UIDs
and UIDVALIDITY's that either. That is, if IMAP's still around.
Anyway, the client really doesn't care about the counter aspect of a
transaction identifier. From the client's perspective, the only thing that
matters is whether the id has changed, or not. From the server's
perspective, you've now hung a particular implementation requirement around
its neck, which may or may not be optimum for the server to do.
I'm not convinced that the semantics of Recent are well defined and
uniformly implemented. That whole discussion has arisen precisely because
it's a mess.
Furthermore, the semantics of Recent do not work well with snapshots.
Cone does everything it needs to do -- checking for new mail, etc... --
without needing Recent. I'm not sure whether Pine does anything with Recent
too. Recent is another thing that IMAP servers are tortured with, with not
a lot to show for it.
Which client actually does something functionally significant with the
Correct. It's unlikely for a MIME text/plain to sport a Subject: header.
There's a little detail that can be easily overlooked: headers received from
the server are folded. The client does need to parse the headers, but with
the headers being folded, the parsing is trivial. Discarding unwanted
headers for a given MIME section is nothing more than background noise.
The server has an option to individually reject a requested address as
invalid, or as unacceptable, for some reason.
Same as SMTP.