MBOX-Line: From MRC at CAC.Washington.EDU  Wed Aug 22 14:14:14 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <MRC@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:40 2018
Subject: [Imap-protocol] Private FETCH items
In-Reply-To: <22D7E33A-FD12-4B76-8240-89A4690A03B6@orthanc.ca>
References: <46CC88EE.5040500@andrew.cmu.edu>
	<22D7E33A-FD12-4B76-8240-89A4690A03B6@orthanc.ca>
Message-ID: <alpine.WNT.0.999.0708221405260.3828@Shimo-Tomobiki.Panda.COM>

On Wed, 22 Aug 2007, Lyndon Nerenberg wrote:
> .FILESIZE is just  asking for trouble.  Nobody cares what the on-disk 
> representation is, and comparing file sizes is NOT the same as comparing 
> message content.

I agree.  The c-client library (the beating heart of UW imapd, Pine, etc.) 
has a concept of an internal size, but that depends upon the mail store 
and thus is only used by mail store drivers.  It never gets as far as 
imapd (or other application), much less exported in the protocol.

Let us be clear here; any .FILESIZE value in any server which supports 
multiple mail store formats could (and WOULD) vary depending upon the 
mailbox format with no obvious indication to the user as to why.  This, by 
itself, should be enough cause to reject it.

> .MD5 is useful in the general sense as a fast way to compare messages for 
> equality, although I think it would be better served in that context if you 
> could MD5 the body content without the 822 headers to be able to handle 
> Received: differences for the same message delivered to two or more folders 
> via different [SL]MTP transactions.  It would probably make more sense to be 
> able to generically MD5 by MIME body part.

IMHO, this functionality belongs as part of CONVERT.  An MD5 checksum is, 
in effect, a conversion.

> What's a GUID?

Presumably this is a global UID which uniquely and permanently identifies 
the message on the server.

I think that IMAP should eventually have a GUID, but it needs careful 
design and review.  I don't think that we should take the first patch that 
comes along.

> But overall I guess I have to question why it's necessary to burden the 
> protocol with this just because somebody wrote some broken code.  I have done 
> an awful lot of server migrations over the years and I have never yet come up 
> against the problem this is trying to detect. I realize you intend this as 
> private data, but once it's in the wild, it will get used, for better and 
> worse.

I agree with this sentiment.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

