[dev] IMP message header triggering spamassassin

[Roel Gloudemans]

I found a problem with IMP. When I send a mail using the IMP 
installation at my company from home; the Received header of the mail 
looks like this:

* from smtp.gloudemans.info ([unix socket]) by mail.gloudemans.info 
(Cyrus v2.2.12-Invoca-RPM-2.2.12-1.1.fc3) with LMTPA; Sat, 30 Apr 2005 
13:45:18 +0200
* from mail.i-to-i.nl (www.i-to-i.nl [194.171.50.70]) by 
smtp.gloudemans.info (Postfix) with ESMTP id 851EF6B80B8 for 
<destination at address>; Sat, 30 Apr 2005 13:45:16 +0200 (CEST)
* from i-to-i.nl (saratoga [127.0.0.1]) by mail.i-to-i.nl (Postfix) 
with ESMTP id A526F24C781 for <destination at address>; Sat, 30 Apr 2005 
13:43:47 +0200 (CEST)
* from dslam105-189-166-62.adsl.versatel.nl 
(dslam105-189-166-62.adsl.versatel.nl [62.166.189.105]) by la.i-to-i.nl 
(Horde MIME library) with HTTP for <sender at address>; Sat, 30 Apr 2005 
13:43:47 +0200

The first hop is set by IMP. It shows the originating client. Since 
this is a dynamic ISP address, spamassassin reports the following:

spam, SpamAssassin (score=6.79, required 6, BAYES_00 -2.60, 
HELO_DYNAMIC_DHCP 1.25, HELO_DYNAMIC_HCC 3.74, HELO_DYNAMIC_IPADDR 4.40)

It assumes the message is spam, because it originated from a dynamic IP 
address. When I tweak the Horde code to make the last line look like

* from mail.i-to-i.nl (dslam105-189-166-62.adsl.versatel.nl 
[62.166.189.105]) by la.i-to-i.nl (Horde MIME library) with HTTP for 
<destination at address>; Sat, 30 Apr 2005 14:17:46 +0200

Spamassassin has no problems with it.

This behavoir is not good. It means that mail sent via Horde/IMP by 
users using their own internet connections will be rejected 
structurally as spam on some (or even a lot of) mailservers.

One could argue that this is a spamassassin problem (I've seen this pop 
up on the spamassassin list), but I've also gotten reports that mail is 
misqualified as spam from other non-spamassassin servers.

What would be a good way to avoid these problems?

One way is for IMP to not set this header. A normal thick client 
doesn't set it. It only reports the user agent. (One could even argue 
that setting this header reveals too much information; like where the 
send is at the moment)

Another way is to tweak the header like in my example.

Cheers,
Roel.