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

[Matthew Elvey <[e-mail]>]

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, [e-mail] 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
>>>>> [e-mail] mailing lists by 2008-08-10. Exceptionally,
>>>>> comments may be sent to [e-mail] 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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf