It’s the second time this week now, that a quite big website uses a mailserver with DNS settings that do not resolve properly.

Why is that? In those two particular cases I don’t think the problem was ignorance concerning RFCs, but a wrong or yet not completely done configuration:

As an example: the host mail.example.com has an A-Record to the IP adrress 1.2.3.4 . And 1.2.3.4 has a correct reverse PTR entry for mail.example.com. BUT:
1.2.3.4 (well, because we are talking about reverse lookups here that is of course 4.3.2.1.in-addr.arpa) also has another PTR entry to mail.example2.com.
BUT: mail.example2.com does NOT have an A-Record that resolves to 1.2.3.4. In my cases it just didn’t have any A-Record.

So what happens is that the mailserver (in my case postfix) will do a reverse lookup of the IP. As a result it will get mail.example.com OR mail.example2.com randomly. If you specified reject_unknown_client_hostname it will try to match that result it got with the IP address the connect comes from doing a forward lookup.
Meaning: If the result of the first lookup was mail.example.com it will find a correct A-Record that resolves to the IP. All is fine.
But if the result of the first lookup was mail.example2.com it won’t find a matching a record and reject the email.

I find that really annoying. I mean, errors happen, but until now, only one of them has replied to my email containing information on the problem.

To everyone out there that has a mailserver: PLEASE configure your DNS entries properly ;)

For those who want to see what I mean live:

Try comspot.de or dataworld.de ;)

Dataworld.de has told me they will check the issue with their Administrators :) So if you find the error being corrected please tell me about it.

Since I’m using Thunderbird for my emailing I didn’t know about that problem. But one site I’m hosting recently has Emailusers that are using Microsoft’s Outlook Express 6 (The one that ships with XP).

What I didn’t know is that OE6 neither handles SSL handshakes correctly, nor is able to authenticate the user properly via SASL auth.

So you either get an error saying the server doesn’t support SSL, but you see the server’s reply code being ‘250 OK’.
Or you get an error depending on sender-, helo-, and recipient restrictions you’ve got. In my case I have implemented various checks concerning the hostname of the qualified client and of course RBL. Both will reject the ‘normal’ user connecting with OE6.
Normally, when the client authenticates himself none of the above mentioned checks will be done, and for that matter none of the authenticated clients will be blocked.

But if you’re using OE, you will be. (Is that actually a bad thing? ;) )

So I hope the solution I’m going to test later on is going to work:

For the SSL thing you can add ssl_wrapper_mode to postfix’s main.cf and connect on port 465. That SHOULD be working.

The SASL Auth thing should be fixed by adding ‘broken_sasl-auth_clients = yes’ to main.cf .

I’ll post here whether it worked or not.

As you may have read over the last few days on several internet news services such as eg. Tecchannel, Realtime Blackhole Lists like eg. Spamhaus are seeming to become less effective against spam.

What I read is that spammers have started to change their IPs very fast, which results in spam mails being more likely to falsely pass RBL Filters.

So what to do about it? There are several possibilitys. One is to use a tool like Spamassassin that can check the mailbody (and the links in it) against databases on the internet and/or their internal (learning) filter.

But I’m not quite convinced yet to use such a system. It’s not just the configuration that might be a little more complicated than eg. RBLs. What also scares me off a little is the maintaining effort. A system like that is very likely to have at least a few false positives, that have to be marked as such, so that the system can ‘learn’ from it. I don’t know yet whether I like that kind of a solution.

But what else is there?

Is Greylisting an answer?
How it works is basically that it at first refuses any email that someone is trying to send to your server with an error like a server misconfiguration error. The sender’s IP is stored then, and after a little while (say, something like 5 minutes), when (and if) the server tries to resend the message to you, it will be accepted and the sender will be added to a whitelist.

The hope in that is that spammers either won’t try to send the email again, or that those extra 5 minutes were enough for the spammers to be detected by services such as spamhaus.

The idea is good, and I think I will implement greylisting on my server and try it – also to see how many ‘real’ mailservers and (free)mailservices there are that also do not try to resend an email after a failure (that would be a false positive then).

Attention: WEIRD!! To attract some spammers for testing purposes, I’m just publishing another emailaddress:

stest@klappspaten.info

Since I’m trying out logcheck an logcheck-database (the etch packages) and SPF I had to add some lines for logcheck to ignore. However some of them are not really SPF related.

(weiterlesen…)