Bug 3962 - SPF check fails for roaming users
Summary: SPF check fails for roaming users
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Plugins (show other bugs)
Version: 3.0.1
Hardware: Other other
: P5 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on: 2462
Blocks:
  Show dependency tree
 
Reported: 2004-11-09 12:45 UTC by Arjen de Korte
Modified: 2004-12-15 04:49 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Arjen de Korte 2004-11-09 12:45:59 UTC 
For systems employing SPF which have 'roaming' users (connecting back to their 
'home' mailserver via SMTP AUTH), the SPF check gives a SPF_FAIL result with a 
sufficiently strict SPF record. The first hop from the roaming user to the 
home mailserver will generally not be authorized to send out e-mail on behalf 
of the SPF enabled domain. The home mailserver may still allow mail relay, as 
it can have a different means of authenticating the client. The latter is 
however lost further on and when SpamAssassin evaluates the chain of systems 
from untrusted networks, it will do so including this first hop. This is 
wrong. 
 
The correct way to evaluate SPF would be to stop processing when a system is 
found that does evaluate to anything except SPF_FAIL. From this point (which 
should be regarded as the 'injectionpoint') down to the first hop is 
irrelevant in terms of SPF. There can be several systems between the 
injectionpoint and the first hop, which use different methods of authorizing 
mail relay. SPF has no meaning there. 
 
As an example, the following "Received:" lines: 
 
Received: from localhost (localhost [127.0.0.1]) 
	by mail.de-korte.org (Postfix) with ESMTP id 52F3F60328 
	for <MUNGED@de-korte.org>; Wed,  3 Nov 2004 14:35:32 +0100 (CET) 
Received: from mail.de-korte.org (localhost [127.0.0.1]) 
	by localhost (AvMailGate-2.0.2-9) id 07732-0140F736; 
	Wed, 03 Nov 2004 14:35:31 +0100 
Received: from [10.0.0.2] (ip51cfcd61.direct-adsl.nl [81.207.205.97]) 
        by mail.de-korte.org (Postfix) with ESMTP id 124B160328 
        for <MUNGED@de-korte.org>; Wed,  3 Nov 2004 14:35:30 +0100 (CET) 
 
To keep you all from looking up the SPF record for 'de-korte.org', the 
(multihomed) system 'mail.de-korte.org' is the one and only system allowed by 
SPF to send mail on behalf of the 'de-korte.org' domain. However, the person 
on ip51cfcd61.direct-adsl.nl may connect to this system via SMTP AUTH and is 
allowed then to relay mail through that server. Yet it will give SPF_FAIL with 
SpamAssassin, as it is not in the list of trusted_networks.
Comment 1 Daryl C. W. O'Shea 2004-12-02 20:52:12 UTC 
Checking the trusted headers to see if they 'match the SPF record' of the sender
would indeed prevent the SPF_FAIL result.  However, given that the remote user
is authenticated there is no reason to do an SPF check at all, as we can simply
extend the trust boundary.

Bug 2462 resolves this issue.
Comment 2 Justin Mason 2004-12-15 13:49:34 UTC 
yep bug 2462 is the fix for this, now applied; by detecting valid authentication
using SMTP AUTH et al, we avoid this error on "injection" servers.

this should therefore now be fixed in SVN.  please reopen (with a sample message
attachment) if not...