IETF Logo Mail Archive

Re: [spfbis] auth-results and spf

Franck Martin <fmartin@linkedin.com> Wed, 10 February 2016 00:10 UTC

Return-Path: <fmartin@linkedin.com>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE621B3258 for <spfbis@ietfa.amsl.com>; Tue, 9 Feb 2016 16:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.08
X-Spam-Level:
X-Spam-Status: No, score=-3.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FAxRjninyUI for <spfbis@ietfa.amsl.com>; Tue, 9 Feb 2016 16:10:11 -0800 (PST)
Received: from mail522.linkedin.com (mail522.linkedin.com [108.174.6.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AEA1B325C for <spfbis@ietf.org>; Tue, 9 Feb 2016 16:10:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1455063011; bh=ra1nn0lLPKdrYIAXBkXu6fKg7jeDirvE0+BhXhPJYOk=; h=MIME-Version:From:Date:Subject:To:Content-Type; b=LP1Cq08mYBuk+WeikIYnkA/cqzOq82sjGwk+SS9n9AkvN5NP51CwHkWVQp/uE5tWE L4WEYDC7OczUXk012QDuBDGpf0JikyT2dOJjmvT2kYu6mnSHgap8M8q7fjyCria/18 qwBP7QUz0Nuve4RbBe2nRgDKm8+2Owe5NwszkV/s=
Authentication-Results: mail522.prod x-tls.subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com"; auth=pass (cipher=ECDHE-RSA-AES128-GCM-SHA256)
Authentication-Results: mail522.prod.linkedin.com; iprev=pass policy.iprev="74.125.82.46"; spf=softfail smtp.mailfrom="fmartin@linkedin.com" smtp.helo="mail-wm0-f46.google.com"; dkim=none (message not signed) header.d=none; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" key.length="128" tls.v="tlsv1.2" cert.client="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com" cert.clientissuer="C=US,O=Google Inc,CN=Google Internet Authority G2"
Received: from [74.125.82.46] ([74.125.82.46:38336] helo=mail-wm0-f46.google.com) by mail522.prod (envelope-from <fmartin@linkedin.com>) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTPS (cipher=ECDHE-RSA-AES128-GCM-SHA256 subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com") id 89/CA-30456-2EF7AB65; Wed, 10 Feb 2016 00:10:11 +0000
Received: by mail-wm0-f46.google.com with SMTP id p63so5596538wmp.1 for <spfbis@ietf.org>; Tue, 09 Feb 2016 16:10:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ra1nn0lLPKdrYIAXBkXu6fKg7jeDirvE0+BhXhPJYOk=; b=Pp89Fcihkq1/Tv4qyqAxFi7SdU37MTr2WXXISgNVSJk28To7tafMxlEvQThzIulQwQ o2vEsJdAvlAjElmKyyFcpH4smZ3ltrSSQF4Ja2U+cT6kUUQCv7PAl/S6RtOZ+7h7hvOT V44qyFp/DQXVfRCjTpiESP0tVM59Fuav6QG9N6mY/23y6mP4OHrYIstamowLughGrLzo L/FmmbRgC9ycp+4yISUjq6e1YFTEuxUPqGQWEckZ+uSODIpiJcMxQn9CI8r2Ct4bhoRX mbNXQRoU23cCKChm12xMzzwv/txTkzGww+EHcXSQ9iLebjBklhtsc6DOCcz4SA1EeBb+ x76A==
X-Gm-Message-State: AG10YOSYgDdrmybcfLHxvMtZqJbZ6paMmGb24GTAZkCTrTGTo0ubWakFdCZZ2oSPY+HYdXkP9qp7dB4VQX2gi4PUfQGwRqSmyOcaxwr+5vwLRw6diWricMaphV4IEPV1qr0t6H8QsYuF+/QXgF/8N3E0N9CAYacyKA==
X-Received: by 10.194.203.5 with SMTP id km5mr17000300wjc.172.1455063009482; Tue, 09 Feb 2016 16:10:09 -0800 (PST)
X-Received: by 10.194.203.5 with SMTP id km5mr17000285wjc.172.1455063009317; Tue, 09 Feb 2016 16:10:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.82.36 with HTTP; Tue, 9 Feb 2016 16:09:49 -0800 (PST)
In-Reply-To: <CABa8R6v0b5vVcgTSveWzzXvvQGHoosCAgADyxBNLOprtaj+TLA@mail.gmail.com>
References: <CABa8R6v0b5vVcgTSveWzzXvvQGHoosCAgADyxBNLOprtaj+TLA@mail.gmail.com>
From: Franck Martin <fmartin@linkedin.com>
Date: Tue, 09 Feb 2016 16:09:49 -0800
Message-ID: <CANyRh98NJOgxniMEpR5ZFX0=J4T-A=-ndEcv2F+7zL62JDDpNQ@mail.gmail.com>
To: Brandon Long <blong@google.com>
Content-Type: multipart/alternative; boundary="047d7bae4532cbfa41052b5f41ed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/spfbis/3NHX3pDlPvrrfa2vf8fw1DJVbhg>
Cc: spfbis@ietf.org
Subject: Re: [spfbis] auth-results and spf
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2016 00:10:13 -0000

Well, for instance with DMARC we do not add again the SPF and DKIM
identifiers used to get the DMARC results. So I guess this is the same, you
have policy.iprev to indicate the connecting IP, this is what I use in
Authentication-Results.

If you were just doing the Received-SPF header, then it has client-ip,
because this header needs to be able to stand on its own.

So I feel there is no need to add a client ip key within the SPF construct
in the Authentication-Results header, just make sure to have policy.iprev
in this header.

Also in the SPF portion of the Authenticated-Results, I make sure to have
the value for the rfc5321.mailfrom and rfc5321.helo there, because the SPF
pass depends on one or the other if your SPF local policy is only based on
the RFC7208.MAILFROM. Technically, there are 2 SPF results, one for
RFC7208.HELO and one for RFC7208.MAILFROM. Your local policy decide on
which one will do what... Many people ignore RFC7208.HELO.

On Tue, Feb 9, 2016 at 1:44 PM, Brandon Long <blong@google.com> wrote:

> Not sure the best list to send this to... but anyone know why the IP isn't
> a formal field in the spf method for the Authentication-Results header (RFC
> 7601)?
>
> For "iprev", there is policy.iprev, but there isn't one for spf.  We put
> it in the comment now, but it would seem like an obvious requirement for
> what was evaluated.
>
> Brandon
>
> _______________________________________________
> spfbis mailing list
> spfbis@ietf.org
> https://www.ietf.org/mailman/listinfo/spfbis
>
>

v2.23.0 | Report a Bug | By Email