headers
Tim Showalter | 3 Apr 2001 03:25

Re: More ANNOTATE comments (was Re: Progress? Meeting?)

Randall Gellens <randy <at> qualcomm.com> 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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Cyrus Daboo | 3 Apr 2001 16:30

Re: More ANNOTATE comments (was Re: Progress? Meeting?)

--On Monday, April 02, 2001 6:25 PM -0700 Tim Showalter <tjs <at> mirapoint.com> 
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
Permalink | Reply | 5 comments |
headers
Tim Showalter | 4 Apr 2001 00:59

Re: More ANNOTATE comments (was Re: Progress? Meeting?)

Cyrus Daboo <daboo <at> cyrusoft.com> writes:

> --On Monday, April 02, 2001 6:25 PM -0700 Tim Showalter <tjs <at> mirapoint.com>
> 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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alexey Melnikov | 4 Apr 2001 01:11

Re: More ANNOTATE comments (was Re: Progress? Meeting?)

Tim Showalter wrote:

> Cyrus Daboo <daboo <at> cyrusoft.com> writes:
>
> > --On Monday, April 02, 2001 6:25 PM -0700 Tim Showalter <tjs <at> mirapoint.com>
> > 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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tim Showalter | 4 Apr 2001 02:46

Re: More ANNOTATE comments (was Re: Progress? Meeting?)

Alexey Melnikov <mel <at> messagingdirect.com> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lyndon Nerenberg | 4 Apr 2001 03:24

Re: More ANNOTATE comments (was Re: Progress? Meeting?)

> 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
Permalink | Reply | 1 comment |
headers
Tim Showalter | 4 Apr 2001 03:46

Re: More ANNOTATE comments (was Re: Progress? Meeting?)

Lyndon Nerenberg <lyndon <at> MessagingDirect.COM> 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
Permalink | Reply | 0 comments |
headers
Alex Wetmore | 17 Apr 2001 20:06
Picon

SORT and sort-key

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
Permalink | Reply | 1 comment |
headers
Mark Crispin | 17 Apr 2001 20:28

Re: SORT and sort-key

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Segmuller | 17 Apr 2001 21:28
Picon
Favicon

I-D ACTION:draft-segmuller-imap-structure-00.txt

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:
mailserv <at> ietf.org.
In the body type:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane