Re: [secdir] Review of draft-freed-sieve-notary-07

[Ned Freed <[e-mail]>]

> Ned Freed wrote:
>  [...]

> >>This can cause problems for the original sender, as he is now getting
> >>the deliver status notifications which he has not requested. The draft
> >>does not explictly specify, but I do assume that the sieve redirect
> >>keeps the original sender intact,
> >>
> >>
> >Sieve redirect is defined in RFC 5228 and it doesn't specify whether the
> >original address is used or the address of the Sieve owner. (What it does say
> >is that if the original message had an empty envelope from, any redirected
> >message must also have an empty envelope from. This prevents certain especially
> >pernicious loops from forming, but I don't see it as relevant to this
> >discussion.)
> >
> >Considering redirect behavior further, it does raise an issue that needs to be
> >addressed in this document, but it's a usability issue, not a security issue.
> >Specifically, what does it mean to add a DSN request or activate deliverby
> >when you don't know where these notifications are going to go? This ruins
> >the usability of both redirect-dsn and redirect-deliverby. I therefore
> >propose adding the following text to redirect-dsn and similar text to
> >redirect-deliverby:
> >
> >  RFC 5228 does not require any particular envelope sender address be associated
> >  with redirected messages. However, the redirect-dsn extension isn't terribly
> >  useful if the place where the delivery status notifications are sent isn't
> >  known. Accordingly, when either :notify or :ret is specified and the envelope
> >  sender address isn't empty, implementations MUST set the envelope sender
> >  address to the address of the sieve owner.
> >
> >
> This looks good to me, so I've entered 2 RFC Editor notes (one for
> redirect-dsn and a similar one for redirect-deliverby)

Ggood. I dp think this has reached the point where a new draft is needed,
especially if  we also decide to pursue the whole absolute time thing.

				Ned