[Top] [All Lists]

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

2008-09-11 18:18:02
I had hoped to be able to stay out of this discussion, but repeated references
to me and to Sun's Sieve implementation, many of them inaccurate and some
fairly disparaging, have created a situation where it seems I have no choice
but to respond.

I tried writing a point by point response to Mr. Elvey's latest message but
soon gave up - it's just too long and a point by point response is too
confusing. So what I'm going to do instead is try and give my view of how we
got here, where we are, and what I think should happen now.

The base specification for the Sieve language was first published in January
2001 as RFC 3028. In addition to defining the core language, this document also
specified several extensions, most notably the reject extension, used to reject
messages around the time of final delivery.

Reject as specified in RFC 3028 was _required_ to return a Message Disposition
Notification, or MDN. (MDNs were themselves defined in RFC 2298, now obsoleted
by RFC 3798.) This choice was made in order to facilitate implementation of
reject in MUAs.

Sun's initial implementation of Sieve included support for reject as defined in
RFC 3028. But because use of reject necessarily creates additional message
traffic, and more specifically when used to deal with joe-jobs can itself be a
source of blowback spam, Sun's filtering GUI did not offer an out-of-the-box
option for users to specify use of reject. We have also pushed back hard on any
suggested use of reject to deal with spam.

However, several of our customers found other legitimate uses for reject. For
example, one fairly popular use case is to use Sieve for processing workflows
in email: When invalid messages are found reject is the method of choice to
inform the sender of the problem. (Note that ingress filtering on such setups
is invariably extremely strict so there's essentially no risk of reject being
applied to spam.) Silently discarding messages, as the discard action would do,
is unacceptable in this case - the sender has to be informed of what happened
and why.

An especially important aspect of such usage is the ability to report errors in
languages other than i-internet. This is something that cannot be done using
SMTP-level errors because SMTP currently lacks any internationalized
error response facility.

When work began on revising the Sieve base specification (now published as RFC
5228) there was a lot more concern over the blowback aspects of reject, so much
so that the WG decided to move the extension from the Sieve base to this
separate specification.

Various choices were available to the WG, ranging from deprecating the
extension in toto,  changing or enhancing how it worked, defining a replacement
extension, or even leaving it is-as. As part of the ensuing discussion I
attempted to explain the situation Sun found itself in: Sun's customers have
literally tens of millions of end users, if not more, many if not most of whom
are using Sieve (although the vast majority are completely insulated from the
underlying technology by a GUI interface and are therefore unaware that Sieve
is involved). We know that some number of these are using reject for purposes
other than dealing with spam and who depend on its ability to return properly
internationalized error messages. Exactly how many, we have no way of

Accordingly, we cannot and will not abandon customers that depend on these
facilities, irrespective of what the IETF says about it. If, for example, the
WG had decided to eliminate reject completely, we probably would have done is
add an option to enable or disable reject support so sites could then choose
whether or not to comply. Similarly, a substantial change in reject semantics
would probably have caused us to add some sort of mode setting option. And so

I laid all of this out in a message to the WG list back in 2006:

This was at a point when the proposal under discussion was to completely change
reject semantics and ban the use of MDNs entirely. I attempted to explain Sun's
situation and how we would deal with such a change. I also attempted to make a
case for preserving existing reject semantics because I believed then, and
continue to believe now, that there are legitimate uses for it that have
nothing to do with spam.

After much discussion, what the WG eventually decided to do in this document
was essentially to (1) Loosen the rules around reject so as to allow the use of
SMTP-level errors when possible and (2) Define a new extension, ereject, which
requires the use of SMTP-level errors in all cases where it is possible to use
them. I believe this to be a reasonable approach.

Moreover, once it became clear where all this was headed I proceeded to updaate
Sun's implementation. Here's how things currently stand for us:

(1) Sun's implementation has always operated exclusively at the SMTP level
    prior to final delivery. We have always performed as many address and
    message validity checks as soon as possible in order to maximize the number
    of messages that can be rejected during the SMTP session.

(2) The latest release now supports both ereject and reject in full
    compliance with the current draft.

(3) In the case of reject, Sun's implementation uses SMTP level responses
    whenever it is possible to do so, i.e., when the reject text is ASCII
    and there's either a single recipient or mutlple recipients all returning
    the same reject text).

(4) In the case of ereject, SMTP level responses are used in all cases except
    when some recipients accepted the message and others rejected it.

(5) I recently added an option to disable ereject for use in cases where
    the MTA is known to be behind some sort of proxy and it is therefore
    not safe to use ereject to deal with spam.

So now someone using Sun's product and who wants to reject messages with Sieve
using SMTP-level errors has the means to do so.  And more importantly for us,
existing uses of reject, especially those involving internationalized response
text, will not be broken. (Note that there will now be some cases where a
reject produces a DSN rather than an MDN. We hope this doesn't cause any
problems, but if it does we'll probably have to add some options to deal with

Now, as far as proposed revisions to current draft go, as far as I can tell
what Mr. Elvey is proposing is tightening up the rules surrounding the use of
ereject even further. Unless there's a loophole in there I'm not seeing, I view
this as unnecessary.

Mr. Elvey also proposes adding a requuirement that there be a way to disable
ereject on SMTP servers operating behind one or more store-and-forward proxies.
Requiring such an option seems like a good idea in theory, although I have to
question whether or not it will have the desired effect - or any real effect -
in practice.

I note in passing that Sun's implementation would not be affected by either of
these changes - we already handle ereject at the SMTP level whenever possible
and we already have implemented an option to disable ereject.

It also may be that Mr. Elvey is proposing something different or in addition
to these things. If so, he needs to explain what that something is, preferably
by posting it as a separate draft, so it can be evaluated.

There have also been some other objections and points raised, including some
IESG discusses, that definitely merit some attention. Tim Polk's discuss issues
in particular definitely need to be addressed. I also support Pasi Eronen's
suggestion as to how to deal with the issue of whether this document updates or
obsoletes RFC 3028.

I would also support the addition of a flat statement saying that reject is
simply not suitable for use in dealing with spam. And it would also make sense
to give an example for reject that's clearly not associated with spam handling.

One final point. Although ereject prevents blowback spam from being generated
in a lot of cases, it does not and cannot eliminate it entirely. The obvious
case where it still occurs is when one recipient accepts the message but
another rejects it. An SMTP extension could be defined for per-recipient DATA
responses and in fact a PRDR draft was circulated some time back but nothing
ever came of it. If people really are concerned about blowback spam I
respectfully suggest that rather than engage in yet another protracted squabble 
on this document, that our collective time would be much better spent on
getting a PRDR scheme as well as internationalized SMTP error responses
(there's draft for this floating around as well) onto the standards track. With
those extensions in place reject can always be done with SMTP-level error

Ietf mailing list