--On Saturday, 08 November, 2008 07:53 -0800 Dave CROCKER
<dhc2@xxxxxxxxxxxx> wrote:
> John C Klensin wrote:
>> Sadly, I have to agree with Keith. While these lists are a
>> fact of life today, and I would favor an informational
>> document or document that simply describes how they work and
>> the issues they raise, standardizing them and formally
>> recommending their use is not desirable at least without some
>> major changes in our email model and standards for what gets
>> addresses onto --and, more important, off of-- those lists.
>
>
> John,
>
> What are the technical deficiencies of this specification?
Dave, Sorry if my note was incomplete. I've halfway around the
world, trying to focus on something else and thought that the
issue Keith raised were clear enough that they didn't require an
in-depth explanation. Ekr's comment reinforces that view.
However...
Our email model assumes that messages that are sent either get
delivered or that the sender gets an NDN back. We have never
had a culture of receipts for delivery to what SMTP thinks of as
the last-hop MTA, much less delivery to the user's mailbox.
Today, messages can just disappear on the way to the user's
mailbox (often at or after that last-hop MTA). They do so
without NDNs out of fear of blowback, and they do so for two
main reasons. One has to do with analysis of message content
for patterns consistent with spam, the other has to with various
address and domain blacklisting techniques. The problem with
the latter is that it is extremely subject to abuse, both
intentional and unintentional. One variation on the former has
involved a DoS attack against a particular domain by used that
domain in faked addresses in spam. That problem is worsened by
operational difficulties in getting off the lists once one has
been classified onto them, a problem exacerbated by "guilty
until proven innocent using standards of proof that are unclear"
that is built into the operational systems.
In theory, we could address this problem by writing a Security
Considerations section that includes "deployment and use of this
mechanism, even by others, undermines the assumption that mail
will either be delivered or NDNs produced and delivered to you
and neither you nor the final recipient will necessarily have
control over the mechanisms and decisions in use". But that
raises issues that are quite similar to the "decision-making
middlebox not controlled from either endpoint" issue as well as
opening up the issue of whether we need to change the mail model
to be more strongly based on delivery confirmations. FWIW,
Security / Operational Considerations like that have been
considered more than adequate to block standardizion... and are
"known technical defects" relative to successful interoperation
with existing and established protocols and models.
> What are the specific problems the mechanism it defines pose
> to "our email model and standards"?
See above.
> What are the specific, "major changes" that would be required
> to the model and standards, to make the current specification
> acceptable?
Again, see above.
> This type of mechanism has massive adoption throughput the
> Internet. It's perceived efficacy also is massive. The
> current specification merely seeks to provide a stable
> technical basis for that mechanism.
Another part of the traditional mail model is that any
legitimate actor ought to be able to run his or her own mail
server. I suspect, based on what is now a fairly large,
although opportunistic, sample, that a very large fraction of
those who are running a mail server on less than a T1/E1 link,
in PD space, and with mail system volume several orders of
magnitude smaller than that of AOL/ Gmail/ Hotmail/ Yahoo have
been burned at least once or twice by these mailing lists.
That implies that these methods are reducing the reliability and
predictability of the email system, which is exactly what Keith
said and, again, is a reason to not standardize.
> In the face of overwhelming community consensus for this
> mechanism, you offer a simple, flat, fundamental rejection,
> yet provide no substantiation.
Unlike you, I don't see "overwhelming community consensus for
this mechanism". There is probably consensus among those for
whom mail system reliability in terms of delivery of legitimate
messages is less important than deleting spam, and especially
among those whose mail operations are large enough that they
will never find themselves blacklisted (although I vaguely
remember an incident in which some outgoing Gmail addresses
ended up on a blacklist). But there is no consensus at all
among those of us who see this sort of technique as
operationally dangerous and problematic... so much so as to call
its value into question.
> Really, John, it would help for a posting to do more than say
> that you don't like the idea of the mechanism.
I don't think that characterization of what I (or Keith) said is
fair. I also don't think that the discussion is moved forward
by either hyperbolic claims about consensus or attacking the
messenger. You may disagree, of course.
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf