At 03:21 PM 5/17/2005 -0400, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
On Tue, 17 May 2005 12:06:16 PDT, David MacQuigg said:
I would look for a TXT record at
> _AUTH.spammers-r-us.com.mail.gov
If you don't understand why such a mail.gov solution won't fly, you probably
shouldn't be designing stuff in this area.
Hint: There's more Internet than US. And most of the world has good reason
to distrust anything in .GOV because it's US-run.
I'm sure you can think of a solution to this problem. Hint: You have to
want a solution.
Hint 2: Nobody trusts ICANN to manage this correctly either.
Looks like the two most likely leaders are the FTC and Microsoft. I don't
see the IETF stepping up to the plate. The FTC will give us a technically
clumsy, not very effective, and legally burdensome solution. Microsoft
will give us a convoluted mess, which won't work well at first, but given a
couple more years of stumbling around by the competition, they will
eventually get it to work.
Hint 3: The only reason why people trust IETF as far as they do is because
it's easier to follow somebody else's specs to get interoperable than design
your own (unless you're a company bent on vendor lock-in, of course).
I'm still hoping for an IETF solution, but not counting on it. The IETF
process has worked well for most of its history. Maybe it will continue to
work for problems other than spam, but it looks to me like they gave up
after MARID. You can't get a consensus when there is an uncompromising
minority, and anything related to spam is going to nothing but
uncompromising minorities.
The ID Declaration proposal is the easiest piece. I'll see how that goes
before committing any more time to the IETF process.
By the way Microsoft is not the only group bent on "lock-in". Sometimes I
think its easier to deal with people whose motivations are financial than
those who have their ego tied up in a computer program. :>)
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *