<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Scott,<br>
    Opendmarc /does/ know about Received-SPF.  Check the RELEASE_NOTES:<br>
    <blockquote>1.1.3       2013/04/13<br>
          Fix reporting of nonexistent SPF results.  Problem noted by<br>
              Andrei Ioachim.<br>
          Fix extraction of data from Received-SPF.  Problem noted by<br>
              Todd Lyons.<br>
      <...><br>
      0.2.0       2012/08/24<br>
          Feature request #15: If there's no SPF Authentication-Results
      field,<br>
              look for a Received-SPF field to get SPF results.<br>
    </blockquote>
    In opendmarc.c there is an explicit check for Received-SPF headers
    in case no Authentication-Result header is found for SPF [look for
    line 2239 "if (!wspf)"].  Failing that [look for line 2271 "if
    (!wspf)"] we end up with "spf -1" in the history, which means no SPF
    information at all.<br>
    <br>
    Thanks for forwarding test data to Murray.<br>
    <br>
    Cheers,<br>
        -nic<br>
    <br>
    <div class="moz-cite-prefix">On 08/19/2013 10:22 AM, Scott Kitterman
      wrote:<br>
    </div>
    <blockquote cite="mid:4594921.G1RUIhlbSq@scott-latitude-e6320"
      type="cite">
      <pre wrap="">I'm reasonably certain that's a test methodolgy error in Maarten's case.  
Opendmarc doesn't know anything about Received:SPF.  I can make it fail 
locally with the opendmarc milter in test mode.  I'm going to send Murray the 
messages (one fails, one doesn't) offlist to see what he can figure out.  Since 
it fails in test mode with a message read from a file, it's not a processing 
sequence issue.

Scott K

On Monday, August 19, 2013 09:48:56 Nic Bernstein wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Scott,
Thanks much.  Also, for completeness, I have tested this using the "SPF"
mode (Received-SPF header) of pypolicyd-spf, as Maarten Oelering reports
success with, and have the same results.  The Received-SPF header is in
the final message, but is not seen by opendmarc.

Cheers,
    -nic

On 08/19/2013 09:29 AM, Scott Kitterman wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">So I'm about 98.7% sure I tested this before and it was working correctly.
It's not now, so let me troubleshoot.

Scott K

On Monday, August 19, 2013 09:07:04 Nic Bernstein wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">Scott,
Could you please post (or email off-list) the contents of a history file
pertaining to a message for which DMARC worked?  That's the only way I
know of to tell if it is, in fact, scoring SPF.  According to earlier
list posts, OpenDMARC will pass a message as long as either SPF or DKIM
pass, so without the history file data, it's hard to tell what's
happening.

For completeness, the default setting of "smtpd_delay_reject = yes" is
in place, there are no "smtpd_data_restrictions," and
"policyd-spf_time_limit = 3600."

Cheers,

    -nic

PS - To enable writing the history file (disabled by default) either add

or uncomment the "HistoryFile" directive in opendmarc.conf:
    HistoryFile /var/run/opendmarc/opendmarc.dat

On 08/16/2013 05:20 PM, <a class="moz-txt-link-abbreviated" href="mailto:opendmarc-users-request@trusteddomain.org">opendmarc-users-request@trusteddomain.org</a> wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="">On Friday, August 16, 2013 16:42:07 Nic Bernstein wrote:
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre wrap="">Folks,
We are attempting to deploy opendmarc(1.1.3) for receiving, with
Postfix
(2.9.2), pypolicyd-spf(1.2) and OpenDKIM(2.6.8).  We are getting mixed
results, in that while we do see the proper Authentication-Results
headers in our messages, opendmarc seems not to see the SPF headers.

Here is a sample from a recent test message:
    Authentication-Results: smtp.onlight.com; spf=pass (sender SPF

authorized) smtp.mailfrom=gmail.com (client-ip=209.85.212.68;
helo=mail-vb0-f68.google.com; <a class="moz-txt-link-abbreviated" href="mailto:envelope-from=nb1onlight@gmail.com">envelope-from=nb1onlight@gmail.com</a>;
<a class="moz-txt-link-abbreviated" href="mailto:receiver=nic@onlight.com">receiver=nic@onlight.com</a>) Authentication-Results: smtp.onlight.com;
dkim=pass

        reason="2048-bit key; insecure key"
        header.d=gmail.com <a class="moz-txt-link-abbreviated" href="mailto:header.i=@gmail.com">header.i=@gmail.com</a> header.b=gzXzLLLE;
        dkim-adsp=pass; dkim-atps=neutral
    
    <...>
    Authentication-Results: ujiji.onlight.com/E85322025F; dmarc=pass

header.from=gmail.com

However, in the history file we see this:
    job E85322025F
    reporter smtp.onlight.com
    received 1376684253
    ipaddr 209.85.212.68
    from gmail.com
    mfrom gmail.com
    dkim gmail.com 0
    spf -1
    pdomain gmail.com
    policy 15
    rua <a class="moz-txt-link-freetext" href="mailto:mailauth-reports@google.com">mailto:mailauth-reports@google.com</a>
    pct 100
    adkim 114
    aspf 114
    p 110
    sp 0
    align_dkim 4
    align_spf 5
    action 2

We have postfix configured like so:
    /etc/postfix/main.cf:
        smtpd_recipient_restrictions = permit_sasl_authenticated,
        
                permit_mynetworks,
                reject_unknown_recipient_domain,
                reject_unauth_pipelining,
                reject_unauth_destination,
                check_policy_service unix:private/policyd-spf,
                permit_auth_destination,
                reject
        
        smtpd_milters = unix:/var/run/opendkim/opendkim.sock
        
                unix:/var/run/opendmarc/opendmarc.sock
    
    /etc/postfix/master.cf:
        policyd-spf  unix  -       n       n       -       0
        spawn
        
                user=nobody argv=/usr/bin/policyd-spf

Yet it appears that the Authentication-Results header from
pypolicyd-spf
is not in the message when it is processed by opendmarc.  We turned on
full debugging in pypolicyd-spf, and added some debugging to mlfi_eom
in
an effort to see what's going on, but while we do see the opendkim
headers being processed (result_method=1,5,7), we do not see the
SPF(result_method=4) stuff at all.  It appears we're not even entering
the  "if (ar.ares_result[c].result_method == ARES_METHOD_SPF)" section
of mlfi_eom(), even though pypolicyd-spf appears to be prepending the
</pre>
                </blockquote>
              </blockquote>
              <pre wrap="">
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre wrap="">proper header, and we do see that header in the final email:
</pre>
                </blockquote>
              </blockquote>
              <pre wrap="">...

</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre wrap="">Anyone have any thoughts?  It seems as though the milters are getting
the message before the policy daemon, and yet the logs would appear to
say otherwise (and they should get it after).

Any guidance would be greatly appreciated.
</pre>
                </blockquote>
              </blockquote>
              <pre wrap="">
I have almost this exact setup and it's working.  I'm specifying the
milters using -o for the relevant service in master.cf instead of in
main.cf, but other than that, I think it's identical.

The logs clearly show that the SPF check is being done and I don't see
how
it couldn't be accomplished prior to the DMARC check as it's done at
RCPT
TO and the DMARC check can't be done until after DATA.

Do you have any smtpd_data_restrictions defined?

You might try defining TrustedAuthservIDs in your opendmarc.conf to
include
smtp.onlight.com if you haven't already.

Scott K
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">
_______________________________________________
opendmarc-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:opendmarc-users@trusteddomain.org">opendmarc-users@trusteddomain.org</a>
<a class="moz-txt-link-freetext" href="http://www.trusteddomain.org/mailman/listinfo/opendmarc-users">http://www.trusteddomain.org/mailman/listinfo/opendmarc-users</a>
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">_______________________________________________
opendmarc-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:opendmarc-users@trusteddomain.org">opendmarc-users@trusteddomain.org</a>
<a class="moz-txt-link-freetext" href="http://www.trusteddomain.org/mailman/listinfo/opendmarc-users">http://www.trusteddomain.org/mailman/listinfo/opendmarc-users</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Nic Bernstein                             <a class="moz-txt-link-abbreviated" href="mailto:nic@onlight.com">nic@onlight.com</a>
Onlight, Inc.                             <a class="moz-txt-link-abbreviated" href="http://www.onlight.com">www.onlight.com</a>
219 N. Milwaukee St., Suite 2a            v. 414.272.4477
Milwaukee, Wisconsin  53202
</pre>
  </body>
</html>