Saturday, September 29, 2007
Ohio LinuxFest 2007 coverage
We've posted up the initial report from o3 of Ohio LinuxFest 2007. Check it out at here.
Tuesday, September 25, 2007
o3 magazine :: issue 9 is out
Issue 9 of o3 magazine is now available for download. This issue looks at Open Source Publishing using Open Office, Scribus and the GIMP. If you ever wanted to know how we put o3 magazine together, this is it.
Saturday, September 22, 2007
o3 magazine on the iPhone
The Apple iPhone is one slick device, its effectively replaced four devices I typically cart around with me. Before the iPhone, I carried around my Motorola Razr, Dell Axim PDA, and pager. The iPhone effectively replaces each of these devices, as well as the iPod. Although I still keep the pager, don't trust AT&T SMS to be 100% reliable all the time!
Obviously one of the first things I did was try to read o3 magazine with the iPhone. It works flawlessly. Hats off to the Scribus team, because the PDF works very well, its easily readable holding the iPhone in either position. Even the o3 magazine site works fine on the iPhone. Very cool stuff.
So if you're away or simply want to read o3 while your traveling -- Get an iPhone!
Obviously one of the first things I did was try to read o3 magazine with the iPhone. It works flawlessly. Hats off to the Scribus team, because the PDF works very well, its easily readable holding the iPhone in either position. Even the o3 magazine site works fine on the iPhone. Very cool stuff.
So if you're away or simply want to read o3 while your traveling -- Get an iPhone!
Friday, September 21, 2007
Ohio LinuxFest 2007
Ohio LinuxFest 2007 is just a week away. If you plan on going or think you might go, you should register asap, seating is limited. This year, o3 magazine will be reporting live from the event. You can get our perspective of the event live from our o3 @ linuxfest blog.
Wednesday, September 19, 2007
o3 news goes LIVE!
o3 has expanded its offerings to include a daily Enterprise / Open Source news site. The new site is up on www.o3news.com. What o3 news is aiming to do is provide fast access to interesting Enterprise / Open source news. It is edited by professionals, for professionals. There is no mob mentality, so the technical, but less sensational articles don't get lost by the mob effect you see on Slashdot's Firehose or Digg.com. If its relevant and interesting, it gets posted. Right now we're getting news from a variety of sources, and as always its produced using just Open Source solutions.
Sunday, September 16, 2007
Appliance partitioning without a hypervisor
The hypervisor is not an operating system replacement, its an operating system feature. Even VMware's ESX platform runs from within an operating system model. The Linux 2.6 kvm feature is a prime example of how a hypervisor can be easily and seamless integrated into the operating system. The kvm module gives the user the choice of running a hypervisor, to switch the feature on and off. This is in contrast to being told you have to run a hypervisor. I don't know about you, but I like having that choice, as not all applications need to run virtualized.
There are some folks that will completely disagree with me, try to tell you that the hypervisor is the death of the operating system. They should try Linux kvm, and then talk to the blade server people. Blade servers, remember when they first came out? The 1U rack mount server was dead, eh wait. Eh no, the 1U rack mount server is still here, yet all those vendors bounced up and down trying to convince you otherwise. Those marketing folks probably need to tone down the sugar content of their coffee! :)
A lot of customers looking at virtual appliances, really just want application partitioning. They want to be able to run DNS, SMTP, IMAPD and perhaps HTTP/HTTPS on a pair of really powerful servers, without worrying that SMTP might take the rest down. The reason for this might be that their needs are small enough, or they want high availability but don't want to invest in racks of servers. Perhaps they are using co-location and have limited space on their budget. It is this scenario where the marketing people are saying virtualization == security, when in reality thats not the case. What they really mean is that virtualization is providing application partitioning, and providing the advantage of securing those applications from each other. If you setup SMTP badly on a virtual appliance, its still going to be at risk.
So in reality, these customers don't actually want virtualization. What they want is a multi-role appliance with each appliance module partitioned from each other. This is what AppOS does, and has done since 2003. They want multi-role appliance partitioning but they think they want virtualization. You can get this with virtualization, but you can also get it with AppOS without the virtualization overhead. AppOS however, gives you the choice of running the solution in either mode. In the end, customers like flexibility and choice!
There are some folks that will completely disagree with me, try to tell you that the hypervisor is the death of the operating system. They should try Linux kvm, and then talk to the blade server people. Blade servers, remember when they first came out? The 1U rack mount server was dead, eh wait. Eh no, the 1U rack mount server is still here, yet all those vendors bounced up and down trying to convince you otherwise. Those marketing folks probably need to tone down the sugar content of their coffee! :)
A lot of customers looking at virtual appliances, really just want application partitioning. They want to be able to run DNS, SMTP, IMAPD and perhaps HTTP/HTTPS on a pair of really powerful servers, without worrying that SMTP might take the rest down. The reason for this might be that their needs are small enough, or they want high availability but don't want to invest in racks of servers. Perhaps they are using co-location and have limited space on their budget. It is this scenario where the marketing people are saying virtualization == security, when in reality thats not the case. What they really mean is that virtualization is providing application partitioning, and providing the advantage of securing those applications from each other. If you setup SMTP badly on a virtual appliance, its still going to be at risk.
So in reality, these customers don't actually want virtualization. What they want is a multi-role appliance with each appliance module partitioned from each other. This is what AppOS does, and has done since 2003. They want multi-role appliance partitioning but they think they want virtualization. You can get this with virtualization, but you can also get it with AppOS without the virtualization overhead. AppOS however, gives you the choice of running the solution in either mode. In the end, customers like flexibility and choice!
Saturday, September 15, 2007
JeOS - its marketing not a new concept
The concept of JeOS is nothing new. The neat and effective buzz word JeOS (pronounced "juice") was coined by VMware product manager Srinivas Krishnamurti on his blog back on July 9th. The concept though is not new (sorry Billy), and we all know how badly things can go when marketing folks start promising features they've misunderstood.
Practically anyone who has created their own chroot environment, thats quite a few administrators over the years. Has already used the premise behind JeOS. Many enterprise grade devices such as layer 2-7 switches, content routers and hardware appliances have been using JeOS for years. JeOS is nothing new, and its not something that needs a hypervisor. JeOS is simple, its "Just Enough" operating system for what you are trying to do. OpenWRT is another example of a JeOS solution.
What JeOS is not is a packaging architecture. Package management does NOT belong on appliances, end of story. Don't believe me? Well lets think. What is mission critical and powers the Internet? Ah.. routers. Is there a yum update on Cisco IOS? Eh no. When you need to upgrade Cisco IOS, you download a new firmware image, and reload. Seems other vendors have taken this approach, and even the wireless lan products do this! Seeing a pattern? The self-contained image is guaranteed to work. Its tested for that specific hardware (or architecture) and it just works. When something is mission critical you can't afford to wait 5 minutes while it calculates dependencies, and then might have to roll back everything that it took 5 minutes to update in the first place because of an error. I'm not talking a flash / disk error either, what happens if you update a package and it corrupted at the source? Its got to roll everything back. This is why package management has no place on an enterprise grade appliance, its why trying to label JeOS as a packaging architecture is really silly.
So what is my take on next-generation server operating systems? Well the operating system should be an appliance delivery and management platform. It needs to provide the interface to the hardware (through drivers), access the management network (whether thats a separate physical network or just an SSL/IPSec VPN doesn't matter), exchange data with the centralized management system and then load the software appliances. Whether those are partitioned under a single kernel, or run as virtual software appliances is completely up to the user. In other words, virtualization should be a choice, not something force fed by some product marketing people.
The hypervisor is a feature, not a requirement. This is something very important to remember, because there really are applications out there where you need the full resources of the system available to you. There are bottlenecks which may not be acceptable, such as software switches and added latency of virtual interfaces. As well as the potential for packet leakage between virtual appliances. There are all potential problems.
Should JeOS be sold as a "one size fits all" of shared libraries and utilities? Quick answer to that is.. eh no. The JeOS solution needs to be minimal, very minimal. In fact it should be just enough to load the software (or virtual software) appliance. The libraries that the appliance uses such as libc, libxml2 and so on, should be part and parcel of the appliance itself. Could be part of a JeOS stack or as in AppOS -- Release Build Environment which provides basic libraries.
What happens if you are sharing libc and libxml2 between an Apache/PHP application and an Apache/Python application on the same server? Lets say the PHP application is compromised due to some unpatched PHP bug, this allows the malicious user to now manipulate libc, and thus effect the perfectly secure Apache/Python application! This is why sharing libraries between production applications is a very bad idea. It is why package management on an appliance is a very bad idea.
A better approach is to have each run its own dedicated copy of shared libraries. Sure this might waste a bit of disk space, but disk space is cheap, even more so with JeOS. This type of complete application partitioning is an important part of AppOS. The AppStacks for example, contain exactly what the application needs.
What I'm getting at here is that JeOS really comes in two pieces, there is the operating system side which provides the "just enough" part to load the appliance image, and manage it. Then you have the "just enough" libraries and utilities that are part and parcel of the software appliance itself. There is no kitchen sink situation for the libraries and utilities part. This is something the developer of the appliance needs to figure out, and provide as part of their solution.
The problem is there are companies out there who are trying to make a business out of dumbing down this development process. The development process should never be dumbed down, if someone who is providing a customer with an appliance cannot figure out that they need libxml2, libjpeg and openssl, and can't compile those from source. Do you really want to trust them with your business critical application? Remember any monkey can type [insert your favourite package manager] install openssl, but then you are relying on them to know that what that package provided is good and compiled properly. If they could do that, wouldn't they have just compiled it from source?
So JeOS is just that, Just Enough OS. Its a new marketing buzz word, not a new concept. If someone would like to dispute that, I'd like to point out that the very concept of JeOS (coined in July 2007) was part of my talk at Ohio LinuxFest 2006 (almost a year prior) on Open Source Zero Day Attack Protection. I just used the term minimal instead of just enough. Maybe I should have called it "Mince" ?
Tags: JeOS, virtual appliances, software appliances, ceos that code
Practically anyone who has created their own chroot environment, thats quite a few administrators over the years. Has already used the premise behind JeOS. Many enterprise grade devices such as layer 2-7 switches, content routers and hardware appliances have been using JeOS for years. JeOS is nothing new, and its not something that needs a hypervisor. JeOS is simple, its "Just Enough" operating system for what you are trying to do. OpenWRT is another example of a JeOS solution.
What JeOS is not is a packaging architecture. Package management does NOT belong on appliances, end of story. Don't believe me? Well lets think. What is mission critical and powers the Internet? Ah.. routers. Is there a yum update on Cisco IOS? Eh no. When you need to upgrade Cisco IOS, you download a new firmware image, and reload. Seems other vendors have taken this approach, and even the wireless lan products do this! Seeing a pattern? The self-contained image is guaranteed to work. Its tested for that specific hardware (or architecture) and it just works. When something is mission critical you can't afford to wait 5 minutes while it calculates dependencies, and then might have to roll back everything that it took 5 minutes to update in the first place because of an error. I'm not talking a flash / disk error either, what happens if you update a package and it corrupted at the source? Its got to roll everything back. This is why package management has no place on an enterprise grade appliance, its why trying to label JeOS as a packaging architecture is really silly.
So what is my take on next-generation server operating systems? Well the operating system should be an appliance delivery and management platform. It needs to provide the interface to the hardware (through drivers), access the management network (whether thats a separate physical network or just an SSL/IPSec VPN doesn't matter), exchange data with the centralized management system and then load the software appliances. Whether those are partitioned under a single kernel, or run as virtual software appliances is completely up to the user. In other words, virtualization should be a choice, not something force fed by some product marketing people.
The hypervisor is a feature, not a requirement. This is something very important to remember, because there really are applications out there where you need the full resources of the system available to you. There are bottlenecks which may not be acceptable, such as software switches and added latency of virtual interfaces. As well as the potential for packet leakage between virtual appliances. There are all potential problems.
Should JeOS be sold as a "one size fits all" of shared libraries and utilities? Quick answer to that is.. eh no. The JeOS solution needs to be minimal, very minimal. In fact it should be just enough to load the software (or virtual software) appliance. The libraries that the appliance uses such as libc, libxml2 and so on, should be part and parcel of the appliance itself. Could be part of a JeOS stack or as in AppOS -- Release Build Environment which provides basic libraries.
What happens if you are sharing libc and libxml2 between an Apache/PHP application and an Apache/Python application on the same server? Lets say the PHP application is compromised due to some unpatched PHP bug, this allows the malicious user to now manipulate libc, and thus effect the perfectly secure Apache/Python application! This is why sharing libraries between production applications is a very bad idea. It is why package management on an appliance is a very bad idea.
A better approach is to have each run its own dedicated copy of shared libraries. Sure this might waste a bit of disk space, but disk space is cheap, even more so with JeOS. This type of complete application partitioning is an important part of AppOS. The AppStacks for example, contain exactly what the application needs.
What I'm getting at here is that JeOS really comes in two pieces, there is the operating system side which provides the "just enough" part to load the appliance image, and manage it. Then you have the "just enough" libraries and utilities that are part and parcel of the software appliance itself. There is no kitchen sink situation for the libraries and utilities part. This is something the developer of the appliance needs to figure out, and provide as part of their solution.
The problem is there are companies out there who are trying to make a business out of dumbing down this development process. The development process should never be dumbed down, if someone who is providing a customer with an appliance cannot figure out that they need libxml2, libjpeg and openssl, and can't compile those from source. Do you really want to trust them with your business critical application? Remember any monkey can type [insert your favourite package manager] install openssl, but then you are relying on them to know that what that package provided is good and compiled properly. If they could do that, wouldn't they have just compiled it from source?
So JeOS is just that, Just Enough OS. Its a new marketing buzz word, not a new concept. If someone would like to dispute that, I'd like to point out that the very concept of JeOS (coined in July 2007) was part of my talk at Ohio LinuxFest 2006 (almost a year prior) on Open Source Zero Day Attack Protection. I just used the term minimal instead of just enough. Maybe I should have called it "Mince" ?
Tags: JeOS, virtual appliances, software appliances, ceos that code
Friday, September 14, 2007
Inside AppOS 4.0
AppOS is an open source appliance platform. You might be wondering where AppOS 1.0, 2.0 and 3.0 are? Until now, AppOS shipped as an integrated hardware / software solution. Customers purchased a 1U or 2U SN-series appliance directly from Spliced Networks or through one of our resellers. AppOS came pre-installed either of disk or on flash. Customers received automated updates and received a quarterly DVD in the mail with the source code.
Spliced Networks, unlike the majority of the other "appliance platform" companies out there, has actually shipped appliances and a lot of them. We have been there, understand the requirements, the process and the problems. This is why AppOS 4.0 is a far superior platform to the competition.
AppOS 4.0 sports all of the features we had in previous releases. The firmware style imaging system, the zero-day attack protection, the virtually instant OS upgrades and the centralized management system. With AppOS 4.0, we've improved on all of these features, further enhanced security and performance. However, with 4.0, we've introduced seamless virtualization without significantly increasing the image size.
AppOS 4.0 can switch seamlessly between our traditional AppOS image system, and a VM based system. It can run both systems simultaneously as well. Unlike other virtual appliances, AppOS 4.0 maintains its highly secure platform within the VM. Making it the most secure Linux-based appliance solution available today.
So if you are looking for the most secure, most highly optimized "JeOS", with the worlds smallest hypervisor built right in, stay tuned. AppOS 4.0 is coming.
Spliced Networks, unlike the majority of the other "appliance platform" companies out there, has actually shipped appliances and a lot of them. We have been there, understand the requirements, the process and the problems. This is why AppOS 4.0 is a far superior platform to the competition.
AppOS 4.0 sports all of the features we had in previous releases. The firmware style imaging system, the zero-day attack protection, the virtually instant OS upgrades and the centralized management system. With AppOS 4.0, we've improved on all of these features, further enhanced security and performance. However, with 4.0, we've introduced seamless virtualization without significantly increasing the image size.
AppOS 4.0 can switch seamlessly between our traditional AppOS image system, and a VM based system. It can run both systems simultaneously as well. Unlike other virtual appliances, AppOS 4.0 maintains its highly secure platform within the VM. Making it the most secure Linux-based appliance solution available today.
So if you are looking for the most secure, most highly optimized "JeOS", with the worlds smallest hypervisor built right in, stay tuned. AppOS 4.0 is coming.
Rethinking SaaS.. rBuilder impacted for 5 hours
Software as a Service (SaaS) is basically taking something you might run locally on a dedicated appliance, server or application and transforming it into a web based service. SaaS is great for some applications, such as this blog. However its bad for things which are risk adverse to downtime and data loss. Although I'd be a bit upset if my blog data was lost! :)
The big thing with SaaS is trust, do you trust the vendor thats providing the service, have they the skills and experience to run a highly available service? In other words, are they "Enterprise Ready" or not.
A business selling server appliances, whether its a hardware / software combination, software appliance or virtual appliance, should really take a close look at where they are doing their development.
Update:
Tim Gerla from rPath was kind enough to provide clarification on the outage below. Certain repositories were inaccessible over the course of 5 hours. This was a limited number of repositories. Repositories were read-only for a time. Tim apologized for the confusion regarding their announcement, and I'm sure they will provide more details with future announcements.
Since we always want to be fair and accurate, this update was added, the original posting is below and the title of this entry has been updated to be more accurate.
Thanks Tim!
End Update
For example, if you relied on rPath's rBuilder On-line service, you would have been straight out of luck for 5 hours this afternoon. Around 13:20 EST, rPath announced:
msw: rBO going into maint mode while we work on a db problem
Shortly after Michael Tharp updated the topic to indicate rBuilder Online is currently down for maintenance.
Over 5 hours later around 18:33 EST, rBuilder Online came back up, and Michael Tharp provided a quick update to indicate that it was back online.
A database problem shouldn't cause a 5 hour outage in a properly designed and highly available environment. Makes you wonder if its really ready for the Enterprise or just a nice packaging system alternative for the desktop?
The big thing with SaaS is trust, do you trust the vendor thats providing the service, have they the skills and experience to run a highly available service? In other words, are they "Enterprise Ready" or not.
A business selling server appliances, whether its a hardware / software combination, software appliance or virtual appliance, should really take a close look at where they are doing their development.
Update:
Tim Gerla from rPath was kind enough to provide clarification on the outage below. Certain repositories were inaccessible over the course of 5 hours. This was a limited number of repositories. Repositories were read-only for a time. Tim apologized for the confusion regarding their announcement, and I'm sure they will provide more details with future announcements.
Since we always want to be fair and accurate, this update was added, the original posting is below and the title of this entry has been updated to be more accurate.
Thanks Tim!
End Update
For example, if you relied on rPath's rBuilder On-line service, you would have been straight out of luck for 5 hours this afternoon. Around 13:20 EST, rPath announced:
msw: rBO going into maint mode while we work on a db problem
Shortly after Michael Tharp updated the topic to indicate rBuilder Online is currently down for maintenance.
Over 5 hours later around 18:33 EST, rBuilder Online came back up, and Michael Tharp provided a quick update to indicate that it was back online.
A database problem shouldn't cause a 5 hour outage in a properly designed and highly available environment. Makes you wonder if its really ready for the Enterprise or just a nice packaging system alternative for the desktop?
Wednesday, September 12, 2007
JeOS .. Nice try but just too much
With VMworld wrapping up tomorrow, we are seeing the emergence of JeOS. JeOS is Just Enough OS, in the Ubuntu world its apparently 280MB. Nice try! Its not just the Canonical folks that are pumping this concept either. rPath seem to have jumped on the bandwagon too.
The concept of JeOS is not new, the fancy marketing buzzword is interesting but its unfortunate they didn't apply as much effort into engineering these solutions. Gentoo is smaller than 280MB, even Debian base is smaller than that so I'm not sure what kind of "juice" they've been passing around the Canonical offices, but 280MB is a joke.
Good to see that the industry is catching up with Spliced Networks. Took them over 4 years! AppOS 1.0 shipped as 160MB "JeOS", with 4.0 down to under 30MB, we must have the leading JeOS around!
The concept of JeOS is not new, the fancy marketing buzzword is interesting but its unfortunate they didn't apply as much effort into engineering these solutions. Gentoo is smaller than 280MB, even Debian base is smaller than that so I'm not sure what kind of "juice" they've been passing around the Canonical offices, but 280MB is a joke.
Good to see that the industry is catching up with Spliced Networks. Took them over 4 years! AppOS 1.0 shipped as 160MB "JeOS", with 4.0 down to under 30MB, we must have the leading JeOS around!
Is GNU/Linux a trademark violation?
Linux is a registered trademark of Linus Torvalds and is administered by the Linux Mark Institute (www.linuxmark.org). The LMI will grant sub-licenses of the Linux trademark to businesses and groups that want to use the word Linux in their product.
When you refer to registered trademarks you are supposed to use the ® symbol, or at the very least attribute the mark to its owner. The folks over at GNU don't do this, if you check out www.gnu.org, there is no mention that Linux is a registered trademark, and they do not make any attempt to attribute the mark to Linus. The same thing goes for Debian, who I might point out have taken the measures to protect their own mark.
The use of GNU/Linux is an attempt to build a new mark from an existing one. Whether or not thats the intention, its essentially what is being done. In the case of Debian GNU/Linux, they are shipping a product (whether its free or not) so it likely falls outside of fair use.
GNU has great stuff, and they deserve every bit of praise and credit as Linux does. I would encourage businesses and entities who use GNU and Linux to build products, to mention that they are GNU-based as well as Linux-based. It is something we are doing with AppOS 4.0. While GNU has great stuff and deserves credit, they do not have the right to violate a registered trademark.
So is GNU/Linux a trademark violation? Should Stallman at the very least be required to get a sub-license? From my dealings with the USPTO (Patent and Trademark Office), GNU/Linux would seem to be a new mark, and thus require sub-licensing. If Linus does not enforce this, does it threaten the Linux mark ? Just some food for thought I would throw out there to the community.
Something for businesses to think about before adopting GNU/Linux instead of just Linux.
When you refer to registered trademarks you are supposed to use the ® symbol, or at the very least attribute the mark to its owner. The folks over at GNU don't do this, if you check out www.gnu.org, there is no mention that Linux is a registered trademark, and they do not make any attempt to attribute the mark to Linus. The same thing goes for Debian, who I might point out have taken the measures to protect their own mark.
The use of GNU/Linux is an attempt to build a new mark from an existing one. Whether or not thats the intention, its essentially what is being done. In the case of Debian GNU/Linux, they are shipping a product (whether its free or not) so it likely falls outside of fair use.
GNU has great stuff, and they deserve every bit of praise and credit as Linux does. I would encourage businesses and entities who use GNU and Linux to build products, to mention that they are GNU-based as well as Linux-based. It is something we are doing with AppOS 4.0. While GNU has great stuff and deserves credit, they do not have the right to violate a registered trademark.
So is GNU/Linux a trademark violation? Should Stallman at the very least be required to get a sub-license? From my dealings with the USPTO (Patent and Trademark Office), GNU/Linux would seem to be a new mark, and thus require sub-licensing. If Linus does not enforce this, does it threaten the Linux mark ? Just some food for thought I would throw out there to the community.
Something for businesses to think about before adopting GNU/Linux instead of just Linux.
Thursday, September 6, 2007
o3 magazine :: issue 8 - Enterprise Email
Issue 8 of o3 magazine is now available for download. This issue provides an end-to-end guide for building and deploying an enterprise-grade email system. o3 is a FREE digital magazine produced by Spliced Networks.
The basic idea behind the solution is to place multiple SMTP relays out there that use recipient lists and relay domains, along with the usual RBLs to cut through the bulk of the spam. The relays then forward mail to the per-domain configured server. This is usually a bunch of servers in a load balanced cluster, but could easily be a single server to. Its not listed on the public MX list, and in fact its firewalled so that only the SMTP relays and permitted client networks can talk to it.
The DSPAM article looks at dropping DSPAM in between the relays and the hidden back end SMTP server. The MTA we use is Postfix, but the recipes work under Linux, BSD and MacOS X. The DSPAM article provides a complete deployment guide. There is an article on Dovecot to provide imapd and pop3, with an article on Encrypting Mail protocols and finally a look at RoundCube to provide web based access.
We didn't stop there though, the issue also looks at Voicemail / Email integration with Asterisk, and we pushed the envelope a little with a look at voicemail to text translation with Julius, a real-time speech recognition project.
There is also an article on MobilityEmail, a good alternative to Outlook if you need to support Windows clients.
Finally, if you check the back page of the magazine, there is a little hint at whats on its way! :)
The basic idea behind the solution is to place multiple SMTP relays out there that use recipient lists and relay domains, along with the usual RBLs to cut through the bulk of the spam. The relays then forward mail to the per-domain configured server. This is usually a bunch of servers in a load balanced cluster, but could easily be a single server to. Its not listed on the public MX list, and in fact its firewalled so that only the SMTP relays and permitted client networks can talk to it.
The DSPAM article looks at dropping DSPAM in between the relays and the hidden back end SMTP server. The MTA we use is Postfix, but the recipes work under Linux, BSD and MacOS X. The DSPAM article provides a complete deployment guide. There is an article on Dovecot to provide imapd and pop3, with an article on Encrypting Mail protocols and finally a look at RoundCube to provide web based access.
We didn't stop there though, the issue also looks at Voicemail / Email integration with Asterisk, and we pushed the envelope a little with a look at voicemail to text translation with Julius, a real-time speech recognition project.
There is also an article on MobilityEmail, a good alternative to Outlook if you need to support Windows clients.
Finally, if you check the back page of the magazine, there is a little hint at whats on its way! :)
Subscribe to:
Posts (Atom)
