Subject: [lemonade] Determining the "has attachment" status of a message

From: Philip Van Hoof <[email-masked]>
Date: Sat, 09 Feb 2008 12:50:30 +0100

Problem:

When you want to retrieve the envelope of messages you want, on a mobile
with limited bandwidth capacity, to do this with a query that has a
small amount of columns to avoid consuming a lot of bandwidth.

If you'd only need to request bodystructure just to know whether or not
you have attachments, then for just that one-bit sized flag you'd
require the user to perform an IMAP query that is significantly larger
than necessary (in bandwidth size, therefore costing real money for the
application's user when doing this over for example GPRS).

Microsoft's E-mail clients add a X-MS-Has-Attach or something header,
which is indeed very useful for exactly this purpose.

Given that the IMAP server is required to have a MIME parser, it could
easily determine this flag for the E-mail client too.

A proposal:

To specify a method or a field in the ENVELOPE response that accurately
tells me whether or not a message has an attachment and whether any of
the attachments doesn't have as content disposition being an inline one.

This will improve accuracy for mobile E-mail clients who want to tell
the user about the has-attachments status of an E-mail before having to
download the entire message or its bodystructure.

ps. The "difficulty" that is "knowing what and what isn't an attachment"
really isn't that much of a difficulty IMHO. Relatively few E-mail
clients deviate from what everybody calls an attachment and what not.

You could specify this in the spec with for example a:

Images that are embedded in the HTML (inline), are no attachments for
most users. A text/html part is not an attachment. Images that are
attached (have a filename attribute or are not to be showed inline in
the text message) are attachments. A rfc822 forwarded messages depending
on the forward-style (inline or not) is an attachment (this one is
questionable, though). An attachment in a forwarded (in a forwarded
message in a ...) message makes the root message get the has-attachment
status too. Etcetera ...

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be

_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 9 Feb 2008 12:54:20 +0100

Philip Van Hoof writes:
> When you want to retrieve the envelope of messages you want, on a 
> mobile with limited bandwidth capacity, to do this with a query that 
> has a small amount of columns to avoid consuming a lot of bandwidth.

This command does so with very few bytes:

a uid fetch x body.peek[header.fields (content-type)]

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 09 Feb 2008 14:05:44 +0200

> a uid fetch x body.peek[header.fields (content-type)]

All my messages contain Content-Type: multipart/signed, which doesn't
help figuring out if it has attachments.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 9 Feb 2008 21:11:21 +0100

Further comment.

You can find the messages with attachment fairly efficiently using a 
two-step process.

First, you get rid of most of the messages without attachments:

a uid search or header content-type multipart header content-disposition 
attachment

If something is not in the search result for this, you know it doesn't 
have an attachment. Messages which match this search may have an 
attachment, but since some other messages also match it, you have to 
look at this smaller set in more detail to be sure:

b uid fetch (result set from a) bodystructure

The bandwidth usage for this is proportional to the number of multipart 
messages.

Now, I wish we had a better way to do this. I would prefer this:

   c uid fetch (result set from a) body.peek[*.header.fields 
(content-disposition)]

but I don't really think an extension to support "*.header.fields" is 
worth the bother... do you?

Arnt

---

From: Philip Van Hoof <[email-masked]>
Date: Sun, 10 Feb 2008 13:37:35 +0100

> First, you get rid of most of the messages without attachments:

[. cut .] Rather complex and bandwidth consuming method

Why not an internal field like the INTERNALDATE telling me whether or
not the message has an attachment in UID FETCH or FETCH?

This is clearly an algorithm that the server, who has the content of the
entire message, can better perform than the client.

The client doesn't have the message's content, so it can't figure all
this out unless it fetches all possible content and hints first.

A search, a bodystructure (of a lot of messages if a lot messages are
multipart -- most are, nowadays --), ...  20,000 messages are not rare
nowadays. 20,000 messages multiplied with one kilobyte. Just to know
whether or not the messages have attachments.

Monetary seen (dollars, not bytes), that's actually expensive over GPRS.

In contrast: 20,000 characters like '1' or '0' and maybe 10 characters
more for the 'HASATTACH ': that's fine. That's still only a few extra
kilobytes. Not yet megabytes (like bodystructure would do for 20,000).

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 10 Feb 2008 13:16:52 -0500

Hi Philip,

> not the message has an attachment in UID FETCH or FETCH?

There is a significant cost in adding a new field to ENVELOPE. A better 
approach would be to define a new keyword $HasAttach. That keyword would be 
read-only - i.e. set by the server only. This requires no protocol 
extension - it just requires the server to set the keyword.

-- 
Cyrus Daboo

---

From: Philip Guenther <[email-masked]>
Date: Sun, 10 Feb 2008 10:36:35 -0800

On Sun, 10 Feb 2008, Philip Van Hoof wrote:
..
> entire message, can better perform than the client.

I keep expecting to see a pointer in this discussion to an openly 
published and universally agreed upon definition of the "has an 
attachment" algorithm.  I have yet to see one.  Does anyone have a pointer 
or can someone state it in pseudo-code?

Philip Guenther

---

From: Mark Crispin <[email-masked]>
Date: Sun, 10 Feb 2008 11:21:13 -0800 (PST)

> or can someone state it in pseudo-code?

There is not such a thing, nor will there ever be such a thing; at least 
one which is reliably correctly implemented.  Anyone who believes 
otherwise has failed to learn the lesson of the past 20+ years of IMAP:

 	Clients can not rely upon correct server behavior.

None of us like to admit it, but "IMAP compliance" is defined today by 
"works with Outlook" and not by any of the specifications we wrote. 
This, in turn, means that the only thing that you can assume will ever 
work in an IMAP server is what Outlook uses.

If Outlook shows that the message "has an attachment" and your client does 
not, guess who get the bug report when the message demonstrably does has 
an attachment?  It will do no good to say that your client is performing 
correctly, and it's a server bug.

I'm sorry, but when I read threads like this I think about all the bug 
reports I deal with due to servers that don't deliver correct ENVELOPE and 
BODYSTRUCTURE, reject all but the most trivial SEARCH commands (or 
sometimes just reject SEARCH entirely), implement setting \Deleted as an 
EXPUNGE,...

The list goes on and on.  I didn't want to put examples in the IMAP 
specification, but was forced to do so anyway.  The very thing that I 
feared happened: there are servers that implement the syntax according to 
the examples instead of the syntax rules.

Not only that, but these servers are the expensive "professional quality" 
servers from Very Big Vendors.  Specification compliance is largely the 
domain of a few freeware open source servers.

And anyone honestly believes that these same servers are somehow going to 
answer "has an attachment" questions correctly?

In a perfect world, it would be a great idea to have an flag indicating 
that there are attachments.  We live in a very flawed world.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 10 Feb 2008 14:30:31 +0100

> [. cut .] Rather complex and bandwidth consuming method

How so? It's O(n*m), where n is the number of messages you need to 
consider and m is the frequency of multiparts. In a sane client, n is 
either the number of new messages, or the number of messages the user 
interacts with.

> not the message has an attachment in UID FETCH or FETCH?

Because you can set a flag according to whatever algorithm you want, and 
not have to come up with an standard algorithm for deciding what 
comprises an attachment and then wait for me and every other server 
author has to implement it.

> This is clearly an algorithm that the server, who has the content of 
> the entire message, can better perform than the client.

The same applies to \Answered, doesn't it?

> Monetary seen (dollars, not bytes), that's actually expensive over GPRS.

ALL operations where you download information about all the messages in 
a mailbox and discard most of it are expensive. It doesn't matter 
whether you download 20,000 subject fields or 20,000 bodystructures: If 
you download 20,000 items and then display only 20, your client has 
wasted real money.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Sun, 10 Feb 2008 11:39:25 -0800 (PST)

> or can someone state it in pseudo-code?

I'd settle for a pointer to a definition of what "has an attachment" actually
means - the algorithm should be derivable from that. Like it or not, MIME
provides a very general message structuring mechanism that isn't limited to the
simplistc concept of "some text plus an attachment or two" or even "text plus
an attatahccment or two with zero or more of these sorts of wrappers around
it". Since MIME is extensible at any time there's no way to tell what the
semantics of, say, a new multipart/foo type is.

The place where the concept of "attachment" enters into the MIME picture is
through disposition labels - you can, if you like, say that a given part has
"attachment" semantics. Trouble is, a lot of stuff that pretty clearly is
supposed to have attachment semantics isn't labelled this way.

About the best you could do is to divide messages into threee piles: Those that
clearly have parts with attachment semantics, those that probably don't (*),
and those where it isn't clear.

And Mark is of course correct in saying that the trickier the definition the
more trouble you'll have getting servers to make the determination. But a
definition is required before server capabilities even enter the picture.

				Ned

(*) I routinely recieve messages containing a single US-ASCII part where that
part is something like a configuration file and should have attachment
semantics. I suspect I'm hardly alone in this.
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Sun, 10 Feb 2008 12:36:48 -0800 (PST)

> supposed to have attachment semantics isn't labelled this way.

Don't forget certain IMAP servers that report disposition labels in body 
parts that have no such thing in the MIME headers.

It is an evil world in which we live.

-- Mark --

http://panda.com/mrc

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 10 Feb 2008 22:04:10 +0100

Ned Freed writes:
> I'd settle for a pointer to a definition of what "has an attachment" 
> actually means - the algorithm should be derivable from that.

2183?

But some common message senders don't use 2183, so readers have to do 
more in practice. I use a five-step algorithm that works for most 
messages. Except that its results are arguably incorrect for forwarded 
messages, DSNs, some messages from (IIRC) Apple Mail and a few other 
odd and unusual classes ;)

