Re: Draft minutes from IETF 77

Thanks, minutes posted:
http://www.ietf.org/proceedings/10mar/minutes/sieve.txt

On Wed, Mar 31, 2010 at 12:58 AM, Alexey Melnikov
<alexey.melnikov <at> isode.com> wrote:
> Aaron Stone wrote:
>
>> From chat logs here:
>> http://www.ietf.org/jabber/logs/sieve/2010-03-24.txt
>> Please let me know if i missed or misunderstood anything.
>>
>
> Thanks Aaron. Some additions below:
>
>> SIEVE WG minutes - Anaheim, Mar. 2010
>>
>> Intro and document status update.
>>
>> Discussion of EAI: the EAI WG has dropped alternative address forms
>> and downgrading within the network. At this point, it is
>> straightforward to put a UTF8 address in a sieve and test against a
>> UTF8 address in a message. Clients do need to be aware that this
>> capability is present. Sieve EAI document should address this for
>> ManageSieve, ihave, requires.
>>
>
> Please record that Chris Newman has volunteered to look at this in a few
> months .
>
>> Discussion of notary: reviewers are needed, implementers please speak up.

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

I haven't checked this in details, but I think Tero found a couple of 
real problems.

From: Tero Kivinen <kivinen <at> iki.fi>
Subject: [secdir] Review of draft-freed-sieve-notary-07
Date: 2010-04-13 13:31:02 GMT

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This draft provides two things. Firstly it will provide ability for
sieve email filtering program to see the delivery status notification
and deliver by information from the envelope. Secondly it allows
setting those same parameters when using sieve redirect action.

The first part does not have security issues, but the second might
have, as it causes delivery notify emails to be sent which were not
originally requested by the original author.

Re: review of draft-freed-sieve-notary-06

On Mar 24, 2010, at 2:01 AM, Arnt Gulbrandsen wrote:

> On 03/24/2010 02:35 AM, Chris Newman wrote:
>> Section 4:
>> 
>>> orcpt - Match the original recipient, or ORCPT, value in decoded
>>> form associated with the TO address used in the SMTP RCPT TO
>> 
>> The term "in decoded form" is vague and can be interpreted different
>> ways (for example, I might consider removal of the "rfc822;" prefix to
>> be part of decoding .
> 
> That's how I implemented it.
> 
> I see it was wrong. (Ned, did I complain about missing examples when I reviewed?)
> 
>> I suggest this say "with xtext encoding (RFC 3461 section 4) removed".
> 
> I'd prefer that a script sees addresses in only one format.
> 
> Why is this justifiable:
>   envelope :orcpt :is "rfc822;max <at> example.org"
> when we also have
>   envelope :from :is "max <at> example.org"
> 
> That difference sounds like a good way to trip up human script authors.
> 
>> Q: Is there a reason this didn't deal with FUTURERELEASE (4865) at the
>> same time?

Status of draft-freed-sieve-notary

This document is past IESG review, but I am blocking approval of this 
document until the following SecDir issues (be Tero Kivinen) are resolved:

> Also in section 5, it should be made clear that the "bytime" can also
> be negative, if the bymode is "notify" and the message is already
> pasts is notification time.
>
> Section 5 also says that the "bytime" is "the initial integer part of
> the delive-by extension", but then comments that deliver-by by-time is
> decremented as message passes through the transport infrastructure.
> This does not make it clear whether the sieve filtering system should
> also decrement the number while message is waiting to be processed.
> I.e. if message was received earlier, but it took some time before the
> sieve email filter could be run on the message, should the "bytime" be
> the original time from the smtp MAIL FROM BY= part, or whether it is
> decremented.
> (This needs to be clarified for both "envelope-deliverby" and 
> "redirect-deliverby",

> because the answer is likely to be different for them.)
>
> Also the example in 5.1 is wrong, as it is only true if the sieve
> filter is run exactly when the deliver-by expired. It should compare
> whether the "bytime" is <= 0, not whether it is equal to 0 (note, that
> if the bymode is "return" then the "bytime" never should reach 0, as
> at that point mail is returned to the sender.
>
> In section 7 it should be made clear that ":bytime" parameter "<limit:
> number>" can be negative too, but it seems that RFC 5228 specifies
> that numbers can only be non-negative so I am not sure whether the