Subject: Re: [secdir] Secdir review of draft-ietf-sieve-refuse-reject-07

From: Aaron Stone <[email-masked]>
Date: Fri, 14 Nov 2008 06:27:11 -0800

My apologies for the extremely delayed reply to this review. I've at  
long last cleared enough time to get into the grist of the comments on  
this draft and prepare revision -08.

On Aug 14, 2008, at 5:51 AM, Carl Wallace wrote:

> 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.
>
> The draft refines the specification of the "reject" action and defines
> the new "ereject" action.  The "reject" action was originally  
> defined in
> RFC3028 but was omitted from its successor, RFC 5228.  Comments,
> questions and nits are below.
>
> - Section 2.1 references "return-path verification".  This is not
> defined in this specification (nor in any of the references that I
> checked).  Given that discard is a consequence, this should be defined
> or re-worded.  Is this the only reason why the message should be
> discarded?  It's a bit strange that the first and third items in the
> list are described more fully in subsections but the second item is  
> not.
>

I've searched for a definition of return-path verification, and cannot  
find one either. It is a well-known technique (or set of techniques,  
really) and that's probably why this hasn't stuck out among readers in  
the email community.

On the basis of being well-known, I think that we can leave this  
without a strong definition. I would be happy to add a weak definition  
that suggests a couple of techniques that might be employed for return- 
path verification.

>
> - The first sentence of Section 2.1.1 states "implementations that are
> able to reject messages at the SMTP/LMTP level MUST do so and SHOULD  
> use
> the 550 response code".  This doesn't allow for cases where protocol
> level rejection cannot be performed.  This MUST should be a SHOULD  
> or be
> followed by a list of exceptional cases.  As a MUST, it is  
> inconsistent
> with the SHOULD in section 2 that covers the list of preferred  
> actions.
>

I believe that the rest of the text in that paragraph makes it clear  
that the meaning of "able" in this context is both "has code to do  
protocol level rejection" and "is not in a situation where protocol  
rejection isn't possible" (such as SMTP with multiple recipients.

We might be splitting hairs on the semantics of "able" vs. "can",  
wondering who shall slay whom ;-)

I think the text is ok as-is, but if there's disagreement I can  
clarify it.

>
> - The first paragraph of section 2.3 is confusing.  Why is a user
> interface allowed to silently upgrade from reject to ereject but other
> implementations are not?  Are silent downgrades OK, i.e., for cases
> where ereject is not supported?
>

The idea is that a UI might have a check box labeled "Reject the  
message" and then will translate that check box into a sieve script.  
That translation might be to 'reject' in version X, but in version Y  
might be 'ereject'. We want to allow and encourage such a transition.

I don't see a problem with silent downgrade and would be comfortable  
adding text for it.

>
> - Reason text uses UTF-8 to align an SMTP language extension spec.   
> The
> reason text value may be inappropriate even if the client and server
> negotiate the use of an SMTP extension (i.e., a different language may
> be used by the client/server).  Should UTF-8 be used here without a
> normative reference to support it?
>

The language was constructed to work with whatever standard ends up  
being used for UTF-8 in SMTP, and also to permit vendor specific  
extensions to qualify. A vendor might have their Sieve implementation  
on an LMTP server that receives connections from their own SMTP  
server. If they build a UTF-8 extension so that the message can at  
least be pushed from the LMTP server to the SMTP server in clear  
UTF-8, we want that to be allowed and encouraged.

I see your point, though, that the language in the document allows a  
situation where a non-ASCII non-UTF-8 extension has been negotiation.  
Under such a circumstance, the transmission of the UTF-8 text is  
permitted, even though the channel may be ill suited to it. I believe  
that it is sufficiently obvious that UTF-8 over a non-ASCII non-UTF-8  
channel is not ok.

> - There are some unexpanded acronyms, minimally MUA and MTA.

MUA and MTA are on the RFC editor's list of WKA (Well Known Acronyms)  
for email documents, so it's safe to leave them unexpanded.

Many thanks,
Aaron
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir