Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]

Thu Jun 16 12:48:02 UTC 2005

> > 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.

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.

The 3 levels that I described were, at the top, intercontinental
peering between members of 5 organizations which roughly
cover the countries in one continent. I suggest that these
5 organizations should adopt the service boundaries of the 
RIRs rather than trying to reinvent the wheel.

Next, there would be peering between all members in the
same continental organization. These members would exchange
email with each other under contract terms which clearly
lay out the responsibilities of sending operators and 
receiving operators.

Finally, at the lowest level, are organizations who do
not see a need to become members of an email peering 
organization and who exchange email with one or two
operators who are members of the peering organization.
However, these organizations will also be bound by an
explicit contracted AUP because the whole point of this
peering hierarchy is to have consistent accountability
throughout the entire email architecture.

This will not prevent spam, but it will provide operators
with the power to shut it off, whenever it occurs. It would
be useful to also have the ability to verify initial senders
of email messages, however that is not essential for this
peering architecture to be useful.

Here is a sample scenario. Grandma opens an email with a trojan
inside it. The trojan installs itself in her machine and starts
sending spam through Grandma's broadband connection. One of the
spam recipients informs their ISP that they just received a spam
message. Their ISP has a look and agrees that this is indeed spam
and they see that this spam is still coming in from a neighboring
operator. The ISP follows the contractual procedure and sends an 
official notification of SPAM to the neighbor. The neighbor follows
a similar process and identifies the source as Grandma's ISP.
They issue a formal notice to Grandma's ISP and 10 seconds after
the notice is received, Grandma's IP connectivity is blocked
entirely except for HTPP accesses which are all directed to
a walled garden explaining the situation and recommending steps
that can be taken to clean up trojans, spyware, viruses, etc.

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?

--Michael Dillon