Slashdot Mirror

Jon Postel said it best: "Be liberal in what you accept, and conservative in what you send." A web browser that crashes due to invalid HTML fails this test. Execution must stop at once... yes, but the program should handle the error. A program that crashes is the Operating System handling a program with bug. See RFC 1122 for more details about the Requirements for Internet Hosts. Section 1.2.2 about the Robustness Principle explains better than I can why you're wrong.

Maybe I'm missing something about DomainKeys, but if I'm using an "@aol.com" "From:" header, I need to send it through AOL's SMTP servers so that AOL can sign it; if I can't reach AOL's SMTP servers, I can't get it signed. It's that simple. Even if I can get it signed by the SMTP server of my ISP, that signature won't match my "From:" header so it fails the check on the user's end.

What are you offering as mitigating that problem?

In the case of AOL you're probably right; they will, on account of their scale, probably want you to submit mail through them. But some domains might allow you to have your own key that is valid. And note the g= flag in the DNS record, which allows the domain to authorize a key only for a specific address.

If I have to sign it on my laptop with my personal key, that is entirely different (and much more difficult to manage) than DomainKeys.

It is indeed more difficult to manage. But I don't see anything in DomainKeys that says the signature couldn't be applied by your laptop, if you had the appropriate software and private key. So it's not different from DomainKeys.

Yes, but if it's not signed it will get dropped. That's the whole point. So it's not "drop them in the nearest mailbox" because it will look like spam--"From:" header doesn't match the signature--and get tossed.

Where does it say that unsigned mail will get dropped? That seems a long way off. But you're right, a signature for the wrong domain is more likely to be suspicious than a message that is just left unsigned.

Each user having a personal signature is a method, but it is much harder to manage. Yes, we can come up with a thousand other implementations to fill in the blanks, but that is not what was being proffered here; this discussion is about the DomainKeys implementation. So I'm confused how your response in any way mitigates the issues I presented.

Yes, per-user signatures are harder to manage, particularly if they are to be stored in the DNS, because they are more likely to require frequent changes than keys at the domain level. There are indeed other proposals out there; I'm the co-author of one of them.

With all the port 25 blocking going on, mailbox providers will surely begin opening up the Submit port.

Corporate IT folks give you VPNs to connect to their SMTP servers. ISPs and other servers are going to increasingly need to open up port 587 to get around port 25 blocks. Not being able to send mail through your real server is likely a very temporary problem that will be solved before sender authentication is widespread enough to drop mail.

Or even a standard one

Perhaps the RFC draft explains it ?

The Google engineers aren't stupid, they know that mail messages are routinely modified in transit, both the headers, which can be wrapped, rearranged, removed or added, and the MIME bodies, which can be decoded, reencoded, and even modified.

As engineers, they also know that cryptographic signatures are designed to detect message tampering.

Combine these two ideas and you get a system which will flag routine message modifications as forgeries, making the DomainKeys signature completely useless in practice. And yes, I've read the rfc draft, and found it wanting.

It *would* work if there was a standard set of well defined transformations performed on emails from the sender's MUA to the recipient's MUA. So if one Gmail user sends to another Gmail user, it'll be ok, because the message won't leave Google's servers.

But Google has no control over other people's systems. When I download mail by POP3 from my ISP, they've added SpamAssassin headers, which will simply destroy the DK cryptographic signature. When I get mail at work, they remove ZIP attachments, which destroys the DK signature. When mail passes through an older gateway, some MIME attachments can be decoded and reencoded, destroying the DK signature.

I could go on but you see the point. Once I get the mail in my mailreader, the DK header is useless junk, and it might as well have been forged, for all the good it does. In fact, if my trust in Google is so high that I'm willing to accept the DK header even though it fails, just because Google are the only ones using it so far, I guarantee that the spammers will pick up on that real fast.

DK is a draft, and is far from ready yet. It should be allowed to mature. Google shouldn't be deploying incomplete solutions. Unless... could this the beginning of the PHB era at Google? If so, I'm disappointed.

Who do they think they are, not prepending "X-" to their weird headers?

You're kidding, right?

The DomainKeys proposal has been submitted as an Internet-Draft. In other words, the DomainKeys-Signature header field is on the best possible track to becoming a recognized field. The only thing that recognition would mean that the DomainKeys-Signature field could not be used for other purposes.

Even so, RFC 822 does not require private header fields (what it calls "user-defined fields") to begin with X-; it is merely offered as good advice to those who never intend to seek official recognition for their fields.

Of course, the extension field name registry endorsed by RFC 822 does not exist, and in fact, no extension field name registry for 822-format messages exists. (It seems like IANA should maintain one, but they don't. RFC 2076 is a good start.) The best guidance is to treat de facto usage as the standard, and allow for expansion through the formal RFC procedures, of which publication as an Internet-Draft is an element.

And remember, it's already an Internet-Draft.

Mark

Who do they think they are, not prepending "X-" to their weird headers?

You're kidding, right?

The DomainKeys proposal has been submitted as an Internet-Draft. In other words, the DomainKeys-Signature header field is on the best possible track to becoming a recognized field. The only thing that recognition would mean that the DomainKeys-Signature field could not be used for other purposes.

Even so, RFC 822 does not require private header fields (what it calls "user-defined fields") to begin with X-; it is merely offered as good advice to those who never intend to seek official recognition for their fields.

Of course, the extension field name registry endorsed by RFC 822 does not exist, and in fact, no extension field name registry for 822-format messages exists. (It seems like IANA should maintain one, but they don't. RFC 2076 is a good start.) The best guidance is to treat de facto usage as the standard, and allow for expansion through the formal RFC procedures, of which publication as an Internet-Draft is an element.

And remember, it's already an Internet-Draft.

Mark

Who do they think they are, not prepending "X-" to their weird headers?

You're kidding, right?

The DomainKeys proposal has been submitted as an Internet-Draft. In other words, the DomainKeys-Signature header field is on the best possible track to becoming a recognized field. The only thing that recognition would mean that the DomainKeys-Signature field could not be used for other purposes.

Even so, RFC 822 does not require private header fields (what it calls "user-defined fields") to begin with X-; it is merely offered as good advice to those who never intend to seek official recognition for their fields.

Of course, the extension field name registry endorsed by RFC 822 does not exist, and in fact, no extension field name registry for 822-format messages exists. (It seems like IANA should maintain one, but they don't. RFC 2076 is a good start.) The best guidance is to treat de facto usage as the standard, and allow for expansion through the formal RFC procedures, of which publication as an Internet-Draft is an element.

And remember, it's already an Internet-Draft.

Mark

Who do they think they are, not prepending "X-" to their weird headers?

You're kidding, right?

The DomainKeys proposal has been submitted as an Internet-Draft. In other words, the DomainKeys-Signature header field is on the best possible track to becoming a recognized field. The only thing that recognition would mean that the DomainKeys-Signature field could not be used for other purposes.

Even so, RFC 822 does not require private header fields (what it calls "user-defined fields") to begin with X-; it is merely offered as good advice to those who never intend to seek official recognition for their fields.

Of course, the extension field name registry endorsed by RFC 822 does not exist, and in fact, no extension field name registry for 822-format messages exists. (It seems like IANA should maintain one, but they don't. RFC 2076 is a good start.) The best guidance is to treat de facto usage as the standard, and allow for expansion through the formal RFC procedures, of which publication as an Internet-Draft is an element.

And remember, it's already an Internet-Draft.

Mark

It doesn't do the whole depth that you get inside your own GroupWise system - but you do get back a message that the remote MTA received the message.

Having built, and tested a system that does allow access to the wireless network through a redirected login page I have to disagree.

While you might have an SSL homepage, and use a proxy, the vast majority of users don't have this. The ones that do, know how to change it, the ones that don't know how to change it need support. 802.1x or a reserved address and domain name aren't really a viable solution right now. The above user that can't change proxy settings, or view a non SSL webpage, still needs support. Guess what else, all you normal users arn't going to have a clue about these either, and they'll need support too. Suddenly your free hotspot, just got more expensive to operate.

The problem with all the solutions is that there isn't really a way to do it that requires no support, but there are ways to do it that require minimal support, keeping costs down, and the service free and valuable to users. The more barriers you put in a user's way, the less they will use the service, all services that we have installed or planned are based around the concept of adding value to a location, ease of use is top of our list when it comes to features, since it's ease of use that allows more people to use the service.

We're both using flexible interpretations of the RFC's, but if you look at the RFC for DHCP they play a bit loose and fast themselves.

"DHCP requires creative use of the client's TCP/IP software and liberal interpretation of RFC 1122"
http://www.ietf.org/rfc/rfc2131.txt Page 10.

I don't even need a liberal interpretation to make what I need work, no special conditions other than make a plain http request to a website and you'll see the login, login and enjoy for free. The architectural problems you mention are minor and affect a small subset of the user base (I have statistics that back this claim up). The support needs that would be created by either of your propsed solutions would mean that the hotspots I run for free would either have to move to a pay to play model, or would need to charge more for support (we charge a nominal 5p/min or so for support calls). Neither really appeal to me, so speaking as someone on the ground, the web-redirect is the best answer to the problem.

The certificate side of things is exactly what hurts, as a user. Either you pay bucks, or you use CAcert. But either way, the steps are far, far more complicated than "gpg --gen-key".

Also, to illustrate what hurts as a developer, compare the current OpenPGP protocol to the new End to End spec.

A good summary of the new E2E spec would be "wrap the XML which made things so simple into another format which will require you to write a new parser, then encrypt that, wrap it in S/MIME, and put it back into the XML."

unlike say the http 1.1 RFC http://www.ietf.org/rfc/rfc2616.txt which weighs in a trim 176 pages?

Since XMPP has been in development for a while, hopefully it shouldn't take too much time for it to climb the Standards Track to full Internet Standard. Right now, XMPP is in the Proposed Standard category, which is the first step (look at the bottom of the list).

The next level up is Draft Standard. To become a Draft Standard, the RFC has to be a Proposed Standard for at least six months, have two independently developed interoperable implementations, and have had "sufficient" successful use. I think that Jabber is pretty much a shoe-in for this category. Several servers been in operation for years from which a large amount of experience with the protocol has been gained, so there shouldn't be any contention about XMPP not being mature. There are many independent implementations, so that shouldn't be an issue either. I don't think there will be any problems getting to Draft Standard in six months.

The final step in the Standards Process is Internet Standard, where the RFC retains its RFC number, and gets the all important STD series number. A standard needs to be in the Draft Standard category at least four months (or until at least one IETF meeting has occurred, whichever comes later). On the technical side, there needs to be a significant implementation of the protocol and much more experience using it needs to be gained. The level of maturity for Standards is such that the protocol is believed to be beneficial to the community. Again, since XMPP has been in the works for over two years now and there are now commercial implementations, I don't think there is a problem with the usage requirements. Furthermore, as the only open messaging protocol, it has a large value to the Internet. Thus, I think getting Jabber to full standard easily is not out of the question.

In about a year, we'll have an Internet Standard for IM and prescence (and an open one, at that)!

RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core
RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
RFC 3922: Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)

RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core
RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
RFC 3922: Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)

RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core
RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
RFC 3922: Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)

RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core
RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
RFC 3922: Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)

application/ogg mimetype is now official

I know it's not the Ogg developers' fault, but media types really need overhauling. When there's only application/ogg, there's no way for an HTTP client to indicate that some forms of Ogg (e.g. Ogg Vorbis, Ogg FLAC, Ogg Speex) are acceptable while others aren't. This makes it impossible to do content negotation (i.e. it's impossible to transparently serve differently-coded Ogg files depending upon what the client supports).

Media types should really be able to have any number of subtypes, so, for example, you could have application/ogg/vorbis and application/ogg/speex.

In any case, it wasn't the libvorbis 1.1.1 release that made application/ogg official, it was the publishing of RFC 3534.

Okay, this is about the third time I've looked at that. How is it not just SPF? I'm perfectly content to believe that MS just added a useless step in order to add license restrictions, but that doesn't explain why the IETF and such actually considered it separately from SPF.

What am I missing here?

This is the problem with having "standards" put out by people other than the IETF and IEEE

1. Will it solve spam? Well, it was announced with the statement "Spam as a technical problem is solved by SPF." but -- despite the lack of a full public retraction of that statement, we're now told it was never intended to solve spam. Fine...but let's note that if it didn't claim to have something do with spam, few people, if any, would care about it.

2. Will it solve forgeries? No. There are still a myriad of ways forgeries can be constructed -- and many of those will pass SPF checks, because they utilize the outbound mail servers as unforged mail. (And while you might think that the people running those mail servers would detect and correct this...you'd be wrong. They've built up multi-year track records demonstrating that they either don't know or don't care -- so it's unlikely they'll wake up tomorrow feeling differently.)

3. Will it stop bounces from forgeries? Maybe. But it's important to note that it doesn't stop them by actually FIXING the broken mail systems which are generating them. This is a brittle approach to solving the problem which has as its only merit that it may be easier than tackling the core issue. But experience strongly suggests that it would be much better for the long-term health of the Internet's mail system to roll up our sleeves and actually deal with the bounce-vs-reject issue than find a way to sweep it under the carpet.

4. Will it stop joe-jobs? Maybe -- if enough people use it, if spammers don't game it (and they're already working on it) and if it doesn't impose its own consequences. (Consider what will happen to your DNS servers if some spammer decides to joe-job your domain and N mail servers out there -- instead of just rejecting the traffic and being done with it -- all try to verify your SPF records simultaneously.)

5. Does it solve an important problem? No. Forgery isn't a serious problem -- spam is.

6. Does it solve the problem thoroughly? No. Really solving mail forgery requires secure DNS, public-key encryption of message content, secure end-user systems, secure mail clients, and other components. These all exist, but until they're ubiquitous, any sense that the mail forgery problem is "solved" is illusory.

Despite all this, there are a few good ideas in SPF, and in DomainKeys, and in some of the other proposals which are out there. But those ideas need to be weighed in light of the environment in which we find ourselves, and take into account:

• Millions of hijacked systems
• Cheap "throwaway" domains
• "Bulletproof" hosting
• Rapidly-updating DNS (which just got worse)
• non-SMTP methods of sending spam
• poorly-maintained mail gateways
• Scalability (SMTP, DNS, etc.) concerns

