So, let's see... the MPAA wants to bug your computer to make sure you don't copy movies, the RIAA wants to bug your computer to make sure you don't copy sound recordings, Microsoft wants to bug your computer to make sure you're not running copies of their software (and that you've paid your license fees for this week), and the FBI wants to bug your computer to make sure you're not threatening national security or communicating with terrorists. (And the ISPs want to tell you exactly how you can communicate with others)
If all of these organizations have their way, there won't be any general-purpose programmable computers anymore - just appliances that can do what Microsoft/MPAA/RIAA and the government think you can be trusted to do without taking away some potential money or power from them.
Linux really is getting to the point where it
can serve as a viable replacement for Windows.
The gap before was always the belief that UNIX was not user friendly, and the lack of applications. Now MacOS X has proven that UNIX can be user-friendly. As for applications, StarOffice and Opera fill the need for most folks, and StarOffice reads MS document formats so you can stay compatible.
(there are other good packages also; I mention these as an existence proof)
How long will it be until some PC vendor realizes they can lower the system cost significantly by bundling free software rather than Windows? How long will it be
until large businesses realize they can
lower their costs significantly by standardizing on free software, and get easier maintenance, and gain additional security to boot?
Windows is a dinosaur, and Microsoft realizes it. That's why they're trying so hard to get monopolies in other markets - they realize they can't continue to count on Windows to provide them with a solid revenue stream.
This sounds like an interesting tool. But I sincerely hope that it doesn't automagically impose NAT, since NATs break many kinds of applications.
NATs can be useful but only if you understand their limitations. Unfortunately, few people understand their limitations - least of all the NAT vendors. The choice of whether to use NAT is not one that can responsibly be made by someone who doesn't understand how they will affect applications' ability to operate, and such a choice certainly should not be made by some kind of automatic network configuration box.
(see http://www.cs.utk.edu/~moore/what-nats-break.html for a list of problems that NATs cause for apps)
And you're missing the point of my comment - which is that the filtering criteria you recommend
(a) are ineffective and (b) cause a lot of legitmiate mail to fail to be delivered.
Yes, you can refuse your own mail for any reason you like. But if you provide a service to other
people you have no right to arbitrarily decide to discard their incoming mail.
And if you trust the blacklists you're seriously deluded. Not only are they notoriously incorrect,
they don't actually catch much spam. And they do
block a lot of legitimate mail.
I'll believe in DRM when it preserves the rights
of the public, including all fair use rights and
all rights which have been identified by the courts, and considering that such rights change
over time and from one jurisdiction to another.
copyright is in need of a drastic overhaul and any
DRM based on the current notion of copyright is screwing the public.
"if the root were run properly, allowing any TLD to be added..."
This is an incredibly naive and irresponsible assertion.
If you aren't familiar enough with DNS to understand
the effect of adding TLDs on DNS cache hit rates (they decrease)
the effect of adding TLDs on DNS root server load (the loads increase)
the technical difficulties associated with having a large number of root servers (adding more servers doesn't necessarily help the load problem)
the undesirability of having poorly-managed TLDs
the undesirability of having a flat DNS space
(which is the logical result of truly allowing any TLD)
...then you don't know enough to be making such assertions.
Nor would allowing more TLDs help this particular problem. If a small number of new TLDs have problems with SLDs inappropriately claimed as trademarks, the problem would be even more difficult to fix with a large number of TLDs.
it keeps you from having your own domain for email
it keeps you from using a third-party service that provides a stable email address (like pobox.com)
it locks you into Verizon's service if you don't want to lose traffic at your verizon.com email address
it keeps you from using Verizon as an ISP if you want to use your company's email address while you travel (yes, you can use a tunnel, but that's a pain)
It might seem okay for them to make whatever restrictions they like for their SMTP servers, but unless they're willing to sell a nailed-up connection with a static ip for a reasonable price, it's not practical for their customers to run their own servers.
Granted, it's somewhat better than blocking port 25, as earthlink does, but it still sucks.
It's getting so that you can't do anything on the net (other than browse the web and exchange email using your assigned address) without getting your ISP's permission.
As bad as SPAM is, it doesn't justify having content police for the Internet. What's next - active monitoring of IP packets for copyrighted material?
Given that the primary purpose of WHOIS is to
publish site operational points-of-contact, to aid in tracking down problems, I find
interesting that none of the witnesses were
representatives of Internet service providers.
Apparently the committee doesn't care about whether
WHOIS can serve its intended purpose (before or
after any legislation which Congress might enact) - they only care about whether WHOIS can be used for
unintended purposes.
Folks who insist that ICANN should vastly expand the number of TLDs need to understand that the current root servers are already overloaded, and that drastically increasing the number of TLDs will also decrease the hit rates in everybody's resolver cache (the probability that the resolver has the TLD records cached goes way down). This further increases the load on the root servers.
There is a separate set of problems with adding more root servers, because the more servers for a zone (including the root), the harder it is to keep them in sync.
Re:ORBS == tool, not violation of freedon of speec
on
ORBS Forks
·
· Score: 1
1. bulk_mailer was written for use by legitimate mailing lists, because sendmail's default method of handling list mail is too slow. Users are forbidden to use it for spam.
From bulk_mailer.c:
* License to copy and use this program is granted according to the terms
* of the current version of the GNU General Public License. However,
* there is one exception: this program may not be used to send unsolicited
* commercial messages.
2. using ORBS would indeed reduce the amount of spam you received. it would also reduce the amount of legitimate mail you received.
perhaps the reason you got zero complaints from people who couldn't send you email, is because they couldn't send you email.
3. ORBS was forced on people whose ISPs naively adopted their blacklist.
Re:And for my next trick...
on
ORBS Forks
·
· Score: 1
If ORBS is a good thing, then persumably security systems that routinely sound alarms when authorized people are going about their designated business are also a good thing.
Re:ORBS == tool, not violation of freedon of speec
on
ORBS Forks
·
· Score: 1
ORBS would have been ``merely'' a tool to help identify open relays if they hadn't also advocated that folks not accept mail from those relays.
As it was, ORBS was a denial-of-service attack on Internet email.
The ORBS folks have done a tremendous disservice to the community - first by mis-reporting sites as open relays even when they had effective mechanisms in place to prevent being used as an effective spam relay; second, by mis-representing how effective their countermeasures were; third, by giving bad advice about relay blocking to naive mail system administrators.
As far as I can tell, these are the chief results of ORBS:
SPAM hasn't been reduced to any noticable degree.
Many people have had legitimate mail blocked because their sysadmins naively trusted ORBS's blacklist.
Many SMTP servers cannot accept mail for the domains for which they are listed as mail exchangers, because of broken relay-blocking code.
This is now a primary cause of failed mail for my mailing lists.
Misrepresentation of others (or for that matter, their SMTP servers) is not part of free speech, especially when it harms the operation of essential services such as email.
spammers aren't exercising free speech. they're
interfering with free speech by trespassing
into private fora, distrurbing private communications, and stealing resources that do not belong to them.
if the first amendment protects spammers, it also protects those who want to walk into my house uninvited for the purpose of nailing advertisements to my walls.
maybe someone should find out where the senator lives, and drive up and down his street at 4am playing advertisements for ponzi schemes over
a loudspeaker.
first of all, it's not clear that a publically funded institution has the right to censor its students' speech at all, unless that student is somehow breaking a law (libel, copyright violation, etc.).
second, a student at a public institution cannot be suspended without cause, which generally means that the student has to have broken some university regulation. even then it should require some kind of due process.
third, if the university really has destroyed the content of the site (including backups) then it may have destroyed evidence that the student could use to defend himself.
a lawyer is needed to figure out the specifics -
but if the article is accurate, the folks responsible for this crime should be made to pay dearly.
the good news is, windows is curable.
we just need a massive windows-awareness
education campaign.
so much disinformation, so little time
on
IETF vs. ICANN
·
· Score: 1
wow, where to start?
Lots of people who comment admit that they haven't read the RFCs, and thus, that they really don't understand the DNS well enough to be commenting on how it should, or even could, work.
Instead they rely on FUD and/or vague and ill-defined notions of decentralization, free expression, or whatever. Yes, these concepts are useful if you understand their limitations. But vague notions do not contribute to sound engineering.
Yes, you could make the root a distributed database. No, this doesn't solve the problem.
(Ever notice how in Gnutella you can get vastly different content under the same filename, and sometimes the filename misrepresents the content?)
If you want consistency of meaning of domain names (e.g. if you want slashdot.org to consistently reach the same web site) there has to be some party to establish some rules to discourage conflicts, and to resolve conflicts over who owns a domain name. You can't get this with multiple roots if the roots are autonomous.
There are practical limits to the size of the root domain, and thus, the number of TLDs, inherent in the DNS protocol, and to some degree, to any system like DNS. You don't want to overload the root servers, so you want clients to be able to cache lookups from the root servers. If you have too many TLDs then the liklihood that a TLD will be in your cache goes down, and the hit rate for the root servers goes up. You can replicate root servers but if you have too many root servers, or if the rate of change of the root is too high (due to a large number of TLDs) it's hard to keep them mutually consistent. It's hard to say exactly where those limits are, but it's safe to say that we cannot flatten the domain space or have an arbitrary number of TLDs and still have consistent meanings of DNS names.
The so-called "TLD shortage" is not artifical.
If you think ICANN is bad try having every domain dispute resolved by the courts, with different courts in different countries issuing conflicting rulings over who owns what names.
(and if you think the US government should run the DNS root, try telling that to China)
If you let people select between a finite number of roots, you end up creating another root which contains the list of (former) roots. Then you need another ICANN-like organization to manage that root. Either that or you have the opportunity for multiple parties to claim that they are root X.
If you get rid of ICANN, you need another organization to replace it. Theoretically it might be possible to improve on ICANN, but the political reality is that lots of powerful and greedy players want control over the DNS root. They're acting in their own interests, not yours. They're not going to willingly cooperate to produce something that works reasonably for everyone. We could easily do worse than ICANN if we started over, and we're unlikely to do significantly better.
It's actually fairly miraculous that none of them ended up fully controlling things, though some of them managed to saddle ICANN with a really unwieldy organizational structure and managed to encourage a lot of uninformed anti-ICANN FUD which continues to this day. (Which is not to say that ICANN doesn't deserve some criticism, but that most of the critics don't know what the h*ll they're talking about.)
Want to know how much authority an Internet-Draft has? Write a plain text document in the proper format (details on the ietf web site), and send it to internet-drafts@ietf.org. Bingo! You've now published your very own Internet-Draft. (Please don't do this unless you have a serious proposal to make: the IETF has limited resources like any other non-profit organiation.)
The point is this: if anybody can write an Internet-Draft, it obviously doesn't by itself carry much weight. Neither do the drafts that prompted this message.
If you think that adding a new TLD for your favorite category will help organize the Internet name space better, you aren't very familiar with either library science or intellectual property law. Librarians have been trying to classify things for decades, and they realize that there's a limit to the effectivness of this approach. No amount of effort will make all of the books that are related to one another end up next to each other on the shelves; neither will it be possible to neatly categorize everything under its "proper" TLD. Furthermore, intellectual property lawyers have consistently insisted (and often convinced courts) that trademarks are owned by their holders no matter which TLD they reside in. They don't care what geeks think about it; they can make more money by creating more opportunities for conflict.
Unlike the pseudo-roots, ICANN has gone to considerable effort to understand these problems, to gather sufficient technical clue in a variety of areas, to get input from various consituencies in many different areas from all over the world. They have not done a perfect job (not even close) but they have at least looked at the problems. The pseudo-roots have only looked at a small fraction of these issues, and their suggestions (like most of those presented here) are shockingly naive.
If you think that we can all just use our own mapping tables, who do you think controls the mappings of IP addresses to network locations? You will have taken control away from ICANN only to replace the DNS service with a much more primitive and error-prone mechanism, and given ultimate control over that mechanism to the ISPs
who represent your interests even less than ICANN.
If you get rid of ICANN, you still need an authority to resolve disputes about the root zone.
Without such an authority, we will inevitably have disagreements between various root servers and inconsistencies between the meanings of some DNS names. People want and need DNS names to be consistent across the entire Internet. You can't get this without a single authority for a zone
that can enforce some discipline about how the zone is maintained and resolve disputes when there are conflicts. You can and should try to give that authority the bare minimum control that it needs to do its job, but you can't get rid of it entirely. This is what ICANN tries to be - a single authority for the root but one that exercises no more control than necessary. It's not perfect, by any means, but that's the idea.
If you were to set up an authority from scratch,
it would need to be organized much like ICANN - with representation from various consituencies, including folks with technical clues about the DNS protocols, the registries, and so forth.
ICANN is a mess but it's not at all clear that you could do better by tearing it down and starting over. Too many people want control of the DNS root, because too many people see it as a way to extort money from people, or to exert control over people, or to gather information about people. Others want to do away with the DNS root because they see an opportunity to make money from a land grab of new TLDs - never mind that the DNS doesn't scale well to large numbers of TLDs (cache effectiveness goes way down, for instance).
One of the main reasons that ICANN is a mess is because folks from NSI (now verisign) worked hard to make it that way. For all practical purposes ICANN was created to keep NSI from controlling things (because they were treating the DNS root and the major TLDs as their monopoly). Since NSI recognized ICANN as an obvious threat to that monopoly, they lobbied in various ways (for instance, by having influential Congressmen attack it) to saddle ICANN with an unwieldy organization with significant clue dilution. They also encouraged those who, for reasons of their own, wanted to attack ICANN. Those efforts were largely successful. NSI will still control.COM for many more years despite providing really lousy service and subjecting their customers to unreasonable and unfair business terms designed to maintain NSI's control over the major TLDs, and ICANN has been hobbled by tremendous amounts of naive and uninformed criticism (along with some that they deserved) that was encouraged by NSI.
If we tried to tear ICANN down and start over,
the same people who worked so hard last time around to make it ineffective would also work hard trying to make the new organization ineffective. For instance, Verisign would see this as an opportunity to regain control of the root and the major TLDs, various folks in the US government would assert (once again) that the Internet belongs to the US and should be under US government control, and ITU would probably insist that they should control it by virtue of international treaty. None of these represent the interests of Internet users.
It may not be possible to "fix" ICANN to the extent that we would like. There are too many politically powerful folks out there who are bent on destroying it, or controlling it, for their own greedy or power-hungry purposes. Right now we have a tentative agreement to work with the ICANN structure, and an uneasy balance of power between the factions that would like to control it. Folks are trying to make it better, and I think it's slowly improving. It's far more likely that we can get better results in the long run by making small incremental changes to ICANN than by tearing it down and starting over.
there are resolver libraries which search relative to a default domain suffix, and which remove one component of that suffix at a time until they get to the root. for example, a user at a.b.tld might be trying to look up foo.bar, but his resolver would first try foo.bar.a.b.tld then foo.bar.b.tld, then foo.bar.tld, then (finally) foo.bar.
so someone who owned (say) com.store could screw everybody whose default domain ended in.store, by populating that com.store domain with bogus entries made to fool folks using.com. for instance, www.cnn.com.store could point to a fake www.cnn.com web site (perhaps a mirror of the real cnn.com site with different advertisements).
ideally of course resolvers wouldn't do this.
but there are a lot of broken implementations out there, and its easier to fix this with ICANN policy than it is to update all of those broken resolver implementations.
groups are not an addition; they were there
in RFC 822 and (I think) RFC 733 before that.
group syntax is just a way to let readers of
the message know what some subsets of the recipients in the To/CC field have in common;
it has nothing to do with mailing lists.
e.g.
To: friends: joe@example.net, bob@example.net;
enemies: sally@foo.bar, jane@foo.bar;
I don't think this is ambiguous at all in the new versions. Reports of delivery errors *always* go to the SMTP MAIL FROM address, or to the address in the Return-Path header field (which was copied from SMTP's MAIL FROM address during final delivery).
one reason that the mailing list problem was not solved by RFCs 2821/2822 is that this cannot be done without adding new functionality. and the DRUMS working group that was tasked with revising the RFCs was to update and clarify the spec - not to change it. They were specifically forbidden from creating new functionality.
now that this work is done perhaps the issues associated with replies to list traffic can be tackled. but the problem isn't as simple to solve as it seems at first, and most of the popular approaches are naive.
Slashdot Mirror
So, let's see... the MPAA wants to bug your computer to make sure you don't copy movies,
the RIAA wants to bug your computer to make sure you don't copy sound recordings, Microsoft wants to bug your computer to make sure you're not running copies of their software (and that you've paid your license fees for this week), and the FBI wants to bug your computer to make sure you're not threatening national security or communicating with terrorists. (And the ISPs want to tell you exactly how you can communicate with others)
If all of these organizations have their way, there won't be any general-purpose programmable computers anymore - just appliances that can do what Microsoft/MPAA/RIAA and the government think you can be trusted to do without taking away some potential money or power from them.
How long will it be until some PC vendor realizes they can lower the system cost significantly by bundling free software rather than Windows? How long will it be until large businesses realize they can lower their costs significantly by standardizing on free software, and get easier maintenance, and gain additional security to boot?
Windows is a dinosaur, and Microsoft realizes it. That's why they're trying so hard to get monopolies in other markets - they realize they can't continue to count on Windows to provide them with a solid revenue stream.
This sounds like an interesting tool. But I sincerely hope that it doesn't automagically impose NAT, since NATs break many kinds of applications.
NATs can be useful but only if you understand their limitations. Unfortunately, few people understand their limitations - least of all the NAT vendors. The choice of whether to use NAT is not one that can responsibly be made by someone who doesn't understand how they will affect applications' ability to operate, and such a choice certainly should not be made by some kind of automatic network configuration box.
(see http://www.cs.utk.edu/~moore/what-nats-break.html for a list of problems that NATs cause for apps)
why not just block all incoming traffic to port 25 then? it's even simpler than MAPS, and it's 100% effective at blocking spam.
of course, it's also 100% effective at blocking legitimate email. but you've already decided that you don't mind MAPS doing that for you.
And you're missing the point of my comment - which is that the filtering criteria you recommend
(a) are ineffective and (b) cause a lot of legitmiate mail to fail to be delivered.
Yes, you can refuse your own mail for any reason you like. But if you provide a service to other
people you have no right to arbitrarily decide to discard their incoming mail.
And if you trust the blacklists you're seriously deluded. Not only are they notoriously incorrect,
they don't actually catch much spam. And they do
block a lot of legitimate mail.
copyright is in need of a drastic overhaul and any DRM based on the current notion of copyright is screwing the public.
This is an incredibly naive and irresponsible assertion.
If you aren't familiar enough with DNS to understand
Nor would allowing more TLDs help this particular problem. If a small number of new TLDs have problems with SLDs inappropriately claimed as trademarks, the problem would be even more difficult to fix with a large number of TLDs.
It might seem okay for them to make whatever restrictions they like for their SMTP servers, but unless they're willing to sell a nailed-up connection with a static ip for a reasonable price, it's not practical for their customers to run their own servers.
Granted, it's somewhat better than blocking port 25, as earthlink does, but it still sucks.
It's getting so that you can't do anything on the net (other than browse the web and exchange email using your assigned address) without getting your ISP's permission.
As bad as SPAM is, it doesn't justify having content police for the Internet. What's next - active monitoring of IP packets for copyrighted material?
Given that the primary purpose of WHOIS is to publish site operational points-of-contact, to aid in tracking down problems, I find interesting that none of the witnesses were representatives of Internet service providers. Apparently the committee doesn't care about whether WHOIS can serve its intended purpose (before or after any legislation which Congress might enact) - they only care about whether WHOIS can be used for unintended purposes.
There is a separate set of problems with adding more root servers, because the more servers for a zone (including the root), the harder it is to keep them in sync.
1. bulk_mailer was written for use by legitimate mailing lists, because sendmail's default method of handling list mail is too slow. Users are forbidden to use it for spam.
From bulk_mailer.c:
* License to copy and use this program is granted according to the terms
* of the current version of the GNU General Public License. However,
* there is one exception: this program may not be used to send unsolicited
* commercial messages.
2. using ORBS would indeed reduce the amount of spam you received. it would also reduce the amount of legitimate mail you received.
perhaps the reason you got zero complaints from people who couldn't send you email, is because they couldn't send you email.
3. ORBS was forced on people whose ISPs naively adopted their blacklist.
If ORBS is a good thing, then persumably security systems that routinely sound alarms when authorized people are going about their designated business are also a good thing.
ORBS would have been ``merely'' a tool to help identify open relays if they hadn't also advocated that folks not accept mail from those relays. As it was, ORBS was a denial-of-service attack on Internet email.
As far as I can tell, these are the chief results of ORBS:
- SPAM hasn't been reduced to any noticable degree.
- Many people have had legitimate mail blocked because their sysadmins naively trusted ORBS's blacklist.
- Many SMTP servers cannot accept mail for the domains for which they are listed as mail exchangers, because of broken relay-blocking code.
This is now a primary cause of failed mail for my mailing lists.
Misrepresentation of others (or for that matter, their SMTP servers) is not part of free speech, especially when it harms the operation of essential services such as email.the only people who define spam this way are the spammers. most people realize that it's a sham.
spammers aren't exercising free speech. they're interfering with free speech by trespassing into private fora, distrurbing private communications, and stealing resources that do not belong to them.
if the first amendment protects spammers, it also protects those who want to walk into my house uninvited for the purpose of nailing advertisements to my walls.
maybe someone should find out where the senator lives, and drive up and down his street at 4am playing advertisements for ponzi schemes over a loudspeaker.
first of all, it's not clear that a publically funded institution has the right to censor its students' speech at all, unless that student is somehow breaking a law (libel, copyright violation, etc.). second, a student at a public institution cannot be suspended without cause, which generally means that the student has to have broken some university regulation. even then it should require some kind of due process. third, if the university really has destroyed the content of the site (including backups) then it may have destroyed evidence that the student could use to defend himself. a lawyer is needed to figure out the specifics - but if the article is accurate, the folks responsible for this crime should be made to pay dearly.
the good news is, windows is curable.
we just need a massive windows-awareness
education campaign.
If you want consistency of meaning of domain names (e.g. if you want slashdot.org to consistently reach the same web site) there has to be some party to establish some rules to discourage conflicts, and to resolve conflicts over who owns a domain name. You can't get this with multiple roots if the roots are autonomous.
It's actually fairly miraculous that none of them ended up fully controlling things, though some of them managed to saddle ICANN with a really unwieldy organizational structure and managed to encourage a lot of uninformed anti-ICANN FUD which continues to this day. (Which is not to say that ICANN doesn't deserve some criticism, but that most of the critics don't know what the h*ll they're talking about.)
If you get rid of ICANN, you still need an authority to resolve disputes about the root zone. Without such an authority, we will inevitably have disagreements between various root servers and inconsistencies between the meanings of some DNS names. People want and need DNS names to be consistent across the entire Internet. You can't get this without a single authority for a zone that can enforce some discipline about how the zone is maintained and resolve disputes when there are conflicts. You can and should try to give that authority the bare minimum control that it needs to do its job, but you can't get rid of it entirely. This is what ICANN tries to be - a single authority for the root but one that exercises no more control than necessary. It's not perfect, by any means, but that's the idea.
If you were to set up an authority from scratch, it would need to be organized much like ICANN - with representation from various consituencies, including folks with technical clues about the DNS protocols, the registries, and so forth.
ICANN is a mess but it's not at all clear that you could do better by tearing it down and starting over. Too many people want control of the DNS root, because too many people see it as a way to extort money from people, or to exert control over people, or to gather information about people. Others want to do away with the DNS root because they see an opportunity to make money from a land grab of new TLDs - never mind that the DNS doesn't scale well to large numbers of TLDs (cache effectiveness goes way down, for instance).
One of the main reasons that ICANN is a mess is because folks from NSI (now verisign) worked hard to make it that way. For all practical purposes ICANN was created to keep NSI from controlling things (because they were treating the DNS root and the major TLDs as their monopoly). Since NSI recognized ICANN as an obvious threat to that monopoly, they lobbied in various ways (for instance, by having influential Congressmen attack it) to saddle ICANN with an unwieldy organization with significant clue dilution. They also encouraged those who, for reasons of their own, wanted to attack ICANN. Those efforts were largely successful. NSI will still control .COM for many more years despite providing really lousy service and subjecting their customers to unreasonable and unfair business terms designed to maintain NSI's control over the major TLDs, and ICANN has been hobbled by tremendous amounts of naive and uninformed criticism (along with some that they deserved) that was encouraged by NSI.
If we tried to tear ICANN down and start over, the same people who worked so hard last time around to make it ineffective would also work hard trying to make the new organization ineffective. For instance, Verisign would see this as an opportunity to regain control of the root and the major TLDs, various folks in the US government would assert (once again) that the Internet belongs to the US and should be under US government control, and ITU would probably insist that they should control it by virtue of international treaty. None of these represent the interests of Internet users.
It may not be possible to "fix" ICANN to the extent that we would like. There are too many politically powerful folks out there who are bent on destroying it, or controlling it, for their own greedy or power-hungry purposes. Right now we have a tentative agreement to work with the ICANN structure, and an uneasy balance of power between the factions that would like to control it. Folks are trying to make it better, and I think it's slowly improving. It's far more likely that we can get better results in the long run by making small incremental changes to ICANN than by tearing it down and starting over.
there are resolver libraries which search relative to a default domain suffix, and which remove one component of that suffix at a time until they get to the root. for example, a user at a.b.tld might be trying to look up foo.bar, but his resolver would first try foo.bar.a.b.tld then foo.bar.b.tld, then foo.bar.tld, then (finally) foo.bar.
.store, by populating that com.store domain with bogus entries made to fool folks using .com. for instance, www.cnn.com.store could point to a fake www.cnn.com web site (perhaps a mirror of the real cnn.com site with different advertisements).
so someone who owned (say) com.store could screw everybody whose default domain ended in
ideally of course resolvers wouldn't do this.
but there are a lot of broken implementations out there, and its easier to fix this with ICANN policy than it is to update all of those broken resolver implementations.
groups are not an addition; they were there in RFC 822 and (I think) RFC 733 before that. group syntax is just a way to let readers of the message know what some subsets of the recipients in the To/CC field have in common; it has nothing to do with mailing lists. e.g. To: friends: joe@example.net, bob@example.net; enemies: sally@foo.bar, jane@foo.bar;
I don't think this is ambiguous at all in the new versions. Reports of delivery errors *always* go to the SMTP MAIL FROM address, or to the address in the Return-Path header field (which was copied from SMTP's MAIL FROM address during final delivery).
one reason that the mailing list problem was not solved by RFCs 2821/2822 is that this cannot be done without adding new functionality. and the DRUMS working group that was tasked with revising the RFCs was to update and clarify the spec - not to change it. They were specifically forbidden from creating new functionality.
now that this work is done perhaps the issues associated with replies to list traffic can be tackled. but the problem isn't as simple to solve as it seems at first, and most of the popular approaches are naive.