Subject: Re: Spam blowback from Sieve implementations.

From: Lisa Dusseault <[email-masked]>
Date: Fri, 1 Dec 2006 12:36:56 -0800

It's not only that.  IF Sun or any  SIEVE implementors were to start  
using a new, different recommended behavior for REJECT on the basis  
of a new standard, then when server software gets upgraded to one of  
these new server implementations, users with existing SIEVE scripts  
would suddenly start seeing new behavior.  That's not very good for  
users.

Lisa

On Nov 30, 2006, at 2:03 AM, Matthew Elvey wrote:

>
> Apropos "Sun will likely ignore the standard": There is already a  
> lot of ignoring (I would call it bending) sieve standards going on  
> in multiple implementations.
>

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 04 Dec 2006 11:36:35 -0500

On 11/30/06 6:08 PM, Ned Freed wrote:
>> Does anyone think I'm trying to keep the standard from allowing Chris to
>> do what he wants with Sun's implementation?  If so that HAS BEEN A
>> MISUNDERSTANDING OF WHAT I'VE PROPOSED.
>
> I don't think there's any misunderstanding....

Ned, you inappropriately referred to the last published draft, which is 
NOT the same as the proposal I made in the email that started this 
thread.  See your misunderstanding?  It makes the points you made 
inapplicable.

On 12/1/06 3:36 PM, Lisa Dusseault wrote:
> using a new, different recommended behavior for REJECT on the basis of 
> a new standard, then when server software gets upgraded to one of 
That's not what I proposed:  The proposal in my email that started this 
thread DOES NOT REQUIRE that the configured behavior of reject change.  
Is any part of that not clear now?
If a server gets upgraded there's nothing in my proposal that prevents 
the upgrade script from setting the _____ as part of the upgrade, while 
new installations, on the other hand, default to the better behaviour.   
IMO, the harm to users of blowback is greater than the harm Lisa 
mentions.  Do you disagree, Lisa?

---

From: Ned Freed <[email-masked]>
Date: Mon, 04 Dec 2006 09:55:28 -0800 (PST)

> Ned, you inappropriately referred to the last published draft,

Um, since when it is inappropriate to refer to the last posted draft? We were
discussing the concern raised at the meeting _relating to what's proposed in
the current draft_ and the specifics of the consensus that was reached as to
how to move forward. I was asked to weigh in and clarify Sun's position is _in
regards to the current draft_, I did so and I believe I was very clear that
that was what I was responding to. It was never my intention to offer a direct
response to the proposal that started this thread: Given that we're saying we
cannot change reject behavior I guess I thought it was obvious that a proposal
that leaves reject unchanged is fine with us. Apparently it wasn't obvious so
let me state it explicitly: We're fine with any proposal that leaves reject
unchanged from the behavior specified in RFC 3028. And we may also be OK with
proposals that change reject in some way with optional arguments or whatever;
it depends on the details.

> which is
> thread.

And which others are now pushing to tweak in various ways. Keeping track
of all the variations and who's behind what is getting complicated, which
is why I'm trying to be very clear about what we can or cannot do, independent
of any of the ideas we're tossing around.

> See your misunderstanding?  It makes the points you made
> inapplicable.

Again, the points I was trying to make were never intended to be applicable
to the original proposal that started this thread. I should have been clearer
about that.

> mentions.  Do you disagree, Lisa?

I can't speak for Lisa, but I most certainly do disagree. We don't support the
use of reject and MDNs as a means of dealing with spam and viruses (and this is
more or less enforced by our GUI) but we do support use of reject for other
purposes. So the equation "reject via MDN" -> blowback does not compute for us.
And given that's the case, why should our customers be penalized because
someone else has failed to think things through and has used reject and MDNs
inappropriately?

This is not to say that the "attractive nuisance" argument has no merit, but
rather than it is totally trumped by the need for backwards compatibility.

				Ned