There are actually several such proposals, and there was a Birds of a Feather session at the last IETF meeting to discuss them (since this approach is explicitly out-of-scope for the MARID WG.

Draft minutes of the meeting are at http://www.ietf.org/proceedings/04aug/minutes/mass .htm

I agree, but there's one thing that confuses me. Elsewhere in this discussion thare are claims that Microsoft has patented the PRA algorithm, Purported Responsible Address. This reads the mail headers to figure out where the mail claims to come from. Yet the IETF decision reads:

With regard to items 3 and 4 above, it is also the opinion of the co-chairs that any attempt by the MARID working group to define any new scopes other than "mailfrom" and "pra" for the SPF syntax will at this time result in failure to find consensus within the working group.

This suggests that PRA actually is an effort which the Working Group will pursue. How can they do so if Microsoft has patented PRA with unknown terms?

I read Microsoft's Intellectual Property Disclosure. It says that the covered material is:

Both Sender ID: Authenticating E-mail <draft-ietf-marid-core-03.txt>
and Purported Responsible Address in E-mail Messages
in combination.

This does not make clear the exact scope of the PRA patent. It could just cover the one specific sequence of steps in the PRA document. Or it could cover the very idea of scanning the email to find the PRA. Or something in between.

Usually patents are written in a hierarchical manner. First you have the broadest possible claim covering the general idea of what you want to do. Then you have a series of dependent claims which expand on the earlier one(s) by providing more details about how it will work. This gives you the greatest possible coverage while allowing the patent to survive and be useful even if some of the broadest claims are invalidated.

I don't see how the IETF WG can proceed with PRA type algorithms when Microsoft has advised them that PRA is covered by a pending patent. And given that they are doing so, it certainly does not seem like they are rejecting Microsoft's approach.

I agree, but there's one thing that confuses me. Elsewhere in this discussion thare are claims that Microsoft has patented the PRA algorithm, Purported Responsible Address. This reads the mail headers to figure out where the mail claims to come from. Yet the IETF decision reads:

With regard to items 3 and 4 above, it is also the opinion of the co-chairs that any attempt by the MARID working group to define any new scopes other than "mailfrom" and "pra" for the SPF syntax will at this time result in failure to find consensus within the working group.

This suggests that PRA actually is an effort which the Working Group will pursue. How can they do so if Microsoft has patented PRA with unknown terms?

I read Microsoft's Intellectual Property Disclosure. It says that the covered material is:

Both Sender ID: Authenticating E-mail <draft-ietf-marid-core-03.txt>
and Purported Responsible Address in E-mail Messages
in combination.

This does not make clear the exact scope of the PRA patent. It could just cover the one specific sequence of steps in the PRA document. Or it could cover the very idea of scanning the email to find the PRA. Or something in between.

Usually patents are written in a hierarchical manner. First you have the broadest possible claim covering the general idea of what you want to do. Then you have a series of dependent claims which expand on the earlier one(s) by providing more details about how it will work. This gives you the greatest possible coverage while allowing the patent to survive and be useful even if some of the broadest claims are invalidated.

I don't see how the IETF WG can proceed with PRA type algorithms when Microsoft has advised them that PRA is covered by a pending patent. And given that they are doing so, it certainly does not seem like they are rejecting Microsoft's approach.

Unfortunately, that's what's covered by Microsoft's patent.

Really.

Microsoft want to patent going through a header to see who the message claims to have been sent by - the "Purported Responsible Address" - aka the PRA.

Take a look at the algorithm they are trying to patent and ask yourself how many times you've done this yourself when trying to figure out where mail came from.

It's like trying to patent an algorithm to find the author of a book: 1) look for a name on the cover 2) look for a name on the spine 3) look for a name in the copyright declaration 4) if you've found it, there you go! 5) if you haven't, too bad.

How can they expect to be taken seriously?

Patents are always a monopoly.

That said, the answer seems to be no. The IETF can adopt a patent-encumbered method as a standard.

As you can see here, there appear to be quite a number of patents which may or may not relate to IETF standards. And you can see that in these cases, it appears that the IETF demands that the patent is licensed on "fair, reasonable and non-discriminatory terms".. whatever that means.

Yes, the IETF does accept proposals which are subject to IPR claims in whatever form.

Here's for more information about the official IPR position of the IETF:

http://www.ietf.org/ipr.html

The main reason IP addresses are "leased" was in order to make maximum use out of the available address block. Each lease would run for three days. If the machine was turned off, the IP address could be recycled to another user. If it remained on, it would be renewed. A small utility application is provided to allow users to release the lease in case of bad configurations. Most cable TV broadband networks use hardware from Scientific Atlanta, so you could blame them.

The DHCP specification (which implements this concept of 'leases') allows a machine to renew its existing IP address. With many systems, the device drivers are smart enough to constantly renew the same IP address. Although I really would like to name my machine, as having a system name of @1-5-08-00-D0-Be-D0 doesn't exactly make me feel at home. And having to remember todays IP address so I can 'ssh' home doesn't help either.

Aft

The Infinite Monkey Protocol Suite (IMPS)

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. The suite includes communications and control protocols for monkeys and the organizations that interact with them.

http://www.ietf.org/rfc/rfc2795.txt/

