IMHO I don't think it would be that horrible of an idea with the right amount of notification and education to state something such as "register your mail servers by this date or risk service interruption". ] but I also run a SMTP server on my laptop which bounces usually between two ] addresses (one at home, one at work)

Actually, I don't care too much about "the rest of you", nothing would force you to publish your outbound mail servers. As long as a few big sites (spam targets) honor the white list I publish for *my* own domain, great. It's voluntary, and to your advantage both as a sender and a receiver to adopt it (assuming the mailing list thing is resolvable). Domains like pobox.com wouldn't be able to use this, so it shouldn't be a requirement.

Of course this period would be several months, if not a year+ .

Planned obsolescence is another interesting idea, but a sure way to implement it isn't coming to mind. Basically I want my MTA to refuse deliveries from MTAs 'X' years/days older than itself. "Years older" vs absolute age is important, so that an isolated enterprise network somewhere could continue to inter-operate with itself no matter how old it grew. How about: use the skey style unrolling (or is that "pre-rolled"?) passwords to generate cookies. Someone we trust creates the 'generation 0' cookie, one-way encrypts it one thousand times, and tells us all the 'generation 1000' cookie, which we put into our MTA configs. At the next tick of the clock (one year later), the authority releases the cookie for 'generation 999', and some of us update our configs (or Microsoft and Sendmail update their new distributions - but NOT Windows Update?). You can go 'X' years without updating your configs if you want - for whatever 'X' you think most of the Internet has chosen. Talking to MTAs newer than me: If my MTA is setup with cookie 'generation 950' and an MTA connects to me offering cookie 'generation 948', then I should be able to one-way encrypt the offered cookie twice and compare it to my cookie and verify that they really are two generations ahead of me, and allow the connection. The skey trick means I don't need to know future cookies to accept email from them. Talking to MTAs older than me: I don't talk to machines 'X' generations older than me. I have the last 'X' cookies hard coded in my configs, or I just (at start time) one-way encrypt my current cookie a maximum of 'X' times to generate all of the valid old cookies I'll accept. The idea isn't to take live humans (including spammers) out of the loop, just the no-admin Windows/Solaris/Linux/whatever machines that haven't been patched in 'X' years. This year's cookie isn't a secret, just next year's and the year after's, so an admin can't setup a box with 'generation 0' and leave it alone for a thousand years to annoy the rest of us.

Look. The DNS is seriously screwed-up enough as it is. Let's not take a bad model and replicate it elsewhere.

I'm not saying use DNS specifically, but using something "DNS" like. Whether it be a database of public keys or certs really doesn't make a difference at this level.

Sure. Are you willing to be the first?

If it came down to the wire and something like this were implemented, and enforced, then yes, I'd be the first in line. If the software, the system and the means are available, I'd make sure we were registered before the system went live. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net Exclusive: We're the only ones who have the documentation.