I still think this functionality is a death sentence a draft editor and 
not much better for server implementers. A client which wants this can 
apply whatever test it prefers and store the result in flags or 
locally.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 10 Feb 2008 22:05:58 +0100

Oh sorry. The message arrived here misformatted and I misread it. Please 
disregard my previous reply.
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 10 Feb 2008 22:37:05 +0100

>>  actually means - the algorithm should be derivable from that.

Sorry, forget it. I mangled my mail and misread it and misresponded.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Sun, 10 Feb 2008 15:02:52 -0800 (PST)

> odd and unusual classes ;)

Which is exactly the point I made - the proper indicator of attachment status
isn't in wide enough use to be reliable. And beyond that this is basically
guesswork. I'm having a hard time with the notion of building services on top
of guesswork.

> apply whatever test it prefers and store the result in flags or

Or for that matter it could be done by a Sieve script that examines the MIME
structuure of the message and sets a flag. Implementation isn't the issue,
design and deployment are.

				Ned

---

From: Philip Van Hoof <[email-masked]>
Date: Mon, 11 Feb 2008 10:43:53 +0100

> author has to implement it.

I'll use poetry

A mobile E-mail client

   the target of Lemonade

is usually not the primary E-mail client. 

   Outlook is.

Outlook doesn't set this flag. 

    Therefore 

       the flag wont be set.

It's the kind of reality we often hear from Mark.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 11 Feb 2008 11:05:46 +0100

> Outlook doesn't set this flag.

That doesn't follow. Look at Thunderbird, which uses a similar approach 
for remembering whether a message is spam or not: If the flag Junk is 
set, the message is considered spam. If the flag nonjunk is set, the 
message is considered nonspam. If neither is set, Thunderbird looks 
closer, makes a decision and sets one flag. Outlook does not interfere 
with this.

(Maybe it's $Junk/$Nonjunk. I don't remember. Some other client uses 
$junk/$nonjunk in the same way.)

Arnt

---

From: Philip Van Hoof <[email-masked]>
Date: Mon, 11 Feb 2008 11:24:40 +0100

> $junk/$nonjunk in the same way.)

Thunderbird is not a mobile E-mail client and therefore has the luxury
of being allowed to consume megabytes of bandwidth just to feed its
local anti-spam infrastructure with the message's content.

A mobile client that when connected using an expensive network does spam
detection by fetching message content locally, is one that is either
designed by a bad architect or by a clever marketing guy.

---

