Mike`s Blog - Hosting

Sender Policy Framework (SPF)

info@mhaller.de (Mike Haller) — Sun, 17 Aug 2008 15:51:38 +0200

A few weeks ago I wanted to make all my hosted domains SPF-enabled. Sender Policy Framework is a great way to prevent forged mails. With SPF, mail servers check whether a mail is allowed to be sent by a specific server.

I'm going to be restrictive here and only allow our mail server to send mails from our hosted domains. This will for example stop spam from sdfjnsd@mydomain.com to mike@mydomain.com. Of course, that's not the only thing which will be made a lot harder for spammers. The domain itself is protected much better and spammers seem to refuse misusing domains with SPF information.

Before activating it on all life domains, I took a private domain to test the configuration with. I changed the domain name server zone file for mhaller.de to contain the following TXT resource record:

Continue reading "Sender Policy Framework (SPF)"

VirtueMart Saferpay

info@mhaller.de (Mike Haller) — Sun, 17 Feb 2008 11:58:33 +0100

Today I released v1.0.0 of the E-Payment module Saferpay for VirtueMart 1.0.x. Hopefully it's of help for people who want to integrate the swiss E-Payment solution provider into their VirtueMart shops.

== <> eq

info@mhaller.de (Mike Haller) — Sat, 02 Feb 2008 10:23:00 +0100

A customer requested to disable all spam filter rules for his accounts. He suspected to miss mails, so he really wanted us to switch off all filters for his accounts.

To implement that within short time, I decided to change the maildrop filter script /etc/courier/maildroprc. I added the following snippet.

# Disable all filters for customer XYZ
if ( $HOST == "example.org" )
{
  log "All filters disabled"
  to $DEFAULT
  exit
}
else
{
  log "Normal filtering rules apply"
}

Well, this snippet does not work as expected. It will always jump into the first case "All filter disabled". As the maildroprc is the general script, which is applied for all incoming mails, the spam filters were disabled practically for all customers. After half a day, my own spam trap account was already fully and couldn't hold any more spam.

So what was going wrong? I read through the courier documentation and found it: == is a numerical comparison. Text comparison must be done using eq. I should have known it better, as I'm a Java Developer. I have never seen any maildroprc example script using eq, so I didn't expect bash-like expressions in there.

The correct snippet:

# Disable all filters for customer XYZ
if ( $HOST eq "example.org" )
{
  log "All filters disabled"
  to $DEFAULT
  exit
}
else
{
  log "Normal filtering rules apply"
}

P.S.: My servers are, hours later, still working on filtering the spam again which was queued. I've got a dedicated machine for running Spamassassin workers, and it's load is .. well high enough.

Exceeding mail quota

info@mhaller.de (Mike Haller) — Fri, 28 Dec 2007 17:51:00 +0100

One of my customers of my hosting business called me and was really upset. He wasn't receiving any emails any more. I checked the system, the mailserver and the logs and could not find a problem on our site. Then, i checked the customers email accounts manually. He exceeded his quota on his main email account info@foo.bar (i mention that, because it's a catch-all account and thus receives a lot of spam).

I told him that his quota was exceeded and he has to delete old mails to make room for new ones. Unfortunately, he already did that quite regularly. After a talk with the "tech-guy" of the customer, the cause of the problem became pretty obvious: the customer had his own mailserver, which uses fetchmail to gather mails from our mailserver. Our mailserver automatically moves high-level spam into a subfolder of the users mail inbox: "Inbox\Junk". His fetchmail is not configured to retrieve subfolders, so only the inbox was cleared, the Junk folder became bigger and bigger and finally filled the box up to the quota limit.

The user was unaware of that little technical detail, as he also has a "Junk" folder in his mailer application and it was empty according to him.

I solved the problem by automatically deleting mails in the Junk folder which are older than 2 weeks using a simple cron job:

#!/bin/bash

find /var/spool/mail -name ".Junk" -type d | \

xargs -I "%" find % -type f -mtime 14

Mailserver cleanup

info@mhaller.de (Mike Haller) — Wed, 21 Nov 2007 18:24:12 +0100

I used my free time today to clean up my server and to work on some issues I planned for some time. My mailserver setup had served 300000 mails in the last three days (that's one mail per second).

Continue reading "Mailserver cleanup"

MySQL's case-sensitivity

info@mhaller.de (Mike Haller) — Sat, 30 Dec 2006 00:00:00 +0100

Yesterday, we transferred the database of a custgomer from his Windows machine to our linux-based database server. At the same time, we wanted to get this administration frontend working again. It was also deployed on that Windows machine, running on a Sun Application Server against the local MySQL database.

The problem with MySQL is, besides some other issues, that it is case-sensitive. Yes, MySQL treates database and table names case-sensitive if it runs on a case-sensitive file system. Hence, copying the database from a Windows machine to a Linux machine by exporting and reimporting created mixed-case mysql data files. Hence, the applications who access this database only used lower-case names. The SQL standard clearly states that identifiers are not case-sensitive. MySQL breaks that. There is a configuration parameter which makes mysql do auto-conversion. It will then automatically lower-case tablenames in the SQL statements.

However, it is not a good idea to do that with existing databases as this will break existing applications. Mysql won't find the files which are already mixed-case any more.

So, we needed to set up a second mysql instance with the case-sensitivity configuration parameter set to the value 1. That means, it will lower-case all tablenames and filenames automatically (on creation and within SQL statements).

To start a second mysql instance on a Gentoo-based system, edit /etc/conf.d/mysql

mysql_slot_0=() mysql_slot_0_1=( "mycnf=/etc/mysql/my_second.cnf" "server-id=3" "port=3307" )

The my_second.cnf contains the configuration parameter:

[mysqld] ... set-variable=lower_case_table_names=1 ...

Now, import your existing backup into the second mysql instance. You should probably use the --host and --port parameters, so your data won't accidently being imported into your primary mysql installation. Specify 127.0.0.1 instead of localhost if he still connects to the primary instance.