MBOX-Line: From lyndon at orthanc.ca  Wed Aug 22 12:27:15 2007
To: imap-protocol@u.washington.edu
From: Lyndon Nerenberg <lyndon@orthanc.ca>
Date: Fri Jun  8 12:34:40 2018
Subject: [Imap-protocol] Private FETCH items
In-Reply-To: <46CC88EE.5040500@andrew.cmu.edu>
References: <46CC88EE.5040500@andrew.cmu.edu>
Message-ID: <22D7E33A-FD12-4B76-8240-89A4690A03B6@orthanc.ca>


On Aug 22, 2007, at 12:05 PM, Ken Murchison wrote:

> FYI, the difference between RFC822.SIZE and RFC822.FILESIZE is that  
> the former uses the cached size in the message index file, and the  
> latter stat()s for the file size at the time of the request.

.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.

.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.

What's a GUID?

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.

--lyndon