From: "DINH Viêt Hoà" <[email-masked]>
Date: Mon, 11 Feb 2008 11:57:31 +0100

> designed by a bad architect or by a clever marketing guy.

Why not do an expensive request as Arnt Gulbrandsen was describing and
cache the result locally on the mobile client ?
By the way, I really think that IMAP sync is the way to go since it
improves the user experience (no delay for cached messages).

Regards,

-- 
DINH Viêt Hoà

---

From: Philip Van Hoof <[email-masked]>
Date: Mon, 11 Feb 2008 12:00:04 +0100

> cache the result locally on the mobile client ?

You still need to do the first expensive request.

The client that I'm developing indeed caches as much as it can locally,
including the attachment state.

> improves the user experience (no delay for cached messages).

Already the case for the majority of E-mail clients.

Doesn't change the first expensive request.

---

From: "DINH Viêt Hoà" <[email-masked]>
Date: Mon, 11 Feb 2008 12:11:15 +0100

> including the attachment state.

To avoid the first expensive request, you can avoid doing that first
expensive request.
For example, you could fetch only the n most recent messages (people's
usual interest)
and fetch the others when the user requests them (see iPhone user
interface for Mail for reference).

> Already the case for the majority of E-mail clients.

note that thunderbird has a delay when trying to open a locally cached mailbox.
some operations will block on a network request.

---

From: <[email-masked]>
Date: Mon, 11 Feb 2008 13:22:19 +0200

>You still need to do the first expensive request.

Just a though (and an attempt to generalize this problem): would it be possible to create a SIEVE extension that can execute certain IMAP commands on the deposited email and based on the result add the desired header-field(s) to it?
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Ned Freed <[email-masked]>
Date: Mon, 11 Feb 2008 04:20:20 -0800 (PST)

> Just a though (and an attempt to generalize this problem): would it be
> possible to create a SIEVE extension that can execute certain IMAP commands on
> the deposited email and based on the result add the desired header-field(s) to
> it?

The answer is no, for at least two reasons. First and foremost, once a message
is in the store it is supposed to be immutable so adding headers is definitely
not allowed. The only alternative would be to replace existing messages with an
entirely new one. And people with local client caches are absolutely going to
love that if it happens.

This restriction is clearly specified in section 3.8 of 
draft-ietf-lemonade-imap-sieve-04.txt, which says:

   Even if the [EditHeader] extension is available, since messages in
   IMAP mailboxes are immutable these actions are NOT applicable.  Use
   of these MUST result in an error condition that will terminate the
   Sieve script.  Explanation: Using them for flag or annotation changes
   to existing messages would cause the message to be changed.  Using
   them for APPEND, MULTIAPPEND, and COPY would cause unexpected
   differences in the stored copy as compared to what the client
   expected, and would make the client's message cache invalid
   unexpectedly.

Second, Sieve is a filtering language designed to operate on messages at or
around the time of final delivery. Generalizing Sieve to act on other message
flows, such as messages being added or moved around in the store is OK (and
already in the process of being specified), but adding capabilities to actually
create message flows of its own lies far outside what Sieve is designed for and
is entirely inappropriate.

The closest Sieve can come to doing what you're asking for here would be to
create the necessary flow external to Sieve and then use flags, annnotations
(no extension for that yet but one could be added), extra copies placed in
additional folders, or even message deletion to communicate the result of
filtering. But modulo the specification of a annotation extension and perhaps a
short informational RFC saying how one might apply Sieve to an arbitrary
message flow, all of this is really more of an implementation/operational
issue, not a standardization issue. Heck, we've been using Sieve this way for
years in our product.

But if header additions/modifications are required I think the only sensible
approach is to use Sieve to make the necessary modifications on final
delivery.

				Ned

---

From: <[email-masked]>
Date: Wed, 13 Feb 2008 11:42:05 +0200

Hi Ned,
SIEVE was just an idea to throw in - since it allow You to manage messages as they are placed into the mailbox. I don't know much about server implementation, but it looked like a good place to add the necessary header field for me.

What exactly do You mean by "final delivery"?
Whenever the client pulls down the header of a message?

If the header field cannot be done when the msg is received, can it be done when the msg is sent (the msgs _are_ changed then - for example, when they are signed).

Thanks.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: ext Ned Freed [mailto:[email-masked]] 
>Sent: 11 February, 2008 14:20
>To: Ordogh Zoltan (Nokia-D-MSW/Tampere)
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: [lemonade] Determining the "has attachment" 
>status of a message
>
>> possible to create a SIEVE extension that can execute certain IMAP 
>> commands on the deposited email and based on the result add the 
>> desired header-field(s) to it?
>
>The answer is no, for at least two reasons. First and 
>foremost, once a message is in the store it is supposed to be 
>immutable so adding headers is definitely not allowed. The 
>only alternative would be to replace existing messages with an 
>entirely new one. And people with local client caches are 
>absolutely going to love that if it happens.
>
>Second, Sieve is a filtering language designed to operate on 
>messages at or around the time of final delivery. Generalizing 
>Sieve to act on other message flows, such as messages being 
>added or moved around in the store is OK (and already in the 
>process of being specified), but adding capabilities to 
>actually create message flows of its own lies far outside what 
>Sieve is designed for and is entirely inappropriate.
>
>The closest Sieve can come to doing what you're asking for 
>here would be to create the necessary flow external to Sieve 
>and then use flags, annnotations (no extension for that yet 
>but one could be added), extra copies placed in additional 
>folders, or even message deletion to communicate the result of 
>filtering. But modulo the specification of a annotation 
>extension and perhaps a short informational RFC saying how one 
>might apply Sieve to an arbitrary message flow, all of this is 
>really more of an implementation/operational issue, not a 
>standardization issue. Heck, we've been using Sieve this way 
>for years in our product.
>
>But if header additions/modifications are required I think the 
>only sensible approach is to use Sieve to make the necessary 
>modifications on final delivery.
>
>				Ned
>

---

From: Ned Freed <[email-masked]>
Date: Wed, 13 Feb 2008 12:05:40 -0800 (PST)

