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

Ned Freed <ned.freed@mrochek.com> Sat, 24 April 2010 21:46 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532973A6AA3; Sat, 24 Apr 2010 14:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.855
X-Spam-Level:
X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41EdRYVOSjb6; Sat, 24 Apr 2010 14:46:01 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 4E4A13A6A8E; Sat, 24 Apr 2010 14:46:01 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NMC1AXOBSW00KSB9@mauve.mrochek.com>; Sat, 24 Apr 2010 14:45:46 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NMAT47YVRK0000BI@mauve.mrochek.com>; Sat, 24 Apr 2010 14:45:43 -0700 (PDT)
Message-id: <01NMC1AVJ6D80000BI@mauve.mrochek.com>
Date: Sat, 24 Apr 2010 14:44:43 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 22 Apr 2010 12:31:14 +0100" <4BD03382.7090705@isode.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> <01NM7KYS0I420000BI@mauve.mrochek.com> <4BD03382.7090705@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1272145166; bh=qXkdKU+y+Cb39xhJTPS3zZbJ+jaPC4a4cfAdnK0k6hw=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=Oa1qUeFRv26Galq19PHU5ml+9XL6uI3jDwE7np6mWoqU5cL7+3PZG/PY0ByLtLv5P dpfq7nCJvaavHfB0Jlj9l/HsDpL9mvaAHCeVtpEmGnaKWZGEsoZsbRmj8AxqSvCQFh 5HJUkYPe08cw0k+WfLzYd22uJKE5V5ZvhirtL934=
X-Mailman-Approved-At: Sat, 24 Apr 2010 14:47:17 -0700
Cc: draft-freed-sieve-notary.all@tools.ietf.org, Ned Freed <ned.freed@mrochek.com>, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-freed-sieve-notary-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Apr 2010 21:46:02 -0000

> 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