[Top] [All Lists]

Re: Spam blowback from Sieve implementations.

2006-12-04 11:56:30

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
> I don't think there's any misunderstanding....

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
NOT the same as the proposal I made in the email that started this

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

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.

On 12/1/06 3:36 PM, Lisa Dusseault wrote:
> 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.

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?

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

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.


<Prev in Thread] Current Thread [Next in Thread>