More evidence of MS stifling open standards

In comp.os.linux.advocacy, Gordon wrote on Thu, 23 Jun 2005 09:21:18 +0100

And why, precisely, is this an improvement over one of the following?

1 DomainKeys, which apparently uses a public-private keyscheme to allow the receiver to check the sender's validity, but does not require that check.

2 A simple scheme such as the following:

a If a server wants to send E-mail to somebody at abc.com *, then it does an MX lookup on abc.com and talk *directly* (or as directly as routing allows) to one of the indicated servers. For the record, one gets for abc.com (which is, after all, a rather large networking giant owned by Disney corporation!):

$ hostx -t mx abc.com abc.com MX 10 mx1.disney.com abc.com MX 10 mx2.disney.com abc.com MX 10 mx3.disney.com abc.com MX 10 mx4.disney.com $

No relays allowed at the toplevel systems. (The only exception would be valid ISP subscribers going through their email server. Communications between their email server and the subscriber would be up to the ISP. These would be spelled out in the T&C. Presumably corporate subnets can do what they want, within their subnet; this policy only applies to Internet-connected mailservers.)

(see RFC821) must contain a valid hostname, and the hostname must authoritatively resolve to the IP address found in the accept() call of the server, again using an MX lookup. If the MX lookup fails the mail must be rejected. Note that subscriber DSP lines should not have valid MX records. An option here would also allow for an RFC1413 identd check, though since most of the mail will be relayed I'm not sure how much sense this makes beyond establishing that a valid user originated it.

c ISPs would be responsible for setting up their firewalls properly, blocking all outgoing port 25 requests from subscribers except to their mail server, or a destination in their demilitarized zone that would forward thereto.

d Spoofing DNS (MX or A) is of course already illegal.

e There might be an option for a "blacklist", but I get the feeling that it would probably convert to a "whitelist".

(I'm probably missing something but this is a start.)

3 Complete replacement of HTTP-25 with HTTPS-25 and the requirement that all senders to port 25 have valid digital certificates, as part of the general connection process. See RFC2246.

Of course one can probably mix and match here, as the transition period commences. We have until November.

-- It's still legal to go .sigless.