If part(s) of a contribution by France Telecom SA employees is(are) included in an IETF standard and France Telecom SA has patents and/or pending applications that are essential to implementation of such included part(s), France Telecom is prepared to grant, on the basis of reciprocity (grant-back) whenever applicable, a license on such included part(s) on reasonable, non-discriminatory terms and conditions.

Such license shall be subject to a written license agreement before using such patents and/or patent applications.

1. open standards based, and;
2. secure.

1. Router LSA, fundamental LSA. Used to describe each router-node, particularly their links, in SPF

2. Network LSA, fundamental LSA. Generated by the designated router on each network, to describe that network for SPF.

3. Summary LSA, used to aggregrate networks between areas

4. ASBR summary, OSPF AS global LSAs to describe ASBRs, in particular, without a corresponding ASBR-summary for an originating router, an AS-External route is not valid.

5. AS external, to describe routes external to the OSPF domain (OSPF AS), ie routes which are distributed into OSPF

6. Multicast Group Membership, for use by the mostly defunct MOSPF multicast routing protocol.

7. NSSA LSA, used to allow ASBRs to exist in otherwise stubby areas (NSSA areas), only valid within NSSA areas, must be translated at the NSSA ABR if one wishes to propogate the routing information to rest of OSPF domain

8. External attributes, defunct

9, 10, 11. Opaque LSAs, with a distribution scope of link, area, AS respectively. Used to propogate arbitrary data, opaque to OSPF itself, over the OSPF protocol, eg traffic-engineering information, information to allow graceful restart of OSPF, even HA clustering information.

that's about it..

What's so awful about vCard?
At least it's standardized.

OK, four people used Gopher (give or take an order of magnitude or three). How many people use WWW?

Can you say inertia? I knew you could.


I guess you've never heard of a smily or netiquette.

You might also find that studying Internet history as well as growing up can diminish your cluelessness.

Heh. It's not just that... one of the things it fixes is the Content-Type HTTP header handling - the specification for which was published five years ago.

I might be mistaken, but Zero Conf was developed by an Apple employee named Stuart Cheshire and others at the IETF as an open standard. Are these the "University dudes" you're to whom you are refering?

Further, from what I've read, zeroconf seems to be loosely based on Appletalk.

And the Streambox guys did it by reverse-engineering the protocol.

I'm an architect for a large corporation that is today trying to find a replacement for NFS. Our key goals are:
- Integration with a Kerberos SSO strategy
- Fast performance
- Cross-platform compatibility with Windows
- Robust Access Control mechanisms, RBAC would be nice but DACL is probably reality.

I'm working on the linux NFSv4 implementation: krb5 support, performance at least as good as NFSv3, built-in ACLs, implementations for Windows also apparently exist (and some features, e.g., share locks and an NT-like ACL model, were clearly chosen to improve windows interoperability--but I'm not a Windows expert).

--Bruce Fields

Clause 1.7 of the license (damned non-cut and paste pdf)

The "Caller ID for E-mail Specification" means the specification having submission ID "draft-atkinson-callerid-00.txt" and entitled "Caller ID for E-Mail," published by Microsoft Corporation on May 19 2004 and located at the following link: http://www.ietf.org/internet-drafts/draft-atkinson -callerid-00.txt.

From (an admittedly quick) reading the draft it is not the merged SPF protocol, it's the original XML based protocol. The merged draft is "draft-ietf-marid-core-01.txt". The license referred to does NOT apply.

That will eventually lead you to Microsoft's page on Sender ID. The actual licence agreement is halfway down the page (they refer to it as caller id and sender id interchangeably it seems).

If you do read the licence agreement you'll see that not only does an MTA developer have to sign/return it but so does an end-user _if_ and _only_ _if_ they want the source to their MTA.

That is, just about everyone. Additionally the language in the license explicitly makes it impossible to use with LGPL/GPL'd MTAs.

Without a truckload of background information, it is hard to figure out how Doug's reply even relates to the parent message by RMS.

RFC 2821 is about the only thing which is referred to in a way that can be looked up without analyzing approximately half of the list archive... but if the intention is to convince the world that M$'s about to do some dastardly deed, and how it could be averted, this information will need to be presented in a much more enlightening and accessible fashion.

