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/