You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Rob Arista <ar...@gmail.com> on 2011/04/16 16:36:36 UTC

How to add a Received-Spf header?

Hey.

I'm doing SPF checking in Spamassassin.  I read the logs ans see the
tests done.  And I get scores in the X-Spam-Report headers.

I can't see how to get SA to add a 'Received-Spf' like described here,
to use it further downstream:

http://www.openspf.org/SPF_Received_Header

The following key-value pairs are designed for later machine parsing.
SPF clients SHOULD give enough information so that the SPF results can
be verified. That is, at least "client-ip", "helo", and, if the "MAIL
FROM" identity was checked, "envelope-from".
...
Here is an example:

    Received-SPF: Pass (example.org: domain of scott@kitterman.com
        designates 72.81.252.18 as permitted sender)
        receiver=example.org; client-ip=72.81.252.18;
        envelope-from=<sc...@kitterman.com>; helo=mailout00.controlledmail.com;

How do I instruct SA to add that specific header & info?

--Bob

Re: How to add a Received-Spf header?

Posted by RW <rw...@googlemail.com>.
On Sat, 16 Apr 2011 11:06:20 -0400
darxus@chaosreigns.com wrote:

> It would be nice if SA could then use this header instead of checking
> SPF again itself, ...

Have you any reason to think it can't?


perldoc Mail::SpamAssassin::Plugin::SPF

Re: SPF fail when SPF record looks good

Posted by a....@ukgrid.net.
Quoting a.smith@ukgrid.net:

> Hi,
>
>   I just noticed this, I have an email which was marked as spam. One  
> of the rules it flagged was:
>
> 0.7 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
>
> In the headers I see:
>
> Received: from [62.8.109.125] (port=24079 helo=mail.dynamail.co.uk)
>
> In the SPF record for dynamail.co.uk I see:
>
> "v=spf1 a mx mx:mail.dynamail.co.uk ip4:195.74.141.160/27  
> ip4:62.8.109.125 ip4:203.31.191.38 ip4:62.8.109.118 ip4:62.8.109.124  
> ip4:62.8.109.123 ip4:62.8.109.114 ip4:62.8.109.122 ip4:62.8.109.116  
> -all"
>
> So firstly the sending IP is mentioned explicitly, and additionally  
> the record is set to hard fail if it doesn't match, not soft fail.  
> Any idea whats going on here?
>
> SpamAssassin version is SpamAssassin 3.3.1 (2010-03-16).


Ok, please ignore me! the from address was a totally different domain! :S

thanks Andy.





Re: SPF fail when SPF record looks good

Posted by Michael Scheidell <mi...@secnap.com>.
On 4/20/11 12:58 PM, a.smith@ukgrid.net wrote:
> Hi,
>
>   I just noticed this, I have an email which was marked as spam. One 
> of the rules it flagged was:
>
> 0.7 SPF_SOFTFAIL           SPF: sender does not match SPF record 
> (softfail)
>
> In the headers I see:
>
> Received: from [62.8.109.125] (port=24079 helo=mail.dynamail.co.uk)
>
> In the SPF record for dynamail.co.uk I see:
>
> "v=spf1 a mx mx:mail.dynamail.co.uk ip4:195.74.141.160/27 
> ip4:62.8.109.125 ip4:203.31.191.38 ip4:62.8.109.118 ip4:62.8.109.124 
> ip4:62.8.109.123 ip4:62.8.109.114 ip4:62.8.109.122 ip4:62.8.109.116 -all"
>
post FULL headers, don't cut anything off or spoof anything, to 
pastebin, and post the link here.

a half dozen reasons this might have had problems.

(and I assume, that .7 points out of 5 wasn't the largest offender?)


> So firstly the sending IP is mentioned explicitly, and additionally 
> the record is set to hard fail if it doesn't match, not soft fail. Any 
> idea whats going on here?
>
most likely, you don't have your local/trusted networks set, and/or the 
'from' really wasn't 'from' @dynamail.co.uk

this is why we need FULL headers.



> SpamAssassin version is SpamAssassin 3.3.1 (2010-03-16).
>
> thanks, Andy.
>
>
>


-- 
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
ISN: 1259*1300
 >*| *SECNAP Network Security Corporation

    * Best Intrusion Prevention Product, Networks Product Guide
    * Certified SNORT Integrator
    * Hot Company Award, World Executive Alliance
    * Best in Email Security, 2010 Network Products Guide
    * King of Spam Filters, SC Magazine

______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r). 
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________  

