[pskmail] Re: Server to Server Mail Routing Algorithm Ideas

  • From: "DL7JP" <DL7JP@xxxxxxx>
  • To: <pskmail@xxxxxxxxxxxxx>
  • Date: Thu, 11 Oct 2007 10:16:16 +0200

Hi Goody,
 
very nice idea! 
Re routing in a server-to-server protocol: If scalability could ever become
an issue (who knows...?), you might want to look at DHTs
http://en.wikipedia.org/wiki/Distributed_hash_table which is roughly what
Skype and other P2P systems use for finding peers they want to communicate
with. There's a lot of material around on this,
http://cis.poly.edu/~ross/papers/email-p2pconf-final.pdf might serve as an
entry to see how it can be applied to Email delivery (must admit: I haven't
read the paper...).
 
Cheers Joachim.


  _____  

From: pskmail-bounce@xxxxxxxxxxxxx [mailto:pskmail-bounce@xxxxxxxxxxxxx] On
Behalf Of Goody K3NG
Sent: Thursday, October 11, 2007 2:18 AM
To: pskmail@xxxxxxxxxxxxx
Subject: [pskmail] Server to Server Mail Routing Algorithm Ideas


I was thinking today about an algorithm for mail delivery once a
server-to-server protocol is developed.  Here's some thoughts I jotted down
on "paper":

Needs/Requirements

- The server to server mail delivery protocol should work independently
without an Internet connection, central control, or central database.  Also,
server nodes should be able to be added or deactivated on an ad hoc basis.

- While PSKmail is currently geared towards using Internet POP accounts,
mail may also be hosted directly on PSKmail servers.  This functionality
could be valuable during disaster situations and/or when Internet
connectivity is not available.  There needs to be a way that mail for local
server accounts can be delivered to the server when that server's Internet
connection is down.

- Source routing is...evil.  "Over-the-air" (local server) email addresses
should never require source routing nor should the capability exist.

- Any exchange of routing information needs to consume very little bandwidth
and be very simple.  Fast convergence is not requirement, but should be
responsive enough to change with propagation changes.


Basic Mail Routing Algorithm Idea

Is the email destination domain local?
 |
 + YES: Deliver locally
 + NO: Does an MX record exist in DNS for the email destination domain name?
       |
       + YES: Attempt delivery to MX server via the Internet; was it
successful?
       |               |  
       |               +YES: DONE
       |               +NO: Is there an over-the-air route (looking at
beacon table)?
       |                     |
       |                     + YES: Send email via server-to-server protocol
to the best route
       |                     + NO: Queue mail and start at top of process
again in X minutes
       |
       + NO:  Is there an over-the-air route (looking at beacon table)?
                      |
                      + YES: Send email via server-to-server protocol to the
best route
                      + NO: Queue mail and start at top of process again in
X minutes

 - Server beacons would broadcast what mail domain names they can accept
email for, and how many hops away the destination server is.  The server
configuration should have a setting to limit the domain names they broadcast
by hops away (i.e. 0 = broadcast only domains hosted on the server, 1 =
domains one hop away, etc.).  The server should indicate "internet" as a
route if they are currently connected to the Internet.  (The server software
should dynamically remove this route if the Internet connection goes down.)
Essentially this is a classic vector-distance routing algorithm.

Example server routing table (at server K1ABC):

server node | domain | hops

K1ABC k1abc.org 0
K1ABC internet 0
K2XYZ quirkyemail.com 0
K2XYZ internet 0
W3AB quirkyemail.com 1
W3AB k1abc.org 1
W3AB w3abmail.com 0
W4XYZ internet 0

(all callsigns and domain names are fictitious and randomly chosen)

In this example, K1ABC is currently connected to the Internet, hosts
k1abc.org email locally, and is "beaconing" two routes over the air.  K2XYZ
is beaconing two routes and hosts mail locally for quirkyemail.com.  W3AB
has no Internet connection, but he can "hear" K1ABC and K2XYZ and is set to
relay email one hop away, so he's beaconing the two routes for the other
servers he can see, plus he's hosting mail for w3abmail.com.  W4XYZ hosts no
mail locally, but has an Internet connection and beacons that as his only
route.

-Functionality could be added later so that servers can have multiple MX
records in (Internet) DNS with secondary lower priority entries pointing to
other PSKmail servers.  If the Internet connection goes down to the server
hosting the email for a domain, SMTP servers on the Internet would deliver
the mail to other PSKmail servers who will try to deliver the mail
over-the-air to the destination server.

-If clients could not reach an Internet-connected server to access a POP
account hosted somewhere on the Internet, they could send a "mail redirect"
command to whatever server they could hit over the air and indicate an
alternate email address (most likely a locally hosted account on that
server).  The server receiving the mail redirect request would forward it to
a PSKmail server in its routing table that is Internet connected.  That
server would access the POP account and re-mail the email to the address
indicated in the mail redirect request.  For example (using the above
routing table example):

Client VE1ABC can't get to an Internet-connected PSKmail server to retrieve
email from someaccount@xxxxxxxx  He sends a redirect request to the W3AB
server requesting someaccount@xxxxxxx, POP passwd: letmein123, redirect to
ve1abc@xxxxxxxxxxxxx  The W3AB node sends the redirect request to the K2XYZ
server who's in his routing table and Internet connected.  The K2XYZ server
retrieves the mail and forwards it to ve1abc@xxxxxxxxxxxxx  It follows the
routing algorithm above and since the MX server isn't reachable over the
Internet, it will revert to the server-to-server air protocol and transfer
the mail to the W3AB node.  The W3AB node follows the routing algorithm and
delivers the mail to the local POP box. VE1ABC then picks up his email from
the local mail account on the W3AB node.

Anyway, just some ideas I had....comments welcome...

73
Goody
K3NG


-- 

Blog: http://thek3ngreport.blogspot.com/

Other related posts: