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.
So far, no one is actually disagreeing with what I proposed in this
thread (except for Ken's disagreeing about making "ereject"
non-portable) which is good.
Cyrus wrote:
Why are we making a decision in SIEVE WG that MDNs are bad?
I think the general email community has spoken on this pretty loudly,
many times, to say that backscatter is bad.
Not in the groupings you frequent? Really?
Now, not all backscatter is MDNs, but e.g. Justin Mason just said
[Backscatter is] nearly as big a problem as direct spam, nowadays; the
DDOS effects of spam backscatter nearly took down my mailserver this past
weekend. :(
Also, if the Sieve spec stayed as is, but became dominant, then it would
lead to a lot more backscatter. It just isn't that popular yet.
Spamcop has a FAQ that asks:
"Why are auto responders bad?" and discusses each type:
http://www.spamcop.net/fom-serve/cache/329.html
On 11/29/06 11:28 AM, Mark E. Mallett wrote:
On Tue, Nov 28, 2006 at 12:47:11PM +0000, Alexey Melnikov wrote:
Matthew Elvey wrote:
Finally, there's "ereject", which never sends MDNs. Among other
things, exim calls for this option, as it never sends MDNs.
I just want to point out that slides/jabber log from the meeting say
that there was a rough consensus for ereject to allow for "protocol
level refusal or MDN". The questions about ereject never generating MDNs
was not asked.
(I am personally undecided on this issue)
Is there a URL where the meeting log(s) are available? I probably
missed an earlier reference, and this thread is the first I've heard
of "ereject" (both my fault in overlooking something, I imagine).
mm
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch2-mon-pm.mp3
(Discussion from 2:46:50; mtg from 2:29:19)
OK, but I stand by what I said. It was proposed that ereject would
never send MDNs, w/o objection.
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.