Sieve Email Filtering: Reject and Extended Reject Extensions
RFC 5429

Note: This ballot was opened for revision 09 and is now closed.

(Jari Arkko) Yes

(Lisa Dusseault) Yes

(Chris Newman) Yes

Comment (2008-09-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I have reviewed this in detail and believe the WG formed rough
consensus around this proposal.  I believe this proposal
appropriately balances the competing goals of i18n, joe-job defenses
and backwards compatibility.

The person objecting during IETF last call claimed that Sun Microsystems
had an economic interest in this proposal.  I am not aware of any such
economic interest (if I were aware of such an interest, I would recuse).

If the WG had rough consensus on one of the previous versions of this
draft that paid less attention to the i18n and backwards compatibility
issues, I would have voted no objection to such a draft although I do
consider this version a better proposal.

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Pasi Eronen) (was Discuss) No Objection

Comment (2008-09-11)
No email
send info
For reference [Joe-DoS], it'd be nice to have some more
bibliographical information (such as name(s) of author(s), and
publication venue or URL).

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) No Objection

Comment (2008-09-10 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Support Tim's discuss

(Jon Peterson) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2008-09-10)
No email
send info
Additional issues that I do consider non-blocking but should probably be addressed:

(a)  The Security Considerations begins as follows:

   The Introduction to this document discusses why rejecting messages
   before delivery is better than accepting and bouncing them.

There is no such discussion in the Introduction, just the following:

   Further discussion highlighting the risks of generating MDNs and the
   benefits of protocol-level refusal can be found in [Joe-DoS].

This is the reference provided for [Joe-DOS]:

   [Joe-DoS]  "Mail Non-Delivery Message DDoS Attacks", 4 2004.

but I have no idea how to find that document.

I would encourage the authors to add a brief discussion describing why
rejecting messages before delivery is better than accepting and bouncing them.
There is some nice text in the Abstract that would be an excellent starting point.

(b) I thought the security considerations omitted two useful concepts.  

The first is that upgrading current implementation of reject and use of the new ereject
extension will help mitigate some of problems identified in RFC 3834.  (This document
simply notes that it doesn't make it worse.)

The second issue is the silent discard problem noted in my discuss.  Consider noting
that silent discard of legitimate messages constitutes denial of service and that
determination of a forged return-path should be performed very carefully (e.g., only
if the referenced algorithm is performed?).

(c) From Carl's review:

    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?  

Perhaps this text means that sieve intrepreters cannot replace reject with ereject,
but tools that generate sieve scripts are free to switch to ereject if the descriptive
representation is still satisfied?  That would be conssitent with the remainder of 
section 2.3.

(d) from Carl's review:

  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?    

(e) from Carl's review:

   There are some unexpanded acronyms, minimally MUA and MTA.

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection