Subject: Re: I-D ACTION:draft-segmuller-imap-structure-00.txt
From: "Wolfgang Segmuller" <[email-masked]>
To: "IMAP Working Group" <[email-masked]>
Date: Tue, 17 Apr 2001 19:03:37 -0400
List-Id: <ietf-imapext.imc.org>

Two reasons:

1) For content-type is needed for the structure.  The content type and
subtype
    determine which structure-body is returned.

2) For both content-type and content-disposition, they are structured fields
that the server parses.

You could convince me to not return the content-disposition, but I didn't
want to complicate the format of the returned data to return an optional
structured field.

Wolfgang

----- Original Message -----
From: "Eric Burger" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 17, 2001 5:09 PM
Subject: RE: I-D ACTION:draft-segmuller-imap-structure-00.txt

>
> This would have been great for Critical Content!
>
> One question: if you allow for FIELDS and FIELDS.NOT, why are content-type
and content-disposition always returned?
>
>

From: Eric Burger <[email-masked]>
To: [email-masked]
Subject: RE: I-D ACTION:draft-segmuller-imap-structure-00.txt
Date: Tue, 17 Apr 2001 21:09:00 GMT
Sender: [email-masked]

This would have been great for Critical Content!

One question: if you allow for FIELDS and FIELDS.NOT, why are content-type and content-disposition always returned?

Date: Tue, 17 Apr 2001 15:28:35 -0400
From: Wolfgang Segmuller <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-segmuller-imap-structure-00.txt
Sender: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

Title : IMAP Extension: Structure
Author(s) : W. Segmuller
Filename : draft-segmuller-imap-structure-00.txt
Pages : 7
Date : 12-Apr-01

This document describes the STRUCTURE extension to the [IMAP]
protocol.  This extension allows the querying of the message
structure information in a self describing way.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-segmuller-imap-structure-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-segmuller-imap-structure-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-segmuller-imap-structure-00.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Wolfgang Segmuller

Date: Tue, 17 Apr 2001 11:28:25 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alex Wetmore <[email-masked]>
cc: <[email-masked]>
Subject: Re: SORT and sort-key
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 17 Apr 2001, Alex Wetmore wrote:
> How should servers handle the case of a single sort-key being specified
> multiple times?
>
> For instance:
> A282 SORT (SUBJECT FROM SUBJECT) UTF-8 SINCE 1-Feb-1994
> or more confusingly:
> A282 SORT (SUBJECT FROM REVERSE SUBJECT) UTF-8 SINCE 1-Feb-1994

Each of these would probably have the same result as the case without the
last SUBJECT.

For example, with SUBJECT FROM SUBJECT, it would only sort by FROM for
messages with identical SUBJECT; and the last SUBJECT would only be
considered with identical SUBJECT and identical FROM.  So that last
SUBJECT sort wouldn't do anything.

> I'd suggest that this should be an error, because it doesn't make sense
> to sort on the same key multiple times (the first example is equivelent
> to (SUBJECT FROM), and I'd guess that the second is as well).

I consider it to be a silly case; I accept it but I wouldn't criticize an
implementation that rejected.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Content-Class: urn:content-classes:message
Subject: SORT and sort-key
Date: Tue, 17 Apr 2001 11:06:18 -0700
From: "Alex Wetmore" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I've been reading the 6th draft of the SORT extension.

How should servers handle the case of a single sort-key being specified 
multiple times?

For instance:
A282 SORT (SUBJECT FROM SUBJECT) UTF-8 SINCE 1-Feb-1994

or more confusingly:
A282 SORT (SUBJECT FROM REVERSE SUBJECT) UTF-8 SINCE 1-Feb-1994

I'd suggest that this should be an error, because it doesn't make sense 
to sort on the same key multiple times (the first example is equivelent 
to (SUBJECT FROM), and I'd guess that the second is as well).

How do existing implementations handle this case?

thanks,
alex

To: Lyndon Nerenberg <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
From: Tim Showalter <[email-masked]>
Date: 03 Apr 2001 18:46:22 -0700
Lines: 10
Sender: [email-masked]

Lyndon Nerenberg <[email-masked]> writes:

> > I had assumed only one address would be available (the one that caused
> > the delivery to this mailbox).
> 
> Is the Return-Path: header visible in this context?

Yes, but Return-Path doesn't convey authentication.

Tim

Date: Tue, 3 Apr 2001 19:24:42 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Tim Showalter <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
Sender: [email-masked]

> I had assumed only one address would be available (the one that caused
> the delivery to this mailbox).

Is the Return-Path: header visible in this context?

--lyndon

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
From: Tim Showalter <[email-masked]>
Date: 03 Apr 2001 17:46:14 -0700
Lines: 38
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> > > >> Seems like a good idea.
> > > >
> > > > I disagree.  I'd prefer to have envelope information in with the
> > > > FETCH information.  Senders and recipients don't change, can't
> > > > be edited, and don't need ACLs.  This information can be
> > > > adequately contained within the existing fetch item syntax and
> > > > there's no need to put it into annotations.
> > > >
> > > > I think it might as well be a seperate extension.  I'd be happy
> > > > to do the work to see it done seperately.
> > >
> > > We need to be careful about how much information is exposed by the
> > > smtp envelope added to either annotations or fetch. In particular,
> > > the recipients field. Passing through all RCPT TO's can
> > > potentially expose bcc addressees to non-bcc addressees - I think
> > > this would be bad.
> >
> > I had assumed only one address would be available (the one that
> > caused the delivery to this mailbox).
> >
> > We also need to specify what happens on COPY.
> 
> I guess it has to be preserved.
> Plus we have to specify what to do on APPEND.
> 
> > What did XSENDER do, and how did it work out?
> 
> It specifies authenticated sender (AUTH parameter to MAIL FROM), for
> example for
> MAIL FROM: <[email-masked]> AUTH=[email-masked]
> XSENDER will return "[email-masked]".

I meant with regards to COPY and APPEND.  (Actually, the answer to
APPEND is probably NIL.)

Tim

Date: Tue, 03 Apr 2001 17:11:25 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
Sender: [email-masked]

Tim Showalter wrote:

> Cyrus Daboo <[email-masked]> writes:
>
> > --On Monday, April 02, 2001 6:25 PM -0700 Tim Showalter <[email-masked]>
> > wrote:
> >
> > >> Seems like a good idea.
> > >
> > > I disagree.  I'd prefer to have envelope information in with the FETCH
> > > information.  Senders and recipients don't change, can't be edited, and
> > > don't need ACLs.  This information can be adequately contained within
> > > the existing fetch item syntax and there's no need to put it into
> > > annotations.
> > >
> > > I think it might as well be a seperate extension.  I'd be happy to do
> > > the work to see it done seperately.
> >
> > We need to be careful about how much information is exposed by the smtp
> > envelope added to either annotations or fetch. In particular, the recipients
> > field. Passing through all RCPT TO's can potentially expose bcc addressees to
> > non-bcc addressees - I think this would be bad.
>
> I had assumed only one address would be available (the one that caused
> the delivery to this mailbox).
>
> We also need to specify what happens on COPY.

I guess it has to be preserved.
Plus we have to specify what to do on APPEND.

> What did XSENDER do, and how did it work out?

It specifies authenticated sender (AUTH parameter to MAIL FROM), for example for
MAIL FROM: <[email-masked]> AUTH=[email-masked]
XSENDER will return "[email-masked]".

Alexey

To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
From: Tim Showalter <[email-masked]>
Date: 03 Apr 2001 15:59:02 -0700
Lines: 29
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:

> --On Monday, April 02, 2001 6:25 PM -0700 Tim Showalter <[email-masked]>
> wrote:
> 
> >> Seems like a good idea.
> >
> > I disagree.  I'd prefer to have envelope information in with the FETCH
> > information.  Senders and recipients don't change, can't be edited, and
> > don't need ACLs.  This information can be adequately contained within
> > the existing fetch item syntax and there's no need to put it into
> > annotations.
> >
> > I think it might as well be a seperate extension.  I'd be happy to do
> > the work to see it done seperately.
> 
> We need to be careful about how much information is exposed by the smtp
> envelope added to either annotations or fetch. In particular, the recipients
> field. Passing through all RCPT TO's can potentially expose bcc addressees to
> non-bcc addressees - I think this would be bad.

I had assumed only one address would be available (the one that caused
the delivery to this mailbox).

We also need to specify what happens on COPY.

What did XSENDER do, and how did it work out?

Tim

Date: Tue, 03 Apr 2001 10:30:16 -0400
From: Cyrus Daboo <[email-masked]>
To: Tim Showalter <[email-masked]>, [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
Sender: [email-masked]

--On Monday, April 02, 2001 6:25 PM -0700 Tim Showalter <[email-masked]> 
wrote:

>> Seems like a good idea.
>
> I disagree.  I'd prefer to have envelope information in with the FETCH
> information.  Senders and recipients don't change, can't be edited, and
> don't need ACLs.  This information can be adequately contained within
> the existing fetch item syntax and there's no need to put it into
> annotations.
>
> I think it might as well be a seperate extension.  I'd be happy to do
> the work to see it done seperately.

We need to be careful about how much information is exposed by the smtp 
envelope added to either annotations or fetch. In particular, the 
recipients field. Passing through all RCPT TO's can potentially expose bcc 
addressees to non-bcc addressees - I think this would be bad.

-- 
Cyrus Daboo

To: [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
From: Tim Showalter <[email-masked]>
Date: 02 Apr 2001 18:25:46 -0700
Lines: 29
Sender: [email-masked]

Randall Gellens <[email-masked]> writes:

> At 11:39 PM -0700 3/18/01, Alexey Melnikov wrote:
> 
> >   >    /message/smtp-envelope
> >>         Defines the top-level of entries which together describe the
> >>         SMTP envelope used in delivery of the message.  There are no
> >>         attributes at this level.  The client SHOULD NOT modify the
> >>         /message/smtp-envelope entry or any sub-entries or any of their
> >>         attributes, except in messages which have the DRAFT flag set.
> >
> >  Randy, can you add /message/smtp-envelope/auth_sender for authenticated
> > sender
> 
> >  (SMTP AUTH extension)?
> >  This will replace Netscape XSENDER extension.
> 
> Seems like a good idea.

I disagree.  I'd prefer to have envelope information in with the FETCH
information.  Senders and recipients don't change, can't be edited, and
don't need ACLs.  This information can be adequately contained within
the existing fetch item syntax and there's no need to put it into
annotations.

I think it might as well be a seperate extension.  I'd be happy to do
the work to see it done seperately.

Tim

From: "Wolfgang Segmuller" <[email-masked]>
To: "IMAP Working Group" <[email-masked]>
Subject: Re: I-D ACTION:draft-segmuller-imap-structure-00.txt
Date: Tue, 17 Apr 2001 19:03:37 -0400
Sender: [email-masked]

Two reasons:

1) For content-type is needed for the structure.  The content type and
subtype
    determine which structure-body is returned.

2) For both content-type and content-disposition, they are structured fields
that the server parses.

You could convince me to not return the content-disposition, but I didn't
want to complicate the format of the returned data to return an optional
structured field.

Wolfgang

----- Original Message -----
From: "Eric Burger" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 17, 2001 5:09 PM
Subject: RE: I-D ACTION:draft-segmuller-imap-structure-00.txt

>
> This would have been great for Critical Content!
>
> One question: if you allow for FIELDS and FIELDS.NOT, why are content-type
and content-disposition always returned?
>
>

From: Eric Burger <[email-masked]>
To: [email-masked]
Subject: RE: I-D ACTION:draft-segmuller-imap-structure-00.txt
Date: Tue, 17 Apr 2001 21:09:00 GMT
Sender: [email-masked]

This would have been great for Critical Content!

One question: if you allow for FIELDS and FIELDS.NOT, why are content-type and content-disposition always returned?

Date: Tue, 17 Apr 2001 15:28:35 -0400
From: Wolfgang Segmuller <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-segmuller-imap-structure-00.txt
Sender: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

Title : IMAP Extension: Structure
Author(s) : W. Segmuller
Filename : draft-segmuller-imap-structure-00.txt
Pages : 7
Date : 12-Apr-01

This document describes the STRUCTURE extension to the [IMAP]
protocol.  This extension allows the querying of the message
structure information in a self describing way.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-segmuller-imap-structure-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-segmuller-imap-structure-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-segmuller-imap-structure-00.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Wolfgang Segmuller

Date: Tue, 17 Apr 2001 11:28:25 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alex Wetmore <[email-masked]>
cc: <[email-masked]>
Subject: Re: SORT and sort-key
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 17 Apr 2001, Alex Wetmore wrote:
> How should servers handle the case of a single sort-key being specified
> multiple times?
>
> For instance:
> A282 SORT (SUBJECT FROM SUBJECT) UTF-8 SINCE 1-Feb-1994
> or more confusingly:
> A282 SORT (SUBJECT FROM REVERSE SUBJECT) UTF-8 SINCE 1-Feb-1994

Each of these would probably have the same result as the case without the
last SUBJECT.

For example, with SUBJECT FROM SUBJECT, it would only sort by FROM for
messages with identical SUBJECT; and the last SUBJECT would only be
considered with identical SUBJECT and identical FROM.  So that last
SUBJECT sort wouldn't do anything.

> I'd suggest that this should be an error, because it doesn't make sense
> to sort on the same key multiple times (the first example is equivelent
> to (SUBJECT FROM), and I'd guess that the second is as well).

I consider it to be a silly case; I accept it but I wouldn't criticize an
implementation that rejected.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Content-Class: urn:content-classes:message
Subject: SORT and sort-key
Date: Tue, 17 Apr 2001 11:06:18 -0700
From: "Alex Wetmore" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I've been reading the 6th draft of the SORT extension.

How should servers handle the case of a single sort-key being specified 
multiple times?

For instance:
A282 SORT (SUBJECT FROM SUBJECT) UTF-8 SINCE 1-Feb-1994

or more confusingly:
A282 SORT (SUBJECT FROM REVERSE SUBJECT) UTF-8 SINCE 1-Feb-1994

I'd suggest that this should be an error, because it doesn't make sense 
to sort on the same key multiple times (the first example is equivelent 
to (SUBJECT FROM), and I'd guess that the second is as well).

How do existing implementations handle this case?

thanks,
alex

To: Lyndon Nerenberg <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
From: Tim Showalter <[email-masked]>
Date: 03 Apr 2001 18:46:22 -0700
Lines: 10
Sender: [email-masked]

Lyndon Nerenberg <[email-masked]> writes:

> > I had assumed only one address would be available (the one that caused
> > the delivery to this mailbox).
> 
> Is the Return-Path: header visible in this context?

Yes, but Return-Path doesn't convey authentication.

Tim

Date: Tue, 3 Apr 2001 19:24:42 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Tim Showalter <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
Sender: [email-masked]

> I had assumed only one address would be available (the one that caused
> the delivery to this mailbox).

Is the Return-Path: header visible in this context?

--lyndon

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
From: Tim Showalter <[email-masked]>
Date: 03 Apr 2001 17:46:14 -0700
Lines: 38
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> > > >> Seems like a good idea.
> > > >
> > > > I disagree.  I'd prefer to have envelope information in with the
> > > > FETCH information.  Senders and recipients don't change, can't
> > > > be edited, and don't need ACLs.  This information can be
> > > > adequately contained within the existing fetch item syntax and
> > > > there's no need to put it into annotations.
> > > >
> > > > I think it might as well be a seperate extension.  I'd be happy
> > > > to do the work to see it done seperately.
> > >
> > > We need to be careful about how much information is exposed by the
> > > smtp envelope added to either annotations or fetch. In particular,
> > > the recipients field. Passing through all RCPT TO's can
> > > potentially expose bcc addressees to non-bcc addressees - I think
> > > this would be bad.
> >
> > I had assumed only one address would be available (the one that
> > caused the delivery to this mailbox).
> >
> > We also need to specify what happens on COPY.
> 
> I guess it has to be preserved.
> Plus we have to specify what to do on APPEND.
> 
> > What did XSENDER do, and how did it work out?
> 
> It specifies authenticated sender (AUTH parameter to MAIL FROM), for
> example for
> MAIL FROM: <[email-masked]> AUTH=[email-masked]
> XSENDER will return "[email-masked]".

I meant with regards to COPY and APPEND.  (Actually, the answer to
APPEND is probably NIL.)

Tim

Date: Tue, 03 Apr 2001 17:11:25 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
Sender: [email-masked]

Tim Showalter wrote:

> Cyrus Daboo <[email-masked]> writes:
>
> > --On Monday, April 02, 2001 6:25 PM -0700 Tim Showalter <[email-masked]>
> > wrote:
> >
> > >> Seems like a good idea.
> > >
> > > I disagree.  I'd prefer to have envelope information in with the FETCH
> > > information.  Senders and recipients don't change, can't be edited, and
> > > don't need ACLs.  This information can be adequately contained within
> > > the existing fetch item syntax and there's no need to put it into
> > > annotations.
> > >
> > > I think it might as well be a seperate extension.  I'd be happy to do
> > > the work to see it done seperately.
> >
> > We need to be careful about how much information is exposed by the smtp
> > envelope added to either annotations or fetch. In particular, the recipients
> > field. Passing through all RCPT TO's can potentially expose bcc addressees to
> > non-bcc addressees - I think this would be bad.
>
> I had assumed only one address would be available (the one that caused
> the delivery to this mailbox).
>
> We also need to specify what happens on COPY.

I guess it has to be preserved.
Plus we have to specify what to do on APPEND.

> What did XSENDER do, and how did it work out?

It specifies authenticated sender (AUTH parameter to MAIL FROM), for example for
MAIL FROM: <[email-masked]> AUTH=[email-masked]
XSENDER will return "[email-masked]".

Alexey

To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
From: Tim Showalter <[email-masked]>
Date: 03 Apr 2001 15:59:02 -0700
Lines: 29
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:

> --On Monday, April 02, 2001 6:25 PM -0700 Tim Showalter <[email-masked]>
> wrote:
> 
> >> Seems like a good idea.
> >
> > I disagree.  I'd prefer to have envelope information in with the FETCH
> > information.  Senders and recipients don't change, can't be edited, and
> > don't need ACLs.  This information can be adequately contained within
> > the existing fetch item syntax and there's no need to put it into
> > annotations.
> >
> > I think it might as well be a seperate extension.  I'd be happy to do
> > the work to see it done seperately.
> 
> We need to be careful about how much information is exposed by the smtp
> envelope added to either annotations or fetch. In particular, the recipients
> field. Passing through all RCPT TO's can potentially expose bcc addressees to
> non-bcc addressees - I think this would be bad.

I had assumed only one address would be available (the one that caused
the delivery to this mailbox).

We also need to specify what happens on COPY.

What did XSENDER do, and how did it work out?

Tim

Date: Tue, 03 Apr 2001 10:30:16 -0400
From: Cyrus Daboo <[email-masked]>
To: Tim Showalter <[email-masked]>, [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
Sender: [email-masked]

--On Monday, April 02, 2001 6:25 PM -0700 Tim Showalter <[email-masked]> 
wrote:

>> Seems like a good idea.
>
> I disagree.  I'd prefer to have envelope information in with the FETCH
> information.  Senders and recipients don't change, can't be edited, and
> don't need ACLs.  This information can be adequately contained within
> the existing fetch item syntax and there's no need to put it into
> annotations.
>
> I think it might as well be a seperate extension.  I'd be happy to do
> the work to see it done seperately.

We need to be careful about how much information is exposed by the smtp 
envelope added to either annotations or fetch. In particular, the 
recipients field. Passing through all RCPT TO's can potentially expose bcc 
addressees to non-bcc addressees - I think this would be bad.

-- 
Cyrus Daboo

To: [email-masked]
Subject: Re: More ANNOTATE comments (was Re: Progress? Meeting?)
From: Tim Showalter <[email-masked]>
Date: 02 Apr 2001 18:25:46 -0700
Lines: 29
Sender: [email-masked]

Randall Gellens <[email-masked]> writes:

> At 11:39 PM -0700 3/18/01, Alexey Melnikov wrote:
> 
> >   >    /message/smtp-envelope
> >>         Defines the top-level of entries which together describe the
> >>         SMTP envelope used in delivery of the message.  There are no
> >>         attributes at this level.  The client SHOULD NOT modify the
> >>         /message/smtp-envelope entry or any sub-entries or any of their
> >>         attributes, except in messages which have the DRAFT flag set.
> >
> >  Randy, can you add /message/smtp-envelope/auth_sender for authenticated
> > sender
> 
> >  (SMTP AUTH extension)?
> >  This will replace Netscape XSENDER extension.
> 
> Seems like a good idea.

I disagree.  I'd prefer to have envelope information in with the FETCH
information.  Senders and recipients don't change, can't be edited, and
don't need ACLs.  This information can be adequately contained within
the existing fetch item syntax and there's no need to put it into
annotations.

I think it might as well be a seperate extension.  I'd be happy to do
the work to see it done seperately.

Tim