Bug 5907 - Inaccurate parsing of Received: headers
Summary: Inaccurate parsing of Received: headers
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (Eval Tests) (show other bugs)
Version: 3.2.4
Hardware: All All
: P5 minor
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-09 04:50 UTC by Pawel Sasin
Modified: 2009-10-21 23:19 UTC (History)
2 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status
msg1.eml - the first message mentioned application/x-extension-eml None Pawel Sasin [HasCLA]
msg2.eml - the second message mentioned application/x-extension-eml None Pawel Sasin [HasCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description Pawel Sasin 2008-05-09 04:50:54 UTC
I have 2 messages, they differ slightly:

# diff msg1.eml msg2.eml
4c4
< Received: from host-81-190-40-230.szczecin.mm.pl (HELO [192.168.0.136]) (sender@[81.190.40.230])
---
> Received: from host-81-190-40-230.szczecin.mm.pl (HELO localhost) (sender@[81.190.40.230])

With the first message the address 192.168.0.136 is beeing used as a relay and evaluated further, while with the second message the address 81.190.40.230 is beeing considered a relay. IMO this needs fixing.

# spamassassin -D < msg1.eml 2>&1 | grep -i "relay"
[...]
[8770] dbg: received-header: relay 192.168.0.136 trusted? no internal? no msa? no
[8770] dbg: metadata: X-Spam-Relays-Trusted: 
[8770] dbg: metadata: X-Spam-Relays-Untrusted: [ ip=192.168.0.136 rdns=HELO helo=host-81-190-40-230.szczecin.mm.pl by=smtp.domain.com ident= envfrom=sender@domain.com intl=0 id= auth= msa=0 ]
[8770] dbg: metadata: X-Spam-Relays-Internal: 
[8770] dbg: metadata: X-Spam-Relays-External: [ ip=192.168.0.136 rdns=HELO helo=host-81-190-40-230.szczecin.mm.pl by=smtp.domain.com ident= envfrom=sender@domain.com intl=0 id= auth= msa=0 ]
[8770] dbg: plugin: Mail::SpamAssassin::Plugin::RelayCountry=HASH(0x8a64348) implements 'extract_metadata', priority 0
[8770] dbg: metadata: X-Relay-Countries: **
[...]

# spamassassin -D < msg2.eml 2>&1 | grep -i "relay"
[...]
[10511] dbg: received-header: relay 81.190.40.230 trusted? no internal? no msa? no
[10511] dbg: metadata: X-Spam-Relays-Trusted: 
[10511] dbg: metadata: X-Spam-Relays-Untrusted: [ ip=81.190.40.230 rdns=host-81-190-40-230.szczecin.mm.pl helo=localhost by=smtp.domain.com ident=sender envfrom=sender@domain.com intl=0 id= auth= msa=0 ]
[10511] dbg: metadata: X-Spam-Relays-Internal: 
[10511] dbg: metadata: X-Spam-Relays-External: [ ip=81.190.40.230 rdns=host-81-190-40-230.szczecin.mm.pl helo=localhost by=smtp.domain.com ident=sender envfrom=sender@domain.com intl=0 id= auth= msa=0 ]
[10511] dbg: plugin: Mail::SpamAssassin::Plugin::RelayCountry=HASH(0x8a64378) implements 'extract_metadata', priority 0
[10511] dbg: metadata: X-Relay-Countries: PL
[...]
Comment 1 Pawel Sasin 2008-05-09 04:52:13 UTC
Created attachment 4314 [details]
msg1.eml - the first message mentioned
Comment 2 Pawel Sasin 2008-05-09 04:52:36 UTC
Created attachment 4315 [details]
msg2.eml - the second message mentioned
Comment 3 Adam Katz 2009-10-21 16:52:31 UTC
This appears to be a bug in your SMTP daemon ("WP-SMTPD"), for which I can't find much information.  It creates an improper(?) Received header that SA (and others) can't properly parse.

See also 
http://news.spamcop.net/pipermail/spamcop-help/2004-March/060041.html
http://forum.spamcop.net/forums/index.php?showtopic=1124
http://google.com/search?q=wp-smtpd

Reporter:  Can you give us any information on that daemon?
Comment 4 Pawel Sasin 2009-10-21 23:19:27 UTC
In the Received: header the sting after the HELO token is the string the client passed to the server at SMTP time. It can consist of any of these characters:

.@%+/=:-_#][
a-z
A-Z
0-9

If client passes anything else it is substituted by a '?' sign, so that you cannot fool the server with something like:

localhost) (envelope-sender addr@domain)

in the helo argument. The problem here is that the client used '[192.168.0.136]' as its helo argument and SA took it for a relay. It shouldn't.