Sieve Email Filtering: Reject and Extended Reject Extensions
draft-ietf-sieve-refuse-reject-09

Support Tim's discuss

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).

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.