Andrew,
I think the questions are appropriate and hope others will
address them. For my personal reactions, see below but, for
those who don't know (I think you do), I've become increasingly
concerned in recent years that the IETF is doing work that
assumes an Internet that no longer really exists or is making
decisions that are unrealistic given external and operational
changes. I also think it has gotten very hard to talk
constructively about tradeoffs and compromises in the IETF, with
far too many strategic decisions made either on the basis of
"several large vendors (or open source implementations) have
done this, so we must (uncritically) adapt" or "X is important,
we believe in X, and therefore anything that doesn't support X
is evil and should be suppressed or eliminated". However, I
hope my comments below help initiate that discussion rather than
leading to defensiveness.
--On Saturday, 12 May, 2018 22:35 -0400 Andrew Sullivan
<ajs@xxxxxxxxxxxxxxxxxx> wrote:
> Hi,
>
> Somewhat in keeping with a cheeky question I asked the IAB at
> the last plenary, I want to ask some questions. These are not
> actually for John, though they hang off his message. The 2d
> person pronoun is directed at the reader of this message, not
> John.
>
> On Fri, May 11, 2018 at 03:05:59PM -0400, John C Klensin wrote:
>
>> nothing in the mail path between what we now call the
>> submission server and the final delivery server gets to
>> interpret, much less tamper with, the internals of the local
>> part of an address. While we have many examples of systems
>> breaking that rule, the integrity of the mail systems depends
>> on it in important ways.
>
> Do you think that, given the various ways that this is now
> actually violated pretty widely around the Internet, the
> "integrity of the mail systems" is already lost?
I think we are in a losing battle and that DMARC, and these
changes, are just symptoms. I suggest that one of those other
fundamental assumptions of the mail system was that we would
have a large collection of MTA installations, with systems
located logically close enough to the senders and recipients to
make notions of user control and authorization for policies and
actions meaningful. Instead, one of the things we hear often
today is that a very large percentage of the world's email
either originates with, or terminates on, and extremely small
number of providers and that much of it is intra-provider, i.e.,
from one <foo>mail user to another <foo>mail user.
One of the manifestations of those changes for email is that, if
someone had come along 20-odd years ago and said "we think this
new idea is really a great one for solving problem Z and don't
really care about what our solution will break because it won't
affect our users", we would have said something like "can't stop
you, have fun, and let us know how it works out for you". The
result was clear: to borrow from a metaphor from that period,
the sides of the information superhighway became littered with
the corpses of proprietary email systems that didn't
interoperate well with Internet mail. In that same
environment, the IETF examined the impact on possible changes to
interoperability very carefully. As examples, I am convinced we
could have done much better with the SMTP extension model, and
perhaps even somewhat better with MIME, had we not cared about
interoperation with deployed and installed systems that
conformed to the earlier specs and their users.
Today, we have a small collection of dominant mail providers.
Their users may be asked to agree to their policies (and
periodic changes to those policies). If the users disagree,
they are presumably free to go elsewhere, but, as those
providers become more and more dominant and their policies more
and more similar, for many users there really isn't an
"elsewhere" to go Then several of those dominant mail
providers get together, design a piece of protocol (and, in
DMARC's case, a trust model) outside the IETF or any other open
process that will work for them and their understanding of, or
preferences about, their users/customers, and then effectively
say to everyone else "you just need to adapt to this because,
otherwise, we won't let you talk with our users" and maybe even
(although I admit I've not heard this explicitly) "if it breaks
your mailing list system, that is not a problem because we have
a better solution anyway and it is free (if you don't count
paying in control, privacy, etc.)".
So, what does the IETF do? We adapt to whatever decisions those
providers we have made and have arguments about which of the
small details of the adaptations are least harmful. On a
technical and operational front, I actually don't see what else
we can do. We have enough participants who use the systems of
those providers and who have no practical choice that not
adapting in some way would make the IETF less open. That is why
I've tried to be careful to ask questions about the approach
taken that might result in better understanding or minor tuning,
but not to oppose it. We also create a WG to consider and
develop alternatives, but it moves slowly in a complex
environment (probably inevitable). We don't know if it will
produce a useful result, nor whether that result will be
deployable, with all of the workarounds, adaptations, and other
kludges that are installed in between possibly acting as
impediments and other sources of inertia.
There are some non-technical things we possibly could have done
(I don't know whether they are still feasible). We could have
worked with ISOC to explain and widely publicize the risks of
protocol development by oligopoly or trade associations
controlled by big actors. We might even have been able to do
something jointly with, e.g., ISO, IEC, and/or ITU to deliver
that message: they are certainly aware of the problem and have
been since before there was an IETF. Would anyone have
listened? I don't know. Was the decision not to do that
influenced by noticing that the same large providers are paying
a large fraction of ISOC's bills and the expenses of many IETF
participants? I hope not.
> If so, does that mean that we have a new _de facto_ mail system
> emerging?
Maybe but, if so, it isn't new. It is an updated version of a
system in which to most of toe world, "email" meant accounts
with, e.g. (and in no particular order), AOL, CompuServe,
MSMail, Prodigy, MCIMail, some BITNET/EARN/NETNORTH hosts, and
some CSNET hosts, each of which could transfer traffic to the
others either indirectly or via quasi-proprietary gateways. We
"won" that time because Internet mail became the core
interoperability model. I'm less optimistic this time.
On the other hand and as just one example, if we have really
decided that having messages encrypted in transit is critically
important, then maybe we need much better "best practices"
advice about how MX preferences and relays should be configured
than was the case when we considered reliably getting the
messages through as our most important objectives.
> If so, does that imply that we ought to document it in some
> documentation series?
If so, yes. In many respects, my problem isn't that these
changes are occurring but that the IETF is in denial about them.
That also suggests that this is exactly the wrong time to be
discussing ways of shutting down mechanisms for getting things
documented that may not be consistent with, e.g., the majority
IETF view of reality.
best,
john
