----- Original Message -----
From: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
To: "Cyrus Daboo" <cyrus(_at_)daboo(_dot_)name>; "Matthew Elvey"
<ietf(_at_)ietf(_dot_)org>; <ietf-mta-filters(_at_)imc(_dot_)org>; "Alexey
Sent: Thursday, September 11, 2008 9:24 AM
Subject: Re: Strong Opposition due to spam backscatter. Re: LastCall:
draft-ietf-sieve-refuse-reject-07 and -08 (Sieve EmailFiltering: Reject and
Extended Reject Extensions) to Proposed Standard
A little additional perspective on this from someone who has
(deliberately) not been active in the SIEVE effort. Cyrus has
alluded to some of this, but the real constraint is with SMTP,
not SIEVE, and should be addressed in the SMTP context.
The issue of NDN blowback has come up repeatedly in discussions
of SMTP. The bottom-line answer, despite complaints from
zealous anti-blowback advocates and clever alternate readings of
the spec, is that the SMTP model simply doesn't work without the
possibility of non-delivery messages.
True and its more about that SMTP wasnt desinged to insure the delivery of
anything. The real issue is that there may be ann increasing liability for
being a source of backscatter or blowback traffic when reacting to being
pummled by some smtp traffic.
While there are other
issues, the most important and obvious of them is that SMTP
permits and encourages multiple-recipient messages and has no
in-protocol mechanism for returning per-recipient replies.
The hurdle is in meeting the US Courts for authenticated messaging per Judge
Grimm's standard in Lorraine v Markel which set the bar-heigth for
commercially insured players everywhere.
In theory, that problem could be overcome with an SMTP extension
for per-recipient replies.
Or in authenticated sources of email. Ones which warrant the identity of
their client's for instance.
There is a long-expired I-D that
discussed doing just that, but it never got an traction (and may
or may not have been the best way to do it). However, while
per-recipient responses have other advantages, there is no
reason to assume that spammers would voluntarily make their
lives more difficult by invoking such an extension.
Conversely, the blowback problem could be solved in principle by
authenticating message senders (probably beyond their
authorization to send mail, which is more or less the problem to
which DKIM and SPF are addressed).
OK sure but the real issue is in not sending mail to an address which is
different than the senders address when it bounces. That is the ONLY rule
which will change anything.
But there is again a
deployment problem unless one assumes that legitimate deployed
SMTP implementations can be changed in only a short period of
Depends - the resetting of the standard bounce failure to not send mail to
addresses it cannot resolve will eliminate about 90% of the backscatter
spam A couple of years is all that's needed to wean the world off
and the surrounding context for further discussion on that issue.
The bottom line is that a debate about prohibiting SIEVE from
returning NDNs is meaningless without changes to SMTP. We don't
have any proposals on the table for such SMTP changes and don't
know how to get from "here" to "there" with any of the proposals
that have been made. I guess that makes this I-D a more
tempting target, but it still does not make it relevant.
If the SIEVE WG somehow decided that it liked one of the
proposals for suppressing the possibility of NDNs, we would then
be having a discussion about whether or not that WG is permitted
to write a spec that requires violations of SMTP. Fortunately,
they did not present us with that choice.
--On Thursday, 11 September, 2008 10:38 -0400 Cyrus Daboo
--On September 10, 2008 3:13:33 PM -0700 Matthew Elvey
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
Yes, I can confirm that and firmly believe that the overall
consensus of the WG is to publish the -07 draft. I don't
believe there is a need to re-poll the WG on this, but if the
Ietf mailing list
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.6.20/1666 - Release Date: 9/11/2008
Ietf mailing list