From the copyright for RFC2821: (SMTP):

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.

From the copyright for Sender ID:

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights

Note that "the authors" is:
J. Lyon
Microsoft Corp
M. Wong
pobox.com

I used to be an SPF fan, largely because it was the source of many hilariously mistaken /. posts, but now I think I need some clarification.

From the copyright for RFC2821: (SMTP):

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.

From the copyright for Sender ID:

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights

Note that "the authors" is:
J. Lyon
Microsoft Corp
M. Wong
pobox.com

I used to be an SPF fan, largely because it was the source of many hilariously mistaken /. posts, but now I think I need some clarification.

So, the license RMS is ranting about doesn't apply, and there doesn't appear to be another license on the Microsoft site. Having said that the Microsoft license does not stop the distribution of source, in fact there's a specific clause allowing it (2.2), you just have to include a paragraph in the source code. Nor does RMS say what his problem is, aside from "Grrr, it's Microsoft".

Of course the SPF implementation is still "non-licensed", there's no mention of restrictions, although they do point out there are patents all over the anti-spam arena.

But hey, we don't expect people to look at this stuff, lets just add yet another protocol.

So the idea has been presented to the FTC, the ACM, the NBER and the ITU. Big deal. What about the Internet Engineering Task Force, guys? They have more than a little to do with setting standards for the Internet. Technical flaws aside, any effort to change the way email gets handled that tries to end-run the IETF is doomed to failure anyway.

I'm tempted to answer your points directly, however, I think it would be better to spend my time pointing you towards the following documents, which, firstly, describe the Internet architecture, and why it was designed the way it is, and secondly, describe how NAT / overlapping address spaces break the architecture. I don't think a debate on NAT can take place until both the design of the Internet and how NAT breaks that design are understood.

• RFC 1958 - Architectural Principles of the Internet - Section 2.3 "It is also generally felt that end-to-end functions can best be realised by end-to-end protocols." is the property that NAT breaks.
• RFC 1631 - The IP Network Address Translator (NAT) - even the original NAT RFC suggests limitations - from section 4. "Conclusions" - "NAT may be a good short term solution to the address depletion and scaling problems. This is because it requires very few changes and can be installed incrementally. NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution. Only implementation and experimentation will determine its appropriateness."
• RFC 3022 - Traditional IP Network Address Translator (Traditional NAT) - the update to RFC1631 lists a number of limitations as well.
• RFC 2993 - Architectural Implications of NAT - a very good document, well worth reading.
• RFC 1627 - Network 10 Considered Harmful (Some Practices Shouldn't be Codified)
• Deprecating Site Local Addresses - an IPv6 oriented document, discussing "site local" addresses, and the problems they cause. They are the equivalent of IPv4 RFC1918 addresses eg. Network 10. The same problems it discusses also occur with RFC1918 addresses.
• Things that NATs break - listed just for completeness.
• The Middleware Dilemma - NAT is a form of middleware, as it does more than just forward IP packets - it maintains state within the network (see RFC1958 for why maintaining state in the network is a problem).
• The Digital Imprimatur : How big brother and big media can put the Internet genie back in the bottle. - The Firewalled Consumer section discusses what NAT is doing to the Internet at a higher level.

Once you've read through these documents, at least to the point of having a basic understanding of them, go through the comment I'm responding to, and look for ways as to how some of your solutions can be better and much more simply achieved via public addressing and the removal of NAT.

Hey and you know whats funny? Most big cablemodem and DSL ISP's *are already doing* exactly that - blocking outbound port 25. And more are realizing its a good idea every day.

Most end users needing to submit mail for outbound relay can use port 587 as more and most hosting companies recognize the need for that.

Open relays were slowly put mostly out of style, soon too will trojaned and 'open proxy by default' wincrap machines sitting on broadband connections. The big question is what will the spammers do next? Get a real job? - we can only hope.

So whats news here, exactly?