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 determining. 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 on. I laid all of this out in a message to the WG list back in 2006: http://www.imc.org/ietf-mta-filters/mail-archive/msg03336.html 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 it.) 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 codes. Ned _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf