Subject: 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

From: Matthew Elvey <[email-masked]>
Date: Wed, 10 Sep 2008 15:13:33 -0700

This is an argument opposing the proposal to have the IETF's IESG make 
draft-ietf-sieve-refuse-reject-07 a Proposed Standard (i.e. RFC).   
Sieve is widely used for email processing; it competes with procmail and 
other rules-processing systems.

My reason for opposing -07 and drafting and supporting -08 is this:

In plain English, the specification up for vote (-07) allows compliant 
email system implementations to continue to be a source for vast amounts 
of spam, while the current draft (-08) does not.

Support for ereject (in the form of a successful <require ["ereject"]>) 
MUST be a clear message to users that the implementation used actually 
is a modern implementation that successfully avoids sending floods of 
unsolicited MDNs (spam) by rejecting messages during the SMTP 
transaction (instead of accepting them and then sending MDNs back to the 
alleged sender) wherever possible, thereby reducing the backscatter 
problem.   If a system implementing the specs we're working on works on 
a store-and-forward basis, then it MUST NOT MISLEAD, i.e. LIE TO ITS 
USERS by claiming to support the enhanced standard we are writing.  -07 
allows an implementation to mislead its users by claiming to support 
enhanced functionality when it does no such thing.  That would simply be 
dishonest.  Archaic implementations are free to support the old SIEVE - 
RFC 3028.   -07 needs to be rectified so that the intro from earlier 
versions remains true:

>  This document updates the definition of "reject" to require rejecting 
> messages during the SMTP transaction (instead of accepting them and 
> then sending MDNs back to the alleged sender) wherever possible, 
> thereby reducing the problem.  (Where 'possible' does NOT include the 
> case where the reject string is one that cannot be sent during the 
> SMTP transaction.)

I wonder if Ned and I have argued past each other.
AFAICT Ned is arguing that he/Sun must be allowed to continue to send 
unsolicited MDNs (even when the reject string is ASCII, and there is one 
recipient) e.g. when Sun's server is used with someone else's LMTP 
server.  And yet he claims that I'm misrepresenting his implementation 
and the reasoning behind it.  (It's hard to know what he thinks, as he 
repeatedly avoid answering my questions.)
Ned acts like saying that I'm against allowing Japanese users to fall 
back to out-of-transaction rejects when non-ASCII reject strings need to 
be used.  I'm not.  Look at the drafts I wrote!  They don't do that!

