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. What is being proposed is very
clear. From section 3.1.3 of draft-ietf-sieve-refuse-reject-04.txt:
MTAs and MDAs MUST NOT implement "reject" by sending MDNs, they
SHOULD reject at the protocol level as described in section 3.1.1.
In the following script, a message is rejected and returned to the
sender.
This is an incompatible change from RFC 3028. Section 4.1 of that document
says:
The optional "reject" action refuses delivery of a message by sending back
an [MDN] to the sender. It resends the message to the sender, wrapping it in a
"reject" form, noting that it was rejected by the recipient. In the following
script, message A is rejected and returned to the sender.
This was actually quite a lot of work for us to implement - we could have
generated DSNs far more easily - but we did so because that's what the
specification said to do.
Changing our implementation to generate DSNs rather than MDNs is quite
literally a one line code change. But implementation difficulty is irrelevant.
Our problem is that our stuff is very widely deployed - we're talking many
millions of mailboxes here, lots of them with attached sieve scripts of one
sort or another. Our sieve user provisioning tools don't make use of reject by
default, but they can be changed to do so. Even worse, quite a few of our
customers use their own provisioning tools to generate sieve scripts and we
have no way of knowing what features of sieve they do or do not use. Changing
reject not to generate MDNs constitues a change in UI behavior, and our
internal rules forbid that.
Of course there's an exception process for making incompatible user-visible
change. But you have to have a really good reason, and "some IETF specification
got changed" really doesn't cut it as a justification in and of itself. Even
worse, part of this process entails anouncing the change well in advance in
order to give customers time to object. Perhaps there would be no objections,
but given past experience I think that's unlikely: People are surprisingly
twitchy about these sorts of behavoral changes.
I therefore think that while we can easily offer an option to switch to using
DSNs and probably SMTP-level responses too, we're stuck generating MDNs by
default. And if the specification says that's now illegal, we'll simply have
to violate the specification. And while this may not matter much in the overall
scheme of things, I think one of the major advantages of IETF specifications is
their reluctance to break backwards compatibility with previous versions. Never
forget that one of the important nails in X.400's coffin was the lack of
compatibility between the 1984 and 1988 versions.
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?
There is no doubt that using any action that creates yet another message to
deal with suspected spam is a bad idea. But there are plenty of other uses for
reject, e.g. telling someone specifically that some message was sent to the
wrong place, or at the wrong time, or didn't contain some required something,
or whatever, is an entirely reasonable use for an MDN. And in such cases it may
actually be better to use an MDN - since so many DSNs are now nothing but
backscatter a lot of people simply ignore them. (How closely do you look at
messages from a remote mailer-daemon or postmaster? Fess up now - when your
email address got chosen for heavy use by some bot haven't you deleted them all
en masse at least once? I sure have.)
So, while the community has indeed spoken very clearly and said that using any
sort of response to deal with spam is a bad idea, I don't think this
generalizes to "using MDNs is a bad idea". (As a side note, I sure wish the
antivirus folks had reached the same conclusion. I don't know about anyone
else, but most of the blowback I get now is from antivirus setups, not antispam
setups. Pretty silly given that false positives are much rarer with antivirus
than with antispam.)
Another issue is that the current draft makes much of the ability of LMTP to
send back final per-recipient responses. This is true of course, but it's a
vacuous truth: You're just pushing the problem somewhere else. That LMTP
client, when faced with a mixture of successes and failures, is going to turn
around and generate a DSN for the failure. And unless the LMTP client is
operating as a direct SMTP to LMTP proxy it's likely going to send back a DSN
even when there's a single failed recipient.
So what's the bottom line? I think the bottom line is that this is really a UI
issue: Actions that generate response messages are simply not appropriate to
offer as a means of dealing with spam or viruses. But this doesn't mean such
actions are never appropriate or useful.
Ned