Subject: RE: Re[2]: [lemonade] Replying to or editing a big list

From: "Burger, Eric" <[email-masked]>
Date: Wed, 30 Nov 2005 14:00:43 -0500

This is where theory clashes with reality.

The theory is that FETCH is for *body* parts.  Message envelope
information (metadata) does not get fetched, partially fetched, etc.

If you could fetch metadata and hack it, you could do stuff like take
out headers, change audit information, etc.

Oops: this is where reality steps in.  MUA's do this all the time when
replying or forwarding messages.  Is there any reason to or not to allow
this for metadata?

One thing I can think of is that to the mail system, body parts have
absolutely no semantic content.  You can hack the bodies to your heart's
content.  Nothing will break in the mail system, although the message
recipient may wonder what you are talking about.

That is NOT true for metadata.  Let's say I have a header that looks
like this:

To: [email-masked], [email-masked],
[email-masked]

And I want to take Glenn out of the list.  I could "poke out" his
address, possibly by overwriting it with a bunch of spaces or somehow
telling the server to delete a character range.

Now for the problem: let's say I or my MUA cannot count, and I say,
"drop characters 24-57.  Then my new To: line becomes:

To: [email-masked]@mirapoint.com

I then, later, get a DSN about not being able to find the hose
[email-masked].

That's a bit whacky.  Worse yet, the error occurs well after the user
enters the address modification.

I suppose we could say that MUA's MUST be well implemented, but that is
a weird requirement that obviously does not always hold.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Clark
Sent: Thursday, November 10, 2005 1:58 PM
To: [email-masked]
Subject: Re[2]: [lemonade] Replying to or editing a big list

> Transforming addresses from 2822 to 2821 form can be challenging. 
> Currently, there is an expectation that clients do this when creating 
> a reply.  Do we want to move this task to the submit server?

I wasn't in London, but I'm sure that this is what OMA has in mind.

Having downloaded the To and Cc lines of the message to the device,
they don't want to upload them again (plus having them duplicated,
in some sense, in the SMTP envelope). So they envisage a server-side
Reply-All and for good measure they have thrown in the kitchen-sink
ability to edit this list. I'm not sure that the editing is worthwhile,
but I can see the validity of building the address list on the server.

I note in passing that pulling the To and Cc lines out of the message
in the store also finesses the Bcc problem of storing the SMTP envelope
contents.

Jonathan Clark
Solutions Architect
Mirapoint Inc
--

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade