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

Alexey Melnikov <> Thu, 22 April 2010 11:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D7033A6801; Thu, 22 Apr 2010 04:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.452
X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mYPtWkTsizlF; Thu, 22 Apr 2010 04:31:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 152903A6840; Thu, 22 Apr 2010 04:31:42 -0700 (PDT)
Received: from [] ( []) by (submission channel) via TCP with ESMTPA id <>; Thu, 22 Apr 2010 12:31:31 +0100
Message-ID: <>
Date: Thu, 22 Apr 2010 12:31:14 +0100
From: Alexey Melnikov <>
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 <>
References: <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] Review of draft-freed-sieve-notary-07
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
>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
>  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)