I think laws can be helpful, provided they are not, well, clueless. As for CAN-SPAM, the best part is outlawing the use of deceptive headers. Now pill pushers and mortgage brokers (who are almost always located in the U.S.) can be prosecuted if they forge headers. If they don't forge headers, then ISPs can blacklist their source much more effectively.
The more common blacklists (at least the ones I use) are Spamhaus , Sorbs, and NJABL. I don't think those are going down anytime soon, with the work they have done to distribute their hosts.
I completely agree that ISPs (and any business that has computers connected to the Internet) should block egress port 25 traffic. I have rallied this point for quite some time, and it has proven to be quite unpopular:
The arguments against sum up to "let's fix the spam problem, but not if it means I can't use my consumer cable modem as if I were a business" and the equaly irresponsible "but I want to run my own mail server-- how dare you try to take away my toy!" To be fair, there are legitimate reasons that a person might need to run their own mail server, but they are quite few and far between-- certainly less in number than spammers!
Sorry to whine, but why would my post be modded a troll? I was completely serious. See my history of posts and you will see that I frequently post about spam and various solutions, including several about SPF:Sender.
Story also posted on C-Net (no account required, yada yada).
What hapened to Yahoo's (as yet unveiled) scheme-to-end-all-schemes for authenticating mail? IMHO, I think that SPF:Sender will make great strides towards combatting spam, combined with new laws that make spoofing illegal. And AOL is backing it, so I think there is a good chance for success, as they are both one of the largest sources of e-mail as well as one of the most commonly spoofed domains.
My guess is $50 per megabyte means the somewhat more complicated "$50 per megabit per second average bandwidth measured at the 95th percentile"
This is a standard method of pricing bandwidth these days. Access is measured in 5 to 10 minute samples of time throught the month, and then ordered by total transfer per sample. This amounts to roughly 8,000 5 minute samples. The 95% mark is 400, so the 400th highest usage sample is used to gauge your "bandwidth". That could be 1Mb/s for a T1 (max on a T1 is 1.54Mb/s), to much higher on a T3, DS3, etc. So "burstiness" is a major factor, and it is not really possible to say what a specific amount of data transfer will cost.
Better option: block all Comcast IP addresses except their mail servers.
Even better option: deploy SPF::Sender and you won't need to deal with Comcast changing the IP address of their outgoing mail servers (I know-- not quite a working option today, but it will be).
Have your mailhost take a look at SMTP+SSL+AUTH for initial mail submission. That's how my mail server is set up (I am the admin), and we provide mail services to many customers. None have any problem, regardless of their ISP, WISP, hotel, etc. they might be using for access.
Actualy, most of the recent viruses/worms/pick-your-term have their own, built in SMTP engine. This allows the infected workstation to look up the MX records of the recipient (the next potential victim, that is), and connect directly to thier incoming SMTP server.
The responsible thing for ISPs and businesses connected to the internet is to block egress port 25 traffic. There are a number of ways to still use external SMTP servers, such as SMTP+AUTH+SSL, which idealy is configured to use a port other than 25 (465 and 587 are the most common with such a configuration).
Kudos to Optus for blocking egress port 25 traffic. They can be assured that their customers will not be part of the problem for anyone else! Other ISPs, and any business that provides internet access to any internal workstations-- please take note, and block egress port 25 traffic. Otherwise, you are part of the problem.
I could not agree more (I'd mod you up, but you're already at 5). I also attribute it to admins trying to prove how cool they were (more is better, when it comes to output). But most of these admins probably don't no how to configure the settings to supress the message, so I think your explanation makes more sense.
Sorry, but I'm not too sure of the terms myself. As I understand it, a point-to-point T1 consists of two parts-- the local loop (copper pair terminating at the ISP), and then the data charge (whatever the ISP is going to charge for hoppingg on their backbone). The local phone company will charge for the distance of the connection, the ISP will charge for the data.
Frame relay is a little different. The end of the T1 terminates into the phone company's 'cloud', gets mixed in with oll their other data, yet routed to the ISP eventualy (gross oversimplification). MPLS has a number of advantages over frame relay (see link in my earlier post), but is still not distance sensitive. I suspect that BTN (as well as other providers) can create a MPLS loop over any distance, even from CmdrTaco's remote location to the co-lo for Slashdot. So that would eliminate the distance part of the feasibility study.
I am doing exactly that-- I have a cage with a T1 from the cage to my house. I am also supplying access for a local community WISP, so my costs are covered. I ran into some problems because my location is outside the LATA of the co-lo facility. So even though it is only 10 miles away, I would have to pay a very high local loop cost.
Then I got in touch with some folks at BTN, they got me set up with a MPLS connection. It is somewhat similar to a frame relay connection, in that it is not distance sensitive. My advantage is that BTN has a connection at my co-lo, so everything fit nicely into place.
So see if you can get a frame relay or MPLS T1, with a little research there might be a very cost effective solution. YMMV
Maybe I don't know SPF, but I think there is a critical flaw in their implementation. As I understand it, the 'ptr' mechanism allows (ie labels a message as 'acceptable') a message to come through if the PTR record of the IP address for the sending server matches.
If a spammer has her own class C, or at least something that she can publish her own PTR (or 'reverse lookup' records), she can label her own IP address as 'chinanet.mx.aol.com' or even just 'mx.aol.com'. My incoming SMTP server checks the SPF record for AOL, sees that if the IP address resolves to 'mx.aol.com', and accepts it as coming from AOL. I think the 'a' mechanism is much more spoof-proof.
Please correct me if I am wrong, I may be reading the docs incorrectly.
I'm pretty sure it is older than this as well, I was thinking 1984 or so. But, the RFC was all I could find in a quick search, and I think it makes the point!
1. A method for assigning URL's and e-mail addresses to members of a group comprising the steps of:
assigning each member of said group a URL of the form "name.subdomain.domain"; and
assigning each member of said group an e-mail address of the form "name@subdomain.domain;"
wherein the "name" portion of said URL and said e-mail address is the same and unique for each particular one of said members such that an only difference between said URL and said e-mail address for said member is that in said URL the "@" symbol of the e-mail address is replaced with a "." and wherein said "subdomain" portion of said URL and said e-mail address is the same for all members of said group.
This is the precice format for e-mail addresses in DNS zone file, for the SOA record. See RFC 1034, section 3.3. Date of prior art, 1987.
I have been searching all over, but I cannot find any specifics about how this will be implemented. Could I see an m4 snippet to add to my Sendmail configuration? Could I see an example zone file for my DNS server? Anything, please!
Seriously, are there any links at all to some technical specifics?
This has already been discussed, with two current proposals, RMX and SPF::Sender. The latter looks a lot closer to implementation, with AOL already testing it.
Use SASL+AUTH (+SSL too, but not absolutely necessary).
User IDs with SASL do not have to be the same as an e-mail address, so make them a little more obscure. I use IDs like 'rt_alec'.
YOU make up the passwords, use things like '3d8%wW!34'. No password cracker will guess that. Most users will have their mail client remember the user name/password anyway.
Have initial mail submission on a port other than port 25! This takes care of hotels, ISPs, etc. that block egress port 25
Now you have a rock solid mail system, accessible from any ISP, and extremely difficult to crack into.
We thought about this one. In my experience, IRC is used as a conduit for zombies, viruses, and the like far more than it is used for people chatting. To be specific, I have noted blocked IRC traffic (ingress and egress) in the firewall logs, yet never once had anyone complain that something was not working. This includes several office environments where I have set up the network, including the firewall. I figured the one or two people who need (or even want) it would shout about it and I would let their machine through. But to date, not one such request.
In the situations where I could examine the internal computers that were attempting to connect via IRC ports, I always found them loaded with spyware and/or viruses. Always. A round with an up to date anti-virus tool, as well as Ad-aware or Spybot, and the IRC traffic ceased.
I have nothing against IRC, but my experience has been that not many people use it. If you come down to Lake Anne, let me know and we'll see what we can do. I opened up the VPN ports and protocols after someone requested it, and it made sense.
Use ipfilter, which has a nat module built in. Works like a champ. I've used this setup on FreeBSD and OpenBSD, even on older hardware (200Mhz Pentium Pro) it can handle 3 zones on a (almost) saturated T1.
This is exactly the approach I took when setting up a similar hotspot. I published some of the technical details here. We use mostly Netgear wireless routers, and a FreeBSD box for the core firewall/gateway.
One of the most efficient deployments, in terms of billing, is as a loss leader. By this I mean where you deploy it for free, with the hopes that the increase in traffic (foot traffic) will more than make up for the cost. This model works for coffee shops, hotels, some restaurants, and perhaps even housing or office complexes.
Example (and shameless plug):
I have set up just such a network in the plaza where my office is located, Lake Anne (in Reston, Virginia). We have a T1, and have wired up four of the restaurants with access points. We are using 802.11b, no encryption, no signups, just come out and connect. The restaurants pay us for the access and to maintain the equipment, which goes a long way to defraying to cost of the T1. The restaurants have "WiFi Zone" stickers in the windows, and we are trying to get some local press coverage.
Most days, I see at least a few people with their laptops in the various restuarants (one of them is, in fact, a coffee shop). I can hardly wait for the spring, since the access extends to the benches surrounding the dock (the plaza is at one end of a small lake).
For the curious, we use a combination of Netgear wireless routers, Apple Airport Extremes, and a FreeBSD gateway/firewall (with a Sangoma T1 adapter in it-- no router necessary). Our F.A.Q. (a work in progress) covers the most common questions people have to hook up, and the restaurants all have a printout of it just in case . The best part is, it works!
First, we have all been trained (correctly) to NEVER opt-out, since it confirms our e-mail address is valid. How do we know if a particular spam is from someone who will obey the law?
Second, it can often be difficult to opt-out anyway, purely from a technical standpoint. I receive e-mail addressed "To:" several addresses, including "info@", "webmaster@", etc. While I am savvy enough to reconfigure my e-mail client to send an e-mail that appears to be "From:" any of my addresses, it is a pain. Most people will not know how to do this, and many people (AOL, etc.) do not use an e-mail client that is capable of altering the sending address.
If the law mandated that opt-out must be implemented by use of a web link (e.g. "This message was addressed to john.doe@mail.us, click the link below and you will be removed immediately"), that would be a little better. None of this detracts from the overriding issue, and that is by requiring opt-out instead of opt-in (either double opt-in or a verification link) this law essentialy legalizes, indeed encourages, spam.
The conclusion is based on a flawed statistical model. If you look closely at the link, you will note that only IP addresses that were listed on the various RBLs were counted as "dynamic". What about dynamic IPs that have not (yet) bmade it onto one of those lists? The lists are by no means a comprehensive compilation of each and every range of dynamic IPs that exist. My guess would be that a significant number of the remaining IPs are, indeed, dynamic;y assigned.
Slashdot Mirror
I think laws can be helpful, provided they are not, well, clueless. As for CAN-SPAM, the best part is outlawing the use of deceptive headers. Now pill pushers and mortgage brokers (who are almost always located in the U.S.) can be prosecuted if they forge headers. If they don't forge headers, then ISPs can blacklist their source much more effectively.
The more common blacklists (at least the ones I use) are Spamhaus , Sorbs, and NJABL. I don't think those are going down anytime soon, with the work they have done to distribute their hosts.
I completely agree that ISPs (and any business that has computers connected to the Internet) should block egress port 25 traffic. I have rallied this point for quite some time, and it has proven to be quite unpopular:
- ISP's need to block egress port 25!!
- Good news!
- What about port 25?
The arguments against sum up to "let's fix the spam problem, but not if it means I can't use my consumer cable modem as if I were a business" and the equaly irresponsible "but I want to run my own mail server-- how dare you try to take away my toy!" To be fair, there are legitimate reasons that a person might need to run their own mail server, but they are quite few and far between-- certainly less in number than spammers!Sorry to whine, but why would my post be modded a troll? I was completely serious. See my history of posts and you will see that I frequently post about spam and various solutions, including several about SPF:Sender.
Story also posted on C-Net (no account required, yada yada).
What hapened to Yahoo's (as yet unveiled) scheme-to-end-all-schemes for authenticating mail? IMHO, I think that SPF:Sender will make great strides towards combatting spam, combined with new laws that make spoofing illegal. And AOL is backing it, so I think there is a good chance for success, as they are both one of the largest sources of e-mail as well as one of the most commonly spoofed domains.
My guess is $50 per megabyte means the somewhat more complicated "$50 per megabit per second average bandwidth measured at the 95th percentile"
This is a standard method of pricing bandwidth these days. Access is measured in 5 to 10 minute samples of time throught the month, and then ordered by total transfer per sample. This amounts to roughly 8,000 5 minute samples. The 95% mark is 400, so the 400th highest usage sample is used to gauge your "bandwidth". That could be 1Mb/s for a T1 (max on a T1 is 1.54Mb/s), to much higher on a T3, DS3, etc. So "burstiness" is a major factor, and it is not really possible to say what a specific amount of data transfer will cost.
Configure your mail server to accept initial mail submission on port 587, and you can use it from anywhere. Even better, add TLS for encryption.
Better option: block all Comcast IP addresses except their mail servers.
Even better option: deploy SPF::Sender and you won't need to deal with Comcast changing the IP address of their outgoing mail servers (I know-- not quite a working option today, but it will be).
Have your mailhost take a look at SMTP+SSL+AUTH for initial mail submission. That's how my mail server is set up (I am the admin), and we provide mail services to many customers. None have any problem, regardless of their ISP, WISP, hotel, etc. they might be using for access.
Actualy, most of the recent viruses/worms/pick-your-term have their own, built in SMTP engine. This allows the infected workstation to look up the MX records of the recipient (the next potential victim, that is), and connect directly to thier incoming SMTP server.
The responsible thing for ISPs and businesses connected to the internet is to block egress port 25 traffic. There are a number of ways to still use external SMTP servers, such as SMTP+AUTH+SSL, which idealy is configured to use a port other than 25 (465 and 587 are the most common with such a configuration).
Kudos to Optus for blocking egress port 25 traffic. They can be assured that their customers will not be part of the problem for anyone else! Other ISPs, and any business that provides internet access to any internal workstations-- please take note, and block egress port 25 traffic. Otherwise, you are part of the problem.
Is this the same story as posted a few days ago?
I could not agree more (I'd mod you up, but you're already at 5). I also attribute it to admins trying to prove how cool they were (more is better, when it comes to output). But most of these admins probably don't no how to configure the settings to supress the message, so I think your explanation makes more sense.
Sorry, but I'm not too sure of the terms myself. As I understand it, a point-to-point T1 consists of two parts-- the local loop (copper pair terminating at the ISP), and then the data charge (whatever the ISP is going to charge for hoppingg on their backbone). The local phone company will charge for the distance of the connection, the ISP will charge for the data.
Frame relay is a little different. The end of the T1 terminates into the phone company's 'cloud', gets mixed in with oll their other data, yet routed to the ISP eventualy (gross oversimplification). MPLS has a number of advantages over frame relay (see link in my earlier post), but is still not distance sensitive. I suspect that BTN (as well as other providers) can create a MPLS loop over any distance, even from CmdrTaco's remote location to the co-lo for Slashdot. So that would eliminate the distance part of the feasibility study.
I am doing exactly that-- I have a cage with a T1 from the cage to my house. I am also supplying access for a local community WISP, so my costs are covered. I ran into some problems because my location is outside the LATA of the co-lo facility. So even though it is only 10 miles away, I would have to pay a very high local loop cost.
Then I got in touch with some folks at BTN, they got me set up with a MPLS connection. It is somewhat similar to a frame relay connection, in that it is not distance sensitive. My advantage is that BTN has a connection at my co-lo, so everything fit nicely into place.
So see if you can get a frame relay or MPLS T1, with a little research there might be a very cost effective solution. YMMV
Maybe I don't know SPF, but I think there is a critical flaw in their implementation. As I understand it, the 'ptr' mechanism allows (ie labels a message as 'acceptable') a message to come through if the PTR record of the IP address for the sending server matches.
If a spammer has her own class C, or at least something that she can publish her own PTR (or 'reverse lookup' records), she can label her own IP address as 'chinanet.mx.aol.com' or even just 'mx.aol.com'. My incoming SMTP server checks the SPF record for AOL, sees that if the IP address resolves to 'mx.aol.com', and accepts it as coming from AOL. I think the 'a' mechanism is much more spoof-proof.
Please correct me if I am wrong, I may be reading the docs incorrectly.
I'm pretty sure it is older than this as well, I was thinking 1984 or so. But, the RFC was all I could find in a quick search, and I think it makes the point!
From the patent documentation:
This is the precice format for e-mail addresses in DNS zone file, for the SOA record. See RFC 1034, section 3.3. Date of prior art, 1987.
I have been searching all over, but I cannot find any specifics about how this will be implemented. Could I see an m4 snippet to add to my Sendmail configuration? Could I see an example zone file for my DNS server? Anything, please!
Seriously, are there any links at all to some technical specifics?
This has already been discussed, with two current proposals, RMX and SPF::Sender. The latter looks a lot closer to implementation, with AOL already testing it.
Here is what you need to do:
Now you have a rock solid mail system, accessible from any ISP, and extremely difficult to crack into.
We thought about this one. In my experience, IRC is used as a conduit for zombies, viruses, and the like far more than it is used for people chatting. To be specific, I have noted blocked IRC traffic (ingress and egress) in the firewall logs, yet never once had anyone complain that something was not working. This includes several office environments where I have set up the network, including the firewall. I figured the one or two people who need (or even want) it would shout about it and I would let their machine through. But to date, not one such request.
In the situations where I could examine the internal computers that were attempting to connect via IRC ports, I always found them loaded with spyware and/or viruses. Always. A round with an up to date anti-virus tool, as well as Ad-aware or Spybot, and the IRC traffic ceased.
I have nothing against IRC, but my experience has been that not many people use it. If you come down to Lake Anne, let me know and we'll see what we can do. I opened up the VPN ports and protocols after someone requested it, and it made sense.
Use ipfilter, which has a nat module built in. Works like a champ. I've used this setup on FreeBSD and OpenBSD, even on older hardware (200Mhz Pentium Pro) it can handle 3 zones on a (almost) saturated T1.
This is exactly the approach I took when setting up a similar hotspot. I published some of the technical details here. We use mostly Netgear wireless routers, and a FreeBSD box for the core firewall/gateway.
One of the most efficient deployments, in terms of billing, is as a loss leader. By this I mean where you deploy it for free, with the hopes that the increase in traffic (foot traffic) will more than make up for the cost. This model works for coffee shops, hotels, some restaurants, and perhaps even housing or office complexes.
Example (and shameless plug):
I have set up just such a network in the plaza where my office is located, Lake Anne (in Reston, Virginia). We have a T1, and have wired up four of the restaurants with access points. We are using 802.11b, no encryption, no signups, just come out and connect. The restaurants pay us for the access and to maintain the equipment, which goes a long way to defraying to cost of the T1. The restaurants have "WiFi Zone" stickers in the windows, and we are trying to get some local press coverage.
Most days, I see at least a few people with their laptops in the various restuarants (one of them is, in fact, a coffee shop). I can hardly wait for the spring, since the access extends to the benches surrounding the dock (the plaza is at one end of a small lake).
For the curious, we use a combination of Netgear wireless routers, Apple Airport Extremes, and a FreeBSD gateway/firewall (with a Sangoma T1 adapter in it-- no router necessary). Our F.A.Q. (a work in progress) covers the most common questions people have to hook up, and the restaurants all have a printout of it just in case . The best part is, it works!
The problem with "opt-out" is two-fold:
If the law mandated that opt-out must be implemented by use of a web link (e.g. "This message was addressed to john.doe@mail.us, click the link below and you will be removed immediately"), that would be a little better. None of this detracts from the overriding issue, and that is by requiring opt-out instead of opt-in (either double opt-in or a verification link) this law essentialy legalizes, indeed encourages, spam.
The conclusion is based on a flawed statistical model. If you look closely at the link, you will note that only IP addresses that were listed on the various RBLs were counted as "dynamic". What about dynamic IPs that have not (yet) bmade it onto one of those lists? The lists are by no means a comprehensive compilation of each and every range of dynamic IPs that exist. My guess would be that a significant number of the remaining IPs are, indeed, dynamic;y assigned.