Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Matthew,

--On September 10, 2008 3:13:33 PM -0700 Matthew Elvey <matthew@xxxxxxxxx> 
wrote:

> Lisa D reported being told: "There is strong WG consensus behind [-07]".
> Lisa D specifically claimed the WG chairs indicated there was.  CHAIRS:
> Can you each please confirm that you stated that there is strong WG
> consensus behind [-07]?

Yes, I can confirm that and firmly believe that the overall consensus of 
the WG is to publish the -07 draft. I don't believe there is a need to 
re-poll the WG on this, but if the IESG would be more comfortable doing so 
given your comments I am happy to do so. Also, if other WG participants 
wish to speak up in support of one position or another right now, they are 
certainly free to do so.

The history of this effort is quite clear in my opinion. The WG decided to 
enhance the existing 3028 reject command to allow use of "reject" behavior 
at SMTP/LMTP protocol time. At the moment I believe your main point is that 
you want the spec to mandate that ereject MUST only result in SMTP/LTMP 
protocol rejection and indeed that all implementations must support 
protocol level rejection. On the several occasions you have brought this 
issue to the WG mailing list it has been explained in detail that there are 
plenty of key use cases where only doing SMTP protocol rejection is not 
possible (e.g. in the very common case where there are multiple recipients 
of the message and one recipient's script erejects, whilst another does 
not).

I think the current wording in the -07 spec is perfectly clear that 
implementations must make every effort to do protocol level rejection 
whenever possible. For example, the first section of 2.1.1 states:

    Sieve implementations that are able to reject messages at the SMTP/
    LMTP level MUST do so and SHOULD use the 550 response code.

Also, section 2.1 states:

    The ereject action MUST NOT be available in environments that do not
    support protocol level rejection

I think those are pretty strong statements about the use of ereject and 
protocol level rejections. I don't see why or how these need to be changed.

Unfortunately, claiming that the current specification results in a 
"spam-friendly RFC" is going to anger a lot of people who have spent a lot 
of time trying to address spam issues as best as possible. It totally 
misrepresents the efforts of the SIEVE WG. I realize, Matthew, that you 
have very strong opinions on this, but I fear such comments are not going 
to result in forward progress.

If you feel that the IETF needs to publish a document stating that all 
email systems MUST support protocol level rejections (which I think is what 
you want to require of all implementors), then I suggest that you publish a 
new I-D to do just that and garner support for moving that forward in the 
IETF. At this point I consider WG consensus to be for publishing -07 - 
albeit with the various comments from IETF last call appropriately 
addressed by the authors.

-- 
Cyrus Daboo

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]