According to Apache's web site, quite a bit of Apache is actualy developed on FreeBSD servers. As far as the individual developers go, I believe Brian Behlendorf makes a good representative of senior Apache developers.
How about the "overhead" of the various BSDs? FreeBSD, OpenBSD, and NetBSD all have what could be described as "too much overhead" in their development model. Yet all three are considered among the shining stars of FOSS operating systems. Stable, robust, and "you know what you're getting".
Juniper uses FreeBSD (they call it 'JunOS').
Their routers have become quite popular for very high traffic installations, due in no small part to the efficient networking code of the FreeBSD kernel. Also, don't forget that the f-root name server (actualy a distributed network of servers) is exclusively FreeBSD.
I am aware that there are difficulties in implementing this, although I must admit I do not fully understand what they are (I am not a system level programmer). I have several web servers, that host up to 100 web sites each. I insist that my clients use SFTP to maintain their site-- I do not support (or even have installed) FTP. While an unpopular choice a few years ago when I set this up, now that DreamWeaver, BBEdit, and many other WSIWYG editors support SFTP directly this is an easy rule to impose.
One of the nice features of most FTP servers is chroot-ing a login to a restricted directory. That way, one client cannot (by mistake or on purpose) wander "up" the directory tree. "What is the/etc directory?" is not a question I want to answer! As I mentioned in my earlier post, I have achieved some degree of satisfaction by clever directory permissions, that at least prevent innocent mistakes. However, if a seasoned Unix hack logs in (as they might if one is hired by a client to edit their site), they could probably poke around a little. All logins are in a common FreeBSD jail, in which the only server running is sshd. Nobody can see the apache directory, for example, or the main server partitions. Still, I don't even want my clients being able to guess who any other of my clients are, and somehow derive a directory path that at least lets them see other user's files, or anything else for that matter. They never, ever, need shell access. SSH is used only for file transfer, so chroot-ing should not need to replice/bin,/etc,/usr/local/bin,/lib, etc., other than whatever the sftp-server subsystem needs. I know greater minds than mine have looked into this, so I was just wondering if anyone else has studied this problem and has a (more) elegant solution.
One feature I have been waiting for is the ability to chroot my users when they log in, even if just for file transfers. This would ensure that users would not be able to wander the entire directory tree of the server. I have had some success (on FreeBSD) with creating single jail for all client logins, and then applying some clever directory permissions for the higher directories (usualy o-x for directories). There was a commercial version of SSH that had a chroot feature, but I would prefer to stick with openssh. IMHO, this is the one area that FTP outdoes SFTP (but not enough for me to dumb my security down and allow FTP!!).
Microsoft depends on the ubiquity of Windows (and Office, Outlook, et al). When everybody is using Microsoft products, everybody needs Microsoft. Their proprietary formats are a de facto standard (except Massachusetts), so if you want to do business with people who use Windows (et al), you have little choice but to also use windows.
As their piracy initiative starts to pick up steam, this will only enhance the "value" of free (or at least lesser cost) alternatives. I predict a large swell of Linux usage-- on the desktop, in these emerging markets, or other areas where the hight cost of Windows (et al) simply locks people out. With that will come a groudswell of support for open formats.
Consider what you need if you are going to do business with the government of Hamburg. You will need to provide and exchange documents and other material in a format they can read (it won't simply be Word and PowerPoint). Now the same thing will happen in these emerging markets, creating more of an interest in these alternative formats, and thus alternative applications (e.g. OpenOffice).
More choices are good for everybody. Use the application of your choice, on the platform of your choice, and produce documents and other material in a format anyone else can read. Right now, I have any number of such choices to produce graphics for a web page (jpg, png, even gif). The formats for Flash and Acrobat have been opened up, and happily they are becoming more standard. But the U.S. Government still requires all RFP submissions in Word.
More choices, however, is bad for Microsoft. They don't want open formats and lots of choices, they want (and need) everone using and exchanging MS Word documents. They want (and need) everybody using Outlook and Internet Explorer, and of course, they want (and ultimately need) everybody using Windows.
How many ISPs have SMTP+AUTH (or some other type of authentication, like POP-before-SMTP)? If they are not running a totaly open relay, usualy they just restrict access to their own IP addresses, and to their domain (e.g. '@comcast.net').
I cannot emphasise enough, do NOT use DotRegistrar!!
I was trying to send a spam complaint to one of the domains registered through them, and the e-mail kept getting bounced. According to ICAAN rules, the contact information must be correct. So I used the only method DotRegistrar has to contact them, their tech support form. For my e-mail address, I used an address with 'dotregistrar' in it (myname.dotregistrar@mydomain.com), I use this technique often to track the dissemination of my email address (e.g. myname.amazon@mydomain.com, myname.ebay@mydomain.com, myname.zdnet@mydomain.com, etc.).
Not only did I get no response from them, but within a week, I started getting a flood of spam to that exact e-mail address! The bastards sold the address that was used exclusively for a complaint (it has never been used for anything else, not even to register a domain) to spammers! Their (no) privacy policy states that they will release collected information "to third parties or to the public at large, for any purpose," but it does not indicate this includes complaints. I guess they got me, eh?
I disagree. I was a big proponent of PGP back in the old days (mid-90's). Back then, it was more cumbersome than complicated. Regardless of the effort to set it up, it still required too much effort on my part to encrypt or sign or decrypt each and every message. My circle of co-workers, contractors, and friends gave up on it after a short while.
Recently, I have begun using Enigmail with GPG. It integrates quite nicely with Thunderbird, and I assume it would with Mozilla as well. We use it companywide, with Macs and PCs (ie OSX and Windows), and we convinced a contractor that uses Linux to use it as well.
While the initial configuration did require some degree of effort, it was not too tough. Encrypting, decrypting, signing, and verifying is almost automatic now, requiring very little effort per message. My PGP (I mean GPG) password is queued for 15 minutes, so from time to time I have to re-enter it. All my messages are signed, and if the recipients are in my keychain, it is encrypted as well.
I think if it is set up by a Slashdot-type person (and let's face it-- that's what most of us are paid to do), an "average" user should have no problem with it.
I don't think this had anything whatsoever to do with any of the root servers. This has to do with Akamai's DNS servers, and the companies (domains) that are using them.
You do realise that your plan to block egress SMTP completely undermines anyone who'd want to usefully use SMTP+TLS+AUTH?
If e-mail providers allow initial mail submission on a port other than 25 (the "standard" is 465 or 587, but I have seen 2525 and even 26), then roaming users are accomodated.
Please see point #4, as well as the appendix, to the parent of your post. That everyone can be both client and sever is not necessarily "great". Spam zombies are clients acting as servers, correct?
Blocking egress port 25 traffic has nothing whatsoever to do with SPF. Mail providers need to have initial mail submission (different than mail transport) on a port other than 25 (465 or 587 are the most "standard" replacements, but I have also seen 2525 or even 26). If egress port 25 is blocked, but you can access your SMTP server via an alternate port (or even a VPN), then the roaming problem is a non-issue.
ISPs (and any other business that gives a workstation a "real" IP address) need to block egress port 25. Comcast is going to be doing this soon, others should soon follow suit. This plugs the zombies.
IP addresses that continue to send spam will be blacklisted. With the zombies effectively out of the loop this will become easier (albeit never quite perfect).
SPF and other authentication schemes need to be adopted to prevent "spoofing" and so called "Joe jobs".
E-mail providers (including small companies) need to deploy mature e-mail systems for their users. In 1995 it was fine to accept e-mail from anyone on port 25, with no authentication and no encryption. In 2004, remote clients need to have an SSL connection available (both for sending mail and accessing inboxes), and must require authentication before accepting initial mail submission (SMTP+TLS+AUTH). Not only is this more secure, but it also addresses the issues always raised by blocking egress port 25 and deploying SPF.
Once these techniques and practices be come commonplace, it won't matter if spam originates from lawless areas of the world. Existing laws against fraud (and other illegal business practices) will cover the extreme efforts that will be necessary to continue spamming.
Appendix:
SMTP+TLS+AUTH is not that tough, no whining. All modern mail clients support it, on all platforms. There is a little bit of work to do on the server end, but that's what you pay your ISP (or IT department) for:
You should not be using the hotel's SMTP server, or any other SMTP server except the one for your domain. Your SMTP server should accept initial mail submission (which is different than mail relay) on something other than port 25! 587 or 465 (SMTPS) work quite well (I strongly suggest SMTP+AUTH+TLS/SSL).
Now your mail originates at the same server all the time, and SPF will work just fine since that IP address is in the SPF record. Your roaming issues are taken care of as well, no more reconfiguring your client software as you move from access point to access point.
I would think the longer this drags on, the worse it is for SCO. They only have finite money (and some people already want that money back), eventualy they will be unable to finance continued litigation.
Linux, and OSS in general, does not seem to be suffering a significant (or even noticable) negative backlash from all of this, if anything it has been free publicity.
If you don't think it should be a crime, then get on the phone with your representatives in congress and state legislatures and try to have the law changed. Right now, copyright infringement is illegal. IMHO, blatant illegal activites, such as bringing a camcorder into a movie theatre (or providing a server with thousands of copyrighted MP3s), should be prosecuted to the full extent of the law. Just because you don't like a law does not mean you can break it.
My real point is that we should pick more appropriate battles. I am concerned with efforts by the MPAA to:
"tax" blank CDR and DVDR material,
impose DRM on all electronic devices,
make it illegal to skip commercials
And other draconian measures to allow them to keep their fiefdom. If a movie studio releases a movie, and wants people to pay to see it, they have every right to inforce that (it is their "property", according to the law). If we don't like that, fine-- skip the movie. But sneaking a camcorder into a theater... ?
This reminds me of the quotes I see from college students worried about the RIAA suits. "If I see a song I want, I grab it. I'm not going to pay for it." That is stealing. There is no way around the fact that it is blatant stealing, and setting up a server to facilitate such activity is illegal. It's not about a couple of friends swapping songs, MP3s, CDs, DVDs, books, etc. It's about mass stealing. Let's fight the battles that make sense.
I agree. This is not the battle to fight, it is a clear cut case of breaking the law. If this is where the MPAA wants to direct their resources, so be it.
There is a well founded fear many Windows admins have about MS patches. They tend to break things. Patch Win2k, and MS-SQL does not work upon reboot. Or that third party medical charting software suddenly does not work.
Windows is very complex (many would say "too complex"), and certainly suffers from the "integration" of its parts. Therefore, unintentional side effects of patches are envitable. With Unix(ish) systems, the descrete parts can be patched, well, descretely. You can patch Sendmail, or MySQL, or OpenSSL all by itself (although sometimes you must recompile applications that depend on shared libraries, such as OpenSSL).
Any rejects are, indeed, handled with a correct SMTP error code being returned. If there have been false positives, I have not been told about them (my clients would let me know). Thus, the accurate statement "as far as I know".
Slashdot Mirror
Why is this tagged "Linux"? Shouldn't it be tagged "IT"?
Pretty graphics, lots of "ooooo" factor. I find that they tell me nothing. This is a trend in the "network security" field:
Tufte would be ashamed.
According to Apache's web site, quite a bit of Apache is actualy developed on FreeBSD servers. As far as the individual developers go, I believe Brian Behlendorf makes a good representative of senior Apache developers.
How about the "overhead" of the various BSDs? FreeBSD, OpenBSD, and NetBSD all have what could be described as "too much overhead" in their development model. Yet all three are considered among the shining stars of FOSS operating systems. Stable, robust, and "you know what you're getting".
BTW- Apache is developed primarily on FreeBSD.
Don't the people (businesses) who pay for a T1, DSL, fiber-to-the-curb, etc. already pay? Why should SBC be paid twice... is that what he is implying?
Juniper uses FreeBSD (they call it 'JunOS'). Their routers have become quite popular for very high traffic installations, due in no small part to the efficient networking code of the FreeBSD kernel. Also, don't forget that the f-root name server (actualy a distributed network of servers) is exclusively FreeBSD.
The form is in PDF format, I would have thought they would have posted it in Word or Excel. Maybe deep down, they think PDF is more ubiquitous.
I am aware that there are difficulties in implementing this, although I must admit I do not fully understand what they are (I am not a system level programmer). I have several web servers, that host up to 100 web sites each. I insist that my clients use SFTP to maintain their site-- I do not support (or even have installed) FTP. While an unpopular choice a few years ago when I set this up, now that DreamWeaver, BBEdit, and many other WSIWYG editors support SFTP directly this is an easy rule to impose.
One of the nice features of most FTP servers is chroot-ing a login to a restricted directory. That way, one client cannot (by mistake or on purpose) wander "up" the directory tree. "What is the /etc directory?" is not a question I want to answer! As I mentioned in my earlier post, I have achieved some degree of satisfaction by clever directory permissions, that at least prevent innocent mistakes. However, if a seasoned Unix hack logs in (as they might if one is hired by a client to edit their site), they could probably poke around a little. All logins are in a common FreeBSD jail, in which the only server running is sshd. Nobody can see the apache directory, for example, or the main server partitions. Still, I don't even want my clients being able to guess who any other of my clients are, and somehow derive a directory path that at least lets them see other user's files, or anything else for that matter. They never, ever, need shell access. SSH is used only for file transfer, so chroot-ing should not need to replice /bin, /etc, /usr/local/bin, /lib, etc., other than whatever the sftp-server subsystem needs. I know greater minds than mine have looked into this, so I was just wondering if anyone else has studied this problem and has a (more) elegant solution.
One feature I have been waiting for is the ability to chroot my users when they log in, even if just for file transfers. This would ensure that users would not be able to wander the entire directory tree of the server. I have had some success (on FreeBSD) with creating single jail for all client logins, and then applying some clever directory permissions for the higher directories (usualy o-x for directories). There was a commercial version of SSH that had a chroot feature, but I would prefer to stick with openssh. IMHO, this is the one area that FTP outdoes SFTP (but not enough for me to dumb my security down and allow FTP!!).
Any other ideas?
Microsoft depends on the ubiquity of Windows (and Office, Outlook, et al). When everybody is using Microsoft products, everybody needs Microsoft. Their proprietary formats are a de facto standard (except Massachusetts), so if you want to do business with people who use Windows (et al), you have little choice but to also use windows.
As their piracy initiative starts to pick up steam, this will only enhance the "value" of free (or at least lesser cost) alternatives. I predict a large swell of Linux usage-- on the desktop, in these emerging markets, or other areas where the hight cost of Windows (et al) simply locks people out. With that will come a groudswell of support for open formats.
Consider what you need if you are going to do business with the government of Hamburg. You will need to provide and exchange documents and other material in a format they can read (it won't simply be Word and PowerPoint). Now the same thing will happen in these emerging markets, creating more of an interest in these alternative formats, and thus alternative applications (e.g. OpenOffice).
More choices are good for everybody. Use the application of your choice, on the platform of your choice, and produce documents and other material in a format anyone else can read. Right now, I have any number of such choices to produce graphics for a web page (jpg, png, even gif). The formats for Flash and Acrobat have been opened up, and happily they are becoming more standard. But the U.S. Government still requires all RFP submissions in Word.
More choices, however, is bad for Microsoft. They don't want open formats and lots of choices, they want (and need) everone using and exchanging MS Word documents. They want (and need) everybody using Outlook and Internet Explorer, and of course, they want (and ultimately need) everybody using Windows.
How many ISPs have SMTP+AUTH (or some other type of authentication, like POP-before-SMTP)? If they are not running a totaly open relay, usualy they just restrict access to their own IP addresses, and to their domain (e.g. '@comcast.net').
I cannot emphasise enough, do NOT use DotRegistrar!!
I was trying to send a spam complaint to one of the domains registered through them, and the e-mail kept getting bounced. According to ICAAN rules, the contact information must be correct. So I used the only method DotRegistrar has to contact them, their tech support form. For my e-mail address, I used an address with 'dotregistrar' in it (myname.dotregistrar@mydomain.com), I use this technique often to track the dissemination of my email address (e.g. myname.amazon@mydomain.com, myname.ebay@mydomain.com, myname.zdnet@mydomain.com, etc.).
Not only did I get no response from them, but within a week, I started getting a flood of spam to that exact e-mail address! The bastards sold the address that was used exclusively for a complaint (it has never been used for anything else, not even to register a domain) to spammers! Their (no) privacy policy states that they will release collected information "to third parties or to the public at large, for any purpose," but it does not indicate this includes complaints. I guess they got me, eh?
I disagree. I was a big proponent of PGP back in the old days (mid-90's). Back then, it was more cumbersome than complicated. Regardless of the effort to set it up, it still required too much effort on my part to encrypt or sign or decrypt each and every message. My circle of co-workers, contractors, and friends gave up on it after a short while.
Recently, I have begun using Enigmail with GPG. It integrates quite nicely with Thunderbird, and I assume it would with Mozilla as well. We use it companywide, with Macs and PCs (ie OSX and Windows), and we convinced a contractor that uses Linux to use it as well.
While the initial configuration did require some degree of effort, it was not too tough. Encrypting, decrypting, signing, and verifying is almost automatic now, requiring very little effort per message. My PGP (I mean GPG) password is queued for 15 minutes, so from time to time I have to re-enter it. All my messages are signed, and if the recipients are in my keychain, it is encrypted as well.
I think if it is set up by a Slashdot-type person (and let's face it-- that's what most of us are paid to do), an "average" user should have no problem with it.
I don't think this had anything whatsoever to do with any of the root servers. This has to do with Akamai's DNS servers, and the companies (domains) that are using them.
Please see point #4, as well as the appendix, to the parent of your post. That everyone can be both client and sever is not necessarily "great". Spam zombies are clients acting as servers, correct?
Blocking egress port 25 traffic has nothing whatsoever to do with SPF. Mail providers need to have initial mail submission (different than mail transport) on a port other than 25 (465 or 587 are the most "standard" replacements, but I have also seen 2525 or even 26). If egress port 25 is blocked, but you can access your SMTP server via an alternate port (or even a VPN), then the roaming problem is a non-issue.
- ISPs (and any other business that gives a workstation a "real" IP address) need to block egress port 25. Comcast is going to be doing this soon, others should soon follow suit. This plugs the zombies.
- IP addresses that continue to send spam will be blacklisted. With the zombies effectively out of the loop this will become easier (albeit never quite perfect).
- SPF and other authentication schemes need to be adopted to prevent "spoofing" and so called "Joe jobs".
- E-mail providers (including small companies) need to deploy mature e-mail systems for their users. In 1995 it was fine to accept e-mail from anyone on port 25, with no authentication and no encryption. In 2004, remote clients need to have an SSL connection available (both for sending mail and accessing inboxes), and must require authentication before accepting initial mail submission (SMTP+TLS+AUTH). Not only is this more secure, but it also addresses the issues always raised by blocking egress port 25 and deploying SPF.
Once these techniques and practices be come commonplace, it won't matter if spam originates from lawless areas of the world. Existing laws against fraud (and other illegal business practices) will cover the extreme efforts that will be necessary to continue spamming.Appendix:
SMTP+TLS+AUTH is not that tough, no whining. All modern mail clients support it, on all platforms. There is a little bit of work to do on the server end, but that's what you pay your ISP (or IT department) for:
You should not be using the hotel's SMTP server, or any other SMTP server except the one for your domain. Your SMTP server should accept initial mail submission (which is different than mail relay) on something other than port 25! 587 or 465 (SMTPS) work quite well (I strongly suggest SMTP+AUTH+TLS/SSL).
Now your mail originates at the same server all the time, and SPF will work just fine since that IP address is in the SPF record. Your roaming issues are taken care of as well, no more reconfiguring your client software as you move from access point to access point.
I would think the longer this drags on, the worse it is for SCO. They only have finite money (and some people already want that money back), eventualy they will be unable to finance continued litigation.
Linux, and OSS in general, does not seem to be suffering a significant (or even noticable) negative backlash from all of this, if anything it has been free publicity.
If you don't think it should be a crime, then get on the phone with your representatives in congress and state legislatures and try to have the law changed. Right now, copyright infringement is illegal. IMHO, blatant illegal activites, such as bringing a camcorder into a movie theatre (or providing a server with thousands of copyrighted MP3s), should be prosecuted to the full extent of the law. Just because you don't like a law does not mean you can break it.
My real point is that we should pick more appropriate battles. I am concerned with efforts by the MPAA to:
- "tax" blank CDR and DVDR material,
- impose DRM on all electronic devices,
- make it illegal to skip commercials
And other draconian measures to allow them to keep their fiefdom. If a movie studio releases a movie, and wants people to pay to see it, they have every right to inforce that (it is their "property", according to the law). If we don't like that, fine-- skip the movie. But sneaking a camcorder into a theater... ?This reminds me of the quotes I see from college students worried about the RIAA suits. "If I see a song I want, I grab it. I'm not going to pay for it." That is stealing. There is no way around the fact that it is blatant stealing, and setting up a server to facilitate such activity is illegal. It's not about a couple of friends swapping songs, MP3s, CDs, DVDs, books, etc. It's about mass stealing. Let's fight the battles that make sense.
I agree. This is not the battle to fight, it is a clear cut case of breaking the law. If this is where the MPAA wants to direct their resources, so be it.
There is a well founded fear many Windows admins have about MS patches. They tend to break things. Patch Win2k, and MS-SQL does not work upon reboot. Or that third party medical charting software suddenly does not work.
Windows is very complex (many would say "too complex"), and certainly suffers from the "integration" of its parts. Therefore, unintentional side effects of patches are envitable. With Unix(ish) systems, the descrete parts can be patched, well, descretely. You can patch Sendmail, or MySQL, or OpenSSL all by itself (although sometimes you must recompile applications that depend on shared libraries, such as OpenSSL).
Any rejects are, indeed, handled with a correct SMTP error code being returned. If there have been false positives, I have not been told about them (my clients would let me know). Thus, the accurate statement "as far as I know".