Sender Policy Framework (SPF)

Posted by Mike Haller on Sunday, August 17. 2008 at 15:51 in Hosting

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:

VirtueMart Saferpay

Posted by Mike Haller on Sunday, February 17. 2008 at 11:58 in Hosting
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

Posted by Mike Haller on Saturday, February 2. 2008 at 10:23 in Hosting
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

Posted by Mike Haller on Friday, December 28. 2007 at 17:51 in Hosting
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

Posted by Mike Haller on Wednesday, November 21. 2007 at 18:24 in Hosting
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).

About

My name is Mike Haller and I'm a software developer and architect at Innovations Software Technology in Germany. I love programming, playing games and reading books. I like good food, making photos and learning and mentoring about the craftsmanship of commercial software development.

Quicksearch

Archives