60 lines
2.6 KiB
Plaintext
60 lines
2.6 KiB
Plaintext
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.
|
|
|