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