IETF Logo Mail Archive

Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities

"Murray S. Kucherawy" <msk@cloudmark.com> Tue, 13 March 2012 20:55 UTC

Return-Path: <msk@cloudmark.com>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C4021F84B5 for <spfbis@ietfa.amsl.com>; Tue, 13 Mar 2012 13:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.603
X-Spam-Level:
X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu2uqUVoy43b for <spfbis@ietfa.amsl.com>; Tue, 13 Mar 2012 13:55:16 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 87BA221F853A for <spfbis@ietf.org>; Tue, 13 Mar 2012 13:55:15 -0700 (PDT)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 13 Mar 2012 13:55:15 -0700
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: "spfbis@ietf.org" <spfbis@ietf.org>
Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
Thread-Index: AQHNAUZS1zQ5UGus8k+dRPuGMu8eIpZoswuw
Date: Tue, 13 Mar 2012 20:55:14 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280884FA@exch-mbx901.corp.cloudmark.com>
References: <061.3e36e3983d163f02c3a839aa54c4e2b3@tools.ietf.org> <6.2.5.6.2.20120313012810.0a31fe60@elandnews.com> <2372065.C4Li7o8hMb@scott-latitude-e6320>
In-Reply-To: <2372065.C4Li7o8hMb@scott-latitude-e6320>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.20.2.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 13 Mar 2012 20:55:17 -0000

Scott did all the work, but...

> -----Original Message-----
> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Scott Kitterman
> Sent: Tuesday, March 13, 2012 11:23 AM
> To: spfbis@ietf.org
> Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
> 

An informative reference to that draft might be a good idea, though I don't have strong feelings either way.

> References to at least draft-ietf-marf-spf-reporting should be added to
> 9.1, but the current text about a special SPF record should remain.

+1

> It does not appear that any of the comments address 9.2.  I think it
> would be useful (and a good preamble to the forwarding discussion) to
> update this text to make use of the email architecture terminology that
> didn't exist when RFC
> 4408 was written.  The references should be updated as well.  I don't
> think any functional changes to 9.2 are needed.

+1

> I disagree with the comments.  First, I think 3.6.2 of RFC 5321 is more
> relevant (it even mentions SPF by name).  I don't think 4408bis should
> update 5321.  I think it would make consensus substantially harder to
> achieve and there is no technical need for it.

+1 (I need a +1 button)

> It would be useful to explicitly say in this section that THE place to
> do SPF checks is at the transition point between the sending ADMD and
> the receiving ADMD.  When a message is relayed within the recieving
> ADMD, SPF checks, per se are not appropriate, all that can be done is
> to use the results of checks done on the ADMD border if they can be
> trasmitted in a reasonably trustworthy manner.

We can make liberal use of or reference to Appendix C of RFC5451 to back this up.

> redirect/include and _spf are nice tools for domains that need them.
> They are not, however, a general solution or requirement.  I think 5.2
> already give adequate coverage to the use of include:.  I think it
> would be useful (as part of the processing limits discussion) to
> include an indication that SPF records SHOULD NOT require TCP fallback
> to retrieve (and this includes the answers for other TXT records
> published for that domain) and offer the _spf example of how to work
> around packet size limitations.

Sounds reasonable.

-MSK

v2.23.0 | Report a Bug | By Email