--On Thursday, October 29, 2015 11:07 +0000 Ted Lemon
<Ted(_dot_)Lemon(_at_)nominum(_dot_)com> wrote:
Ted, while I would be interested in such a discussion, I will
not be in Yokohama. I might be able to participate in a
discussion remotely, but that could equally be held at some
other time and, as you point out, some of us do better f2f.
Thanks. I'm sorry you won't be there--you are one of the
people I was hoping could participate. Unfortunately, it
looks like the next N IETFs are all difficult travel IETFs for
U.S. folks, which is fair enough considering how many U.S.
IETFs we have had recently.
The issues for me are only partially costs and other "difficult
travel" issues. With the Apps Area changes and reduction in the
number of WGs that are directly relevant to topics to which I
think I bring special expertise, it is hard for me to look at,
e.g., the IETF 94 agenda and conclude that it would be worth
giving up a whole week even if the meeting site were
travel-convenient. So, without questioning the decisions
themselves, we are creating a reverse chicken-and-egg problem
around some topic groups.
...
Yup. It also avoids the rich motherlode problem: if you have
a hundred million mailboxes on your service, and someone
breaks in, a hundred million peoples' privacy could be
compromised (of course, this is an oversimplification, since I
think google has some pretty solid security fu, for example,
but we've seen other large providers, particularly the US
government, hit by this recently).
yep. Another part of this is that, while we often think of
things as having become a two-tier problem with a few giant
providers and a shrinking number of very small ones, it is
really three-tier, with, e.g., ISPs who offer email as a
collateral service (and who haven't outsourced those services to
one of the giant providers) in the middle. It is a common
characteristic of those ISPs that email is a loss center --
something they have to do, but not something that will ever
produce any revenue and for which, for other reasons, almost no
one will ever select a different ISP because of bad email
service. While I agree with you about Google (and maybe most
of their competitors in that tier), I've had lots of reasons to
be less optimistic about that ISP tier.
If the answer is "no" and the earlier comment that email
standards are set today, not by an open process but by a
handful of large providers working in concert (including
those two), then one meeting that ought to be held, with
appropriate lawyers present, would discuss a class action
antitrust suit against the companies involved. It could be
more effective, interesting, and profitable than whining on
the IETF list and, given that standards-setting hypothesis,
would presumably be prerequisite to any real progress.
FWIW, I do not think that there is any bad action going on
here. Google accepts email from my server just fine, actually
quite a bit better than a lot of Postfixes, because small
sites so frequently use greylisting. I haven't noticed Yahoo
doing anything particularly good or bad. The problem is not
bad action, but simply that nobody is motivated to make things
work in a distributed matter other than a few people like us.
And the big providers, by dint of their size, have really big
problems, and really big staffs that are working on them, so
it's not surprising that they move more quickly than we do and
think me at least as a bit of a dilettante (it would be pretty
funny if they thought of you that way).
I didn't mean to suggest malice, although it can look that way
from the outside and to those who assume evil intent first and
then go looking for examples. However, when a handful of
providers who together dominate the presumed market get together
to figure out how to mitigate those really big problems and do
in a way that hurts providers who are not part of that
self-selected group that is considered a priori illegal in some
jurisdictions. For reasons that are ultimately the same as
those you mention above and elsewhere, getting more careful
attention to the small provider situation and keeping protocols
interoperable across the whole range of SMTP implementations may
require some significant non-technical stimulus.
john