> SIEVE was just an idea to throw in - since it allow You to manage messages as
> they are placed into the mailbox. I don't know much about server
> implementation, but it looked like a good place to add the necessary header
> field for me.

It's "good" only in the sense that the operation can be performed there and the
necessary machinery (Sieve) already exists. But this still doesn't answer the
question of whether or not this entire approach makes sense to standardize or
even document - I'm still waiting for a reasonable specification for what it
means to "have an attachment".

> What exactly do You mean by "final delivery"?

I'm have to say I'm a bit flabbergasted that you would ask such a question. The
term "final delivery" has been used to refer to the point where messages leave
the transport infrastucture for well over 25 years. Indeed, this term is so
commonly used and so well understood that Dave Crocker's new email architecture
document uses it but doesn't bother to define it. (I guess maybe it needs to...
Dave, take note.) It is also used in RFCs [2]821, [2]822, the NOTARY
specification, the Sieve specifications, and many many many others.

> Whenever the client pulls down the header of a message?

No, this is simply a retrieving a stored message, nothing more and nothing
less. The message has to have left the transport infrastructure before anything
like this can happen.

And what we call this or similar operations is irrelevant. One of the key
guarantees IMAP provides is that messages the store receives are immutable. The
store doesn't modify them in any way, and clients can be and frequently are
written to take advantage of this property. Any store that violates it - and
some have - will inevitably run into all sorts of interoperability issues.

> If the header field cannot be done when the msg is received, can it be done
> when the msg is sent (the msgs _are_ changed then - for example, when they are
> signed).

There are various schools of thought about whether or not it is OK for
modifications to occur to in-transit messages, ranging from those who think
pretty much anything goes to those who see any changes beyond the prepending of
trace headers as flatly unacceptable. But regardless of the treatment of
in-transit messages, there seems to be fairly broad agreement that modification
at the boundaries of the transport system, that is, during submission and final
delivery, is OK.

However, submission to the transport infrastructure occurs within the
administrative domain of the message originator, which often isn't the same as
that of the recipient. This means that submission is not something the
recipient's system has any control over. OTOH, it is axiomatic that final
delivery occurs within the administrative domain of the recipient. And since
messages can be modified at this point (but not later), it's the last
opportunity to add or change header fields. After that some other mechanism
such as a flag or annotation has to be used.

I should also point out the other issue with this: Final delivery only applies
to messages that have been submitted for transport. It doesn't apply to
messages clients insert into the store directly. In this case the message is
immutable once it leaves the client and even if you implement Sieve processing
at this point its results cannot be conveyed by adding a header field.

				Ned

---

From: <[email-masked]>
Date: Thu, 14 Feb 2008 11:28:41 +0200

Hi Ned,
thank You for taking the time and explaining it.

I have one more suggestion: a flag? Those are flipped on an off all the time. The server could flip in a /attachment any time. I do not have 20 years of email client/server implemention experience behind me, so please excuse me if this is "yet another bad idea".

>Sent: 13 February, 2008 22:06
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: RE: [lemonade] Determining the "has attachment" 
>status of a message
>
>> Hi Ned,
>
>> SIEVE was just an idea to throw in - since it allow You to manage 
>> messages as they are placed into the mailbox. I don't know 
>much about 
>> server implementation, but it looked like a good place to add the 
>> necessary header field for me.
>
>It's "good" only in the sense that the operation can be 
>performed there and the necessary machinery (Sieve) already 
>exists. But this still doesn't answer the question of whether 
>or not this entire approach makes sense to standardize or even 
>document - I'm still waiting for a reasonable specification 
>for what it means to "have an attachment".
>
>I'm have to say I'm a bit flabbergasted that you would ask 
>such a question. The term "final delivery" has been used to 
>refer to the point where messages leave the transport 
>infrastucture for well over 25 years. Indeed, this term is so 
>commonly used and so well understood that Dave Crocker's new 
>email architecture document uses it but doesn't bother to 
>define it. (I guess maybe it needs to...
>Dave, take note.) It is also used in RFCs [2]821, [2]822, the 
>NOTARY specification, the Sieve specifications, and many many 
>many others.
>
>No, this is simply a retrieving a stored message, nothing more 
>and nothing less. The message has to have left the transport 
>infrastructure before anything like this can happen.
>
>And what we call this or similar operations is irrelevant. One 
>of the key guarantees IMAP provides is that messages the store 
>receives are immutable. The store doesn't modify them in any 
>way, and clients can be and frequently are written to take 
>advantage of this property. Any store that violates it - and 
>> If the header field cannot be done when the msg is received, 
>can it be 
>> done when the msg is sent (the msgs _are_ changed then - for 
>example, 
>> when they are signed).
>
>There are various schools of thought about whether or not it 
>is OK for modifications to occur to in-transit messages, 
>ranging from those who think pretty much anything goes to 
>those who see any changes beyond the prepending of trace 
>headers as flatly unacceptable. But regardless of the 
>treatment of in-transit messages, there seems to be fairly 
>broad agreement that modification at the boundaries of the 
>transport system, that is, during submission and final delivery, is OK.
>
>However, submission to the transport infrastructure occurs 
>within the administrative domain of the message originator, 
>which often isn't the same as that of the recipient. This 
>means that submission is not something the recipient's system 
>has any control over. OTOH, it is axiomatic that final 
>delivery occurs within the administrative domain of the 
>recipient. And since messages can be modified at this point 
>(but not later), it's the last opportunity to add or change 
>header fields. After that some other mechanism such as a flag 
>or annotation has to be used.
>
>I should also point out the other issue with this: Final 
>delivery only applies to messages that have been submitted for 
>transport. It doesn't apply to messages clients insert into 
>the store directly. In this case the message is immutable once 
>it leaves the client and even if you implement Sieve 
>processing at this point its results cannot be conveyed by 
>adding a header field.
>
>				Ned
>

---

From: Philip Van Hoof <[email-masked]>
Date: Thu, 14 Feb 2008 10:34:13 +0100

> at the boundaries of the transport system, that is, during submission and final

Letting the IMAP server add a "X-Has-Attachment: Yes" header or perhaps
even a Has-IMAP-Attachment to specify that it was the IMAP server who
added it, works for me as client developer (if I can BODY.PEEK that in
the HEADERS).

