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

[Ballot discuss]
I have reviewed draft-ietf-sieve-refuse-reject-07. Overall, the
document looks good, but I have the following concerns that I'd like
to discuss before recommending approval of the document:

It's a bit strange to have "Updates: 3028" (and a normative
reference to RFC 3028) here, since RFC 3028 has been obsoleted by RFC
5228. Perhaps changing RFC 3028's entry to say "Obsoleted by RFC5228,
RFCnnnn" would better reflect the situation?

The document says the main difference between 'reject' and 'ereject'
is that the latter allows SMTP/LMTP level rejection (and there are
some details about non-ASCII strings).  I think I understand this
part, but it seems there's another difference: the former talks about
sending an MDN, while the latter sends a DSN.

I'm not that familiar with the distinction between MDNs and DSNs (and
on first reading, thought they meant the same thing), and I think the
document would benefit from short description here, reminding readers
that they're not the same thing, and explaining why 'reject' and
'ereject' do things differently.

From Carl Wallace's SecDir review:

Section 2.1: as noted in Tim's DISCUSS, the text about "return-path
verification", and discarding the message is that fails, needs some
more text explaining this step. Also, why this step doesn't apply to
the 'reject' action? (I'd think implementations of 'reject' would also
do it...).

[Ballot discuss]
Please consider the comments provided by Spencer Dawkins in his Gen-ART
  Review.  Spencer asked some clarity questions, and he asked two technical
  questions  involving RFC 2119 language.  I have not seen a response to
  this review, and it deserves one.

[Ballot discuss]
Personal Note: As an email user, I greatly appreciate the authors and wgs efforts to defend
against joe-jobs.  Supporting message rejection before delivery seems like an important
step forward.  Thanks!

Second Note:  AFAIK, Carl Wallace's secdir review (submitted 8/14/08) has not received a
response, so I integrated his issues into my own review.  If his issues were addressed and
have been resolved, please let me know! 

The document reads well and is generally very clear.  There are a few issues that should be
addressed before publication, though.  I am particularly concerned about the circumstances
for silent discard and conformance requirements for ereject implementations:

(1) In section 2.1, the second ereject action is a silent discard "if a return-path
verification clearly indicates that the message has a forged return-path".

This seems underspecified.  As noted in Carl's secdir review, there is no definition
for return-path verification and (unlike actions 1 and 3) no further information in
this spec. Is there an accepted algorithm for determining a forged return-path?  If so,
a reference would be very helpful.

In the absence of a solid reference, this step is worriesome. My concern is this: silent
discard of a legitimate message in a store-and-forward application constitutes an
undetectable denial of service attack.  Email has become an essential business tool.  If
an implementor relies on bad heuristics to make this determination, the results could
be ugly.

To be clear I am not advocating removal of silent discard.  I am sure that it is quite
reasonable under specific circumstances.  I just would like the document to spell out
the circumstances where the wg believes this action to be appropriate.

(2) To expand on the second issue in Carl's secdir review, the conformance requirements for
implementations of ereject are unclear.  Section 2.1 lists three actions; the text before the
list implies that all three actions are optional to implement, and that an implementation
could conceivably support just one of the three options.

However, the sentence following the list implies that action 1 is a MUST implement which
seems consistent with the first sentence in 2.1.1.  The text in Section 2.1.2 implies that
action 3 can only be used under limited circumstances.  (There is no corresponding subsection for action 2).

Please review for clarity and consider adding a subsection to address the applicability of
action 2.

