ietf-mta-filters
[Top] [All Lists]

[Asrg] 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-10 18:13:59
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, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com 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
ietf(_at_)ietf(_dot_)org mailing lists by 2008-08-10. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org 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.



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg