Basically, it's a very poor re-implementation of SPF, with all of SPF's disadvantages and none of its advantages.
Under the MSFT scheme, the TXT records are verbose, likely requiring several records where SPF will probably fit in one. They have a hare-brained scheme to parse Received: headers to get around certain problems. Their scheme is absurdly complex.
And neither SPF nor MSFT's scheme do anything about spam coming from <>, cracked Windoze machines, or "valid" throwaway accounts. They also make forwarding more difficult than it should be.
TUTOS has its warts, no question. We hired someone to customize it for some of our special business processes (generating evaluation agreements, for example) and it works fairly well. It's good enough for us, and the price is great.
I'm just wondering how easy it is for the administrative staff to use SQL Ledger.
We're a small company, so I do the accounting. However, I don't think SQL Ledger is hard to use; I'm training my wife to use it, and she's really a computer novice.
We're self-funded and haven't been audited, so I have no idea how an auditor or lender would react, but I don't really care -- my accountant has no problems with what we use. In fact, he hasn't ever asked what software we use.
We do not use a secondary MX host, because we can live with the delay. We also have techniques for preventing MX-host-skipping for customers who do use secondary MX machines.
As I wrote earlier, we've been doing this for quite a while. You can see our statistics here.
Greylisting will not catch anwhere near 97% of spam. Our statistics show it catches anywhere from 15% to 30%. Nevertheless, the fact that it uses hardly any resources on your computer makes it worth doing.
You can also mitigate the delay problem by having a secondary MX record. Rather than waiting an hour, a legitimate SMTP host will retry the message on the seondary MX and it will get through almost immediately.
Putting a backdoor into code is completely unethical.
If I ever contracted someone to write software for me, I would put a clause in the contract stating that the developer agrees to pay me $1,000,000 if it is discovered that he put a backdoor in the code. It's utterly wrong.
> Why should I upgrade hardware if the valid load on > the machine does not change?
The good news is you probably won't have to. Very few production mail servers are CPU-bound, so adding content scanning actually evens out the resource usage. You go from a horribly-overengineered CPU to one which matches the network and disk capacity.
The bad news is that nothing in life is free, and if you want to content scan absolutely huge quantities of e-mail, you need fast hardware. It's up to you to decide if hardware or wading through spam is cheaper.
Microsoft had an agreement with Industry Canada's Computers for Schools program. It was also secret. I got a copy under Canada's Access to Information law, though no-one was very cooperative.
There was nothing particularly disturbing about the agreement, although there was one funny part:
5. VIRUSES --- you acknowledge that the SOFTWARE may contain viruses and you accept any risks associated with using the SOFTWARE without recourse to Microsoft, Microsoft Canada Co. or the Government of Canada.
My product CanIt can tempfail mail also. However, it can be dangerous, because you tend to get a big increase in SMTP connection attempts. If you can tempfail early (as Theo's scheme does), it's not so bad.
Our stats, however, show that most spam does not come from open relays any more. With the advent of cheap broadband, I'd say a lot of spam comes directly from DSL or cable-modem machines. Some comes from Web servers with broken formail scripts, and some from legitimate non-open relays that are abused by subscribers. Only the minority comes from open relays nowadays.
I sell a commercial piece of software called CanIt, and I supply the source code to purchasers for the following reasons:
A lot of the system is written in Perl and PHP, and it's impractical to obscure the source code.
It gives me a competitive advantage over people who don't supply source code, because CanIt is something people might want to customize.
Of course, the license agreement limits what you can do with the source (basically, do what you want except distribute it, but don't expect support if you change it.) I would sue the pants off someone who violated the license agreement.
I know that Spam Assassin is a bit resource hungry, and isn't practical for large scale operations
Au contraire, if you're clever about it, SpamAssassin works great in large-scale operations. In conjunction with MIMEDefang, people use SpamAssassin to scan a lot of mail -- over 1 million messages/day in two sites I know of.
krlynch writes: They BOTH make the mistake that continues to negatively impact the arguments of Open Source/ Free Software advocates: childish personal attacks.
I tried not to make personal attacks, but the AdTI paper is so blatant that I don't see any harm in showing exactly what I think of it now and then. There are well-written non-personal defenses of free software (like Villaneuva's); it's just not my style to hold back.
Dark Nexus writes: About the only thing that I find arguable about that small section of the ADTI report is the part about Open Source not working for a business model. First thing that David Skoll indicates is that he doesn't care about business models.
Perhaps I should have reworded that. What I mean is, I don't care about the GPL in relation to existing, proprietary software business models. And it's not my job to explain to people how to make money from GPL'd software. GPL'd software is out there, and we'd all better learn to adapt.
The gnat writes: This is the code the Internet is built on- it's a good thing it's under such a liberal license, and a good thing that Microsoft chose to use it.
I have no problem with BSD license advocates. But I choose GPL, the AdTI paper attacked the GPL, and it was the GPL I was defending. If people want to use BSD licenses or proprietary licenses, that's fine. All I'm saying is they'd better learn to live with GPL'd software, because it will be out there. It's changing the game.
Anarchos writes: It's interesting to note that Roaring Penguin's own CanIt license [roaringpenguin.com] is considerably more restrictve than the GPL, despite the article's "Tough. Adapt or die" refrain for proprietary licensing.
Yes, the secret's out: I sell non-free software. I'm experimenting with business models, and one that I'm trying is to sell non-free software value-added on top of free software. I gradually migrate the non-free portions to the free parts. That's what paid for the RADIUS support I added to pppd in the Linux PPP CVS. That's what paid for MIMEDefang (the free software which underpins CanIt.)
I'm not a total free software zealot. I believe there always will be proprietary software, and it will always have a niche. But it has to coexist with free software, and CanIt is my experiment with coexistence.
Don't think so, probably not at best. Sure, it's POSSIBLE, depending on your relationship with your client, but many of the large clients are going to have you sign NDAs and/or non-competes
I wrote some software under contract for a very, *very* large multinational (I think we're talking Fortune 50 here, not Fortune 500) and it said right in the contract that I owned the code, and would license it under the GPL.
Each situation is unique; it depends on the nature of the client and the software.
Yes, MIMEDefang is sendmail-specific, because it uses milter. However, most of it is in Perl and there's a bit of C glue to hook into milter. With a bit of effort, you could probably port it to another MTA.
Slashdot Mirror
Basically, it's a very poor re-implementation of SPF, with all of SPF's disadvantages and none of its advantages.
Under the MSFT scheme, the TXT records are verbose, likely requiring several records where SPF will probably fit in one. They have a hare-brained scheme to parse Received: headers to get around certain problems. Their scheme is absurdly complex.
And neither SPF nor MSFT's scheme do anything about spam coming from <>, cracked Windoze machines, or "valid" throwaway accounts. They also make forwarding more difficult than it should be.
If this ever becomes more than vapor, all your spam will suddenly start coming from <>.
SMTP has built-in limitations that are very hard to get around.
TUTOS has its warts, no question. We hired someone to customize it for some of our special business processes (generating evaluation agreements, for example) and it works fairly well. It's good enough for us, and the price is great.
I'm just wondering how easy it is for the administrative staff to use SQL Ledger.
We're a small company, so I do the accounting. However, I don't think SQL Ledger is hard to use; I'm training my wife to use it, and she's really a computer novice.
We're self-funded and haven't been audited, so I have no idea how an auditor or lender would react, but I don't really care -- my accountant has no problems with what we use. In fact, he hasn't ever asked what software we use.
TUTOS has a calendar module that works well enough for us.
For CRM, we use TUTOS.
For accounting, it's SQL-Ledger. Both the CRM and accounting apps are backed by PostgreSQL.
For office suites, OpenOffice.
Web browsing is Mozilla; e-mail is whatever our employees prefer (Mozilla, Kmail, Evolution, Pine, Mutt, whatever...)
We are completely MSFT-free and intend to stay that way.
Check out Drupal. Although primarily developed for MySQL, it does work with PostgreSQL.
XFCE 3 is great, and I use it. With XFCE 4, they got rid of the icons when you close windows in favour of the wretched taskbar. :-(
Unless/until they re-introduce the option of iconifying windows the old way, I stick with XFCE 3.
I've been married for almost 12 years, and we have three kids. I'm as creative as ever; just don't have time to produce concrete results. :-(
We do not use a secondary MX host, because we can live with the delay. We also have techniques for preventing MX-host-skipping for customers who do use secondary MX machines.
As I wrote earlier, we've been doing this for quite a while. You can see our statistics here.
Greylisting will not catch anwhere near 97% of spam. Our statistics show it catches anywhere from 15% to 30%. Nevertheless, the fact that it uses hardly any resources on your computer makes it worth doing.
You can also mitigate the delay problem by having a secondary MX record. Rather than waiting an hour, a legitimate SMTP host will retry the message on the seondary MX and it will get through almost immediately.
Our CanIt anti-spam product has been doing it for quite a while.
I posted an article about it in January.Putting a backdoor into code is completely unethical.
If I ever contracted someone to write software for me, I would put a clause in the contract stating that the developer agrees to pay me $1,000,000 if it is discovered that he put a backdoor in the code. It's utterly wrong.
Go on, then, have a crack at the PostgreSQL server on my box (see my URL.)
> Why should I upgrade hardware if the valid load on > the machine does not change?
The good news is you probably won't have to. Very few production mail servers are CPU-bound, so adding content scanning actually evens out the resource usage. You go from a horribly-overengineered CPU to one which matches the network and disk capacity.
The bad news is that nothing in life is free, and if you want to content scan absolutely huge quantities of e-mail, you need fast hardware. It's up to you to decide if hardware or wading through spam is cheaper.
You can have high-performance message scanning; you just have to be clever about how you implement it.
For example, someone was using MIMEDefang to scan almost 2 million messages/day on a single machine.
To scale up, just throw in another equally-preferred MX record.
Microsoft had an agreement with Industry Canada's
Computers for Schools program. It was also secret. I got a copy under Canada's Access to Information law, though no-one was very cooperative.
There was nothing particularly disturbing about the agreement, although there was one funny part:
5. VIRUSES --- you acknowledge that the SOFTWARE may contain viruses and you accept any risks associated with using the SOFTWARE without recourse to Microsoft, Microsoft Canada Co. or the Government of Canada.
I think M$ is just plain paranoid.
My product CanIt can tempfail mail also. However, it can be dangerous, because you tend to get a big increase in SMTP connection attempts. If you can tempfail early (as Theo's scheme does), it's not so bad.
Our stats, however, show that most spam does not come from open relays any more. With the advent of cheap broadband, I'd say a lot of spam comes directly from DSL or cable-modem machines. Some comes from Web servers with broken formail scripts, and some from legitimate non-open relays that are abused by subscribers. Only the minority comes from open relays nowadays.
Of course, the license agreement limits what you can do with the source (basically, do what you want except distribute it, but don't expect support if you change it.) I would sue the pants off someone who violated the license agreement.
I know that Spam Assassin is a bit resource hungry, and isn't practical for large scale operations
Au contraire, if you're clever about it, SpamAssassin works great in large-scale operations. In conjunction with MIMEDefang, people use SpamAssassin to scan a lot of mail -- over 1 million messages/day in two sites I know of.
Aha... Now I understand the meaning of that phrase...
I tried not to make personal attacks, but the AdTI paper is so blatant that I don't see any harm in showing exactly what I think of it now and then. There are well-written non-personal defenses of free software (like Villaneuva's); it's just not my style to hold back.
Dark Nexus writes: About the only thing that I find arguable about that small section of the ADTI report is the part about Open Source not working for a business model. First thing that David Skoll indicates is that he doesn't care about business models.
Perhaps I should have reworded that. What I mean is, I don't care about the GPL in relation to existing, proprietary software business models. And it's not my job to explain to people how to make money from GPL'd software. GPL'd software is out there, and we'd all better learn to adapt.
The gnat writes: This is the code the Internet is built on- it's a good thing it's under such a liberal license, and a good thing that Microsoft chose to use it.
I have no problem with BSD license advocates. But I choose GPL, the AdTI paper attacked the GPL, and it was the GPL I was defending. If people want to use BSD licenses or proprietary licenses, that's fine. All I'm saying is they'd better learn to live with GPL'd software, because it will be out there. It's changing the game.
Anarchos writes: It's interesting to note that Roaring Penguin's own CanIt license [roaringpenguin.com] is considerably more restrictve than the GPL, despite the article's "Tough. Adapt or die" refrain for proprietary licensing.
Yes, the secret's out: I sell non-free software. I'm experimenting with business models, and one that I'm trying is to sell non-free software value-added on top of free software. I gradually migrate the non-free portions to the free parts. That's what paid for the RADIUS support I added to pppd in the Linux PPP CVS. That's what paid for MIMEDefang (the free software which underpins CanIt.)
I'm not a total free software zealot. I believe there always will be proprietary software, and it will always have a niche. But it has to coexist with free software, and CanIt is my experiment with coexistence.
--
David F. Skoll
I just had to write a response.
I wrote some software under contract for a very, *very* large multinational (I think we're talking Fortune 50 here, not Fortune 500) and it said right in the contract that I owned the code, and would license it under the GPL.
Each situation is unique; it depends on the nature of the client and the software.
Yes, MIMEDefang is sendmail-specific, because it uses milter. However, most of it is in Perl and there's a bit of C glue to hook into milter. With a bit of effort, you could probably port it to another MTA.
Regards,
David.