Micorsoft's Sender ID Authentication......?

[Niels_Bakker]

The number of agreements needed in the email world is significantly higher than what is needed for BGP.

The proponents of "email peering" typically want to switch from the current model (millions of independant email servers) to a different model, with only a few big actors.

* Michael.Dillon@btradianz.com [Thu 16 Jun 2005, 14:48 CEST]:

I don't know who these proponents are, that you refer to. However, in my earlier message I quite clearly described a model that allows for millions of independent email servers organized in roughly 3 levels of hierarchy and I described how it could be done so that email peering IS NOT LIMITED to a few big actors.

You pour some RIR sauce over your hierarchy of the top five players but that still makes it a model with only a few big actors.

[..]

This will not prevent spam, but it will provide operators with the power to shut it off, whenever it occurs. It would

No. Infrastructure will provide operators with that power, legal agreements will not.

[..]

What is missing today?

Paraphrased: Basically a lot of administrative overhead that will increase costs of everybody involved with no direct benefit except for the satellite players providing those new services and those looking for control over basic infrastructure for whatever reason.

If the BGP peering side of the business can sort out all of this stuff, then why can't the email side of the business do the same, or perhaps, do even better?

It's not comparable, as has been explained several times to you.

  -- Niels.

[michael.dillon1]

>If the BGP peering side of the business can sort out all of
>this stuff, then why can't the email side of the business do
>the same, or perhaps, do even better?

It's not comparable, as has been explained several times to you.

Perhaps you have never been involved in BGP peering? Let
me explain what the BGP peering side of the business does,
in addition to operating BGP sessions with peers. To start
with, most ISPs don't start peering until after they have
negotiated and agreement. Those agreements are legal contracts
with many pages specifying the responsibilities of the two
parties, limits on how the technology is to be applied,
SLAs, processes for interoperation and communication between
NOCs, i.e. the people protocols.

The thousands of bilateral BGP peering contracts are most
definitely comparable to the email peering that I am
proposing. I have seen many of these contracts in companies
that I worked for in the past. They are rather similar to
one another in many ways. Since the total number of BGP
peers is rather small, it is quite workable to let these
contracts evolve to some sort of rough standard and that is
what has happened.

In the email world, there are many, many more players, and
some kind of secret sauce is essential to converge bilateral
email peering agreements to some kind of community standard
rather than letting evolution take its course and risking
chaos as a result. The stuff that you call RIR sauce, is what
I would call "open and public negotiation" in some kind of
a forum which is not biased or dominated by parties who may
have some market dominance. It is, in fact, the antithesis of
a model with a few big actors.

It is also a model that works, more or less, in other industries.
The FCC is one example imposed by government. The RIRs is
another example formed from the ground up. There is more than
one way to do this. Which would you prefer as a role model,
the FCC or ARIN?

--Michael Dillon
P.S. ARIN itself has absolutely nothing to do with email
services and is unlikely to get involved in this in any
way. I am using them mainly as a successful example of
an open public organization that manages a common resource.

[Steve_Gibbard]

If the BGP peering side of the business can sort out all of
this stuff, then why can't the email side of the business do
the same, or perhaps, do even better?

It's not comparable, as has been explained several times to you.

Perhaps you have never been involved in BGP peering? Let
me explain what the BGP peering side of the business does,
in addition to operating BGP sessions with peers. To start
with, most ISPs don't start peering until after they have
negotiated and agreement. Those agreements are legal contracts
with many pages specifying the responsibilities of the two
parties, limits on how the technology is to be applied,
SLAs, processes for interoperation and communication between
NOCs, i.e. the people protocols.

This is a commonly made claim, but is rarely true in practice. A few of the largest networks, generally with small numbers of peers, require peering contracts. Most of the smaller networks with large numbers of peering sessions seem to have decided that the overhead of dealing with contracts isn't justified by the benefits. We've got several hundred peering sessions here, and maybe four or five signed contracts.

The thousands of bilateral BGP peering contracts are most
definitely comparable to the email peering that I am
proposing. I have seen many of these contracts in companies
that I worked for in the past. They are rather similar to
one another in many ways. Since the total number of BGP
peers is rather small, it is quite workable to let these
contracts evolve to some sort of rough standard and that is
what has happened.

If we ignore the contract piece, this sounds a lot like UUCP.

In the email world, there are many, many more players, and
some kind of secret sauce is essential to converge bilateral
email peering agreements to some kind of community standard
rather than letting evolution take its course and risking
chaos as a result. The stuff that you call RIR sauce, is what
I would call "open and public negotiation" in some kind of
a forum which is not biased or dominated by parties who may
have some market dominance. It is, in fact, the antithesis of
a model with a few big actors.

It sounds like you envision five big actors, who would function as regulated long distance/international e-mail carriers, each of which would have a monopoly in their region. This is the phone network model in a lot of places, except that phone monopolies don't often cover more than a few countries while your five e-mail monopolies would have an average of 40 countries each.

I'll withhold public judgment on whether this would be a good thing.

-Steve

[Joe_Abley3]

Far not, I have nothing to add on the "e-mail peering" hand-waving, but...

If the BGP peering side of the business can sort out all of
this stuff, then why can't the email side of the business do
the same, or perhaps, do even better?

It's not comparable, as has been explained several times to you.

Perhaps you have never been involved in BGP peering? Let
me explain what the BGP peering side of the business does,
in addition to operating BGP sessions with peers. To start
with, most ISPs don't start peering until after they have
negotiated and agreement. Those agreements are legal contracts
with many pages specifying the responsibilities of the two
parties, limits on how the technology is to be applied,
SLAs, processes for interoperation and communication between
NOCs, i.e. the people protocols.

