MBOX-Line: From murch at andrew.cmu.edu  Thu Aug 23 07:32:53 2007
To: imap-protocol@u.washington.edu
From: Ken Murchison <murch@andrew.cmu.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: <46CD9A95.4030001@andrew.cmu.edu>

Lyndon Nerenberg wrote:
> 
> 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.

True.  The author of the patch may be using this for something other 
than what I was thinking.  I'll have to ask.


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

I probably wasn't clear in the use case.  Cyrus now has the ability to 
replicate a mailstore in near realtime.  Several sites (including CMU in 
the near future) are using this to have redundant mailstores in case of 
a hardware failure.  Rather than create a new tool or protocol to verify 
the consistency of the mailstore pairs, extending IMAP with a couple of 
new FETCH items seems like a reasonable thing to do.


> What's a GUID?

As Mark deduced, its Global Unique ID


-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

