... but it'll sound like one: I recently converted from a rather involved anti-spam defense utilizing SpamAssassin with Razor, Pyzor, and several RBL checks. I spent a fair amount of time selecting RBLs that worked the best and tweaking SA test scores whenever I got false positive/negative messages. I even had all sorts of validity checks turned on in the MTA to block out badly formed messages and the like.
I replaced all those defenses with: DSPAM. And I'm seeing better results out of the box than I ever did with a multi-layered SA-based solution, even after a lot of time tweaking.
A quick anecdote: When I converted, I opened up a bunch of previously blocked spamtrap addresses, just to get some good training material for the filter. I've long since passed my initial training threshhold but haven't even bothered to block the spamtraps again because I never see the spam. At the risk of sounding like I'm bragging, I literally don't have a spam problem anymore, and DSPAM is entirely responsible for that.
Now, I'm not necessarily advocating that you give up all your custom defenses and switch to DSPAM. (I've turned off all my other filters, but I haven't removed them completely.) There's always a chance that an ingenious spammer will find a weakness in DSPAM setups, but I can testify to the fact that DSPAM is "scary good" as of right now. Training the filter is a simple matter of dropping misclassified messages (and there aren't many) into an IMAP folder.
If what you have is working for you, stick with it. But if you're looking for a low-maintenance, high accuracy filter, you should definitely give DSPAM a shot.
Re:I'm one of the guys that gets to fill in...
on
SBC CWA Strike Imminent
·
· Score: 3, Insightful
I largely agree with your statements -- except the last one...
Now I'm off to frickin' Detroit to run phone lines for 12 hours a day, 7 days a week.. thanks Union.
Don't "thank" the union. The union did not mandate 12x7 shifts. SBC did that. SBC could have hired a larger number of contractors or offered volunteer overtime or any number of other solutions to keep operations moving in the event of a strike. They chose instead to mandate 12x7 shifts for every non-bargained employee and to recall those employees from their vacations. CWA had no hand in that decision.
Not only that, but the initial communications indicated that SBC would not be offering overtime pay for salaried managers who were required to work hourly union positions. Nice of SBC to pass the cost of the strike along to the folks who are still at work keeping the company running.
That said, I've no sympathies with either side of this conflict. My sympathies lie with those hit by the collateral damage: mainly the non-bargained employees and managers like yourself who are on mandatory 12x7s, but also the customers who are for damn sure not going to get a normal level of service. They are the losers here, not SBC, and not CWA.
But just as many perceptions are colored by the opinions of what appears to be a large number of uninformed individuals, my perceptions -- and the perceptions of several of us in the media -- are colored in much the same way, and probably by some of the same people. So I thought it might be useful to share how my perception of Linux has been created over the last several months by a minority of those who back Linux. In reading this column, many of you might see similarities to how you formed impressions about Apple, Linux and even Microsoft.
I regret that this person is jaded by open-source extremists. I particularly regret it because, to my knowledge, nothing violent has ever happened in support of the open-source or Linux movements, despite the strong emotions some feel. Terror is utterly contrary to freedom and freedom is really what Linux and open source software is about.
However, the quoted paragraph belies the truth of the situation. When September 11 happened, the Islamic churches in this country (and likely elsewhere) effectively and unofficially began a grassroots PR campaign to distance themselves from the extremists who committed the atrocities of the day. They did this because the American perception was that Muslims were a violent, terrorist-friendly people, which just isn't true or accurate.
Realistically, though, only those in this country who are ignorant, foolish, or just plain bigoted still have this perception. The truth is, ignorance does not lie in being part of a movement where some people believe a little too much. Ignorance lies in allowing your perception of the movement to be shaped by those extremists rather than considering the movement as a whole.
Most people who vote in this country understand this concept very well -- why is it so hard to grasp with regard to software?
I don't want to stray too far from topic, but the reviewer mentions Gentoo's Portage system having horrible breakage? This concerns me a bit as I'm a recent inductee into all that is Gentoo and have thusfar been quite happy with Portage as well as the system in general. Are there really serious issues that one should know about before trusting Gentoo and Portage, or is this mostly FUD?
Not really interested in "sucks/rules" responses, but if anyone has some concrete examples or information, I'd definitely be interested.
This appeared on the NANOG list about an hour ago. Seems they are at least addressing some of the problems that this has caused with mail services. Please don't go flaming this person's e-mail address. Consensus on list is that he's a "good guy making the best of a bad situation".
Unfortunately, despite the fact that they say they aren't collecting e-mail addresses, for the community at large the issue is we now have to trust them to continue to honor that promise. Considering their actions in implementing SiteFinder in a most irresponsible fashion, I'm not sure that trust would be well placed.
Date: Sat, 20 Sep 2003 14:01:39 -0400 From: Matt Larson To: nanog@nanog.org Subject: VeriSign SMTP reject server updated
Folks,
One piece of feedback we received multiple times after the addition of the wildcard A record to the.com/.net zones concerned snubby, our SMTP mail rejection server. This server was designed to be the most modest of SMTP implementations and supported only the most common sequence of SMTP commands.
In response to this feedback, we have deployed an alternate SMTP implementation using Postfix that should address many of the concerns we've heard. Like snubby, this server rejects any mail sent to it (by returning 550 in response to any number of RCPT TO commands).
We would like to state for the record that the only purpose of this server is to reject mail immediately to avoid its remaining in MTA queues throughout the Internet. We are specifically not retaining, nor do we have any intention to retain, any email addresses from these SMTP transactions. In fact, to achieve sufficient performance, all logging has been disabled.
We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. One alternate option we are considering is rejecting the SMTP transaction by returning a 554 response code as described in Section 3.1 of RFC 2821. Our concern is if this response effectively causes most SMTP servers to bounce the message, which is the desired reaction. We are researching common SMTP servers' handling of this response code; at least one popular server appears to requeue mail after receiving 554. Another option is remaining with the more standard SMTP sequence (returning 250 in response to HELO/EHLO), but then returning 550 in response to MAIL FROM as well as RCPT TO.
I would welcome feedback on these options sent to me privately or the list; I will summarize the former.
After seeing this submission published, I noticed several folks who mentioned the very good point that by posting this, I may very well be drawing the attention to the contest that would make it a "success". I essentially responded to this via a newly posted article on my site, but thought it was worth posting here as well, so that hopefully my reasoning will make more sense. (Article Follows.)
As Slashdot was kind enough to post, the San Francisco Chronicle has an article about a hacker or group of hackers that are calling for massive website defacements as part of a warped (and highly illegal) contest, to occur entirely on July 6th. I considered not submitting the story to avoid drawing attention to it. After all, this could end up being the next "Y2K" where everyone sits around waiting for the doomsday that doesn't occur. To those who don't think I should've posted the story, I apologize -- but suggest you read the rest of this article to understand my reasoning.
It's entirely possible that very few, if any, websites will be defacde that day. It's even possible that more may happen now that warnings are on high-traffic sites such as Slashdot; call it a self-fulfilling prophecy.
Slashdot's reader pool contains a great many folks who own web servers or are site administrators, such as myself. Certainly there are a few black hats in the crowd, but for the most part, the audience is people in the trenches of the technology industry. I can't think of a better place to reach the people who's pagers would actually be ringing or vibrating on Sunday if/when defacements occur.
Also, the story had already been picked up by mass media, such as the S.F. Chronicle. Since it was already being published to the general population, I feel that more good than harm would come from highlighting the issue in the technical community.
My apologies to the others who rely on web/e-mail services from gotclue.net, as I've probably made this server a more likely target by drawing attention to the issue. I'll be reviewing patches and packages over the next few days and making some fresh backups, just in case. If I can have my cell phone ring on Sunday but, by doing so, keep a thousand other cell-phones from ringing for the same reason, so be it.
Does it surprise anyone that the CEO of the company bringing legal action is a former Microsoft exec? It's clear that Mailblocks is more interested in making money than in fighting SPAM. I can't say I blame them for that, but it's a shame that they're attempting to supress useful technology in order to eliminate competition. In fact, the MSNBC article alludes to several other similar lawsuits brought about by the same firm. Survival via settlement, just like the article said.
Limiting SPAM using challenge/response would be far more effective on the whole as a draft RFC that any MTA (or add-on) could implement, rather than a closed system that even individual developers can't duplicate for fear of a lawsuit.
Opinion alert: The problem of SPAM is far more important than the problem of keeping one startup in business. Those on the anti-SPAM side of the "war" argue about how to define SPAM, how to combat it when it occurs, and sue each other over who thought of it first. (I personally discovered long ago that if you let a group of technical folks argue the technical merits of a solution until the end of time, they will.) Thus, the spamming minority continues to win, because they don't have anything to fight about -- they just keep pounding out those weight loss and penis enlargement ads. Sue the damn spammers, not other spam-fighters.
Challenge/response isn't exactly new or exciting, even as applied to e-mail. How about PGP? It already provides the ability to authoritatively assert the identity of a sender and recipient. The only missing link is what to do with a rejected or non-PGP signed message. Couldn't generating a keypair be made as simple as the ch/resp method Mailblocks uses? The implications of trust levels as implemented in PGP are profoundly interesting too. Generating an initial whitelist becomes far more useful once you can say, 'I trust all my senders, and all my mother's senders, and all of Uncle Joe's senders...' IANAP*, but it seems like an idea that would work!
One potential problem with this is that KEY records were originally intended for DNSsec usage and some controversy has arisen with regard to using KEY records for other purposes, such as OE. This pretty much sums it up, however, and it seems as though they've gone on using KEY for this purpose.
(I realize the articles listed are 8-9 months old, but clearly the issue is still relevant.)
I'm unfortunately not running OE, as my DNS provider (UltraDNS) did not provide the capability to add KEY records to a zone at the time I went through the installation process. Not sure if they do so now; perhaps time to check! I'd be interested in discovering which DNS providers do or do not provide the ability to insert KEY records into zones.
No, overclocking your Honda will not make it run like a Trans Am.
And you can't just add a(nother) fan to keep it cool either.
(I envision a little 4-cylinder rolling down the road at 35mph, at around 11,000RPM in first gear... hood open for better ventilation.)
Re:have to take out 8 of the servers, but 4 are he
on
The Root of All E-Mail
·
· Score: 1
Old map showing the approximate locations of each of the root servers.
Although there are 6 listed in the VA/MD area, they're all in different places, some in different towns.
Of course, some of the locations may have changed by now, but I don't think they'd be silly enough to put 4 in the same building. Rather defeats the purpose!
I have the (mis)fortune to work with a very large-scale WAN project, around 8,000 nodes, connected via low-cap circuits.
At any given time, between 0.75% - 1.5% of those nodes are out of service due to what I would describe as routine circumstances (power outages, circuit flaps, etc.).
That percentage is for a network that is monitored 24x7. Although some Internet firms invest in this sort of continuous monitoring, a great deal do not. Consequently, I think it's safe to assume that the percentage of nodes unreachable due to "routine" circumstances could be substantially higher than my baseline above.
If the "5%" figure is accurate, it's quite possible that it's simply the results of completely normal occurrences. I don't really follow the logic of the article in assuming that spammers and hackers are the most likely cause.
On another note: During casual surfing, one is likely to notice about one out of every ten to twenty random sites is either down or misconfigured. One wonders if the research conducted might have been casual surfing coupled with a pencil tally.:-)
Just auction IP addresses through a central exchange, all IP addresses, including the sacrosanct class As.
To some degree, this is already occurring. ARIN charges for block allocations. In turn, Tier 1 service/access providers routinely toss their clients smaller chunks of IP's, with the option to purchase larger chunks. In this manner, IP's are already controlled by a central repository, and you can purchase as much as you want. ARIN simply adds the conditional that you must justify the necessity of those allocations. This to me seems a much better solution than the same (or a similar) entity deciding that it doesn't care WHY you want the IP addresses, so long as the check doesn't bounce.
Some regulations are required: don't allow monopolies or cartels; declare IPs fungible to allow central administrators to reallocate or consolidate blocks for routing purposes.
This raises the usual array of annoying questions:
- Who creates the regulations and under what authority?
- Who decides what defines an IP monopoly or cartel? If I'm there first and with VC funding I purchase 50% of the available address space and other companies then chew up the remaining space over time, am I now a monopoly if I choose to resell that IP address space at severely inflated prices? Or is that just capitalism at work?
Slashdot Mirror
... but it'll sound like one: I recently converted from a rather involved anti-spam defense utilizing SpamAssassin with Razor, Pyzor, and several RBL checks. I spent a fair amount of time selecting RBLs that worked the best and tweaking SA test scores whenever I got false positive/negative messages. I even had all sorts of validity checks turned on in the MTA to block out badly formed messages and the like.
I replaced all those defenses with: DSPAM. And I'm seeing better results out of the box than I ever did with a multi-layered SA-based solution, even after a lot of time tweaking.
A quick anecdote: When I converted, I opened up a bunch of previously blocked spamtrap addresses, just to get some good training material for the filter. I've long since passed my initial training threshhold but haven't even bothered to block the spamtraps again because I never see the spam. At the risk of sounding like I'm bragging, I literally don't have a spam problem anymore, and DSPAM is entirely responsible for that.
Now, I'm not necessarily advocating that you give up all your custom defenses and switch to DSPAM. (I've turned off all my other filters, but I haven't removed them completely.) There's always a chance that an ingenious spammer will find a weakness in DSPAM setups, but I can testify to the fact that DSPAM is "scary good" as of right now. Training the filter is a simple matter of dropping misclassified messages (and there aren't many) into an IMAP folder.
If what you have is working for you, stick with it. But if you're looking for a low-maintenance, high accuracy filter, you should definitely give DSPAM a shot.
Don't "thank" the union. The union did not mandate 12x7 shifts. SBC did that. SBC could have hired a larger number of contractors or offered volunteer overtime or any number of other solutions to keep operations moving in the event of a strike. They chose instead to mandate 12x7 shifts for every non-bargained employee and to recall those employees from their vacations. CWA had no hand in that decision.
Not only that, but the initial communications indicated that SBC would not be offering overtime pay for salaried managers who were required to work hourly union positions. Nice of SBC to pass the cost of the strike along to the folks who are still at work keeping the company running.
That said, I've no sympathies with either side of this conflict. My sympathies lie with those hit by the collateral damage: mainly the non-bargained employees and managers like yourself who are on mandatory 12x7s, but also the customers who are for damn sure not going to get a normal level of service. They are the losers here, not SBC, and not CWA.
I don't want to stray too far from topic, but the reviewer mentions Gentoo's Portage system having horrible breakage? This concerns me a bit as I'm a recent inductee into all that is Gentoo and have thusfar been quite happy with Portage as well as the system in general. Are there really serious issues that one should know about before trusting Gentoo and Portage, or is this mostly FUD?
Not really interested in "sucks/rules" responses, but if anyone has some concrete examples or information, I'd definitely be interested.
Unfortunately, despite the fact that they say they aren't collecting e-mail addresses, for the community at large the issue is we now have to trust them to continue to honor that promise. Considering their actions in implementing SiteFinder in a most irresponsible fashion, I'm not sure that trust would be well placed.
Are we having fun yet?
After seeing this submission published, I noticed several folks who mentioned the very good point that by posting this, I may very well be drawing the attention to the contest that would make it a "success". I essentially responded to this via a newly posted article on my site, but thought it was worth posting here as well, so that hopefully my reasoning will make more sense. (Article Follows.)
Thanks,
Paul Robinson
gotclue.net
- Does it surprise anyone that the CEO of the company bringing legal action is a former Microsoft exec? It's clear that Mailblocks is more interested in making money than in fighting SPAM. I can't say I blame them for that, but it's a shame that they're attempting to supress useful technology in order to eliminate competition. In fact, the MSNBC article alludes to several other similar lawsuits brought about by the same firm. Survival via settlement, just like the article said.
- Limiting SPAM using challenge/response would be far more effective on the whole as a draft RFC that any MTA (or add-on) could implement, rather than a closed system that even individual developers can't duplicate for fear of a lawsuit.
- Opinion alert: The problem of SPAM is far more important than the problem of keeping one startup in business. Those on the anti-SPAM side of the "war" argue about how to define SPAM, how to combat it when it occurs, and sue each other over who thought of it first. (I personally discovered long ago that if you let a group of technical folks argue the technical merits of a solution until the end of time, they will.) Thus, the spamming minority continues to win, because they don't have anything to fight about -- they just keep pounding out those weight loss and penis enlargement ads. Sue the damn spammers, not other spam-fighters.
- Challenge/response isn't exactly new or exciting, even as applied to e-mail. How about PGP? It already provides the ability to authoritatively assert the identity of a sender and recipient. The only missing link is what to do with a rejected or non-PGP signed message. Couldn't generating a keypair be made as simple as the ch/resp method Mailblocks uses? The implications of trust levels as implemented in PGP are profoundly interesting too. Generating an initial whitelist becomes far more useful once you can say, 'I trust all my senders, and all my mother's senders, and all of Uncle Joe's senders...' IANAP*, but it seems like an idea that would work!
* - I Am Not A Programmer(I realize the articles listed are 8-9 months old, but clearly the issue is still relevant.)
I'm unfortunately not running OE, as my DNS provider (UltraDNS) did not provide the capability to add KEY records to a zone at the time I went through the installation process. Not sure if they do so now; perhaps time to check! I'd be interested in discovering which DNS providers do or do not provide the ability to insert KEY records into zones.
No, overclocking your Honda will not make it run like a Trans Am.
And you can't just add a(nother) fan to keep it cool either.
(I envision a little 4-cylinder rolling down the road at 35mph, at around 11,000RPM in first gear... hood open for better ventilation.)
Old map showing the approximate locations of each of the root servers.
Although there are 6 listed in the VA/MD area, they're all in different places, some in different towns.
Of course, some of the locations may have changed by now, but I don't think they'd be silly enough to put 4 in the same building. Rather defeats the purpose!
I have the (mis)fortune to work with a very large-scale WAN project, around 8,000 nodes, connected via low-cap circuits.
:-)
At any given time, between 0.75% - 1.5% of those nodes are out of service due to what I would describe as routine circumstances (power outages, circuit flaps, etc.).
That percentage is for a network that is monitored 24x7. Although some Internet firms invest in this sort of continuous monitoring, a great deal do not. Consequently, I think it's safe to assume that the percentage of nodes unreachable due to "routine" circumstances could be substantially higher than my baseline above.
If the "5%" figure is accurate, it's quite possible that it's simply the results of completely normal occurrences. I don't really follow the logic of the article in assuming that spammers and hackers are the most likely cause.
On another note: During casual surfing, one is likely to notice about one out of every ten to twenty random sites is either down or misconfigured. One wonders if the research conducted might have been casual surfing coupled with a pencil tally.