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

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 22 April 2010 11:31 UTC

Return-Path: <alexey.melnikov@isode.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 2D7033A6801; Thu, 22 Apr 2010 04:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.452
X-Spam-Level:
X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599]
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 mYPtWkTsizlF; Thu, 22 Apr 2010 04:31:43 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 152903A6840; Thu, 22 Apr 2010 04:31:42 -0700 (PDT)
Received: from [172.16.2.165] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <S9AzkwBHThZa@rufus.isode.com>; Thu, 22 Apr 2010 12:31:31 +0100
Message-ID: <4BD03382.7090705@isode.com>
Date: Thu, 22 Apr 2010 12:31:14 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <ned.freed@mrochek.com>
References: <19396.29206.787824.69029@fireball.kivinen.iki.fi> <01NM7KYS0I420000BI@mauve.mrochek.com>
In-Reply-To: <01NM7KYS0I420000BI@mauve.mrochek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-freed-sieve-notary.all@tools.ietf.org, 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: Thu, 22 Apr 2010 11:31:44 -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)