Subject: 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
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Date: Thu, 11 Sep 2008 10:22:00 +0200
List-Id: <ietf-mta-filters.imc.org>

Matthew Elvey writes:
> If a system implementing the specs we're working on works on a 
> store-and-forward basis, then it MUST NOT MISLEAD, i.e. LIE TO ITS 
> USERS by claiming to support the enhanced standard we are writing. 
> -07 allows an implementation to mislead its users by claiming to 
> support enhanced functionality when it does no such thing.

Why not? My code (I implemented -07 a few weeks ago) advertises support 
for the standard even if it may or may not provide enhanced 
functionality. I think that's fine. It does provide in-protocol 
rejection when possible, and the rules have very pleasant consequences. 
Most importantly, it's possible to make system configuration changes 
that affect system's ability to to in-protocol rejection without 
invalidating anyone's sieve script.

> That would simply be dishonest.

It's just another RFC about best-effort something something. There are 
many others already, so most implementers are familiar with the 
concept. And AFAICT, implementers generally implement a best effort, 
not behave dishonestly.

(I read some more of this monster mail, but IMHO it degenerates into a 
pure rant around the point where Aaron Stone is first called «the 
author of -07». Not worth answering.)

Arnt