[For completeness, here is the corresponding text from Carl's review:

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

[Ballot discuss]
Personal Note: As an email user, I greatly appreciate the authors and wgs efforts to defend
against joe-jobs.  Supporting message rejection before delivery seems like an important
step forward.  Thanks!

Second Note:  AFAIK, Carl Wallace's secdir review (submitted 8/14/08) has not received a
response, so I integrated his issues into my own review.  If his issues were addressed and
have been resolved, please let me know! 

The document reads well and is generally very clear.  There are a few issues that should be
addressed before publication, though.  I am particularly concerned about the circumstances
for silent discard and conformance requirements for ereject implementations:

(1) In section 2.1, the second ereject action is a silent discard "if a return-path
verification clearly indicates that the message has a forged return-path".

This seems underspecified.  As noted in Carl's secdir review, there is no definition
for return-path verification and (unlike actions 1 and 3) no further information in
this spec. Is there an accepted algorithm for determining a forged return-path?  If so,
a reference would be very helpful.

In the absence of a solid reference, this step is worriesome. My concern is this: silent
discard of a legitimate message in a store-and-forward application constitutes an
undetectable denial of service attack.  Email has become an essential business tool.  If
an implementor relies on bad heuristics to make this determination, the results could
be ugly.

To be clear I am not advocating removal of silent discard.  I am sure that it is quite
reasonable under specific circumstances.  I just would like the document to spell out
the circumstances where the wg believes this action to be appropriate.

(2) As noted in Carl's secdir review, the conformance requirements for implementations
of ereject are unclear.  Section 2.1 lists three actions; the text before the list implies that
all three actions are optional to implement, and that an implementation could conceivably
support just one of the three options.

However, the sentence following the list implies that action 1 is a MUST implement which
seems consistent with the first sentence in 2.1.1.  The text in Section 2.1.2 implies that
action 3 can only be used under limited circumstances.  (There is no corresponding subsection for action 2).

Please review for clarity and consider adding a subsection to address the applicability of
action 2.

[Ballot comment]
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.

[Ballot discuss]
Personal Note: As an email user, I greatly appreciate the authors and wgs efforts to defend
against joe-jobs.  Supporting message rejection before delivery seems like an important
step forward.  Thanks!

Second Note:  AFAIK, Carl Wallace's secdir review (submitted 8/14/08) has not received a
response, so I integrated his issues into my own review.  If his issues were addressed and
have been resolved, please let me know!

The document reads well and is generally very clear.  There are a few issues that should be
addressed before publication, though.  I am particularly concerned about the circumstances
for silent discard and conformance requirements for ereject implementations:

(1) In section 2.1, the second ereject action is a silent discard "if a return-path
verification clearly indicates that the message has a forged return-path".

This seems underspecified.  As noted in Carl's secdir review, there is no definition
for return-path verification and (unlike actions 1 and 3) no further information in
this spec. Is there an accepted algorithm for determining a forged return-path?  If so,
a reference would be very helpful.

In the absence of a solid reference, this step seems a little dangerous. My concern
is this: silent discard of a legitimate message in a store-and-forward application
constitutes an undetectable denial of service attack.  Email has become an essential
business tool.  If an implementor relies on bad heuristics to make this determination,
the results could be ugly.

(2) As noted in Carl's secdir review, the conformance requirements for implementations
of ereject are unclear.  Section 2.1 lists three actions; the text before the list implies that
all three actions are optional to implement, and that an implementation could conceivably
support just one of the three options.

However, the sentence following the list implies that action 1 is a MUST implement which
seems consistent with the first sentence in 2.1.1.  The text in Section 2.1.2 implies that
action 3 can only be used under limited circumstances.  (There is no corresponding subsection for action 2).

Please review for clarity and consider adding a subsection to address the applicability of
action 2.

[Ballot comment]
Personal Note: As an email user, I greatly appreciate the authors and wgs efforts to defend
against joe-jobs.  Supporting message rejection before delivery seems like an important
step forward.  Thanks!

Second Note:  AFAIK, Carl Wallace's secdir review (submitted 8/14/08) has not received a
response, so I integrated his issues into my own review.  If his issues were addressed and
have been resolved, please let me know!

The document reads well and is generally very clear.  There are a few issues that should be
addressed before publication, though.

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

(2) In section 2.1, the second ereject action is a silent discard "if a return-path
verification clearly indicates that the message has a forged return-path".

This seems underspecified.  As noted in Carl's secdir review, there is no definition
for return-path verification and (unlike actions 1 and 3) no further information in
this spec. Is there an accepted algorithm for determining a forged return-path?  If so,
a reference would be very helpful.

In the absence of a solid reference, this step seems a little dangerous. My concern
is this: silent discard of a legitimate message in a store-and-forward application
constitutes an undetectable denial of service attack.  Email has become an essential
business tool.  If an implementor relies on bad heuristics to make this determination,
the results could be ugly.

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


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

- 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? 

- 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?   

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

[Ballot comment]
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.

IANA Last Call comments:

Action #1:
Upon approval of this document, the IANA will make the following
changes in the "Sieve Extensions" registry at
http://www.iana.org/assignments/sieve-extensions

OLD:
Capability name: reject
Description:
RFC number: [RFC3028]
Contact address: Tim Showalter


NEW:
Capability name: reject
Description: adds the "reject" action for refusing delivery
of a message. The exact reason for refusal is
conveyed back to the client.
RFC number: [RFC-ietf-sieve-refuse-reject-07.txt]
Contact address: the Sieve discussion list


Action #2:

IANA will remove the following from the "Sieve Extensions" registry
at http://www.iana.org/assignments/sieve-extensions

Capability name: refuse
Description:
RFC number:      [draft-elvey-refuse-sieve-01.txt]
Contact address: Matthew Elvey
                The Elvey Partnership, LLC
                3042 Sacramento-ietf St Ste 04
                San Francisco, CA
                U.S.A.
               

Action #3:

Upon approval of this document, the IANA will make the following
assignment in the "Sieve Extensions" registry at
http://www.iana.org/assignments/sieve-extensions

Capability name: ereject
Description: adds the 'ereject' action for refusing delivery
of a message. The refusal should happen as early
as possible (e.g. at the protocol level) and might
not preserve the exact reason for refusal if it
contains non-US-ASCII text.
RFC number: [RFC-ietf-sieve-refuse-reject-07.txt]
Contact address: the Sieve discussion list

We understand the above to be the only IANA Actions for this
document.

SIEVE Reject and Extended Reject extension WG Chairs Write-up for IESG.

draft-ietf-sieve-refuse-reject-07.txt - Proposed Standard

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?
         
          Shepherd: Cyrus Daboo  I have
          personally reviewed this document and believe it ready for
          submission to the IESG.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?
         
          It has had adequate review from WG members. Not from non-WG
          members. No concerns with the nature of those reviews.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?
         
          No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.
         
          No concerns with this document.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?
         
          There is strong WG consensus behind this. Whilst one
          participant did feel that the specification needed to be much
          stronger in its wording and applicablility, the consensus of
          the rest was that that would unduely be a burden to
          implementations.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)
         
          No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?
         
          ID nits were checked and no problems found.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].
         
          References are split into two sections. There is one normative
          reference to the LMTP specification which is an Informational
          RFC. We request a variance to allow this downref.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?
         
          Yes.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?
         
          Yes.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

          Working Group Summary
            Was there anything in WG process that is worth noting?  For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)?  In the case of a Media Type
            review, on what date was the request posted?

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director? Is an IANA expert needed?

Technical Summary

The SIEVE Reject and Extended Reject extension adds back the reject
action to SIEVE 5228, and adds an extended action with additional
behavior related to carrying out the reject at SMTP time.

Working Group Summary

This document has been discussed and reviewed in the SIEVE Working Group.
There is consensus in the Working Group to publish this document
as a Proposed Standard.

Document Quality

A number of implementations of this extension have already been
developed and in some cases deployed. Most participants are eager to see
this specification published as an RFC.

Personal

Document Shepherd: Cyrus Daboo
AD: Lisa Dusseault