Verify fake header

[Steve Freegard]

Hugo van der Kooij wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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 host01.nabdhserv.net (nabdhserv.net [75.126.218.58])
>      by balin.waakhond.net (Postfix) with ESMTP id 5DEF617E8050
>      for <hvdkooij at VANDERKOOIJ.ORG>; Sat, 25 Oct 2008 10:41:59 +0200 (CEST)
> Received: from [82.178.213.148] (helo=gmail.com)
>      by host01.nabdhserv.net 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 - host01.nabdhserv.net
> X-AntiAbuse: Original Domain - vanderkooij.org
> X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
> X-AntiAbuse: Sender Address Domain - VANDERKOOIJ.ORG
> Message-Id: <20081025084203.5DEF617E8050 at balin.waakhond.net>
> 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 host01.nabdhserv.net is not allowed to do this for
> my domain vanderkooij.org

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 microsoft.com'; 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.

Cheers,
Steve.