North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: IETF SMTP Working Group Proposal at smtpng.org
- From: sjj
- Date: Wed Aug 21 16:38:17 2002
> 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
> 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.