John, the problem is deciding who is an *authorized* email sender. For
example, I own a machine in a random rack -- can it send email? The
way I operate, it sometimes needs to -- I often set up tunnels to it
let it send my email. For that matter, it hosts several IETF and
personal mailing lists.
Now assume that someone in some strange and wondrous part of the world
has a similar need. Are they authorized? According to whom?
There have been a lot of authentication-based and filter-based schemes
proposed, but I've yet to see a scheme that solves the authorization
problem satisfactorily. Not everyone wants to (or is able to) entrust
their email to a a Tier 1 ISP; if nothing else, the Tier 1s would
charge for the privilege.
--Steve Bellovin, http://www.research.att.com/~smb
Steve, you're authorized if you say you are and agree to accept responsibility.
Most corporations would readily provide the addresses of their mail servers;
anyone on DSL or cable connection could do the same. But by changing the
default behavior to block port 25 until requested, you could readily address the
spam problem. It would take some work on the part of operator community
(hence the subject), and doesn't fit in the world wide commune perspective
of networking, but it would make the Internet far more useful for everyone.
/John
Not everyone wants to (or is able to) entrust
their email to a a Tier 1 ISP; if nothing else, the Tier 1s would
charge for the privilege.
A tier 1 provider in the SMTP mesh does not have to
be the same thing as a tier 1 provider in the
physical mesh. See the structure of the NNTP mesh
over the years for examples. I fully expect to see
specialized email peering providers arise who will
have SMTP peering arrangements with the large email
site like AOL, Yahoo, Hotmail etc. and who then arrange
peering with large numbers of smaller sites who either
cannot find SMTP peering locally or who want to
be assured of alternate SMTP routes in the event
their main peer cannot reach all destinations.
Michael Dillon
.. and then I pay my upstream for the privilege of them sending
my mail along for me? All of that equipment so a bunch of
universities can feed their upstream a whole chunk of email
reliably isn't exactly going to be cheap. These specialised
email providers are going to have to have _some_ form of
transit to handle 'just email', increasing the cost.
I wonder how many backbone providers want to run their own
email gateways for all email passing through their network
and have to provide some form of guaranteed service to their
customers.
I wonder how this is going to affect SMTP mail handling as
it stands - for example, how many 'hops' will there be
between this university's mail gateway and, say, MIT's
mail gateway(s)? Will people start playing header rewrite
tricks so MTAs around the world don't bomb out with
"exceeded hop count" ? "Just one hop!" games, a la IP routing in
the final stages of last century, may rear its ugly head again.
I don't believe comparing this to NNTP is entirely valid -
you don't have the overhead of multiple crazy NNTP server
implementations causing you the utmost of pain; you don't have
to worry about handling bounces and temporary DNS failures along
each path; article routing (whether you chose push or pull)
was much, much simpler.
Adrian
Adrian Chadd wrote:
I wonder how this is going to affect SMTP mail handling as
it stands - for example, how many 'hops' will there be
between this university's mail gateway and, say, MIT's
mail gateway(s)? Will people start playing header rewrite
tricks so MTAs around the world don't bomb out with
"exceeded hop count" ? "Just one hop!" games, a la IP routing in
the final stages of last century, may rear its ugly head again.
Could the MTA�s run something similar to MPLS so they could reduce the hop count and "funnel" the email though instead of storing and forwarding it hop by hop? Maybe some users would then be willing to pay more for the extra complexity and it would also skyrocket job security.
Pete
How would multi-hop routing work for ~100M domains, anyway?
Requiring a hop in the middle could be useful in order to create a choke point where rate limiting can be done, but doing multihop makes little sense. The authorization information implied in the routing can just as easily be learned from the sender, if protected through cryptographic means. (Yes, #include <pki.h> but that's the part where we show that we aren't so lazy after all.)
: > Not everyone wants to (or is able to) entrust
: > their email to a a Tier 1 ISP; if nothing else, the Tier 1s would
: > charge for the privilege.
:
: A tier 1 provider in the SMTP mesh does not have to
: be the same thing as a tier 1 provider in the
: physical mesh.
...!i!feel!a!dose!of!queasy!nostalgia!coming!on!here
Steve, you're authorized if you say you are and agree to accept responsibility.
Most corporations would readily provide the addresses of their mail servers;
anyone on DSL or cable connection could do the same. But by changing the
default behavior to block port 25 until requested, you could readily address the
spam problem. It would take some work on the part of operator community
(hence the subject), and doesn't fit in the world wide commune perspective
of networking, but it would make the Internet far more useful for everyone.
(I realize I'm a few days late on this, been travelling all week)
What about that small business with a remote site on a cable modem? All they want is their local server to talk to the one upstream, and they'd rather pay, say, Time Warner $50 a month on a dynamic instead of $200 for a single static IP. Can't really blame them, can you? Is this authorization-filter-scheme going to account for servers on dynamic IP?
Rob Nelson
ronelson@vt.edu