Roundtable December 2006

roundtable@muug.ca

16 participants
16 discussions

NetBSD, OpenBSD, FreeBSD, yikes!
by Montana Quiring 05 Dec '06

05 Dec '06

I've been playing with Solaris over the past year but I would like to get more experience with UNIX. There seems to be three (correct me if I'm wrong) main players in the BSD playing field. Can someone briefly give a semi-layman, semi-tech explaination of the differences between NetBSD, OpenBSD and FreeBSD? >From reading their web pages and googling they all seem to pride themselves on security. I think it's NetBSD that prides its self on having the most portability and tightly written code, the downside being they are not the most current when it comes to supporting new hardware, etc. I'm looking to use a BSD to create a secure web server and maybe OpenLDAP as well. This would be for a production environment and not just tinkering. Xen compatability would also be a bonus.

6 5

MUUG Meeting, Dec 12, 7:30pm -- Round-table and Holiday Mingle
by gedetil＠cs.umanitoba.ca 05 Dec '06

05 Dec '06

The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting on Tuesday, December 12. The meeting topic for this month is as follows: Round-table and Holiday Mingle As the year winds down, it's time for MUUG to take things at a more relaxed pace. So, we'll allow the round-table discussion to go a bit longer (rather than cutting it short as we sometimes have to), then instead of a very short coffee break, we'll have a more laid-back mingler with some holiday treats and more time for informal discussion. Not sure if the fat guy in red will show up, but rumour has it there will be some gifts given out... So, whether you've been naughty or nice this year, don't miss out on the fun! The group holds its general meetings at 7:30pm on the second Tuesday of every month from September to June. (There are no meetings in July and August.) Meetings are open to the general public; you don't have to be a MUUG member to attend. ********************************************************************** Please note our meeting location: The IBM offices, at 400 Ellice Ave. (between Edmonton and Kennedy). When you arrive, you will have to sign in at the reception desk, and then wait for someone to take you (in groups) to the meeting room. Please try to arrive by about 7:15pm, so the meeting can start promptly at 7:30pm. Don't be late, or you may not get in. (But don't come too early either, since security may not be there to let you in before 7:15 or so.) Limited parking is available for free on the street, either on Ellice Ave. or on some of the intersecting streets. Indoor parking is also available nearby, at Portage Place, for $3.00 for the evening. Bicycle parking is available in a bike rack under video surveillance located behind the building on Webb Place. ********************************************************************** For more information about MUUG, and its monthly meetings, check out their Web server: http://www.muug.mb.ca/ Also note that MUUG maintains two mailing lists, called "muug-announce" and "roundtable". If you're not already on these lists, we encourage you to subscribe now: http://www.muug.mb.ca/mailman/listinfo/ The "muug-announce" list is used for monthly meeting announcements (such as this one) as well as other important announcements of interest to MUUG members. The "rountable" list is meant to be a forum for follow-ups to topics discussed at the meetings, or for round-table-style discussion on other topics that come up between meetings. Of course, for this to be effective, we need to reach a certain critical mass. So, please subscribe, and stay involved! -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609

1 0

re: wifi access ...
by Dan Keizer 05 Dec '06

05 Dec '06

You can check out: http://les.net/products/product_wpgwifi.php if Les still has it operating .. I haven't checked in a while, but it was up a while back ... Dan.

2 1

greylisting
by Trevor Cordes 04 Dec '06

04 Dec '06

After domain keys, I implemented the milter-greylist that Gilbert was talking about. It's pretty easy (on FC, with yum packages). Anyone care to compare notes? I've chosen the following values: timeout 25h greylist 6m autowhite 30d subnetmatch /24 Does anyone think there could be an MTA retarded enough to have the queue retry time set to longer than 25h? The greylist default was 5d, but that seems a bit excessive, or am I missing something here? As for the greylist option, shouldn't 1m be enough to do the trick? Either a spammer will retry or it won't, how long you make it wait should not matter. Of course, once everyone implements greylisting, then all spammers will simply start retrying -- it's only CPU cycles, and those keep getting cheaper. I suppose setting greylist to 30m or 60m or something might stop some spammers who are now waiting, but not very long. But that's got to be rare. autowhite should be set pretty high IMO. My only complaint with the greylist concept is the fact that at the end of the conf file is: # This is a list of broken MTAs that break with greylisting. This is like me adding mailertable entries for every domain that RBL's my dyanmic IP (which I do, but the list is getting unwieldly). It's a can't-win scenario. Too bad there are MTA's out there that are so braindead. Of course, some of them like AOL aren't necessarily braindead, but instead are hard to greylist because of the common-pool problem. That's why I set subnetmatch to /24 which should be fairly safe (since we're still checking to/from/ip tuples, not just IP). But that's just a big kludge, and there appears to be no immediate easy solution to the problem. Unless... change hte subnetmatch to /16 (or even /0??) and rely more on the to/from tuple. Why not? Most spams use random to/froms. Not ideal, but /0 would get around the braindead/pool problem while still providing some greylist benefit. I'm going to keep an eye on stats on my boxes to see how this greylisting impacts things, and I may report back.

4 3

Re: [RndTbl] WiFi in Winnipeg
by Montana Quiring 04 Dec '06

04 Dec '06

Thanks for the info about Twist, but it looks like they aren't open on Sundays which is when we are wanting to meet. Any other suggestions, please? Thanks, -Montana On 11/30/06, Rob Olivier <rolivier(a)mts.net> wrote: > The Twist, on Graham ave, does have free WiFi > > http://www.twistcafe.com/index.asp > > Nice place too. > > Rob O > > > > On Thu, 2006-30-11 at 07:45 -0600, Montana Quiring wrote: > > Does anyone know of a restaurant in Winnipeg (central preferred) that > > has free WiFi? > > If not then has anyone tried one of the pay services, like at > > Starbucks, and what was your experience? > > Thanks. > > -Montana > > _______________________________________________ > > Roundtable mailing list > > Roundtable(a)muug.mb.ca > > http://www.muug.mb.ca/mailman/listinfo/roundtable >

2 1

MTA domain keys (dk-filter)
by Trevor Cordes 03 Dec '06

03 Dec '06

Is anyone else looking into (or has implemented) "domain keys" on their MTA (sendmail, etc)? For those who don't know yet, domain keys is another "grand solution to spam", like SPF and DKIM. It's being pushed by Yahoo, and almost any mail sent to yahoo.com without DK will be tagged as Bulk. http://antispam.yahoo.com/domainkeys I just spent 4 hours making it all work (and figuring it all out) in FC5 on my firewall/router/mail-server/workstation/kitchen-sink. My impression is it's still pretty experimental, and there are no prebuilt yum packages available for it. The source for dk-filter (a sendmail milter) is pretty buggy and obtuse. But it seems to work finally. I have it setup mainly for outgoing mail, so my mail will get through to yahoo/etc ok. I have the incoming check options set to "allow no matter what", yet it provides some pretty cool fine-level control. One option in particular that looks very useful is: # signaturemissing, miss * The DNS TXT record for the sending host indicates that every message should contain a DK signature, but none was found in the message. I'm thinking I could reject all "miss" emails fairly safely. If a domain is setup properly and says "we always sign our emails", and if dk is working, then an unsigned/badly-signed email purporting to be from them must be a spoofed spam. I wonder how many domains are marking themselves as "we sign every email". I wonder how you even indicate that option in the TXT record; I haven't found a doc for that cryptic code yet. Likewise, if I'm confident dk is working well then turning that option on may help the world by allowing dk-aware MTA's to drop spam purporting to be from me! I have some other observations/questions: If I email to myself @yahoo.com, yahoo puts a little blue message under the From: header saying domain keys were confirmed. Neat! For the emails to domains that I have to forward through Shaw (or they get blocked by the RBL's because of my dyanamic IP), will Shaw introduce headers that will cause the sig check to fail? Certainly they must plop in a Received: header? If so, how are domain keys to ever function properly when an intermediate mail server is involved? (Also would apply to people sending to me where it goes to easydns, my backup MX server, first.) In that scenario, having domain keys would be worse than not because then the normal-config dk-filter would reject the "corrupt" email. If there were no dk's at all, then the email would go through (albeit marked as bulk). I don't want a scenario where I may get *more* "lost" or "dropped" emails, especially without bounce debugs! Am I reading the functioning of domain keys correctly with the above point? Or perhaps the intermediate host is supposed to verify the dk then regen a new one for the next hop? But if the intermediate MTA isn't dk-aware, it may just leave the original header intact causing the final dk check to fail?

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Roundtable December 2006