It turns out that I was more then a little confused on how SMTP AUTH/SASL worked. Now I have no idea how to get that going... Ugh!
On the other hand, I did get something actually working for Spam/virus filtering. Turns out AMaVIS is a handy scanner that includes spam filtering and will run external spam filtering and virus filtering. I was able to hook AMaVIS in to the mail system to scan spam and ClamAV into AMaVIS to combine the scanning on that front too. So far, it is already tossing out spam, yay! It is supposed to be assigning a score to all mail but I'm not too sure where that is at... Anyhow, it is throwing spam out so I probably just need to do some tuning.
In other messaging news, of the instant type, Jive Messenger released version 2.4.0 including a new name: Wildfire. I've upgraded the Jabber server from Messenger 2.3.1 to Wildfire 2.4.0. Always good to see great projects remaining active. Gaim 1.5 still doesn't work with it (TLS issue of some sort still) but Gaim just announced their 2.0 beta. I haven't tried that yet but I doubt I'll get to it until the stable release what with the holidays and such.
The last interesting tidbit is that I installed Cacti from package on Siona. I just added Siona and Friday in there and so far so good. Check it out and login as username "guest" password "password". I like this tool...
For upcoming plans, I'm still sorting out some of the domain and hosting issues leftover from Nikita's passing. Not too tricky, but we just have to get some stuff cleaned up. Mmm also syndicating news. Possibly giving up on my hand-written news doodad and switching to something with features, like WordPress. Who knows? Stranger things have happened.
Monday, 19 December 2005
Tuesday, 6 December 2005
Goodbye, Nikita
Nikita has officially passed on. May she find peace in Computer Heaven where all good computers go if they have led a long and happy life which Nikita certainly had. She first started out as workstation ion 1997 with few aspirations other then to run a word processor, a browser, and a couple of games.
In her life, Nikita was able to overcome this humble life of low-speed network links and buggy office applications to become a webserver on a high speed connection, eventually as high as dual-OC3's with failovers. In her last days, she served as a primary DNS server and mail host for a lucky group of friends.
It was on a quiet Sunday in December when the power went out. Her health had been failing but this was the last power failure for her. She passed quietly idling and is in a better place now.
Nikita
Rest In Peace
~1997 - December 6, 2005
In her life, Nikita was able to overcome this humble life of low-speed network links and buggy office applications to become a webserver on a high speed connection, eventually as high as dual-OC3's with failovers. In her last days, she served as a primary DNS server and mail host for a lucky group of friends.
It was on a quiet Sunday in December when the power went out. Her health had been failing but this was the last power failure for her. She passed quietly idling and is in a better place now.
Nikita
Rest In Peace
~1997 - December 6, 2005
Monday, 21 November 2005
Duplicating data one more time
Last week I was reading up a bit on SPF and briefly at the other proposals for verifying that email is legitimate rather then spam. So far as I can see, the basic premise of these types of solutions is that the recipient (e.g. you) can find out if the email message is from a legitimate source.
The basis of SPF if that the sender's domain (e.g. nibble.bz in my case) would include a TXT record that lists all valid sending email servers. I really find this astounding. DNS has been messed with for a lot of things and now this? The RFCs state that TXT records are not to be used for structured data. I don't know how those bird-brains could promote such trash as being a good idea. "But it's easy!" Well, find me a paper or a book on computer security and I'll show you at least two places that say computer security comes at the expense of ease of use. Sorry folks, I don't buy SPF.
Holistic dicussion aside, one of the underlying shortcomings of many existing mail setups, Nibble Net's included, is that the sender is never authenticated in the first place. I use my email from all over the lower mainland and when I send mail I just use whatever the nearest relay is. At work, I use the SFU mail servers, at home, I might use the Shaw mail servers. Why? Relaying mail is typically permitted on the basis of IP address alone and not any sort of login.
Now we get in to authenticated SMTP. Users within a domain can login and send mail from one of the various hosts within that domain isntead of using, say, the SFU mail server. Ah! See there's the rub. For a client (my workstation at SFU) to send an email, I use the same protocol for talking to the server and the server uses for talking to the recipient's mail server. To talk to the server here, it would make sense that I put in a username and password so the server can identify me. Fine, great, swell. Now for the server here at SFU to send a message to hotmail.com, for example, there's no password involved. There's no certificates, no nothing. See where I'm going with this? The Simple Mail Transport Protocol is geared for exchanges messages equally well between your mail program and a server as it is between a virus-infected PC and a mail server. "You don't know where it's been" couldn't be more true.
Well SPF, SenderID, DomainKeys all try to address the server-to-server side of the problem. The client-to-server is best solved by forcing users to provide authentication information which is what I took a stab at on the weekend. Now all the user information for our users is stored in a LDAP directory so it is best if users authenticate against that. Not so fast, sport. Aparently, we're going to have to use Simple Authenticate and Security Layer (SASL). "That's pretty cool," I think to myself, "I'll be able to use PLAIN, CRAM-MD5, DIGEST-MD5, or GSSAPI (if I had Kerberos installed)."
So I poke around and poke around and to the best of my searching, it turns out there's a couple things going on here. Firstly, SASL is a set of libraries so that clients and servers can perform the various SASL operations and secondly Postfix will do SASL authenticate against a seperate SASL password file. Suposedly, I would have to duplicate all the user data in another password file. Heck, even with system logins and Jive Messenger logins using LDAP, I still have a seperate Samba password file and a plethora of htpasswd type files and up until I retired NIS there was the yppasswd database as well! Common folks, let's duplicate the user info ONE MORE TIME! So far as I can tell, I will have to setup an additional daemon, sasld. So the users email program talks to Postfix, Postfix talks to the SASL daemon, the SASL daemon talks to the OpenLDAP server, and finally the user will be authenticated and allowed to send mail. Excitement! Well, if I'm even in the right ballpark, then the setup is actually pretty simple. A couple options in each of three servers to get strong authentication working. Nevertheless, a task for another day.
Speaking of other tasks, I did finally start trying to clean up the DNS names and SSL certificates. So the best convention for keeping the DNS stuff organized that I can figure is to give each machine a proper host name (siona.dl.nibble.bz, friday.dl.nibble.bz, etc) and then give each *service* a hostname to match the service like imaps.dl.nibble.bz. Then issue a certificate for each service such that there's no confusion as to what's going on (you're authenticating the service you're accessing) and if services do get moved to different machines, changes like that are transparent to the user.
Anyhow, enough excitement, it's time to go home.
The basis of SPF if that the sender's domain (e.g. nibble.bz in my case) would include a TXT record that lists all valid sending email servers. I really find this astounding. DNS has been messed with for a lot of things and now this? The RFCs state that TXT records are not to be used for structured data. I don't know how those bird-brains could promote such trash as being a good idea. "But it's easy!" Well, find me a paper or a book on computer security and I'll show you at least two places that say computer security comes at the expense of ease of use. Sorry folks, I don't buy SPF.
Holistic dicussion aside, one of the underlying shortcomings of many existing mail setups, Nibble Net's included, is that the sender is never authenticated in the first place. I use my email from all over the lower mainland and when I send mail I just use whatever the nearest relay is. At work, I use the SFU mail servers, at home, I might use the Shaw mail servers. Why? Relaying mail is typically permitted on the basis of IP address alone and not any sort of login.
Now we get in to authenticated SMTP. Users within a domain can login and send mail from one of the various hosts within that domain isntead of using, say, the SFU mail server. Ah! See there's the rub. For a client (my workstation at SFU) to send an email, I use the same protocol for talking to the server and the server uses for talking to the recipient's mail server. To talk to the server here, it would make sense that I put in a username and password so the server can identify me. Fine, great, swell. Now for the server here at SFU to send a message to hotmail.com, for example, there's no password involved. There's no certificates, no nothing. See where I'm going with this? The Simple Mail Transport Protocol is geared for exchanges messages equally well between your mail program and a server as it is between a virus-infected PC and a mail server. "You don't know where it's been" couldn't be more true.
Well SPF, SenderID, DomainKeys all try to address the server-to-server side of the problem. The client-to-server is best solved by forcing users to provide authentication information which is what I took a stab at on the weekend. Now all the user information for our users is stored in a LDAP directory so it is best if users authenticate against that. Not so fast, sport. Aparently, we're going to have to use Simple Authenticate and Security Layer (SASL). "That's pretty cool," I think to myself, "I'll be able to use PLAIN, CRAM-MD5, DIGEST-MD5, or GSSAPI (if I had Kerberos installed)."
So I poke around and poke around and to the best of my searching, it turns out there's a couple things going on here. Firstly, SASL is a set of libraries so that clients and servers can perform the various SASL operations and secondly Postfix will do SASL authenticate against a seperate SASL password file. Suposedly, I would have to duplicate all the user data in another password file. Heck, even with system logins and Jive Messenger logins using LDAP, I still have a seperate Samba password file and a plethora of htpasswd type files and up until I retired NIS there was the yppasswd database as well! Common folks, let's duplicate the user info ONE MORE TIME! So far as I can tell, I will have to setup an additional daemon, sasld. So the users email program talks to Postfix, Postfix talks to the SASL daemon, the SASL daemon talks to the OpenLDAP server, and finally the user will be authenticated and allowed to send mail. Excitement! Well, if I'm even in the right ballpark, then the setup is actually pretty simple. A couple options in each of three servers to get strong authentication working. Nevertheless, a task for another day.
Speaking of other tasks, I did finally start trying to clean up the DNS names and SSL certificates. So the best convention for keeping the DNS stuff organized that I can figure is to give each machine a proper host name (siona.dl.nibble.bz, friday.dl.nibble.bz, etc) and then give each *service* a hostname to match the service like imaps.dl.nibble.bz. Then issue a certificate for each service such that there's no confusion as to what's going on (you're authenticating the service you're accessing) and if services do get moved to different machines, changes like that are transparent to the user.
Anyhow, enough excitement, it's time to go home.
Friday, 4 November 2005
Tocaraul now with searching and stuff
After making some modifications Tocaraul now has fewer bugs, a search function, and functions to delete songs from the request queue (or flush the whole thing). So far, we're doing good. I think that's probably going to be about all the features that I can update without making significant changes to how the code is structured.
I would like to break-up everything into views (request queue is one, library is another, search is a sort of sub-view of library) so that more and more features can be builtin to each part of the program without adding confusion to the interface. That smacks of effort so Fabio and I will see what else we're going to work on. Probably the play history. That would be cool.
I would like to break-up everything into views (request queue is one, library is another, search is a sort of sub-view of library) so that more and more features can be builtin to each part of the program without adding confusion to the interface. That smacks of effort so Fabio and I will see what else we're going to work on. Probably the play history. That would be cool.
Monday, 31 October 2005
Jivin' for Jabber
Turns out there are a few things to keep in mind when setting up an XMPP (Jabber) server. I had to change the domain name a couple times and add a couple service records but the system is now up and running in a standard open-federation configuration. Users on Siona can use their system login for user@dl.nibble.bz and then *poof* that's it. We can message eachother, message other users of different XMPP servers. Access for server-to-server in Jive can be configured eiher by white-list or black-list so I'm just running ours open for now.
And Google developers have said they will join the open federation as soon as possible. One of the sticking points they want to address is control over spammers and bots who could register on any server in the community that allows public registration and then spam the crap out of the Google Talk users. Which is a fair concern but we're all egerly awaiting Google's move to the open federation.
I've been spending more time working with Tocaraul as a front-end for the Icecast server I'm running from home. All the good Ogg encodings are in the library for a whopping total of 2377 songs. Tocaraul is a couple of Python scripts to handle song requests from a web interface. Basically, I'm learning Python :P It's pretty handy stuff. For info on Tocaraul progress, take a look at the WebSVN page there and there's both a change log and a TODO for upcoming features.
And Google developers have said they will join the open federation as soon as possible. One of the sticking points they want to address is control over spammers and bots who could register on any server in the community that allows public registration and then spam the crap out of the Google Talk users. Which is a fair concern but we're all egerly awaiting Google's move to the open federation.
I've been spending more time working with Tocaraul as a front-end for the Icecast server I'm running from home. All the good Ogg encodings are in the library for a whopping total of 2377 songs. Tocaraul is a couple of Python scripts to handle song requests from a web interface. Basically, I'm learning Python :P It's pretty handy stuff. For info on Tocaraul progress, take a look at the WebSVN page there and there's both a change log and a TODO for upcoming features.
Friday, 21 October 2005
Things are Looking up in the Directory
Siona is now running a live LDAP directory and so far it is going pretty well. System authentication is all directory based. Logins and sessions and all that good fun. I configured a Jabber server (Jive Messenger) to auth users against the directory and it works swell! Any system users can login with their system account on the Jabber server and IM and that fun stuff.
I plan to migrate Samba next which is not a very big impact but would be good to get in the central user directory. Dovecot for IMAP and POP authentication after that. Postfix eventually as well which will be interesting. With Postfix, that will afect how mail is routed possibly making it easier to setup virtual domains or whatever. I think that about covers the auth stuff that's offered.
That Jabber server is a little special. I'll have to get some of the peeps using it so we can try to test some of the features. Just basic stuff like authorizing users and setting up or joining chat rooms. So far it seems a little sketchy. There are also some other handy features of the server like a searchable directory. I don't know how that will work out. I just know that I don't know how to get my IM client to even use that feature :P
At any rate, the LDAP works really great and after a bit of a rough start out of the gate, it is really going to be useful as heck. This Jabber we will have to see but it seems promising.
I plan to migrate Samba next which is not a very big impact but would be good to get in the central user directory. Dovecot for IMAP and POP authentication after that. Postfix eventually as well which will be interesting. With Postfix, that will afect how mail is routed possibly making it easier to setup virtual domains or whatever. I think that about covers the auth stuff that's offered.
That Jabber server is a little special. I'll have to get some of the peeps using it so we can try to test some of the features. Just basic stuff like authorizing users and setting up or joining chat rooms. So far it seems a little sketchy. There are also some other handy features of the server like a searchable directory. I don't know how that will work out. I just know that I don't know how to get my IM client to even use that feature :P
At any rate, the LDAP works really great and after a bit of a rough start out of the gate, it is really going to be useful as heck. This Jabber we will have to see but it seems promising.
Sunday, 16 October 2005
Auth This...
Well, I'm finally going to try to get a working LDAP server up and running on Siona finally. There are so many services that would just work better with a working directory, I gots to put one in. I'm still struggling with bootstrapping the whole operation. I've read some stuff, looked for some tools, but basically unless it's part of a big enterprise package, it's a little, uh, heavy for most operation.
But basically I would be able to run everything through it. Users could save their contact lists online. Login info could come from the directory for any number of services inluding system logins, Samba, Jabber, email, the works! It's all patched together right now with a crude mix of pam, maintenance scripts, and just plain not working. The only common service that I have been able to find is LDAP. PAM is really promising but a bunch of services, like Samba, do a challenge type auth so the passwords have to be decryptable rather then a straight hash.
And all-in-all, setting LDAP as a n00b is really confusing. I just hope this all works out in the end and we'll have world peace and a fair distribution of wealth.
But basically I would be able to run everything through it. Users could save their contact lists online. Login info could come from the directory for any number of services inluding system logins, Samba, Jabber, email, the works! It's all patched together right now with a crude mix of pam, maintenance scripts, and just plain not working. The only common service that I have been able to find is LDAP. PAM is really promising but a bunch of services, like Samba, do a challenge type auth so the passwords have to be decryptable rather then a straight hash.
And all-in-all, setting LDAP as a n00b is really confusing. I just hope this all works out in the end and we'll have world peace and a fair distribution of wealth.
Subscribe to:
Posts (Atom)