... this (above) is vastly different to my experience.

At ISC we have between 1000 and 2000 BGP sessions active at exchanges around the world. I can count the number of those that required signed peering agreements on two hands.

Of those that did require paperwork, most were very happy to set up BGP sessions straight away, without waiting for the contracts to be signed and mailed. (If there are any such people watching, to whom I never got around to sending you a signed contract back, please let me know, and sorry

Unless I am just very special, and some natural law protects me from mountains of legal paperwork which everybody else is obliged to climb, BGP peering is a lot more free and loose in real life than you suggest.

Joe

[Dave_CROCKER2]

Folks,

This might not turn out to qualify under the precise term of "peering" but I
like the general implication that things are not entirely open and that there
are service criteria.

...I described how it could be done so
that email peering IS NOT LIMITED to a few big actors.

....

What is missing today?
- contracted email SLAs between operators
- contracted admin interoperation procedures between operators
- contracted SLA and AUP with customers that allows immediate
shutdown when malware is detected
- organizations which can sort out all the details of the
above contracts, etc.

If the BGP peering side of the business can sort out all of
this stuff, then why can't the email side of the business do
the same, or perhaps, do even better?

Email over the Internet has important differences from IP. For the most part, IP
datagrams are not differentiated. Also, peering often involves physical channels
and transit service.

By contrast, the issue with email, today, has to do with problematic content.
This entails significantly different approaches to policy making. Because it is
at the application level, service over the Internet usually does not involve
special physical channels and transit services are far more limited.

That said, it certainly makes sense to hold email operators accountable
for some aspects of their traffic. (We need to be careful about how
much, lest we slide right into pure censorship.)

The approach of CSV <http://mipassoc.org/csv&gt; is intended to have
operator-to-operator accountability. A purpose of things like the
spamops draft (and, more generally, the mipassoc.org approach) is to
establish rough consensus on best practises for operators.

With respect to something on the order of an SLA, I originally pursued
the idea of formal corporate sign-up to the best practises but ran into
an immediate and huge barrier. It requires too much strategic decision
making by the companies.

So it occurred to me that there already was an informal model of
voluntary inter-operator collaboration to fight spam and that that might
provide a basis for something a bit more scalable and a bit more formal.
That's where a membership organization that issues formal best practises
comes in.

  d/

[Todd_Vierling]

You mean like ucbvax? (If you don't know what that means, you have no
business talking about Internet e-mail.)

Seriously, the mess you're proposing was already done. It didn't scale.
Taken from http://en.wikipedia.org/wiki/UUCP :

[Joe_Maimon1]

Todd Vierling wrote:

The proponents of "email peering" typically want to switch from the
current model (millions of independant email servers) to a different
model, with only a few big actors.

I don't know who these proponents are, that you refer to. However,
in my earlier message I quite clearly described a model that allows
for millions of independent email servers organized in roughly
3 levels of hierarchy and I described how it could be done so
that email peering IS NOT LIMITED to a few big actors.

You mean like ucbvax? (If you don't know what that means, you have no
business talking about Internet e-mail.)

Seriously, the mess you're proposing was already done. It didn't scale.

I think the salient point is that BGP itself does not and would not scale to the same level of demand SMTP peering agreements would need.

Currently 160k prefixes and 16bit ASNs -- while in and of itself stretching many operators scaliability limits -- come nowhere close to millions of domain names, mailsystems, mail orgs, mail users and pieces of mail.

Aggregation is currently failing for BGP, there is no rational basis to assume it could even begin to make traction for SMTP.

Its a pipe dream.

[Rob_Seastrom2]

Michael.Dillon@btradianz.com writes:

The thousands of bilateral BGP peering contracts are most
definitely comparable to the email peering that I am
proposing.

Dude, it's 2005. You can put down the X.400 crack pipe now.

                                        ---Rob

[michael.dillon1]

> The thousands of bilateral BGP peering contracts are most
> definitely comparable to the email peering that I am
> proposing.

Dude, it's 2005. You can put down the X.400 crack pipe now.

Why does fixing the SMTP email architecture by applying some
lessons learned from BGP peering lead people to talk about
X.400, UUCP, Bitnet, Fidonet and other obsolete protocols?

You're right, it's 2005 and we have suffered from email
SPAM for 10 years now, getting worse every year. So when
are we going to admit that SMTP-based email is *NOT* the
superior solution for email that we all thought it was
in 1995?

--Michael Dillon

[Todd_Vierling]

Because these protocols did EXACTLY the same thing you've been attempting to
push: explicitly routed, trust-based-peering delivery. IT DOES NOT SCALE,
and we know this because many of us have long since implemented it!
Personally, I've directly used three of the above, and still do run one of
them on my personal home server.

There are far too many SMTP machines already deployed out there -- we're not
talking thousands; here it's tens to hundreds of thousands worldwide -- to
reel it back in and make widespread, mandatory mail peering anything but a
bedroom fetish for high salaried security consultants.

SMTP is not perfect; however, it is the de facto standard and is widely
adopted BECAUSE it does not require any of this crap. In the ideal case,
where remote networks do strive to keep themselves clean, it works well.

Blacklisting a remote network for its failure to keep a clean house is also
not perfect, nor are any of the other heuristic approaches being taken. In
spite of their imperfections, these approaches are making an impact, and
pointing the blame where it belongs: squarely at the misbehaving network.

You may feel free to descend back into the world where control of e-mail is
in the hands of a few, but the rest of us have given up the ghost on that
approach. I do, however, know of a good clinic where they can help you
fight your addiction, once you're ready to admit the problem -- that's the
first step towards recovery.

[jlewis]

It's actually millions. And I'm not just pulling that number out of
someone's ....