It doesn't have to be an internal variable like internaldate. I'm not
against letting the IMAP server add headers. In fact I would even be in
favour of letting the IMAP server make sure that the structure of the
messages is guaranteed to be alright and things like that. 

If that makes IMAP a more reliable store, by precisely specifying and
guaranteeing its behaviour, then that makes IMAP a better standard in my
opinion.

---

From: Ned Freed <[email-masked]>
Date: Thu, 14 Feb 2008 06:59:21 -0800 (PST)

> I have one more suggestion: a flag? Those are flipped on an off all the time.
> The server could flip in a /attachment any time.

Yes, either a flag or an annotation could be used. Flags have the advantage of
being defined in the base protocol and there's already a Sieve extension to set
them. So you could use a delivery- and append-time sieve scripts to set this
flag and not need any additional capabities beyond stuff that's already being
worked on.

But this now gets into the issues Mark was talking about in regards to server
limitations and extension support. And we're still no closer to a clear
understanding of what this bit really means and when to set it. And this brings
us back to my question: What needs standardizing here?

				Ned

---

From: "Vaudreuil, Greg M \(Greg\)" <[email-masked]>
Date: Thu, 14 Feb 2008 09:12:42 -0600

The has_attachment flag is purely a UI advisory.  We need to standardize
the name of the flag, and leave it to the server administrator and
client to iterate to a meaning.  To Marks's point this is one that may
change over time.

The quality of the advisory becomes a service differentiator, not an
issue of interoperability.  Interoperability is limited to the client
being able to identify and interpret the flag set by the server.

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ned Freed
Sent: Thursday, February 14, 2008 9:59 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [lemonade] Determining the "has attachment" status of a
message

> The server could flip in a /attachment any time.

Yes, either a flag or an annotation could be used. Flags have the
advantage of
being defined in the base protocol and there's already a Sieve extension
to set
them. So you could use a delivery- and append-time sieve scripts to set
this
flag and not need any additional capabities beyond stuff that's already
being
worked on.

But this now gets into the issues Mark was talking about in regards to
server
limitations and extension support. And we're still no closer to a clear
understanding of what this bit really means and when to set it. And this
brings
us back to my question: What needs standardizing here?

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 14 Feb 2008 07:48:41 -0800 (PST)

