Re: SPF issues

[Theo Van Dinter <fe...@kluge.net>]

Note: I'm cc'ing this message to sa-users since it really ought to be a
public discussion IMO.  Since it came from a public discussion (bugzilla
ticket 3598), I figured you wouldn't mind.  If this is an issue, however,
I apologize ahead of time.

On Mon, Jul 12, 2004 at 11:07:38PM +0200, Al Smith wrote:
> You're right - it's not strictly a bug, however it's arguably incorrect 
> behaviour. SA flags the mail SPF_FAIL, which implies that I can either

Well, it's a matter of relativity.  On your MTA, mail from your domain
can be sent from anywhere if they use smtp authentication or generally
from your internal machines.  To everyone else on the planet, only people
sending from your appropriate servers should be valid.

These are 2 widely different situations, depending on where you query
from.  Since there is only 1 SPF record for both situations, you're very
likely to have issues with one of them.  Therefore a possible solution is
having differing records based on if the query is coming from "internal"
or "external" machines.

> I was hoping that SA could be able to recognise the fact that it's coming 
> from an SMTP auth'd connection and modify it's behaviour w.r.t SPF in that
> instance.

SMTP auth doesn't mean anything in terms of SPF though.  auth means
you're allowed to relay as a user, not that the mail you're relaying
through is valid.  I can do SMTP auth to my home machine and send mail
in from any address I want.


Ok, so aside from the discussion up above (SPF really is functioning
as it's supposed to in your case), the usual solution for this (MTA
level) would be to have the MTA check a list and stop on the first hit.
Something like: Local IP OK, SMTP Auth OK, SPF Fail FAIL, RBL FAIL,
accept OK.  Which conveniently bypasses this issue completely.  We don't
have anything like that in SA, instead usually relying on whatever calls
SA to decide if something needs to be scanned by SA.  So in your case,
I would have whatever calls SA figure out "hey, this was sent to us
directly via a valid SMTP AUTH connection, so skip scanning".  Which is
valid, unless you 1) are worried about your authenticated users sending
you spam, 2) are worried about your authenticated users forging mail to
you from other domains.  I think there are larger issues if 1 or 2 is
a concern though.

-- 
Randomly Generated Tagline:
"I have a simple test to determine if any windows executable that I
 received via E-mail is a virus or not: If I received it, it's a virus."
         - Charlie Watts on the SpamAssassin mailing list