Grey-listing in effect on MUUG server
Howdy folks! I mentioned this at Tuesday's meeting, but for the benefit of those of you who weren't there, but are active on the MUUG roundtable mailing list, I thought I should repeat it here. As of Tuesday afternoon (November 14th), I've installed a package called milter-greylist (http://hcpnet.free.fr/milter-greylist/) on the MUUG server, to help in our ongoing battle against spam. So far, it's been remarkably effective (in combination with SpamAssassin and spamass-milter, which had been previously installed) at reducing our incoming spam. Since we've configured it to greylist all external addresses by default, this may impact some of you when you post to the list via e-mail. The first time it comes across the combination of your (or your ISP's) SMTP server IP address, your return e-mail address, and the destination e-mail address, it will temporarily reject the message, asking the SMTP server to retry again after some time (I've set that delay to 14 minutes). After that, that combination stays cached in the greylist for some amount of time (which is set by default to 5 days), during which time the same combination of addresses will be accepted without delay. The net result of this is that you may occasionally see a delay between when you send e-mail to the list and when it actually gets received, especially if you post infrequently. Rest assured, however, that your message should get through without too much extra delay. If for some reason you find yourself unable to send at all, you can contact me at me e-mail address below (and not the muug.mb.ca address). We're also running the same milter-greylist software on that server, but with a less aggressive policy, which does default white-listing in most cases. Preferably, contact me from exactly the same address you try to use for posting to the mailing list, so I can check e-mail headers to determine SMTP server address information, etc. I will then, if necessary, add the appropriate whitelist override for your address on the MUUG server. For those of you running your own sendmail servers on the Internet, I highly recommend milter-greylist. It's very small, doesn't use up much CPU or memory (much, much less than SpamAssassin in both cases), and seems to work very well. (Make sure you put it first in your InputMailFilters list, so the other milters don't have to do as much work.) If you're not running sendmail, but some other SMTP server, you should look for a similar grey-listing solution for your mail server. -- Gilbert E. Detillieux E-mail: <gedetil@cs.umanitoba.ca> Dept. of Computer Science Web: http://www.cs.umanitoba.ca/~gedetil/ University of Manitoba Phone: (204)474-8161 Winnipeg MB CANADA R3T 2N2 Fax: (204)474-7609
Gilbert E. Detillieux wrote:
combination stays cached in the greylist for some amount of time (which is set by default to 5 days), during which time the same combination of addresses will be accepted without delay.
I wondering what the harm would be if you made it say a couple of months instead of 5 days. I would think you may even be able to make it a lot longer without harm. -- Bill
"GD" == Gilbert E Detillieux <gedetil@cs.umanitoba.ca> writes:
[ lots of great stuff about greylisting truncated ] GD> If you're not running sendmail, but some other SMTP server, GD> you should look for a similar grey-listing solution for your GD> mail server. Excellent timing, Gilbert! I was just looking for something to add for my personal mail setup, though I've got qmail instead of sendmail. What I did find though, might be helpful for others too. There is another program called qpsmtpd, which takes a plugin approach. This allows for multiple ways to handle the incoming message, with an included greylist plugin as one of them. It also supports DNS block lists, virus and spamassassin scans, and even the sendmail milters you mentioned. It started out as a replacement for qmail-smtpd, but is now quite flexible, and can sit out in front of other MTAs as well. If interested, it can be found at: http://smtpd.develooper.com/ Cheers, Tim -- "Some civil servants are neither servants nor civil." -- Winston Churchill
On 17-Nov-06, at 12:00 AM, Tim Lavoie wrote:
"GD" == Gilbert E Detillieux <gedetil@cs.umanitoba.ca> writes:
[ lots of great stuff about greylisting truncated ]
GD> If you're not running sendmail, but some other SMTP server, GD> you should look for a similar grey-listing solution for your GD> mail server.
Excellent timing, Gilbert! I was just looking for something to add for my personal mail setup, though I've got qmail instead of sendmail.
What I did find though, might be helpful for others too. There is another program called qpsmtpd, which takes a plugin approach. This allows for multiple ways to handle the incoming message, with an included greylist plugin as one of them. It also supports DNS block lists, virus and spamassassin scans, and even the sendmail milters you mentioned.
It started out as a replacement for qmail-smtpd, but is now quite flexible, and can sit out in front of other MTAs as well. If interested, it can be found at: http://smtpd.develooper.com/
Cheers, Tim
If you happen to be running OpenBSD or FreeBSD, you can run spamd (not part of spamassassin). It does greylisting for any MTA and add's almost no load to the machine. To enable it on OpenBSD requires removing 6 comment #'s (IIRC). shawn
On Thu, 2006-11-16 at 16:33 -0600, Gilbert E. Detillieux wrote:
If you're not running sendmail, but some other SMTP server, you should look for a similar grey-listing solution for your mail server.
Postfix has shipped with examples/smtpd-policy/greylist.pl for a few years now. I finally was inspired to set it up this morning which took about 45 minutes. Seems to be working well but to early to say for sure. John
One word of warning: the example greylist.pl is known to have several race conditions (file-locking bugs) that can corrupt the database. It's also fairly inefficient. Having said that, for low-volume mail servers it still works OK... generally its problems only show up under high volume. -Adam John Lange wrote:
Postfix has shipped with examples/smtpd-policy/greylist.pl for a few years now.
I finally was inspired to set it up this morning which took about 45 minutes. Seems to be working well but to early to say for sure.
John
"Shawn" == Shawn Wallbridge <shawn@synack-hosting.com> writes:
Shawn> If you happen to be running OpenBSD or FreeBSD, you can run Shawn> spamd (not part of spamassassin). It does greylisting for Shawn> any MTA and add's almost no load to the machine. To enable Shawn> it on OpenBSD requires removing 6 comment #'s (IIRC). That is easy, though qpsmtpd on Debian was pretty easy as well. The main catch was to move qmail to listen only on localhost, since the external interface now has qpsmtpd instead. So far, so good. No spam in the spambox this morning, at all. Most were caught by the Spamhaus DNS blocklist I already use, but the greylist whacked the remainder. Some of the other plugins look interesting too, but weren't involved in the first few hours. They basically look for weird behaviour which spammers engage in, such as starting to chatter before the SMTP greeting. I'm leaving the log level high for a bit, as I'm curious about how often these show up. Tim
On Fri, 2006-11-17 at 10:22 -0600, Tim Lavoie wrote:
"Shawn" == Shawn Wallbridge <shawn@synack-hosting.com> writes:
Shawn> If you happen to be running OpenBSD or FreeBSD, you can run Shawn> spamd (not part of spamassassin). It does greylisting for Shawn> any MTA and add's almost no load to the machine. To enable Shawn> it on OpenBSD requires removing 6 comment #'s (IIRC).
That is easy, though qpsmtpd on Debian was pretty easy as well. The main catch was to move qmail to listen only on localhost, since the external interface now has qpsmtpd instead.
So far, so good. No spam in the spambox this morning, at all. Most were caught by the Spamhaus DNS blocklist I already use, but the greylist whacked the remainder.
Would it not make sense to do it in the other order? Greylisting being much less CPU intensive than other spam blocking methods. On a related note, personally I'm strongly opposed to block lists since: a) they only work after spam has been sent b) they catch far to many innocent victims c) when other methods are applied properly, blocklists only improve results by a very small amount. "b" being the main reason I don't like them. John
"JK" == John Lange <john.lange@open-it.ca> writes:
JK> Would it not make sense to do it in the other order? JK> Greylisting being much less CPU intensive than other spam JK> blocking methods. The DNS check is pretty lightweight, and early in the process. Heavier checks do run later. JK> On a related note, personally I'm strongly opposed to block JK> lists since: JK> a) they only work after spam has been sent JK> b) they catch far to many innocent victims JK> c) when other methods are applied properly, blocklists only JK> improve results by a very small amount. JK> "b" being the main reason I don't like them. Hm. The Spamhaus lists work after spam has been sent to *somebody*, not necessarily me, so no problem there. Innocent whiners can send an email to let me know if they've been blocked inadvertently. :) More seriously, the RBL stuff does have a way to request getting your address un-blocked, and I think this sort of thing does nudge the ISPs into being more proactive to limit out-bound cruft. The sbl-xbl list also turfs a lot of botnet traffic, without having to scan each message with a local virus checker at my end. For my limited scope, with a handful of users and domains, it's not a big deal to eyeball the log once in a while to see if there's been a false positive. Haven't had one yet, and it's turfed a *lot* of crap. Still, it might be fun to run on just the greylist for a while to see how it does. I do use an account-specific filter (CRM114) too, but it's now had nothing to catch since last night. While very effective, it's naturally the most heavy-weight process, as well as the most fuss to keep the learning process up to date. Tim
On 11/17/2006 10:49 AM, John Lange wrote:
On Fri, 2006-11-17 at 10:22 -0600, Tim Lavoie wrote: ...
So far, so good. No spam in the spambox this morning, at all. Most were caught by the Spamhaus DNS blocklist I already use, but the greylist whacked the remainder.
Would it not make sense to do it in the other order? Greylisting being much less CPU intensive than other spam blocking methods.
I didn't think DNS blocklists were particularly CPU intensive. It's when you get into things like content filtering and DCC that you want to pre-screen as much as possible.
On a related note, personally I'm strongly opposed to block lists since:
a) they only work after spam has been sent
Sort of the same problem as signature based anti-virus, anti-spyware, and even many content-based SPAM filters, as well as DCC bulk mail filters. They all still help a great deal against repeat offenders. Given the saturation bombing approach many spammers still use, blocklists still do help. They don't do much against spam attacks distributed over wide botnets, but they still block a fair bit.
b) they catch far to many innocent victims
Are there any credible stats on this? I've never spotted anything that looks like it might be a false positive in my server logs when I've checked. Of course, some of the claimed "innocent victims" are people like that spammer that sued Spamhaus in an Illinois court and got a summary judgment against them.
c) when other methods are applied properly, blocklists only improve results by a very small amount.
"b" being the main reason I don't like them.
John
Has anyone ever compared the effectiveness and accuracy of the various DNS blocklists? I currently use these 3: list.dsbl.org relays.ordb.org sbl.spamhaus.org Of these, dsbl.org shows up in my logwatch summaries most often, spamhaus.org occasionally, and ordb.org almost never. I'm assuming sendmail runs the checks in the order you list them, which is why dsbl.org gets almost all of them, but I'm wondering if I put spamhaus.org first, would it get more than dsbl.org gets now? On a slightly related note, I also virus-scan e-mail using clamav, but I've found that since the U of M installed its FortiGate firewall that also virus-scans e-mail, clamav doesn't seem to catch much other than some phising scams that they include signatures for. It does seem to be a bit quicker on the draw for new outbreaks, though, than the commercial AV scanners like FortiGate and Trend, so I find it's still helpful as an additional line of defense. Gilles -- Gilles R. Detillieux E-mail: <grdetil@scrc.umanitoba.ca> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada)
"Gilles" == Gilles Detillieux <grdetil@scrc.umanitoba.ca> writes:
>> On a related note, personally I'm strongly opposed to block >> lists since: a) they only work after spam has been sent Gilles> Sort of the same problem as signature based anti-virus, Gilles> anti-spyware, and even many content-based SPAM filters, as Gilles> well as DCC bulk mail filters. They all still help a Gilles> great deal against repeat offenders. Given the saturation Gilles> bombing approach many spammers still use, blocklists still Gilles> do help. They don't do much against spam attacks Gilles> distributed over wide botnets, but they still block a fair Gilles> bit. I suspect that the lists actually do pretty well even against the botnets, as the blocklist providers are grabbing IPs on the fly from monitors around the net. Some, such as the Spamhaus sbl-xbl list incorporate others, which are also composite lists. Information sharing is a good thing. Picking the last one out of my log, the XBL (exploit block list) dropped it because it was on the CBL list; this latter list only blocks single IPs, not ranges, in this case a bot-infected system in Malaysia. Since these lists are updated quickly, their timeliness is pretty decent. >> c) when other methods are applied properly, blocklists only >> improve results by a very small amount. "b" being the main >> reason I don't like them. John Gilles> Has anyone ever compared the effectiveness and accuracy of Gilles> the various DNS blocklists? I currently use these 3: Gilles> list.dsbl.org relays.ordb.org sbl.spamhaus.org Gilles> Of these, dsbl.org shows up in my logwatch summaries most Gilles> often, spamhaus.org occasionally, and ordb.org almost Gilles> never. I'm assuming sendmail runs the checks in the order Gilles> you list them, which is why dsbl.org gets almost all of Gilles> them, but I'm wondering if I put spamhaus.org first, would Gilles> it get more than dsbl.org gets now? I only set up the one, Spamhaus' sbl+xbl, but it drops the vast majority of garbage before other checks (now including greylist) or filtering are used. The SBL and XBL lists are different, so Spamhaus has an entry which lets you hit both with one query. SBL is basically the primary spammers, while the XBL list includes proxies, botnets and etc. Tim
"Tim" == Tim Lavoie <tim@fractaldragon.net> writes:
Tim> SBL is basically the primary spammers, while the XBL list Tim> includes proxies, botnets and etc. ======= *sigh* Apparently my typo filter is still needing some work.
On Fri, 2006-11-17 at 11:31 -0600, Gilles Detillieux wrote:
On 11/17/2006 10:49 AM, John Lange wrote:
On Fri, 2006-11-17 at 10:22 -0600, Tim Lavoie wrote: ...
So far, so good. No spam in the spambox this morning, at all. Most were caught by the Spamhaus DNS blocklist I already use, but the greylist whacked the remainder.
Would it not make sense to do it in the other order? Greylisting being much less CPU intensive than other spam blocking methods.
I didn't think DNS blocklists were particularly CPU intensive.
I suppose not but I was under the assumption that it had to do more than just a normal DNS lookup. Some of them do lookups based on email content, not just IP based blocking.
Has anyone ever compared the effectiveness and accuracy of the various DNS blocklists? I currently use these 3:
list.dsbl.org relays.ordb.org sbl.spamhaus.org
Since I ruled out using blocklists some time ago its possible things have improved (but I doubt it). For example, lets say there are some spam bots on an ISPs network. They send out spam relayed through the ISPs mail server. Does this not mean that the ISPs mail server will quickly find itself on a block list? If the answer is "no", then the blocklist isn't accomplishing anything since no spam is being blocked. If the answer is "Yes", then my issue is that thousands of innocent mail users on that ISP will be inconvenienced for absolutely no fault of their own. If on the other hand it is blocking based only on the actual IP of the machine doing the sending then in the short term it might be acceptable. However if the IPs don't expire automatically then you are simply back to blocking innocent people. This brings up another problem with block lists. What if you get a virus and your machine gets hijacked to send spam? Bingo you are on a blocklist and good luck getting removed especially since the average user is not likely to have any clue they are even on the list. Effectively you get double victimized. Not only does your computer likely have to be rebuilt but you can no longer send mail. Or in the case of an ISP, lets say they have a user with an insecure CGI on their web site. Somehow they are relaying mail and again you end up on a block list and its very hard to get off and at the same time everyone else using that machine for mail is victimized. And it is my understanding that the blocking is frequently done on entire subnets or even entire ISPs. Again, lots of innocent victims of this technique. Its just my personal opinion but I don't like that particular tactic since it has so many potential pitfalls and does so very little that can't be done with other methods. I have no doubt that its effective in reducing spam but just because something works doesn't make it the correct approach. For example we could eliminate all auto accidents by banning cars. Or more relevantly, here is your perfect spam filter: iptables -A INPUT --destination-port 25 -j DROP Guaranteed to eliminate 100% of your spam ;) John
There are a couple of steps which ISPs can do to minimize spam, and therefore the effects of the related blocking on their users. I'll use MTS as an example, mainly since I'm familiar with them as a customer. They seem to be pretty proactive, which happens to be something I like. First line of defense: offer software to at least try to block infections and other mischief. In this case, it's ZoneAlarm Suite, with firewall, anti-virus, anti-spyware and all the goodies. Restricting traffc in, out and what programs can run is an excellent first step. Sure, some folks won't install it, or will check "OK" every time they're prompted, but it will reduce the flow of malicious traffic within the ISP's own network. Second defense: Outbound SMTP has to go through their server, not direct from random, unpatched Windows boxes which are always on-line. Malware has started looking for these settings and using them as well, but it's a choke-point which allows for filtering at the protocol level. If they decide to do so, it also makes it easier to detect and cut access to infected systems to protect other customers. This would also cover email sent by way of web forms and the like. Third defense: There is some in-bound filtering, though I don't use that email account, so I can't attest to its effectiveness. The end result of this multi-level defense is that an entire ISP has reduced the chance that its IP range is going to be clobbered by blocklists. Good for the customer, good for the company. As a customer, I can be reasonably assured that my out-bound email won't be blocked, or if something happens, won't stay blocked for long. I'm sure other companies do the same, but obviously many don't. Tim
On 17 Nov, John Lange wrote:
b) they catch far to many innocent victims
"b" being the main reason I don't like them.
Hear hear! It causes me no end of grief with my clients -- all on dynamic IP's. Whatever happened to the freedome of the net where every "little guy" can have the same functionality as the "big guys". First MTS blocks SMTP, next they'll block HTTP, ...
On Fri, 2006-11-17 at 14:26 -0600, Tim Lavoie wrote:
There are a couple of steps which ISPs can do to minimize spam, and therefore the effects of the related blocking on their users.
[...]
The end result of this multi-level defense is that an entire ISP has reduced the chance that its IP range is going to be clobbered by blocklists.
I think this makes my point. You and your ISP have to do a lot of work and spend a lot of money (a great deal of it on 3rd party software) just to keep yourself (a non-spammer) off the various bock lists.
Good for the customer, good for the company. As a customer, I can be reasonably assured that my out-bound email won't be blocked,
But why should you ever be get blocked in the first place? Unless you are actually spamming you get caught up in this through no fault of your own and god help you if you or your ISP ends up on a block list.
or if something happens, won't stay blocked for long.
Again you are going to have to do a LOT of work to get yourself removed from these block lists. There are probably dozens of them and it will take weeks and weeks of effort. And if your email address ever gets hijacked for use in a FROM line you will never get off the black lists.
I'm sure other companies do the same, but obviously many don't.
Again, many many more legitimate emails blocked for no good reason. And not to open up a whole new can of worms but blocklists are wide open for abuse. Who owns them? Who decides who is on or off the list? There are examples of web site blocking software filtering out legitimate sites for political/religious reasons and email blocking is subject to the same potential for abuse. I think the intention and the concept of block lists are laudable but unfortunately in practical terms there is just too much collateral damage for very little gain. John
On 17 Nov, John Lange wrote:
For example, lets say there are some spam bots on an ISPs network. They send out spam relayed through the ISPs mail server. Does this not mean that the ISPs mail server will quickly find itself on a block list?
If the answer is "no", then the blocklist isn't accomplishing anything since no spam is being blocked.
If the answer is "Yes", then my issue is that thousands of innocent mail users on that ISP will be inconvenienced for absolutely no fault of their own.
The other day I ran into a "Yes" situation that was causing an ISP to completely block email from all of Shaw -- including Shaw's smarthost! The agressiveness and braindead-ness of servers and RBL's has been taken to an insane level. No one cares about false positives anymore.
This brings up another problem with block lists. What if you get a virus and your machine gets hijacked to send spam? Bingo you are on a blocklist and good luck getting removed especially since the average user is not likely to have any clue they are even on the list.
This happened all the time before the RBL's decided to block the entire Shaw/MTS dynamic IP space -- the greater of two evils.
And it is my understanding that the blocking is frequently done on entire subnets or even entire ISPs. Again, lots of innocent victims of this technique.
Yup.
iptables -A INPUT --destination-port 25 -j DROP
Guaranteed to eliminate 100% of your spam ;)
MTS's (dynamic-IP) approach!
On 17 Nov, Tim Lavoie wrote:
Second defense: Outbound SMTP has to go through their server, not direct from random, unpatched Windows boxes which are always on-line.
And not direct from random fully secured linux firewall boxes I manage which are not infected, never have been, and probably never will. They could make a case for blocking OUTBOUND SMTP, but why on earth do they need to block INBOUND SMTP!!! That has nothing to do with spam. That is a simple cash grab and screw-the-little-guy ploy to make someone running a tiny super low-volume micro-business server pay the exhorbitant static-IP address fees that, strangely, don't have SMTP blocked at all. Does that mean that people who have the dough to buy static IP's are any better at admin'ing their systems and not becoming bot zombies? The more important point is: today they block outbound SMTP. Then they block inbound SMTP. Tomorrow they block, what? HTTP? SSH? P2P? FTP? VNC? I don't know about you, but I don't want my ISP controlling what traffic I can send. Sure, penalize or drop me if I go over the prescribed GB/month limits, but don't censor me. Sure, you may love them blocking SMTP to limit the spam you get, but what happens when they block a port that is important to you? And I called them on it and made a formal complaint and they didn't give a rats ass. The best they could do is suggest I spoof incoming SMTP by using port 26 and a mail forwarder (which I had already done, but what a pain).
The end result of this multi-level defense is that an entire ISP has reduced the chance that its IP range is going to be clobbered by blocklists.
It's like government. Most functions should be pushed out to as low on the chain as possible. Aggregating functions up to the higher/highest level is usually counterproductive and inefficient in the end. In that sense it is my firm belief it is the individual mail server admins, or better yet the end users, who should have control over their anti-spam.
reasonably assured that my out-bound email won't be blocked, or if
And you can be reasonably assured that their overloaded mail servers will sometimes take hours to get your time-sensitive email out the queue. Shawmail often takes 12 hours+ to get mail through the smarthost. I'd much rather run my own mailserver, thank you.
"TC" == Trevor Cordes <trevor@tecnopolis.ca> writes:
TC> On 17 Nov, Tim Lavoie wrote: >> Second defense: Outbound SMTP has to go through their server, >> not direct from random, unpatched Windows boxes which are >> always on-line. TC> And not direct from random fully secured linux firewall boxes TC> I manage which are not infected, never have been, and probably TC> never will. True enough. For outbound SMTP, they provide an option in the mail host that is available. If performance or availability are suffering, that is indeed something they need to fix. Otherwise, it shouldn't be a problem. That's not to say that there are no problems, just that any which do occur should be fixed. TC> They could make a case for blocking OUTBOUND SMTP, but why on TC> earth do they need to block INBOUND SMTP!!! That has nothing TC> to do with spam. That is a simple cash grab and TC> screw-the-little-guy ploy to make someone running a tiny super TC> low-volume micro-business server pay the exhorbitant static-IP TC> address fees that, strangely, don't have SMTP blocked at all. TC> Does that mean that people who have the dough to buy static TC> IP's are any better at admin'ing their systems and not TC> becoming bot zombies? I suspect that those who are serious enough to get the static IP should be up to the task. Yes, the market catered to is different, and I would think that expectations of the customer are different as well. The choice to make IPs dynamic is a business one, not technical. The choice is yours to make as a customer whether that works for you. If not, go elsewhere. Unless you need hands on a physical box, there are tons of hosting setups which are reliable, inexpensive and are aimed at people hosting network applications. Terms of service will vary, but you can read that up front. For virtual servers, it's probably even easier for you to migrate to another provider if you aren't satisfied, since you aren't relying on a cable to a physical address. TC> The more important point is: today they block outbound SMTP. TC> Then they block inbound SMTP. Tomorrow they block, what? TC> HTTP? SSH? P2P? FTP? VNC? I don't know about you, but I TC> don't want my ISP controlling what traffic I can send. Sure, TC> penalize or drop me if I go over the prescribed GB/month TC> limits, but don't censor me. Oh, I'm not a censorship fan, and I do appreciate having everything as open as possible. Balance is vital, as always. Services are why customers come to your door. Security is also important, and cost is always a factor. I don't want to be restricted, but I sure wish that some fellow customers would get disconnected for being idiots. :) Tim
On 11/17/06, Gilles Detillieux <grdetil@scrc.umanitoba.ca> wrote:
b) they catch far to many innocent victims
Are there any credible stats on this? I've never spotted anything that looks like it might be a false positive in my server logs when I've checked. Of course, some of the claimed "innocent victims" are people
Just to add more anecdotal evidence to the pile, I've seen a lot of problems caused by DNS based blacklists - At a previous employer we got briefly blacklisted for having an open relay. Almost 2 years later I found a case where someone (a government agency) was using a copy of the blacklist from that era and was denying our mail (ok, so this technically wasn't a DNS based blacklist, but this was ~6 years ago!) - At a (different) previous employer we got put on a blacklist because our Antispam gateway was configured to autorespond and it responded to one of the addresses the blacklists uses to find spammers (I think it was spamcop). - At the same previous employer we configured our systems to return 4xx errors or reject addresses outright depending on what blacklist was hit and it caused problems for more than one innocent company Each case above involved some emails of importance to the business. Yes, using the lists was effective in dropping a lot of spam, but in one case I can remember on #3 it almost cost us a lot of business. Sean -- Sean Walberg <sean@ertw.com> http://ertw.com/
On 17 Nov, Tim Lavoie wrote:
The choice to make IPs dynamic is a business one, not technical. The choice is yours to make as a customer whether that works for you. If not, go elsewhere.
For many customers "going elsewhere" is not an option or I would have switched them all to Shaw ages ago. In many buildings MTS is the only option unless you want to pay Shaw $5000-$10000 to run a cable, which so far no one wants to do.
Unless you need hands on a physical box, there are tons of hosting setups which are reliable, inexpensive and are aimed at people hosting network applications.
Two problems: 1) control; 2) cost. No matter how inexpensive, you're still looking at adding $15-$25/month. When unfettered access to all ports (within bandwidth usage limits) should be free, why spend $250 more per year? And if you migrate off your email/web/etc services to a shared hosting service, you lose most of your control: control to do what you want with antispam, precise control over web application software, etc. It's the loss of freedom that irks me so much. 10 years ago the 'Net was touted as the "great equalizer", where every box on it was equal. Now they want to limit your activity and say: pay $10/mo for email hosting, pay $15/mo for web hosting, pay $20/mo for DNS hosting, pay $40/mo for static IP so you can do your own hosting; or what is truly the only way to have full control: pay $150+/mo for colocating a server.
On 11/18/06, Trevor Cordes <trevor@tecnopolis.ca> wrote:
Two problems: 1) control; 2) cost. No matter how inexpensive, you're still looking at adding $15-$25/month. When unfettered access to all ports (within bandwidth usage limits) should be free, why spend $250 more per year? And if you migrate off your email/web/etc services to a
That level of control isn't worth $250/yr? If not, you should question your need for those extra features. It's the loss of freedom that irks me so much. 10 years ago the 'Net
was touted as the "great equalizer", where every box on it was equal.
Rule #1 of the networks -- "My network, my rules". I count myself in the crowd that does it all myself. Half is because I like it, half is because I derive income from it so it's worth it to me. But the ability to do it myself off my $40/month cable modem is a privilege, not a right. If I couldn't, I'd go back to renting a VPS for $30/mo, because it doesn't have to be done on my box. Sean -- Sean Walberg <sean@ertw.com> http://ertw.com/
Trevor Cordes wrote:
It's the loss of freedom that irks me so much. 10 years ago the 'Net was touted as the "great equalizer", where every box on it was equal. Now they want to limit your activity and say: pay $10/mo for email hosting, pay $15/mo for web hosting, pay $20/mo for DNS hosting, pay $40/mo for static IP so you can do your own hosting; or what is truly the only way to have full control: pay $150+/mo for colocating a server.
I certainly understand where Trevor is coming from. On the other hand Internet access pricing is a balancing act. You want to make it affordable by the masses but you do have to make a profit. One can argue about what services you artificially limit and charge more for but with the current business model it seems inevitable that you are going to get the pricing environment that we have today. A blast from the past thanks to the Way Back machine. http://web.archive.org/web/19990117005122/www.mbnet.mb.ca/mbnet_rates.html 1998 (only eight years ago) MBnet was charging $3,999/month for a 3mbps connection. And this rate was very competitive! I am not that concerned with differential pricing between client and server but I am bugged by the asymmetric bandwidth model. This trend is being somewhat reversed but it is still very difficult to get reasonably priced upload bandwidth. -- Bill
On Sat, 2006-11-18 at 16:31 -0600, Sean Walberg wrote:
On 11/18/06, Trevor Cordes <trevor@tecnopolis.ca> wrote:
Two problems: 1) control; 2) cost. No matter how inexpensive, you're still looking at adding $15-$25/month. When unfettered access to all ports (within bandwidth usage limits) should be free, why spend $250 more per year? And if you migrate off your email/web/etc services to a
That level of control isn't worth $250/yr? If not, you should question your need for those extra features.
I don't in principle mind someone charging what the market will bear, rather than just a shade above marginal cost, but I don't much like it in a situation where my choice is limited. And of course, that's invariably where such pricing behaviour crops up. I think the level of competition that exists in network connectivity is qualitatively different from that which exists in other types of markets, say, retail coffee. Unregulated private network infrastructure results in either massive duplication or inadequate competition, and the cost excesses of both problems get passed along to consumers. Another difference between coffee and networks is that moving from one brand of coffee to another is relatively easy. The substitutability upon which real market competition depends is much more difficult to achieve for wired networks than other types of "products", I suspect. I sympathize with Trevor's complaint entirely. Regards, Syd
On 11/18/06, Sydney Weidman <syd@plug.ca> wrote:
I don't in principle mind someone charging what the market will bear, rather than just a shade above marginal cost, but I don't much like it in a situation where my choice is limited. And of course, that's
I'd agree, but we're comparing apples and oranges. Shaw and MTS provide residential service, or for a slight premium, "business" service. If you want wide open access to the Internet, you're asking for transit. It's merely a convenience that you can get some features of transit service on $40/month. Sean -- Sean Walberg <sean@ertw.com> http://ertw.com/
On Fri, 2006-11-17 at 10:12 -0600, Adam Thompson wrote:
One word of warning: the example greylist.pl is known to have several race conditions (file-locking bugs) that can corrupt the database. It's also fairly inefficient. Having said that, for low-volume mail servers it still works OK... generally its problems only show up under high volume. -Adam
Message received! After only a few days of running this script it is obvious that the included greylist.pl should not be used in production. It was returning signal 11 and stranding hundreds of perl processes not to mention it was causing postfix to bounce mail like crazy. It only works under very low volumes and your server never receives more than one email at a time. I have now switched to postgrey which is also berkeleyDB based but is recently maintained and has a few more advanced features which I like. So far so good but its only been running for less than an hour. John
participants (11)
-
Adam Thompson -
Bill Reid -
gedetil＠cs.umanitoba.ca -
Gilles Detillieux -
John Lange -
Sean Walberg -
Shawn Wallbridge -
Sydney Weidman -
Tim Lavoie -
Tim Lavoie -
Trevor Cordes