> added it, works for me as client developer (if I can BODY.PEEK that in

You won't be nearly as happy a client developer when this leads to
inconsistencies in message sizes and causes interop problems.

> messages is guaranteed to be alright and things like that.

I'm sorry, but what you are for or against isn't relevant in this case. This is
black letter protocol design: IMAP guarantees that message content is immutable
and clients are written to depend on this being the case.

> guaranteeing its behaviour, then that makes IMAP a better standard in my

What makes IMAP reliable is that it's behavior is already precisely and
reliably defined: It doesn't change message content.

				Ned

---

From: Philip Van Hoof <[email-masked]>
Date: Fri, 15 Feb 2008 02:41:39 +0100

> inconsistencies in message sizes and causes interop problems.

Sure, and perhaps you are right. Therefore letting the IMAP server set a
\$HasAttachment flag is probably a better idea.

Works for me too.

---

From: Ned Freed <[email-masked]>
Date: Thu, 14 Feb 2008 17:53:25 -0800 (PST)

> client to iterate to a meaning.

So the proposal is to write a short RFC saying "if you want a way to tell
clients whether or not a message has an attachment - whatever that means - use
this flag". I would characterize such a specification as Mostly Harmless, I
guess. I do predict some measure of difficulty getting such a specification
approved absent at least a basic definition of what it means for a message to
have an attachment.

> To Marks's point this is one that may change over time.

Um, I think that was one of my points, not Mark's. If I understand Mark's point
correctly (and Mark please correct me if I don't) he sees all of this as a
waste of time since too many server implementors aren't bothering to properly
implement more basic parts of the IMAP specification, let alone all these
myriad extensions we're now discussing. So like it or not, clients have to be
prepared to do all the heavy lifting themselves.

> being able to identify and interpret the flag set by the server.

Greg, I'm afraid that on this one I have to side with Mark. I see very little
evidence that anyone is basing implementation selection decisions on the
general availability of these sorts of features. To the extent that features
are used as a selection criteria, it's invariably the specific features someone
thinks they need in the very short term, irrespective of what those features
are.

This is the main reason I rarely participate in profile discussions - I fail to
see the point.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 15 Feb 2008 13:18:00 +0000

>b uid fetch (result set from a) bodystructure
As a side note: one can use SEARCHRES to do "result set from":

a uid search RETURN (SAVE) or header content-type multipart header content-disposition attachment
b uid fetch $ bodystructure

>worth the bother... do you?
Hmm, I need to think about this part.

---

From: Eric Burger <[email-masked]>
Date: Fri, 15 Feb 2008 12:01:10 -0500

[Was: Re: [lemonade] Determining the "has attachment" status of a message]

This posting is in my capacity as chair of lemonade, not as a participant.
Feel free to discuss the logic, as since I am also posting in my capacity as
a human, there is a large chance that I am wrong.  This message contains no
decisions on protocol discussion.  However, it does stipulate behaviors we
expect work group participants to follow.  As the IETF is a consensus-based
organization, if you have a problem with this, please bring it up with the
chairs; if you have a serious problem, please bring it up with the area
directors.

This is a long post.  If you do not get to the bottom of the message, I
would like to point out up here that I am reiterating one of Ned's
philosophies in the post.  If you get to the bottom, you will see what I am
talking about.  This post is in no way targeted toward Ned.

There have been a number of postings that suggest that because one or more
large messaging vendors have a poor track record of implementing IETF
protocols, we cannot expect them to implement a this or that IETF lemonade
proposal in the future.  Given their dominant position in the market, we
should not attempt to propose this or that lemonade proposal as it would not
be implemented anyway.

Indulge me with the following logic.

1.  Consumers of lemonade have a well-known relationship with the
    administrator of the IMAP server offering lemonade services.
    a. If I am an enterprise consumer, my I.T. Department
       has bought a lemonade compliant IMAP server and most
       likely tells me which devices I am allowed to use.
       Today, this looks like Windows Mobile for Exchange
       usersd; BlackBerry or Gold for BES or Gold users
       (gatewaying to IMAP, Exchange, or whatever); or
       iPhone or other IMAP clients for legacy IMAP users.
    b. If I am a typical mobile consumer, I am getting
       my mobile e-mail from my mobile service provider.
    c. If I am a power mobile consumer, I am most likely
       using my own IMAP server.  If not, I know who does
       administer my IMAP server.

2.  Given a well-known relationship with the administrator of
    the IMAP server, if my mobile e-mail does not work due
    to a poor implementation of the server, I know whom to
    complain to.  Using the cases above:
    a. My I.T. Helpdesk
    b. My mobile service provider customer service desk
    c. My ISP (or myself)

3.  If one accepts the above logic, then I would offer
    poor implementations get detected in the right place,
    or at least by people who are in a position to figure
    out if there is a client or server problem.

4.  Normally, the market enforces compliance.  If a vendor
    is not compliant, the market should punish them by
    buying compliant implementations.  [Before you respond,
    read on...]

5.  Some servers have such dominant market share that it
    becomes a de facto standard.  Oftentimes the market
    interprets implementation errors or non-interoperable
    implementations on the part of such a server to be
    errors in the compliant client.

What does this mean for us?  For example, some people say the evil company
[insert your personal favorite target here]  will not implement what we
specify here.  This could be by design.  That is, implement just enough to
say Standard but not enough to really remain proprietary.  This could also
be by honest mistakes (implementation errors) or a particular interpretation
of ambiguous specifications.  This situation is an objective reality.
However, we have some choices in how to deal with this reality.

One choice is to say, "No matter what we do, no one will listen to us, so we
should not bother."  Another choice is to say, "Standards are important, and
especially for the new work of lemonade, there is a chance most of the
server vendors, big ones included, just might implement the specifications
correctly."

I am a strong believer in microeconomics.  I personally believe
microeconomics (the market) will have us converge on the most efficient
solution.

If you are seriously in the camp that evil people will be evil and there is
nothing us little people can do about it, please drop off the list.  In my
market-based approach to resource allocation, if most of the contributors
here believe that lemonade will not make a difference, then most of the
contributors will stop contributing to lemonade.  In this case, I will
happily close down the work group and stop wasting everybody's time.

If you are in the camp that says we can help change the world for the better
by extending the reach of messaging in a ubiquitous manner, even to devices
of lesser capability or over impaired networks, please accelerate your
efforts to write, review, comment upon, and approve the documents remaining
in our work plan.  When we are finished, the market will tell us whether we
were right or not.

Hence the new Subject for this thread: Fix It and Deal with the Problem, or
Go Away.  If there is a way to fix the Internet messaging infrastructure to
support the lemonade environment, please fix it with as much speed as
possible.  If you think that no matter what we do nothing will change,
please go away and stop distracting those that do want to finish this work.

Lastly, as a chair I need to make it abundantly clear that I do NOT consider
Ned in the "in the way" camp.  He says how he operates very clearly (sorry
to pull this slightly out of context):

> This is the main reason I rarely participate in profile discussions - I fail
> to see the point.

If you look at the archives, Ned is eerily quiet on topics he considers to
be tilting at windmills.  For this, as Chair, I am grateful and honor his
methods of participation.

I would also, as Chair, point out the lemonade list and work group is NOT
the venue for debate as to whether the work of this group is a stupid waste
of time or an honorable investment.  I would expect that discussion to occur
at the IMC or some other venue.  [Chair hat off - if there is no venue for
people to blow off steam, I can open up a blog for this purpose at
standardstrack.com.]  If you personally come to a personal decision that
this work is for naught, please do send the chairs or Area Directors a note
so we can tell the difference between you traveling or taking a vacation and
you leaving.

Again, I PROMISE that if enough people think no one is going to actually
implement lemonade, we will close the group.

Conversely, I would request those that remain promise to use realistic
measures for choosing approaches and mechanisms for the implementation of
lemonade.  Complexity, difficulty to achieve interoperability, consuming
inordinate amounts of client resources, network resources, or server
resources are all great reasons to reject a particular proposal.  "We will
never get brand X to implement a particular proposal" is NOT an acceptable
reason to reject a proposal.

NOTE WELL: Consider this a first warning that the chairs will consider
postings in the vein of, "We cannot do X because we will never get server
vendor M to implement it" as disruptive to the consensus-driven process for
developing standards.  NOTE WELL THE VERY SPECIFIC USE OF BCP 83 / RFC 3683
LANGUAGE HERE AND THE IMPLICATIONS THEREOF FOR REPEATED VIOLATION OF THIS
NOTE WELL.

> This is the main reason I rarely participate in profile discussions - I fail

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Eric Burger <[email-masked]>
Date: Fri, 15 Feb 2008 12:48:01 -0500

[as a contributor]

If it is impossible for the server to determine there is an attachment, it
is impossible for the client to determine there is an attachment.  However,
we have tons of existence proofs that clients can determine there is an
attachment.

I would concur there are composition clients that screw up MIME.  However, I
would offer we let the market fix that.

I like Greg's proposal because if, with today's technology, it is hard to
determine if a message has an attachment, we can leave that to implementers
to figure it out.  We only have to provide a mechanism for flagging the
message as having attachments.

I am also hesitant to publish *an* algorithm for determining a message has
attachments, unless it is 100% or is part of a document that specifies how a
composition client composes a message with attachments.  Otherwise, we will
be left with *the* algorithm for determining a message has attachments,
whether it is right or wrong.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 16 Feb 2008 09:16:17 +0100

Eric Burger writes:
> [as a contributor]
>
> If it is impossible for the server to determine there is an 
> attachment, it is impossible for the client to determine there is an 
> attachment.
> [...]

That doesn't follow. Each client can work to its own standard, but a 
server has to  satisfy them all.

I have messages (real ones, sent from real people to me personally) 
where clients can reasonably take opposite views of whether there are 
attachments.

Arnt

---

From: Eric Burger <[email-masked]>
Date: Sun, 24 Feb 2008 19:26:24 -0500

To the participants of the lemonade work group:

It has come to my attention that it would be easy to interpret the original
posting below as a personal attack on Mark.  In particular, that I would
have desired Mark to leave the work group.  In retrospect, I realize my
message was overly strong.  Moreover, I should not have involved the work
group.  By any measure, I went out of bounds, and for that, I offer my
apology to Mark.

Mark has been a valuable contributor to IMAP for many years, and to lemonade
in particular.  Without his contributions, we would not have probably the
most important advance in the state of lemonade Internet e-mail, the Trio.

To Mark:
I am personally grateful for how you handled what was clearly my gaffe.
Please accept my personal apology.  I hope you continue to believe the work
of the lemonade work group is of value, and please do not "Go Away."

Regards to all,
Eric

On 2/15/08 12:01 PM, "Eric Burger" <[email-masked]> wrote:

>> to
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and have
> received this message in error, please immediately return this by email and
> then delete it.

---

From: Philip Guenther <[email-masked]>
Date: Mon, 25 Feb 2008 22:01:27 -0700

> we have tons of existence proofs that clients can determine there is an

Sure, but that doesn't mean the result of a server's test will be useful 
to any given client when the client has no way of knowing what the 
server's algorithm is.

What is a client supposed to do with a has-attachment indication that may, 
from the client's point of view, suffer from both false negatives and 
false positives?  Why bother asking if for something when you can't 
reliably use the result?

> I like Greg's proposal because if, with today's technology, it is hard 
> to determine if a message has an attachment, we can leave that to 
> implementers to figure it out.  We only have to provide a mechanism for 
> flagging the message as having attachments.

I'm with Ned in that I have a hard time believing that "quality of 
has-attachment flag" will come anywhere near the top of the radar for 
people writing RFPs.

If you reject the need for an absolute standard for what it means to have 
an attachment, then servers can't be judged on objective accuracy.  They 
can only be judged on how their interpretation interacts with the 
customer's mix of clients.  If that really was a key point in deciding 
whether a server "got the deal", it could drive server implementors into 
trying to guess the "make and model" of a given client session so as to 
'tune' its has-attachment responses for that client.  That seems like a 
Bad Thing to me.

> I am also hesitant to publish *an* algorithm for determining a message 
> has attachments, unless it is 100% or is part of a document that 
> specifies how a composition client composes a message with attachments. 
> Otherwise, we will be left with *the* algorithm for determining a 
> message has attachments, whether it is right or wrong.

At least if it could guaranteed to suffer _either_ no false positive _or_ 
no false negatives, then the resulting flag would be potentially useful as 
an optimization.  Then would come the "how useful an optimization is this" 
discussion.

Philip Guenther
[email-masked]

---

From: Mark Crispin <[email-masked]>
Date: Mon, 25 Feb 2008 21:18:45 -0800

+1 on all points.

Strongly.

Let me be blunt.  A "has attachment" indicator is useless without a 
specific, unambiguous, definition for what "has attachment" means.  And 
the moment you make such a definition, the majority of implementors will 
reject that definition since it does not correspond with what they believe 
it should be.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 26 Feb 2008 09:53:22 -0500

Hi Philip,

--On February 25, 2008 10:01:27 PM -0700 Philip Guenther 
<[email-masked]> wrote:

> What is a client supposed to do with a has-attachment indication that
> may,  from the client's point of view, suffer from both false negatives
> and  false positives?  Why bother asking if for something when you can't
> reliably use the result?

And over time clients may want to have an even more sophisticated indicator 
of message types beyond just has-attachment. e.g. in Mulberry it can 
display an attachment icon that is "badged" with addition detail for 
"styled text message" (contains a text/html alternative), "signed message" 
(multipart/signed), "encrypted message" (multipart/encrypted), "calendar 
component" (contains a text/calendar). All of that is done by fetching the 
BODYSTRUCTURE and doing a client-side analysis.

The original premiss for wanting has-attachment was that BODYSTRUCTURE is 
too expensive. Well perhaps it might be better to work on making that less 
expensive. We know we already have compression that makes a big difference 
in reducing the number of bytes. We could also have a lightweight 
BODYSTRUCTURE alternative that just returns the MIME structure detail in a 
nested list with the option to only go down to a specified depth - none of 
the other content-xxx headers, parameters, length etc would need to be 
sent. That would also significantly reduce the size of the response. This 
overview of the MIME structure can then be used by clients to do any 
"has-attachment" type analysis on its own.

-- 
Cyrus Daboo

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 26 Feb 2008 07:26:38 -0800

I thought about it some more, and came to the realization that even
clients will get it wrong.  What is a multipart/mixed with an audio/alaw
with a critical-context of voice-message?  It really depends.

You win. 

-----Original Message-----
From: Philip Guenther [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2008 12:01 AM
To: Eric Burger
Cc: [email-masked]
Subject: Re: [lemonade] Determining the "has attachment" status of a
message

On Fri, 15 Feb 2008, Eric Burger wrote:
> attachment.  However, we have tons of existence proofs that clients 
> can determine there is an attachment.

> implementers to figure it out.  We only have to provide a mechanism 
> for flagging the message as having attachments.

If you reject the need for an absolute standard for what it means to
have an attachment, then servers can't be judged on objective accuracy.
They can only be judged on how their interpretation interacts with the
customer's mix of clients.  If that really was a key point in deciding
whether a server "got the deal", it could drive server implementors into
trying to guess the "make and model" of a given client session so as to
'tune' its has-attachment responses for that client.  That seems like a
Bad Thing to me.

> message has attachments, whether it is right or wrong.

At least if it could guaranteed to suffer _either_ no false positive
_or_ no false negatives, then the resulting flag would be potentially
useful as an optimization.  Then would come the "how useful an
optimization is this" 
discussion.

Philip Guenther
[email-masked]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 26 Feb 2008 16:28:04 +0100

Cyrus Daboo writes:
> The original premiss for wanting has-attachment was that BODYSTRUCTURE 
> is too expensive. Well perhaps it might be better to work on making 
> that less expensive. We know we already have compression that makes a 
> big difference in reducing the number of bytes.

FWIW. An impressively thorough investigation (30 seconds) shows that the 
compressed response for 'fetch x:y (uid envelope bodystructure)' is 
eight bytes bigger than that to 'fetch x:y (uid envelope)' per message 
when x:y spans a few hundred messages. Almost too small to believe, so 
YMMV and I'd be interested to hear about it.

Arnt

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 26 Feb 2008 10:33:34 -0500

Hi Arnt,

--On February 26, 2008 4:28:04 PM +0100 Arnt Gulbrandsen <[email-masked]> 
wrote:

> compressed response for 'fetch x:y (uid envelope bodystructure)' is eight
> bytes bigger than that to 'fetch x:y (uid envelope)' per message when x:y
> spans a few hundred messages. Almost too small to believe, so YMMV and
> I'd be interested to hear about it.

What percentage of those message actually contained "attachments" - i.e. 
multiparts? Or can you estimate the average number of parts per message for 
those messages?

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 Feb 2008 10:55:26 -0500

> The original premise for wanting has-attachment was that BODYSTRUCTURE is 
> BODYSTRUCTURE alternative

I think the original premise is short-sighted.  Even for cellular 
networks, bytes over the air are getting cheaper and faster at a much 
greater rate than protocols get developed.  I'd really hate to gum up 
the protocol with something like this, just to provide a pretty minor 
optimization that won't be needed in two years anyway.

Please, let's declare this one dead, yes?

Barry

---

From: Philip Van Hoof <[email-masked]>
Date: Tue, 26 Feb 2008 17:22:54 +0100

> YMMV and I'd be interested to hear about it.

That's interesting. Because with those numbers it would not really make
a lot of sense to add things to the protocol for a has-attachment
marker: 

In stead, just require either TLS with compression and/or COMPRESS in
Lemonade.

The eight bytes make sense to me if the majority of strings in the body-
structure response are the same for most messages. Which sounds to me
like the case for average mailboxes. So it's not a very surprising
number (although admittedly very small). 

Would it be possible to do similar tests with larger mailboxes?

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 27 Feb 2008 10:46:02 +0100

Cyrus Daboo writes:
> What percentage of those message actually contained "attachments" - 
> i.e. multiparts?

I know it can be counted, but I don't know how, I'm afraid.

> Or can you estimate the average number of parts per message for those 
> messages?

That I can count. 2.1.

Arnt
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 27 Feb 2008 10:53:13 +0100

Philip Van Hoof writes:
> That's interesting. Because with those numbers it would not really 
> make a lot of sense to add things to the protocol for a 
> has-attachment marker:
>

We already do that.

> The eight bytes make sense to me if the majority of strings in the 
> body-structure response are the same for most messages. Which sounds 
> to me like the case for average mailboxes. So it's not a very 
> surprising number (although admittedly very small).
>

Deflate doesn't do noticeably worse when the input size increases, so I 
think that's a waste of time. But it's easy to do, so if you're 
curious, go ahead. If you want an account on a server which supports 
COMPRESS=DEFLATE I can give you one.

Arnt

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 27 Feb 2008 10:21:56 -0500

Hi Arnt,

> I know it can be counted, but I don't know how, I'm afraid.

Ha - turns out that Mulberry has a mailbox column display for the number of 
parts in a message. So choosing that and sorting by that column allows a 
quick determination of this.

So for my home and work Inboxes I have:

home: 35% of messages had more than one part
work: 40% of messages had more than one part

>> Or can you estimate the average number of parts per message for those

This is the average number of "leaf" nodes in the MIME hierarchy as that is 
what Mulberry counts (i.e. multiparts are not counted):

home: 1.6 average number of parts per message
work: 1.5 average number of parts per message

Of course these numbers will varying a lot based on different user 
"profiles" and types of activity.

-- 
Cyrus Daboo

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 28 Feb 2008 17:51:30 -0800

And how many are X-TNEF?  Would a "smart" client call that an
attachment? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Cyrus Daboo
Sent: Wednesday, February 27, 2008 10:22 AM
To: Arnt Gulbrandsen; [email-masked]
Cc: Philip Guenther
Subject: Re: [lemonade] Determining the "has attachment" status of a
message

Hi Arnt,

--On February 27, 2008 10:46:02 AM +0100 Arnt Gulbrandsen
<[email-masked]>

> I know it can be counted, but I don't know how, I'm afraid.

Ha - turns out that Mulberry has a mailbox column display for the number
of parts in a message. So choosing that and sorting by that column
allows a quick determination of this.

> That I can count. 2.1.

This is the average number of "leaf" nodes in the MIME hierarchy as that
is what Mulberry counts (i.e. multiparts are not counted):

--
Cyrus Daboo

---

From: Ned Freed <[email-masked]>
Date: Fri, 29 Feb 2008 08:24:56 -0800 (PST)

> And how many are X-TNEF?  Would a "smart" client call that an

Given that TNEF can be (a) Markup for the preceeding text part (b) An
attachment container, or (c) Both, absent actual analysis of the content
there's no way to tell. And this ignores the common (d) Client can't deal with
TNEF anyway so might as well ignore it entirely, which in addition to being
client specific doesn't exactly fit into either boolean possibility, does it?

				Ned

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 29 Feb 2008 08:45:12 -0800

Precisely.  This is why I gave up on the concept of the server figuring
out "has attachment."

-----Original Message-----
From: Ned Freed [mailto:[email-masked]] 
Sent: Friday, February 29, 2008 11:25 AM
To: Eric Burger
Cc: Cyrus Daboo; Arnt Gulbrandsen; [email-masked]; Philip Guenther
Subject: Re: [lemonade] Determining the "has attachment" status of a
message

Given that TNEF can be (a) Markup for the preceeding text part (b) An
attachment container, or (c) Both, absent actual analysis of the content
there's no way to tell. And this ignores the common (d) Client can't
deal with TNEF anyway so might as well ignore it entirely, which in
addition to being client specific doesn't exactly fit into either
boolean possibility, does it?

				Ned