Entries tagged exim4

For the past couple of days I've been working on some "easy hosting" setup for Debian. This is a continuation of my shell-script based solution, but intended to be much more dynamic.

The system makes it simple for us to deploy a Debian Etch installation, and allow users to create virtualhosts easily. (And by easily I mean by creating directories, and very little else.)

So, for example, to create a new website simple point the IP address of your domain example.org to the IP of your machine. Then run:

mkdir -p /srv/example.com/cgi-bin
mkdir -p /srv/example.com/htdocs

If you then want to allow FTP access to upload you may run:

echo "mysecretpass" > /srv/example.com/ftp-password

This will give you FTP access, username "example.com", password "mysecretpass". You'll be chrooted into the /srv/example.com/ directory.

All of this is trivial. Via Apache's mod_vhost_alias, and a simple script to split logfiles and generate statistics via webalizer for each domain. The only thing that I really needed to do was to come up with a simple shell script & cron entry to build up an FTP password file for pure-ftpd.

So here's where it gets interesting. The next job, obviously, is to handle mail for the domains. Under Debian it should be a matter of creating an appropriate /etc/exim/exim4.conf - and ignoring the rest of the setup.

I'm getting some help with that, because despite knowing almost too much about SMTP these days I'm still a little hazy on Exim4 configuration.

I'm watching the recent debian configuration packages system with interest, because right now I'm not touching any configuration files I'm sure that it is only a matter of time.

In other news I cut prices, and am seeing a lot of interest in my mail-scanning.

Finally my .emacs file has been tweaked a lot over the previous few days. Far too much fun. (support files.)

Tags: apache2, exim4, mail-scanning, pure-ftpd, virtual hosting | 2 comments

So, I've just got a portable machine. I've configured it to be a pretty minimal installation of Debian Lenny, but one thing that makes me unhappy is mail handling.

By default it came with several exim4- packages. Now in general Exim4 rocks. But it is a deamon running all the time, and overhead I could live without.

I looked around to find a mail transport agent that would be more suited to the machine and was suprised to find nothing suitable.

Basically I figure the machine will never generate "real" emails. Instead it will only receive mails from cron, etc. The machine will never have a real fixed IP, and so relaying mail externally is a waste of time. The mail should just go somewhere predictable and local.

There are a couple of lightweight agents which will forward to another system, but nothing seems to exist which will queue mail locally only.

So I've hacked a simple script which will do the job.

Given the spool director /var/spool/skxmail the following command:

skxmail root < /etc/passwd

Produces this:

/var/spool/skxmail/
`-- root
    |-- cur
    |-- new
    |   `-- 1227702470.P8218M243303Q22.vain.my.flat
    `-- tmp

4 directories, 1 file

That seems to be sufficient for my needs. (I support the flag which says "read the receipient from the body).

Of course to do this properly I'd be setgid(mailgroup). Instead I assume that local means everybody can see it and /var/spool/skxmail is mode 777. Ooops.

Still happy to share if it sounds interesting.

ObFilm: Dogma

Tags: debian, exim4, skxmail, smtp | 8 comments

I've successfully upgraded my primary web/mail/misc host from Debian Etch to Debian Lenny. There were a few minor problems, but on the whole the upgrade was as painless as I've come to expect.

In the past I'd edited my Exim4 configuration to add quite a few ACL checks, for example rejecting mails based upon spoofed/bogus HELO identifiers, and rejecting messages that didn't contain "Subject" or "Date" headers.

The Debian Exim4 configuration may be split into multiple files (which is how I prefer it on the whole). The idea that you just add new files into the existing hierarchy and they'll magically appear in the correct location when a real configuration file is generated. On the whole this works well, but sometimes editing files in-place is required, and it was these local edits that caused me pain.

Fixing things up was mostly not a challenge, primarily it was a matter of removing ACLs until exim4 started without errors - all my spam checking is handled ahead of exim4 these days, except for the last-ditch spam filtering with a combination of procmail-fu and the crm114 classifier package.

Taking a hint from Bubulle's weblog I decided to nuke my CRM114 spam database to avoid any possible version-mismatch issues so now I'm having to classify a lot of "unsure" messages. Happily my memory of doing this last time round is that the initial training of spam/ham takes a day or so to complete.

Anyway now I can start looking to advantage of the things new to Lenny. But probably not until I'm sure things have calmed down and upgraded correctly.

steve@skx:~$ uptime
 05:00:31 up 260 days, 14:23,  2 users,  load average: 0.95, 0.51, 0.31
steve@skx:~$ cat /etc/issue
Debian GNU/Linux 5.0 \n \l

ObFilm: Bill & Ted's Excellent Adventure

Tags: crm114, etch, exim4, lenny | No comments

Recently I noticed a report of an alleged remote root security compromise of a machine, via the exim mailserver.

At the time I wasn't sure how seriously to take it, but I followed updates on the thread and it soon became clear that there was a major problem on our hands.

It later became obvious that there were two problems:

CVE-2010-4344

A remote buffer overflow, allowing the execution of arbitrary code as the user Debian-exim.

CVE-2010-4345

A privilege escelation allowing the attacker to jump from running code as Debian-exim to running code as root.

Trivial exploits are floating around the internet - and we were seeing this bug be exploited in the wild as early as yesterday afternoon.

Although I can feel somewhat smug that my own personal server is running qpsmtpd ahead of exim it's still a wake-up call, and this hole has the potential to significantly expand available botnets - it is probably only a matter of days hours until we see worms taking advantage of the flaw.

ObPlug: I've put together an updated version of exim4 for etch - if you're still running etch then you don't have any official security support (timely upgrading is obviously preferred) and it might be useful to have more folk pointed at that..

ObQuote: "We're all going to die down here" - Resident Evil.

Tags: compromises, exim, exim4, security | 7 comments

I've shuffled around all the repositories which are associated with the blogspam service, such that they're all in the same place and refer to each other correctly:

• https://github.com/BlogSpam-net/

Otherwise I've done a bit of tidying up on virtual machines, and I'm just about to drop the use of qpsmtpd for handling my email. I've used the (perl-based) qpsmtpd project for many years, and documented how my system works in a "book":

• https://book.mail-scanning.com/

I'll be switching to pure exim4-based setup later today, and we'll see what that does. So far today I've received over five thousand spam emails:

  steve@ssh /spam/today $ find . -type f | wc -l
  5731

Looking more closely though over half of these rejections are "dictionary attacks", so they're not SPAM I'd see if I dropped the qpsmtpd-layer. Here's a sample log entry (for a mail that was both rejected at SMTP-time by qpsmtpd and archived to disc in case of error):

   {"from":"<[email protected]>",
    "helo":"adrian-monk-v3.ics.uci.edu",
    "reason":"Mail for juha not accepted at steve.fi",
    "filename":"1512284907.P26574M119173Q0.ssh.steve.org.uk.steve.fi",
    "subject":"Viagra Professional. Beyond compare. Buy at our shop.",
    "ip":"2a00:6d40:60:814e::1",
    "message-id":"<[email protected]>",
    "recipient":"[email protected]",
    "host":"Unknown"}

I suspect that with procmail piping to crm114, and a beefed up spam-checking configuration for exim4 I'll not see a significant difference and I'll have removed something non-standard. For what it is worth over 75% of the remaining junk which was rejected at SMTP-time has been rejected via DNS-blacklists. So again exim4 will take care of that for me.

If it turns out that I'm getting inundated with junk-mail I'll revert this, but I suspect that it'll all be fine.

Tags: blogspam, exim4, github, mail-scanning, perl, qpsmtpd | 1 comment