Obviously, a developer cannot control how his product is deployed by a 
customer.  Consider a Sieve implementation within an SMTP server that is 
hidden behind a store-and-forward SMTP proxy; call this whole system 
"B".  It's beyond the control of the developer of SMTP server software 
to prevent a customer from creating a system like "B".  Any SMTP server 
can be hidden thus. However, as authors of the Sieve implementation, we 
can specify what it can and cannot be connected to.   We specify how and 
when SMTP servers deliver their messages to recipients, by transmitting 
the messages only to specified systems, after all.  Naysayers say 
otherwise, but provide no argument. What I am trying to restore is the 
demand that a)any SMTP (or LMTP) server software implementing this Sieve 
extension be capable of performing in-transaction ereject and b) that if 
such software is incorporated into a larger system by a customer, that 
that customer not claim that that system, if it is like "B", supports 
ereject, because that would be dishonest.  The software should cause 
<require ["ereject"]> to fail in such a case, either because of a 
configuration option the the customer sets (truthfully, one hopes) or by 
detecting that it has been deployed in such a system, or a combination 
(e.g. a smart installation script could poke around and if appropriate, 
ask: <You appear to have installed this system behind a 
store-and-forward SMTP proxy; therefore it cannot support the Sieve 
"ereject" action.  Accept this configuration?  [Yes]/No.>  This would 
ensure that the system does not LIE TO ITS USERS.  It would alert the 
customer to the issue, perhaps leading them to abandon the 
store-and-forward system for a modern one.

Tim Polk just mentioned "I would encourage the authors to add a brief 
discussion describing why rejecting messages before delivery is better 
than accepting and bouncing them. "  There was such a discussion in an 
earlier draft.  It was removed by the author of -07.  I've restored it 
in -08 (which I'm about to submit to the queue).

Tim also says "Consider noting that silent discard of legitimate 
messages constitutes denial of service and that determination of a 
forged return-path should be performed very carefully. "  This is true.  
Likewise, sending MDNs containing spam and viruses also has security 
implications.  Both need to be mentioned.

I believe all the nits and other issues that have been raised need to be 
addressed; a WGLC and LC are also needed.

I think it's generally recognized that MDN backscatter is bad.  Now, not 
all backscatter is MDNs, but e.g. Justin Mason has said
> [Backscatter is] nearly as big a problem as direct spam, nowadays; the
> DDOS effects of spam backscatter nearly took down my mailserver ... 
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

I strongly support requiring that all implementations implement the ability to do
proper smtp-time (or lmtp-time) protocol-level refusals (other than
MUA-based implementations).  It's an important interoperability issue.
There is a loophole in -07 for an implementer to decide that what he or she
feels is preferred is to not bother fulfilling this requirement. It
needs to be closed.

Lisa wrote:

 > ... ask people to speak up to agree with you.

Please speak up if you [dis]agree with the points raised, as others have.

But note, people have already spoken up - or chosen not to:

Ned's answer to my question below is yes, with respect to 'refuse':

> >  Do we want to have the spec allow implementers to not bother to
> >  implement the ability to do proper smtp-time refusals, even though all
> >  implementers at the meeting indicated that it was possible for the
> >  implementations to be changed so that they could do so, and not doing so
> >  produces and will continue to produce immense economic harm caused by
> >  spam blowback?
No one else expressed support or agreement.

On 7/27/08 10:30 AM, [email-masked] wrote:

>  >  IMO this draft is _not_ ready for publication on standards track.

Indeed.  Despite opposing protestations, -07 does violate RFC 3798's 
instruction to take appropriate precautions to minimize the potential 
damage from denial-of-service attacks, namely *unsolicited* MDNs.  Even 
if they are intentionally sent by the sender, MDNs sent under -07 still 
violate RFC 3798's instruction to take appropriate precautions to 
minimize unsolicited MDNs.  Furthermore, I do NOT concede that a user 
who uses reject is even expressing an intention to send unsolicited 
MDNs; the opposition is mistaken here.  I see no logic behind that 
assumption.

On 8/18/08 10:37 AM, Lisa Dusseault wrote:
>
> On Aug 13, 2008, at 11:16 PM, Matthew Elvey wrote:
>
>> Hi.
>>
>> I have a court-imposed filing deadline to meet of Aug 31 (See 
>> www.caringaboutsecurity.wordpress.com and/or 
>> www.elvey.com/spam/70-ORDER-GrantingElveyLeaveToFileMemorandumExplainingObjections.pdf - 
>> it's apropos my representation of 6 million TD Ameritrade customers 
>> in an Identity Theft Class Action lawsuit) and am working and going 
>> camping this month as well, so I anticipate being unable to respond 
>> this month.  If you would wait 'till the first September telechat, 
>> please.  Will you do that?
>
> I can do that.
Humph.   It's not 'till September 11, 2008, but I see you and Chris 
already voted several days ago, and others just voted; that seems 
inappropriate for several reasons.  For one thing, there have been 
multiple objections to progressing -07.

Lisa D reported being told: "There is strong WG consensus behind [-07]". 
Lisa D specifically claimed the WG chairs indicated there was.  CHAIRS: 
Can you each please confirm that you stated that there is strong WG 
consensus behind [-07]?  If you could point to evidence, that would be 
good too.  I don't think it's the case, based on the public email 
record.  (I do see Cyrus Daboo declaring WG consensus.)  In fact believe 
only 2 people have expressed opposition to the changes I have proposed.  
There was WG rough consensus earlier versions of the draft which, unlike 
the current one, would not knowingly exacerbate the spam problem.  Given 
the increased opposition (e.g. from Frank Ellermann) and the conflict of 
interest among some IESG voting parties, and the lack of WG consensus, 
and the merits, I don't think holding the present vote, or voting in 
favor, is appropriate.    At IETF 67,  it was proposed that ereject 
would never send MDNs, w/o objection. -07 violates that consensus.  
Nits: It's not a "stable specification".  It has known errors.  Besides 
which, there was no WGLC on the draft - it went straight to IETF review  
- WTF?
>>
>> *ECONOMICS*
>> There's a strong economic incentive for those behind implementations 
>> that would require a lot of work to fix to make a concerted effort to 
>> actively support weakening the standard.  The economic costs due to 
>> the blowback are very diffuse - spread out over most of the 
>> Internet-using population, in contrast to the concentrated, but IMO 
>> relatively small cost of fixing the archaic implementations...  I'm 
>> all for considering economic efficiency, but both sides need to be 
>> weighed and weighed fairly.
> Can you make or point to arguments (perhaps you've posted them to the 
> SIEVE list already) about why the changes "weaken the standard"?  
> Another point that needs a little more explanation is why the original 
> design would be more expensive to implement than the current 
> requirements, although implementation costs aren't always the same 
> across implementations anyway. 
I can and have, below.  I find it rather odd to see you vote for 
something and then indicate that you haven't read the recent SIEVE list 
discussions about the merits of the standard, especially when you have 
been involved in past SIEVE list discussions about the merits of the 
standard.  The implementation costs of just continuing to support the 
old "refuse" are obviously close to 0 in terms of development cost; 
there's also the cost of sending MDN backscatter - having to configure 
and maintain a dedicated IP from which to send it, or bearing the 
reputation costs of (e.g. being blocklisted for) sending it.
> Then we might be able to get to the economic arguments.  At this point 
> your economic arguments are impugning the motives of strawman 
> opponents rather than addressing the fitness of the proposed RFC. 
That's rather insulting, Lisa, although it's also rather nonsensical at 
the same time.   My economic arguments are re-presented below as 
well.    I wonder how you could have missed them unless you were 
avoiding them.  The economic argument is hard to miss.

Re. Joe Job vs Backscatter: Back when I wrote the first version of this 
draft, the former was the common term, and it has stayed in successive 
versions; since then, the latter has gained prominence.  IMO, either 
term is appropriate.

>
>>
>> You do/did do work for Sun, right?  Seems like there's the appearance 
>> of a conflict of interest to me.  Note: I'm not accusing you of 
>> anything; I'm just saying that there seems to be a conflict of 
>> interest...
Ned Freed and Chris Newman, at least, are on that list; you defended Sun 
products' continued bad reject behavior 12/4/06.  Little surprise Ned 
launched into ad hominem attacks on me, and claimed I had done the 
same.  I find it sad to see Sun staff (and a former IAB and IESG member) 
pushing for a spam-friendly RFC.

I think it's rather obvious what the economic interest is here, but I'll 
spell it out again since the prior explanation requires putting together 
two concepts expressed separately.

On 7/23/08 7:57 AM, Ned Freed wrote:
>> Has anyone done a complete implementation of the current refuse-reject
>> specification?
> We have.
JESMS?  Which, of course, DOES implement spamtest and virustest.  Elsewhere?
http://wiki.fastmail.fm/index.php?title=SieveExtensionsSupportMatrix 
answers the more general question.

I'd love to know how Net can know that a product that supports Sieve's 
spamtest and reject is, in his words, "NOT used as a means of dealing 
with spam".
That seems impossible to me.

Ned demands that all old implementations of 'refuse' not be required to 
change. Occasionally, abandoning old standards is good (slavery, human 
sacrifice, absolute monarchy).  Sometimes refining old standards is 
good.  FYI, travel,  study, and friendship has afforded me some 
familiarity with Japanese negative politeness and the like.  The 
Japanese are generally considered the masters of the practice of 
continuous improvement.  They are not closed to change; they do however 
perform it very differently.  And as I've said before, I'm not pushing 
users to abandon non-ASCII language in the first place, so there is no 
issue in the first place.
> I did not, and still do not, see how this knowingly exacerbates the 
> spam problem -- in fact it encourages servers to reduce backscatter, 
> itself a form of spam.

>
> Lisa
>
>>
>>
>> -Matthew
>>
>> On 8/7/08 6:44 PM, Lisa Dusseault wrote:
>>> Hi,
>>>
>>> I'm on vacation next week so I haven't put this document on the Aug 
>>> 14 IESG telechat.  The Aug 28 telechat is the next opportunity for 
>>> IESG Evaluation.  That timing gives you three weeks before the first 
>>> possible decision on the document.
>>>
>>>
>>> On Aug 7, 2008, at 12:09 PM, Matthew Elvey wrote:
>>>
>>>> Hello.Â  I am the original author of this I-D.
>>>>
>>>> I am strongly opposed to the document in its current form (-07).
>>>>
>>>> I wrote the original draft primarily to address the backscatter 
>>>> problem* from Sieve implementations that I worked with, problems 
>>>> the creation of which was mandated by the original Sieve 
>>>> specification.
>>>> I wrote (with assistance from Alexey Melnikov) several drafts, 
>>>> which effectively addressed my concerns.  Versions that 
>>>> accomplished the goal that motivated the whole effort were 
>>>> developed that were entirely adequate for becoming an RFC-level 
>>>> standard, however bitrot set in, along with an effort to simplify 
>>>> the base specification which created a need for significant 
>>>> changes.  They also received a stronger level of support than -07.
>>>> I will be introducing and arguing for a revision subsequent to the 
>>>> current -07 draft to address the concerns I have raised on-list, 
>>>> and request that the IESG not make a decision in less than a few 
>>>> weeks so I have a chance to do so and receive feedback.
>>>> Recent versions have been a fundamental departure from the versions 
>>>> that have Alexey and I listed as coauthors, and pervert the goal of 
>>>> the standard I initiated.
>>>> I do not believe the IETF wants to be known for knowingly 
>>>> exacerbating the spam problem, in particular the backscatter 
>>>> problem, and I belive adoption of -07 does that by endorsing a 
>>>> practice and architecture that does so, i.e. the archaic 
>>>> store-and-forward, instead of the modern 'transparent SMTP proxy'** 
>>>> architecture.
>>>>
>>>> *http://en.wikipedia.org/wiki/Backscatter_(e-mail)
>>>>
>>>> **http://en.wikipedia.org/wiki/Transparent_SMTP_proxy
>>>>
>>>> On 7/27/08 8:02 AM, The IESG wrote:
>>>>> < br> The IESG has received a request from the Sieve Mail 
>>>>> Filtering Language
>>>>> WG (sieve) to consider the following document:
>>>>>
>>>>> - 'Sieve Email Filtering: Reject and Extended Reject Extensions '
>>>>> <draft-ietf-sieve-refuse-reject-07.txt> as a Proposed Standard
>>>>>
>>>>> This document has a normative reference to RFC 2033 which 
>>>>> documents LMTP,
>>>>> Local Mail Transfor Protocol.  Support for LMTP is not required for
>>>>> servers supporting the mechanisms in this specification.  The
>>>>> procedure of RFC 3967 is applied in this last call to approve the
>>>>> downward reference.
>>>>>
>>>>> The IESG plans to make a decision in the next few weeks, and solicits
>>>>> final comments on this action.  Please send substantive comments 
>>>>> to the
>>>>> [email-masked] mailing lists by 2008-08-10. Exceptionally,
>>>>> comments may be sent to [email-masked] instead. In either case, please
>>>>> retain the beginning of the Subject line to allow automated sorting.
>>>>>
>>>>> The file can be obtained via
>>>>> http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-07.txt 
>>>>>
>>>>>
>>>>>
>>>>> IESG discussion can be tracked via
>>>>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13141&rfc_flag=0 
>>>>>
>>>>>
>>>>>
>>>>
>

On 6/18/08 11:22 AM, Matthew Elvey wrote:
>
> On 5/29/08 9:22 AM, Ned Freed wrote:
>> <Ned quoted me but didn't include a quotation line; please do so in 
>> future, Ned.>:
<N.B. Request ignored.  How disrespectful.>
>>> I disagree.  There is a loophole for an implementer to decide that 
>>> what he or
>>> she feels is preferred is to not bother fulfilling this requirement. 
>>> It needs
>>> to be closed.
>> Then you really need to provide better evidence that such a loophole 
>> exists -
>> because I'm not seeing it.
> That's funny.  You do see it.  You just don't realize it.  You drove 
> the LMTP truck through the loophole!! (see LMTP discussion below)  My 
> latest draft doesn't have the loophole that you've insisted LMTP 
> implementations should be able to drive through!
>
> > ...
>
> Agreed.
>> ...
> Agreed.
>
>>> I still strongly support requiring a change to the default behaviour,
>>> and feel that there is reluctance to change the current behaviour for
>>> what was presented as nothing more than an unwillingness to explain 
>>> what
>>> we all agreed were net good reasons for the change.
> ... the justification is poor.  The point is that the 
> evidence/argument provided against changing the default behaviour is 
> weak.
>>
>> Suppose the Sieve implementation is operating as part of the LMTP 
>> server. (This
>> isn't how I'd ever do it, but it is nevertheless a perfectly legitimate
>> implementation option.) A message comes in via SMTP and is queued for
>> delivery. The LMTP client sends it to the LMTP server, which then runs
>> the Sieve which then does an ereject. This is then translated into a
>> 550 LMTP response.
>>
>> What is the MTA supposed to do now? 
> You're asking me what to do once you've painted yourself into a 
> corner.  My answer is: DON'T paint yourself into a corner.
>
> Do I sympathize with you for (hypothetically) painting yourself in a 
> corner?  Sure.  But if you insist on doing it in perpetuity, I don't.
>
> Do the TCP or Ethernet specs say send data as fast as you please?  No; 
> why should we say 'do what you please' here just because there's a 
> market for such harmful product? If you've written an ingress MTA to 
> always accept mail before determining that the final delivery can be 
> made, then you have reasons to paint yourself into a corner: laziness, 
> defense of market niche, the system/software you've written works 
> better that way...  Good enough reasons?  Not IMO.
Note, by laziness, I simply mean reluctance to devote the time/financial 
resources to make the product capable of smtp-time (or lmtp-time) 
protocol-level refusals directed by Sieve.  The term "laziness" is 
frequently used in economics! (It's often considered a virtue! However 
in this case, I do not consider it one.) This is part of my economic 
argument.

There's a strong economic incentive for those behind implementations 
that would require a lot of work to fix to make a concerted effort to 
actively support weakening the standard to avoid having to make the 
fix.  The economic costs due to the blowback are very diffuse - spread 
out over most of the Internet-using population, in contrast to the 
concentrated, but IMO relatively small cost of fixing the archaic 
implementations...  I'm all for considering economic efficiency, but 
both sides need to be weighed and weighed fairly.

I don't claim to be an expert in all major MTAs, but I do claim that if 
they all could easily be made capable of smtp-time (or lmtp-time) 
protocol-level refusals directed by Sieve, then the 
SieveExtensionsSupportMatrix row for refuse/ereject wouldn't have a 'c' 
(for 'Can't be implemented without rearchitecting') in the Sendmail and 
exim columns, and would have more 'x'es.  Most major MTAs have been made 
to support SpamAssassin for before-queue filtering: 
http://wiki.apache.org/spamassassin/IntegratedInMta - in other words, 
while smtp-time (or lmtp-time) protocol-level refusals directed by Sieve 
do always seem possible, they don't always seem to be drawback-free.  
For example, it could impact an MTAs compartmentalized security 
architecture communication.

This is and was in no way an attack on Ned.  In fact, I did not and 
still do not know whether Sun/Ned's product(s) "always accepts mail 
before determining that the final delivery can be made" or not.  (I'd 
like to know!  It's important info WRT this vote.)  And even if I did, 
it's still not a personal attack or an attack on Sun (or any other 
architect or implementer).  It's very unfortunate that he misinterpreted 
it as such an attack, but that in no way means it was such an attack.

>
>> Returning a 550 SMTP response is not possible for the simple reason 
>> that the
>> SMTP connection is long gone - in fact it could have taken place 
>> hours or even
>> days earlier.
>> I will also note that the behavior of such an MTA, which not only 
>> isn't the
>> agent with the Sieve implementation, it likely will not even be aware 
>> that
>> Sieve is involved, is entirely out of scope for this working group. 
>> We cannot
>> impose requirements here even if we wanted to.
We most certainly can specify under what conditions the Sieve 
implementation can connect to other systems.  I've explained how to do 
it.  AFAIK, no rule says my method is in any sense illegal.
>>
>>> If there is indeed such a case, it needs to be specified.
>>
>> Specify what? 
> Do what you did.
>> The unfortunate reality is that once a message has been accepted
>> by an ingress MTA the options for getting rid of it narrow down to 
>> discarding it, with or without sending a notification.
>> Now, I have long been a proponent of turning away as many messages as 
>> possible
>> while the connection is still there for reporting errors. But neither 
>> this
>> document nor this workging group are the places to make the case for 
>> doing
>> things this way.
>>
>>> Oh, and the acronyms MDA,  MTA and MUA are now used but not defined (as
>>> Mail Delivery, Transfer and User Agents, respectively)
>>> draft-crocker-email-arch-10.txt defines 'em, but it's been an I-D 
>>> for as
>>> long as this I-D, so I suggest we just spell 'em out on initial use.
>>
>> I agree the terms need to be defined but the right way to do is is by
>> referencing the architecture document. The Sieve environment draft 
>> did so and
>> this has not proved to be a barrier to publication.
> Ok.  Defined or just spelled out; either is fine with me.
This was not done in -07.  Nit.

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 11 Sep 2008 10:22:00 +0200

Matthew Elvey writes:
> If a system implementing the specs we're working on works on a 
> store-and-forward basis, then it MUST NOT MISLEAD, i.e. LIE TO ITS 
> USERS by claiming to support the enhanced standard we are writing. 
> -07 allows an implementation to mislead its users by claiming to 
> support enhanced functionality when it does no such thing.

Why not? My code (I implemented -07 a few weeks ago) advertises support 
for the standard even if it may or may not provide enhanced 
functionality. I think that's fine. It does provide in-protocol 
rejection when possible, and the rules have very pleasant consequences. 
Most importantly, it's possible to make system configuration changes 
that affect system's ability to to in-protocol rejection without 
invalidating anyone's sieve script.

> That would simply be dishonest.

It's just another RFC about best-effort something something. There are 
many others already, so most implementers are familiar with the 
concept. And AFAICT, implementers generally implement a best effort, 
not behave dishonestly.

(I read some more of this monster mail, but IMHO it degenerates into a 
pure rant around the point where Aaron Stone is first called «the 
author of -07». Not worth answering.)

Arnt

---

From: [email-masked]
Date: Thu, 11 Sep 2008 15:16:04 -0700 (PDT)

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