Verify fake header

Steve Freegard steve.freegard at
Sun Oct 26 14:54:52 GMT 2008

Hugo van der Kooij wrote:
> Hash: SHA1
> Hi,
> To the best of my knowledge this header should never occur on any valid
> message:
> 	X-AntiAbuse: Sender Address Domain - VANDERKOOIJ.ORG
> The whole header set is:
> Received: from ( [])
>      by (Postfix) with ESMTP id 5DEF617E8050
>      for <hvdkooij at VANDERKOOIJ.ORG>; Sat, 25 Oct 2008 10:41:59 +0200 (CEST)
> Received: from [] (
>      by with esmtpa (Exim 4.69)
>      (envelope-from <hvdkooij at VANDERKOOIJ.ORG>)
>      id 1KteiY-0006T2-K4
>      for hvdkooij at VANDERKOOIJ.ORG; Sat, 25 Oct 2008 12:41:57 +0400
> To: hvdkooij at VANDERKOOIJ.ORG
> From: hvdkooij at VANDERKOOIJ.ORG
> Subject: ÏÑÏÔÉ ÌÏíÏÉ ÈÕ æÔæÝ - Come and See
> Content-Type: text/html; charset=windows-1256"
> X-AntiAbuse: This header was added to track abuse, please include it
> with any abuse report
> X-AntiAbuse: Primary Hostname -
> X-AntiAbuse: Original Domain -
> X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
> X-AntiAbuse: Sender Address Domain - VANDERKOOIJ.ORG
> Message-Id: <20081025084203.5DEF617E8050 at>
> Date: Sat, 25 Oct 2008 10:41:59 +0200 (CEST)
> Does anyone know a check to tackle these fakes in a more generic way?
> That host is not listed in my SPF information so given that knowlegde it
> should be clear that is not allowed to do this for
> my domain

You've configured SPF srictly using -all, but you're aren't enforcing 
this in your inbound MTAs for your domain.  If you had done so, then you 
wouldn't have even seen this message, so it would have been a moot point 
and we wouldn't be having this conversation.  Isn't that one of the main 
points of SPF?

I guess your argument is that the sender should have done more to 
prevent the emission of the message in the first place.  I agree - but 
that's the whole problem with spam; it's all because people aren't 
careful enough.

MTAs are way to generous currently - if you allow a client RELAY 
permissions, then it allow clients to do pretty much anything.  You want 
to send a mail with an envelope from 'billg at'; no problemo 
- the assumption by MTAs is that RELAY permissions imply that they are 
being used as a smart host.

SMTP AUTH can help, but there are plenty of bots that can capture AUTH 
credentials and use them - but the problem persists for AUTH hosts too; 
they are allowed the same wide-ranging RELAY permissions and can send as 
anyone to anywhere.

MTAs should evolve with new access controls that limit RELAY permissions 
to only allow envelope-sender domains to a limited list of domains 
controlled by the administrator.  At FSL we did this by only allowing 
domains outbound that we accepted inbound - anything else would get a 
'relay denied' rejection.  This isn't 100% optimal especially on a large 
site but it's an easy way to get this up and running quickly.

This is a great way to be able to identify and reject outbound junk 
quickly and at low cost before applying other filtering.

That's my opinion anyway.


More information about the MailScanner mailing list