You seem to complaining that this might not work because everyone on the planet would need to use it and even then spammers could use their own domains.
Certainly it's true that nearly everyone will need to get on board for this to work. Fortunately, it should be an easy update on both the MTA and DNS ends.
The real advantage here, I think, is that it will make filtering and blacklisting much easier. Instead of trying to filter on 18 zillion weird rules and scads of IP addresses, some of which may have some valid users, you just need to filter on domain names.
For this to work, we will need one or more trustworthy registries of bad domain names. And it should probably be distributed, with a way to continually update it by automatically propagating the list of bad domains to all clients. There should be a way to get a domain into the blacklist very quickly if anyone receives spam from that domain.
Alternatively, a system could be in place to treat all new domains as bad by default. That has obvious problems though -- how would you get your domain trusted? Would it require a VeriSign like identification process? I would oppose that -- I think people should be able to buy domains and freely run email servers on them without paying some central "authority."
My biggest concern with this idea is that I run a domain where I give out POP email addresses to people. I'm still trying to figure out how that will affect me.
For instance, the box on which I get all my mail, to which all my mailing list subscriptions go, and which is associated with my online identity everywhere I have one...is located halfway across the continent from me. It's neither my home Linux box, nor my local ISP. I keep it that way because I never know if I might need to change ISPs for some reasons, and that box is always up and always there. I use fetchmail to pull down my email.
But as a matter of course, I have mutt configured on my desktop box to send in the name of my halfway-across-the-country account, even though it sends through my ISP's SMTP server. (It used to send through my home Linux box's own SMTP server, but then a lot of addresses started bouncing it because it was on a list of cablemodem IPs.) How would I be able to continue doing this under such a system?
I've always thought that ISPs should add a default "smtp" zone for their customers that resolves to their mail server. That way, you can set your progarm up to use "smtp" and no matter where you are, it will resolve properly.
Now, as far as blocking port 25, I've always thought that was a great idea as well, until last week. Our office has used BellZinc's DSL for connectivity. A few months ago, our smtp suddenly stopped working, and after calling tech support, they told me they had accidentally left port 25 on one of their racks unblocked (and I happened to be on that rack) so they had fixed the situation. (Actually, I had to call twice to find that out, the first guy had no clue whatsoever).
So I switched the smtp server in the office to resolve to Bell's, and all was good. But we've had a few interruptions, espessially over the last couple weeks, where we couldn't send mail at all. After talking to tech, it turns out their mail server is being hammered by whatever virus-of-the-week was hitting windows, and was unusable. I was blown away by their lack of willing to help me: they wouldn't unblock port 25 for me (even to one specific IP), and they has no answers to "Well, what am I supposted to tell everyone in the office? No email for... an unknown amount of time?"
Of course, I could have just set up my server to accept mail on another port, but that would have been a pain for me - local change on every client, instead of one SMTP fix. Anyways, as of Monday, we have a new ISP. (I won't get into how Bell tried to tell us we had a 1-year contract and wanted to charge us 4 extra months for breaking. They couldn't send us any proof, but apparently it was a "verbal" contract. Wow.)
Anyways, I'm a little mixed on blocking port 25. I don't know what a better solution would be. Perhaps not allowing a computer running Windows to directly connect to the internet. Or maybe monitoring the email sent, and setting either a limit on the number per day, or just watching for patterns of mass mailings.
Near the top of this thread I was merely asking if others had experienced this same thing. We had only looked at a few songs and we either had a really bad run of luck or it is a very common occurence with their music store. If 15 other people confirmed our experience I might blow them off for another year or two. Since that doesn't appear to be the case, we'll try it out again, perhaps in a different genre and definitely with different artists.
Slashdot Mirror
You seem to complaining that this might not work because everyone on the planet would need to use it and even then spammers could use their own domains.
Certainly it's true that nearly everyone will need to get on board for this to work. Fortunately, it should be an easy update on both the MTA and DNS ends.
The real advantage here, I think, is that it will make filtering and blacklisting much easier. Instead of trying to filter on 18 zillion weird rules and scads of IP addresses, some of which may have some valid users, you just need to filter on domain names.
For this to work, we will need one or more trustworthy registries of bad domain names. And it should probably be distributed, with a way to continually update it by automatically propagating the list of bad domains to all clients. There should be a way to get a domain into the blacklist very quickly if anyone receives spam from that domain.
Alternatively, a system could be in place to treat all new domains as bad by default. That has obvious problems though -- how would you get your domain trusted? Would it require a VeriSign like identification process? I would oppose that -- I think people should be able to buy domains and freely run email servers on them without paying some central "authority."
My biggest concern with this idea is that I run a domain where I give out POP email addresses to people. I'm still trying to figure out how that will affect me.
For instance, the box on which I get all my mail, to which all my mailing list subscriptions go, and which is associated with my online identity everywhere I have one...is located halfway across the continent from me. It's neither my home Linux box, nor my local ISP. I keep it that way because I never know if I might need to change ISPs for some reasons, and that box is always up and always there. I use fetchmail to pull down my email.
But as a matter of course, I have mutt configured on my desktop box to send in the name of my halfway-across-the-country account, even though it sends through my ISP's SMTP server. (It used to send through my home Linux box's own SMTP server, but then a lot of addresses started bouncing it because it was on a list of cablemodem IPs.) How would I be able to continue doing this under such a system?
I've always thought that ISPs should add a default "smtp" zone for their customers that resolves to their mail server. That way, you can set your progarm up to use "smtp" and no matter where you are, it will resolve properly.
... an unknown amount of time?"
Now, as far as blocking port 25, I've always thought that was a great idea as well, until last week. Our office has used BellZinc's DSL for connectivity. A few months ago, our smtp suddenly stopped working, and after calling tech support, they told me they had accidentally left port 25 on one of their racks unblocked (and I happened to be on that rack) so they had fixed the situation. (Actually, I had to call twice to find that out, the first guy had no clue whatsoever).
So I switched the smtp server in the office to resolve to Bell's, and all was good. But we've had a few interruptions, espessially over the last couple weeks, where we couldn't send mail at all. After talking to tech, it turns out their mail server is being hammered by whatever virus-of-the-week was hitting windows, and was unusable. I was blown away by their lack of willing to help me: they wouldn't unblock port 25 for me (even to one specific IP), and they has no answers to "Well, what am I supposted to tell everyone in the office? No email for
Of course, I could have just set up my server to accept mail on another port, but that would have been a pain for me - local change on every client, instead of one SMTP fix. Anyways, as of Monday, we have a new ISP. (I won't get into how Bell tried to tell us we had a 1-year contract and wanted to charge us 4 extra months for breaking. They couldn't send us any proof, but apparently it was a "verbal" contract. Wow.)
Anyways, I'm a little mixed on blocking port 25. I don't know what a better solution would be. Perhaps not allowing a computer running Windows to directly connect to the internet. Or maybe monitoring the email sent, and setting either a limit on the number per day, or just watching for patterns of mass mailings.
Near the top of this thread I was merely asking if others had experienced this same thing. We had only looked at a few songs and we either had a really bad run of luck or it is a very common occurence with their music store. If 15 other people confirmed our experience I might blow them off for another year or two. Since that doesn't appear to be the case, we'll try it out again, perhaps in a different genre and definitely with different artists.