SPF fail when SPF record looks good

Posted by a....@ukgrid.net.
Hi,

   I just noticed this, I have an email which was marked as spam. One  
of the rules it flagged was:

0.7 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)

In the headers I see:

Received: from [62.8.109.125] (port=24079 helo=mail.dynamail.co.uk)

In the SPF record for dynamail.co.uk I see:

"v=spf1 a mx mx:mail.dynamail.co.uk ip4:195.74.141.160/27  
ip4:62.8.109.125 ip4:203.31.191.38 ip4:62.8.109.118 ip4:62.8.109.124  
ip4:62.8.109.123 ip4:62.8.109.114 ip4:62.8.109.122 ip4:62.8.109.116  
-all"

So firstly the sending IP is mentioned explicitly, and additionally  
the record is set to hard fail if it doesn't match, not soft fail. Any  
idea whats going on here?

SpamAssassin version is SpamAssassin 3.3.1 (2010-03-16).

thanks, Andy.




Re: How to add a Received-Spf header?

Posted by Rob Arista <ar...@gmail.com>.
On Sat, Apr 16, 2011 at 8:06 AM,  <da...@chaosreigns.com> wrote:
> But it can only add headers beginning with X-Spam-.  So you might be able
> to add a header with that, and then use procmail or something to add your
> Received-SPF header based on a X-Spam-Received-SPF header.  But you would
> probably still need to write a SA plugin to do it.
>
> The better option is probably to add the Received-SPF header at your MTA.
> With postfix, I use https://launchpad.net/postfix-policyd-spf-perl/

I use postfix too.  Pretty simple setup right now, but I'm looking to
add better checking.  I read about that postfix-policyd-spf-perl. And
it looks like there's a python version too.

I just learned that you can use postfix procyfilterss and milters
together, and that the proxyfilter runs before the milters.

So I'm thinking about thiis.

Run SA in a prequeue proxy filter, and set SPF checking priority very
negative to do an early check for SPF Fails.

If there is no Fail, then run the rest of SA tests, then handoff to
the policyd-spf to RE-do the SPF checks, like you said using the local
DNS cache for not too much extra overhead, and get the Received-SPF
header added.

If there IS a FAIL in that early check, then use a Shortcircuit rule
to stop SA tests, and just handoff to the policyd-spf to RE-do the SPF
checks and apply any REJECT policy right there.

I think that should work.  Does it look like it to you?

SA can check for and use Received-SPF headers that already exist.  So
it's already aware of them and how they're constructed.  Seems silly
not to be able to add the header too right in Spamassassin and have to
use a 2nd program to re-do stuff that's already been done.

I've never written a plugin like that.  I'll see if I can figure out
how.  I would've thought somebody, somewhere had already done this, by
now.

--Bob

Re: How to add a Received-Spf header?

Posted by da...@chaosreigns.com.
On 04/16, Rob Arista wrote:
> I can't see how to get SA to add a 'Received-Spf' like described here,
> to use it further downstream:

I believe the only way SA can add headers is with the "add_header" config
option:
http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Conf.html#item_add_header__7b_spam__7c_ham__7c_all__7d_header_nam
Or man Mail::SpamAssassin::Conf

But it can only add headers beginning with X-Spam-.  So you might be able
to add a header with that, and then use procmail or something to add your
Received-SPF header based on a X-Spam-Received-SPF header.  But you would
probably still need to write a SA plugin to do it.


The better option is probably to add the Received-SPF header at your MTA.
With postfix, I use https://launchpad.net/postfix-policyd-spf-perl/

It would be nice if SA could then use this header instead of checking SPF
again itself, but since it's silly to run SA without a local caching DNS
server anyway, it shouldn't be significant additional overhead to do it
twice.

-- 
"Safe is anywhere a hungry person can't walk in three days." - John Titor
http://www.ChaosReigns.com