Eskimo North

Dear Robert,

My post must have gone away with me blindly closing tabs in Firefox. I thought I'd sent it. Let me try to remember what I wrote...

You wrote:


I think a web mail system that felt and worked more like yahoo or hotmail would be a good feature.

With secure login, mail filtering and sorting, and a more graphically pleasing layout, it'd be a home away from home for members who're travelling, and could even become the primary interface for some. Certainly refugees from the many free e-mail services would find it more comfortable than the Squirrel Mail interface.

I'm sure there are other things you can offer. Hopefully some more ideas will come in...

Be well,

Mike D.

The problem with doing this is that Yahoo and Hotmail can do what they do because it is the exclusive interface for incoming mail, but mail here has shell mailers, imap, pop-3, and webmail, all of which have different methods of keeping address books, ect, and this makes it impossible to have a central location for defining filtering, etc.

To do this I'd pretty much have to create an entirely different mail structure with a domain name dedicated to it seperate from eskimo.com and eskimo.net.

I'd like to see better support for different spam filtering options. Right now, I have the choice of: 1) use the eskimo standard spam filtering; or 2) request no spam filtering, then have 300:1 ratio of spam to real email; 3) figure out something on my own.

I started at #1, but then started having problems receiving email from one of my primary email contacts at psnw.com (kept getting caught in eskimo's spam filters). So then I had to resort to #2, and that 300:1 ratio is only slightly exaggerated. Intermittently, I'd been pursuing #3, but not had much success (for example, when I asked for Bogofilter infrastructure to be setup on Eskimo).

In the end, I am fairly satisfied with the Procmail setup I copied from http://www.spambouncer.org. Now my spam-to-email ratio is perhaps 1:10, which is definitely tolerable. It took a long time for me to find that solution on my own, however. I'd gone for many months with practically unusable email.

How about transitioning some of your servers to Linux? There's a lot of software out there that could be used with no porting effort if we were on Linux rather than SunOS.

Sort of on the same topic, some speed bumps would be nice, too. Even something as simple as the text-based mutt email client seems to run much slower on Eskimo than it runs on my 1.8GHz P4 desktop PC.

Most of the non-shell servers (web, file, mail, etc.) are running Linux, and plans are to eventually have the shells on Linux with SunOS emulation.

#3 has also been available all along as both procmail and elm filtering. Samples can be seen on the Email Settings page linked on the home page.

Please do not bounce or auto-reply to spams, as that both (a) only verifies to non-forging spammers that your address is valid, causing more to appear, and (b) often causes a loop when forged-addresses bounce back and get bounced themselves, etc.

It's a constant battle between accepting legit email and blocking bogus email, and spammers always cross the lines in the sand. As Joe Bob Briggs would say, "Without eternal vigilance, it could happen here."

But creating a .procmailrc that can successfully filter out most of the spam is really difficult. I'm suggesting that Eskimo should provide a starter .procmailrc (like the one I got from spambouncer.org) to get users started. And to explain how to set up commands for adding false positives and negatives into one's whitelists/blacklists.

Spambouncer's instructions were barely below my pain threshhold for learning curve. I got it working in about 2-4 hours. I'm pretty Unix-fluent, though... I suspect most Eskimo customers would never get that setup going.

I would argue that anything that requires the user to spend over an hour researching and/or configuring is not really being "provided" by Eskimo as a service. Eskimo only provided infrastructure which allowed me to implement a solution if I took the initiative to figure one out.

As a former elm user, I'm familiar with elmfilter. The tactics used by spammers today have totally overwhelmed elmfilter's ability to deal with spam attacks.

I did consult the aforementioned URL prior to setting up Spambouncer. The only really good info there is the special instructions regarding .forward. That info should be highlighted in bold since no one will be able to get any procmail solution going if they fail to notice that.


No worries there... the "bounce" part of Spambouncer's name is a misnomer. Autoreplies are disable by default. The functionality is put there for service providers who are implementing Spambouncer on a system-wide basis to generate those "I'm rejecting your email as spam" messages like Eskimo is currently getting from Comcast.

My personal setup has that feature disabled. I am only passively filtering email.

Now that I'm convinced I have Eskimo's ear, I would again humbly request that you install Bogofilter or some other solution that utilizes a spam learning algorithm (Bayesian, or otherwise). I am manually managing my supplemental blacklist, but as you probably realize, the spammers who get through my first line of defense don't really have header info that I can reliably target for future spam.

Thanks for the tip on spambouncer. Dealing with spam is always a little frustrating.

This last summer I had to opt out of Eskimo's filtering as they were blocking too many legitimate messages. Which was too bad because I had been happy with the filtering up to that point. But then my spam jumped incredibly and I had to get smarter on my filters fast.

My primary filter is one that blocks messages outside of the North american timezone. Someone posted it on Lobby a while back and it has been a lifesaver. Blocks 2/3 of spam.
:0
* !^Date:.*-(0[5-9]00|1000)
/$MAILDIR/timezone

I actually have it just go to /dev/null. If you need to get mail from specific countires outside of the US I would advise still using this filter and just putting in the timezones you need. It catches way too much garbage not to use.

Being in the mountaineers I get a lot of e-mail from a wide variety of domains. I parsed all the legitimate mail I could put together and made a list of legitimate domains. Then I made a filter that captures all the mail that is not in a known good domain. That filter catches 2/3 of my remaining spam. I can't /dev/null that filter because it might catch a legitimate message but I just go through once or twice a month and look for good messages and dump the rest. The nice thing about this filter is that if it ever catches legitimate mail I just add the domain in the list and the filter is immediately updated.

Of course I do the usual whitlelist/blacklist. A blacklist is only usefull for the rare spammer that keeps sending from the same address. I also blacklist IP addresses that seem to be prolific spam domains. I also blacklist domains that have sent me a lot of spam and never sent a legitimate message.

I have a filter that catches mail that doesn't have my e-mail address in the TO or CC line. I used to /dev/null those messages but occaisionally someone will send actual e-mail to a group of people that will get caught by that filter.
:0
* !^To:.*alpinist
* !^Cc:.*alpinist
$MAILDIR/notTO

I also filter out messages that are from daemons.
:0:
* ^FROM_DAEMON
$MAILDIR/daemon

You have to check this when sending to new e-mail addresses as your bounced messages will be caught by this filter. This filter catches bounced messages that are a result of people spoofing your e-mail address. Messages in this filter are likely to have viruses in them.

Right now there are still some infrastructure issues that make a secure login possible. We need to get the main web server SSL enabled for that and owing to some library issues that has been problematic. But we're slowly working on it between things blowing up.

That's good to know, Robert.

I agree, too, with the comments above on improved support for user-controlled spam filtering. I had to opt out of the domain-level filtering because some of my list members couldn't reach me at all. Basic filtering with whitelisting would improve things for me.

Some of the options discussed here are on my list of things to look at and try, but having one that's encouraged and supported would be nice. Sad to say, procmail filters are still daunting to me. <sigh>

Thanks for all the hard work.

Be well,

Mike D.

Hey! We finally made it to the promised land 2 years later Well, sans SunOS emulation, anyhow.

I'm unhappy with the "Sans SunOS Emulation" part, and there are still a few serious gotchas I'm working on, but yes, there is now a Linux shell server at shell.eskimo.com.

Problems I'm having, the "MASQUERADE_AS" and other masquerade functions in sendmail don't seem to work on that platform. Yet, I compile the exact same source code on Redhat 6.2 and they work.

Telnet and rlogin don't work right. I managed to get telnet to work with 4.3 telnet clients but still not with 4.2 clients and I haven't been able to figure out why. The only public source I can find for rlogin/telnet clients that work with Unix98 ptys is what is already there. The BSD versions require BSD ptys which aren't presently compiled into the kernel. And, compiling a Sparc kernel with anything but the default configuration is proving to be a major nightmare on account of the fact that dependencies are serious broken in the recent 2.6 kernels.

I am trying to load FreeBSD on a machine and play with that since SunOS emulation is still supported; not going to get rid of the new Linux server, but may turn up a second new shell server operating under FreeBSD to support SunOS applications, some of which I still need.