nanog mailing list archives
Re: IETF SMTP Working Group Proposal at smtpng.org
From: sjj () pobox com
Date: Wed, 21 Aug 2002 16:20:14 -0400
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.
Current thread:
- IETF SMTP Working Group Proposal at smtpng.org william (Aug 20)
- Re: IETF SMTP Working Group Proposal at smtpng.org Avleen Vig (Aug 20)
- Re: IETF SMTP Working Group Proposal at smtpng.org william (Aug 20)
- Re: IETF SMTP Working Group Proposal at smtpng.org Avleen Vig (Aug 20)
- Re: IETF SMTP Working Group Proposal at smtpng.org sjj (Aug 21)
- RE: IETF SMTP Working Group Proposal at smtpng.org Robert Blayzor (Aug 21)
- Re: IETF SMTP Working Group Proposal at smtpng.org Ron da Silva (Aug 21)
- Re: IETF SMTP Working Group Proposal at smtpng.org Peter van Dijk (Aug 21)
- Re: IETF SMTP Working Group Proposal at smtpng.org Dave Israel (Aug 21)
- RE: IETF SMTP Working Group Proposal at smtpng.org Robert Blayzor (Aug 21)
- Re: IETF SMTP Working Group Proposal at smtpng.org sjj (Aug 21)
- RE: IETF SMTP Working Group Proposal at smtpng.org Brad Knowles (Aug 21)
- RE: IETF SMTP Working Group Proposal at smtpng.org Robert Blayzor (Aug 21)
- RE: IETF SMTP Working Group Proposal at smtpng.org Brad Knowles (Aug 21)
- Re: IETF SMTP Working Group Proposal at smtpng.org william (Aug 20)
- Re: IETF SMTP Working Group Proposal at smtpng.org Avleen Vig (Aug 20)
- Re: IETF SMTP Working Group Proposal at smtpng.org Brad Knowles (Aug 21)
- Re: IETF SMTP Working Group Proposal at smtpng.org batz (Aug 21)
- Re: IETF SMTP Working Group Proposal at smtpng.org Gary E. Miller (Aug 21)
- Re: IETF SMTP Working Group Proposal at smtpng.org batz (Aug 21)
- Re: IETF SMTP Working Group Proposal at smtpng.org Gary E. Miller (Aug 21)
- Re: IETF SMTP Working Group Proposal at smtpng.org batz (Aug 21)
- RE: IETF SMTP Working Group Proposal at smtpng.org Al Rowland (Aug 21)