From johnl@iecc.com Sun Jul 1 07:54:36 2012 Return-Path: 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 0FDC511E8072 for ; Sun, 1 Jul 2012 07:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.089 X-Spam-Level: X-Spam-Status: No, score=-111.089 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 GlTd+9ObBXWk for ; Sun, 1 Jul 2012 07:54:35 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E700C11E80AE for ; Sun, 1 Jul 2012 07:54:32 -0700 (PDT) Received: (qmail 67735 invoked from network); 1 Jul 2012 14:54:34 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Jul 2012 14:54:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4ff064aa.xn--btvx9d.k1207; i=johnl@user.iecc.com; bh=SllFqDgSnYy1CQ5SBWv/RmR/LlV3BPx6sSfjYgWMn1E=; b=nmBPTtqsTTyie3GlBTs40eTgHeE+aBDDIP8KtFBHUY6WFaCf3HaX+jqXISMHQEAfn192eIq6pzBVET9UUB0tDN2WrQaXGjXePHyYs1zun8cKs7cRtK9e8xuld6Tc2ozmg1wXa6G21LHS/ppnH6ryGi0ya1eGtqYj11uDIqK6lFo= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4ff064aa.xn--btvx9d.k1207; olt=johnl@user.iecc.com; bh=SllFqDgSnYy1CQ5SBWv/RmR/LlV3BPx6sSfjYgWMn1E=; b=VgrzxVIv2RnR6dGTBORJ/Ru4PCWivK5sOoxTdPjhVDWskQ7uoMPb2WxowEIAPmSWtUa7eNitVloFExPeivZMui7V5SkKjuF6IRUiV3TS5UffetqFZIDiVx5+YidTDOl17pPQqJtk9LYOuwzT5gOGa+Qh39EjkvCu7BEapdXoX2c= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 1 Jul 2012 14:54:11 -0000 Message-ID: <20120701145411.30505.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: superuser@gmail.com Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 14:54:36 -0000 >Given the conclusions of the experiment draft, why are we continuing to >even talk about the SPF RRTYPE? I think 4408bis should drop it altogether. If we don't at least mention it anywhere, some future readers may come to the conclusion that we forgot about it. If there's an appendix with changes since 4408, it would be fine to have one line saying "removed type 99 RR" and leave it at that. R's, John From hsantos@isdg.net Sun Jul 1 10:03:58 2012 Return-Path: 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 1593D11E8093 for ; Sun, 1 Jul 2012 10:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 XfptI-kOfoqn for ; Sun, 1 Jul 2012 10:03:57 -0700 (PDT) Received: from groups.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF1411E8080 for ; Sun, 1 Jul 2012 10:03:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1360; t=1341162235; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=c4mm5lh3Dc0++fDNivwF2CMqVQI=; b=Am8dHBSVX3cFOnBInrT9 XiYgwiy03j1lkqrLCs6zM39W7SHtwKVKfTu/SEkTFjiqnfBunXlgMdf8DTmn6t+i RogKyuqAfcmWLGO8jKP1L+UQy4h+Qyyw2y2SnALZXYZ+j+JIdK0ZPO7u6ZV9Wcdu 1XKwzO63sSZbt3QHmvP5J4c= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 01 Jul 2012 13:03:55 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1479051118.1041.5108; Sun, 01 Jul 2012 13:03:54 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1360; t=1341162133; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vdoYhoY FiaA1jcM/CwiJM7ec9MoHjoI9+sg+rtQmKIw=; b=OCg2CKooNmCOaiAGWCt5ky/ bxTV0FJgVexs0n5S/po0sPLxmAHw0YLvOhRCQ+KgARed+KLPPIMlUZfROQL8YF5y aeBjmBAHLYtXS08ywGbgS7hbxrxS3YvwhhFI4bKdq56pmPEbOvwW9JkqaWGRXEuo GhVjOd0uKK56N+5QA1pw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 01 Jul 2012 13:02:13 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2077898926.9.2280; Sun, 01 Jul 2012 13:02:12 -0400 Message-ID: <4FF082E3.1040604@isdg.net> Date: Sun, 01 Jul 2012 13:03:31 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <20120701145411.30505.qmail@joyce.lan> In-Reply-To: <20120701145411.30505.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 17:03:58 -0000 John Levine wrote: >> Given the conclusions of the experiment draft, why are we continuing to >> even talk about the SPF RRTYPE? I think 4408bis should drop it altogether. > > If we don't at least mention it anywhere, some future readers may come > to the conclusion that we forgot about it. > > If there's an appendix with changes since 4408, it would be fine to have one > line saying "removed type 99 RR" and leave it at that. I would suggest something that offers less of a why? "scratch your head" statements especially for the existing systems that do currently support the query, like due to lack of technical feasibility, removed the optional type 99 RR lookup This specification notes continue usage from a updated protocol standpoint is now considered DNS wasteful (inefficient) with less expectation for support of type 99 RR queries and responses. It offers the idea that a) there was analysis done to reach this update design position, b) the use of the term "optional" suggest that it wasn't important anyway - nothing will break, the system (protocol) lives on and c) offers the encouragement to deployments to disable existing parallel queries and for implementators to make it obsolete not to consider it during their BIS update efforts. New readers/implementators will less know the background. -- HLS From sm@elandsys.com Sun Jul 1 21:36:22 2012 Return-Path: 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 5785811E8146 for ; Sun, 1 Jul 2012 21:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 eNa3eMaNCN30 for ; Sun, 1 Jul 2012 21:36:19 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B60911E813D for ; Sun, 1 Jul 2012 21:36:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.218]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q624a5Sb014409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Jul 2012 21:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341203781; bh=UJbjxYl67YcraPlzTCZ8h7gCiUENeE5FWyOWya4FR1I=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=mVI7QwzE04ZY7l3foz+2+7bwQmPXqT8vyuygEY/yD9l4q2tBtrdKvQlYhH1JWKbHI l+mqT3V33KCuEn27J9Ouu2IdJ7J3J0GKeVcEjpy/XUwmzOq+uH8y29hwzE1Dh1PFJ8 P/MxSQbt8qTh63AH/3KnoU8tKebnjC9HmMBD3p50= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1341203781; i=@elandsys.com; bh=UJbjxYl67YcraPlzTCZ8h7gCiUENeE5FWyOWya4FR1I=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=1Rx7LjUzygf37d9DEwzO3BMh4cx6j8HAqlJJ1BKYa3SZU/J4y+7WL7oO2/bov6j/G 4/0kjb+1AG+PcQhqyCRozj+LT7VZR1JevAc8CCTp8OiHLwH6xODBQHgPIpT/mwmthy ZqClZXehd470gJ7uKLY6H/onbLLYwVjBbgzMRJKM= Message-Id: <6.2.5.6.2.20120701213231.07df0058@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 01 Jul 2012 21:34:53 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1753008.jfhW4KDlhY@scott-latitude-e6320> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <1499001.S9Rc5jekbH@scott-latitude-e6320> <6.2.5.6.2.20120629141459.0a01ddb8@resistor.net> <1753008.jfhW4KDlhY@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Summary of open issues - #26 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 04:36:22 -0000 Hello, I am closing the ticket for Issue #26 as it would be a substantive change to the protocol that is not widely adopted. Regards, S. Moonesamy From vesely@tana.it Mon Jul 2 01:54:45 2012 Return-Path: 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 AAF3221F8ADB for ; Mon, 2 Jul 2012 01:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=-1.158, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 kV5+l1vP2yil for ; Mon, 2 Jul 2012 01:54:44 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B05AD21F89C9 for ; Mon, 2 Jul 2012 01:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1341219287; bh=lS+5YJFmyr43dyTbGtIv6299OizbM94hMzsB0BwuM8g=; l=504; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=N2VNvFNghU6CdbW+v4ulbHDOAC+xsRPC0KE+N/5GHbROBX6M8nRMUGWd28nTmGDSj rfTg53Y2xeG+ZAAqKsjzBoMHhnApkmRvfZZoA3TLLGn/JE3FY/HHnylhYp37k222UQ vq/iYAc0KhaIXRXR3OggXNeMELxyJuxTGtKilxLY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 02 Jul 2012 10:54:47 +0200 id 00000000005DC033.000000004FF161D7.00003F24 Message-ID: <4FF161D7.7000106@tana.it> Date: Mon, 02 Jul 2012 10:54:47 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120630152222.15891.qmail@joyce.lan> In-Reply-To: <20120630152222.15891.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] spfbis - Requested session has been scheduled for IETF 84 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 08:54:45 -0000 On Sat 30/Jun/2012 17:22:22 +0200 John Levine wrote: >>An interesting way to entertain ourselves would be to define a list of >>pros and cons of adopting SPF, from a mail admin perspective. > > If you're buying the beer, we'll be happy to meet in the bar in the > evening. But not in a precious WG meeting slot. Uh, I think I can afford that, more easily than retrieving, say, E. C. Zeeman's lecture on the dynamics of the hawk-dove-bully-retaliator model. The latter was interesting, though. From spf2@kitterman.com Mon Jul 2 16:53:33 2012 Return-Path: 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 C27CF21F85D7 for ; Mon, 2 Jul 2012 16:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 3jpL9uQIKUJr for ; Mon, 2 Jul 2012 16:53:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A71E521F85FD for ; Mon, 2 Jul 2012 16:53:31 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2A8BF20E40BB; Mon, 2 Jul 2012 19:53:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341273217; bh=nxn9xnaKt+3rs5llF8f/aClYwEzkOtF13pY9jqEIuxk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dRyG1Ff6+0regzozv5h/c1lKzyQQv+B3PI5NH8Jxg1uv2GGAqmwQe1f5cEAAxZNim xINuPjDKu5YBaEtfd05vQcLK36vCMiNAOEow4wfSE7snrOUYcLBw3wjVvkfsQSpHhS hIYMPmS9jrZrcp3KRFk/+X6y9aYTOrTcjUC0OTVQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EAE9120E406C; Mon, 2 Jul 2012 19:53:36 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 02 Jul 2012 19:53:36 -0400 Message-ID: <1567036.rU5QQqS7VH@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <1610254.tmmhToiaLs@scott-latitude-e6320> References: <20120629190443.9297.40140.idtracker@ietfa.amsl.com> <1610254.tmmhToiaLs@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart2386772.TyAdtBCW8h" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-02.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 23:53:33 -0000 --nextPart2386772.TyAdtBCW8h Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Friday, June 29, 2012 03:07:49 PM Scott Kitterman wrote: > On Friday, June 29, 2012 12:04:43 PM internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the SPF Update Working Group of > > the IETF. > > > > > > Title : Sender Policy Framework (SPF) for Authorizing > >Use> > > of Domains in Email, Version 1 Author(s) : Scott Kitterman > > > > Filename : draft-ietf-spfbis-4408bis-02.txt > > Pages : 56 > > Date : 2012-06-29 > > Here's the revision log additions for this version: ... > Initial draft of wording to deprecate Type SPF. ... This change engendered a fair amount of discussion started by Alessandro Vesely here: http://www.ietf.org/mail-archive/web/spfbis/current/msg01726.html There seemed to be a general view that I had too much about Type SPF still in the draft, so I've taken another whack at it and reduced it further. A related point: In my last draft, I left the Type 99/SPF discussion in the IANA considerations section. I did that on purpose because even though RFC 4408 will be obsolete after 4408bis is published, we still want an active definition for the assignment (to preserve it's use for SPF for the near future since people won't immedialtely remove Type SPF records, to document that the code point has been used and it not available, and to make it easy for a future effort to pick up it's use again if it were ever warranted). I do think the body of the document needs to at least mention it for clarity, but it should be more minimal than my original attempt. I'm attaching an rfcdiff from the 02 draft to my current attempt. You'll see I moved some of the information about type SPF to IANA considerations (not sure if I can do that) and seriously slimmed down the discussion in the body of the draft. Scott K --nextPart2386772.TyAdtBCW8h Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-03-from-2.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-spfbis-4408bis-03-from-2.diff.html" Diff: draft-ietf-spfbis-4408bis-02.txt - draft-ietf-spfbis-4408bis-03.txt
 draft-ietf-spfbis-4408bis-02.txt   draft-ietf-spfbis-4408bis-03.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft Agari Internet-Draft Agari
Obsoletes: 4408 (if approved) June 29, 2012 Obsoletes: 4408 (if approved) July 2, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: December 31, 2012 Expires: January 3, 2013
Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
Version 1 Version 1
draft-ietf-spfbis-4408bis-02.txt draft-ietf-spfbis-4408bis-03.txt
Abstract Abstract
E-mail on the Internet can be forged in a number of ways. In E-mail on the Internet can be forged in a number of ways. In
particular, existing protocols place no restriction on what a sending particular, existing protocols place no restriction on what a sending
host can use as the reverse-path of a message or the domain given on host can use as the reverse-path of a message or the domain given on
the SMTP HELO/EHLO commands. This document describes version 1 of the SMTP HELO/EHLO commands. This document describes version 1 of
the Sender Policy Framework (SPF) protocol, whereby a domain can the Sender Policy Framework (SPF) protocol, whereby a domain can
explicitly authorize the hosts that are allowed to use its domain explicitly authorize the hosts that are allowed to use its domain
name, and a receiving host can check such authorization. This name, and a receiving host can check such authorization. This
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2012. This Internet-Draft will expire on January 3, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 31 skipping to change at page 3, line 31
2.5.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11 2.5.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11 2.5.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.6. TempError . . . . . . . . . . . . . . . . . . . . . . 12 2.5.6. TempError . . . . . . . . . . . . . . . . . . . . . . 12
2.5.7. PermError . . . . . . . . . . . . . . . . . . . . . . 12 2.5.7. PermError . . . . . . . . . . . . . . . . . . . . . . 12
3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Publishing . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Publishing . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1. DNS Resource Record Types . . . . . . . . . . . . . . 13 3.1.1. DNS Resource Record Types . . . . . . . . . . . . . . 13
3.1.2. Multiple DNS Records . . . . . . . . . . . . . . . . . 14 3.1.2. Multiple DNS Records . . . . . . . . . . . . . . . . . 13
3.1.3. Multiple Strings in a Single DNS record . . . . . . . 14 3.1.3. Multiple Strings in a Single DNS record . . . . . . . 14
3.1.4. Record Size . . . . . . . . . . . . . . . . . . . . . 14 3.1.4. Record Size . . . . . . . . . . . . . . . . . . . . . 14
3.1.5. Wildcard Records . . . . . . . . . . . . . . . . . . . 14 3.1.5. Wildcard Records . . . . . . . . . . . . . . . . . . . 14
4. The check_host() Function . . . . . . . . . . . . . . . . . . 16 4. The check_host() Function . . . . . . . . . . . . . . . . . . 16
4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 16 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 16
4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 17
4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 17 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 17
4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 17 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 13, line 42 skipping to change at page 13, line 42
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
smtp-out.example.com. TXT "v=spf1 a -all" smtp-out.example.com. TXT "v=spf1 a -all"
When publishing via TXT records, beware of other TXT records When publishing via TXT records, beware of other TXT records
published there for other purposes. They might cause problems with published there for other purposes. They might cause problems with
size limits (see Section 3.1.4). size limits (see Section 3.1.4).
3.1.1. DNS Resource Record Types 3.1.1. DNS Resource Record Types
[RFC4408] defined a new DNS RR of type SPF, code 99. The format of SPF records MUST ba published as type TXT [RFC1035]. The character
this type is identical to the TXT RR [RFC1035]. For either type, the content of the record is encoded as [US-ASCII]. Use of alternate DNS
character content of the record is encoded as [US-ASCII]. RR types has been dropped. See Appendix A of
[draft-ietf-spfbis-experiment].
While it is recognized that the current practice (using a TXT record)
is not optimal, the transitional strategy to the new, dedicated RR
type failed to gain traction and has been abandoned for SPF Version
1. Such use is deprecated for version 1, but should a need be
identified for an incompatible update to a later version, its use
might be appropriate. The background for this is described in
Appendix A of [draft-ietf-spfbis-experiment].
An SPF-compliant domain name MUST have SPF records of type TXT. An
SPF-compliant domain name MUST NOT publish only records of type SPF.
If a domain has records of both types, they MUST have identical
content.
3.1.2. Multiple DNS Records 3.1.2. Multiple DNS Records
A domain name MUST NOT have multiple records that would cause an A domain name MUST NOT have multiple records that would cause an
authorization check to select more than one record. See Section 4.5 authorization check to select more than one record. See Section 4.5
for the selection rules. for the selection rules.
3.1.3. Multiple Strings in a Single DNS record 3.1.3. Multiple Strings in a Single DNS record
As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
skipping to change at page 14, line 30 skipping to change at page 14, line 19
string. If a published record contains multiple strings, then the string. If a published record contains multiple strings, then the
record MUST be treated as if those strings are concatenated together record MUST be treated as if those strings are concatenated together
without adding spaces. For example: without adding spaces. For example:
IN TXT "v=spf1 .... first" "second string..." IN TXT "v=spf1 .... first" "second string..."
MUST be treated as equivalent to MUST be treated as equivalent to
IN TXT "v=spf1 .... firstsecond string..." IN TXT "v=spf1 .... firstsecond string..."
SPF or TXT records containing multiple strings are useful in TXT records containing multiple strings are useful in constructing
constructing records that would exceed the 255-byte maximum length of records that would exceed the 255-byte maximum length of a string
a string within a single TXT or SPF RR record. within a single TXT record.
3.1.4. Record Size 3.1.4. Record Size
The published SPF record for a given domain name SHOULD remain small The published SPF record for a given domain name SHOULD remain small
enough that the results of a query for it will fit within 512 octets. enough that the results of a query for it will fit within 512 octets.
This will keep even older DNS implementations from falling over to This will keep even older DNS implementations from falling over to
TCP. Since the answer size is dependent on many things outside the TCP. Since the answer size is dependent on many things outside the
scope of this document, it is only possible to give this guideline: scope of this document, it is only possible to give this guideline:
If the combined length of the DNS name and the text of all the If the combined length of the DNS name and the text of all the
records of a given type (TXT or SPF) is under 450 characters, then records of a given type is under 450 characters, then DNS answers
DNS answers should fit in UDP packets. Note that when computing the should fit in UDP packets. Note that when computing the sizes for
sizes for queries of the TXT format, one must take into account any queries of the TXT format, one must take into account any other TXT
other TXT records published at the domain name. Records that are too records published at the domain name. Records that are too long to
long to fit in a single UDP packet MAY be silently ignored by SPF fit in a single UDP packet MAY be silently ignored by SPF clients.
clients.
3.1.5. Wildcard Records 3.1.5. Wildcard Records
Use of wildcard records for publishing is not recommended. Care must Use of wildcard records for publishing is not recommended. Care must
be taken if wildcard records are used. If a domain publishes be taken if wildcard records are used. If a domain publishes
wildcard MX records, it might want to publish wildcard declarations, wildcard MX records, it might want to publish wildcard declarations,
subject to the same requirements and problems. In particular, the subject to the same requirements and problems. In particular, the
declaration must be repeated for any host that has any RR records at declaration must be repeated for any host that has any RR records at
all, and for subdomains thereof. For example, the example given in all, and for subdomains thereof. For example, the example given in
[RFC1034], Section 4.3.3, could be extended with the following: [RFC1034], Section 4.3.3, could be extended with the following:
skipping to change at page 17, line 9 skipping to change at page 17, line 9
name, or if the DNS lookup returns "domain does not exist" (RCODE 3), name, or if the DNS lookup returns "domain does not exist" (RCODE 3),
check_host() immediately returns the result "none". check_host() immediately returns the result "none".
If the <sender> has no localpart, substitute the string "postmaster" If the <sender> has no localpart, substitute the string "postmaster"
for the localpart. for the localpart.
4.4. Record Lookup 4.4. Record Lookup
In accordance with how the records are published (see Section 3.1 In accordance with how the records are published (see Section 3.1
above), a DNS query needs to be made for the <domain> name, querying above), a DNS query needs to be made for the <domain> name, querying
for type TXT. SPF Version 1 queries for records of type SPF SHOULD for type TXT only.
NOT be done. If both SPF and TXT RRs are looked up, the queries MAY
be done in parallel.
If all DNS lookups that are made return a server failure (RCODE 2), If all DNS lookups that are made return a server failure (RCODE 2),
or other error (RCODE other than 0 or 3), or time out, then or other error (RCODE other than 0 or 3), or time out, then
check_host() exits immediately with the result "temperror". check_host() exits immediately with the result "temperror".
Alternatively, for a server failure (RCODE 2) result, check_host() Alternatively, for a server failure (RCODE 2) result, check_host()
MAY track failures and treat multiple failures within 24 hours for MAY track failures and treat multiple failures within 24 hours for
the same domain as "permerror". the same domain as "permerror".
This alternate, is not intended to save further queries, which MUST This alternate, is not intended to save further queries, which MUST
be done according to RFC 2308, but to return a permanent negative be done according to RFC 2308, but to return a permanent negative
skipping to change at page 45, line 11 skipping to change at page 45, line 11
The folks on the IRTF ASRG mailing list. The folks on the IRTF ASRG mailing list.
The folks on the IETF MARID mailing list. The folks on the IETF MARID mailing list.
The folks on #perl. The folks on #perl.
12. IANA Considerations 12. IANA Considerations
12.1. The SPF DNS Record Type 12.1. The SPF DNS Record Type
Per [RFC4408], the IANA assigned the Resource Record Type and Qtype Per [RFC4408], the IANA assigned the Resource Record Type and Qtype
from the DNS Parameters Registry for the SPF RR type with code 99. from the DNS Parameters Registry for the SPF RR type with code 99.
The format of this type is identical to the TXT RR [RFC1035]. The
character content of the record is encoded as [US-ASCII]. Use of
this record type is obsolete for SPF Version 1.
12.2. The Received-SPF Mail Header Field 12.2. The Received-SPF Mail Header Field
Per [RFC3864], the "Received-SPF:" header field is added to the IANA Per [RFC3864], the "Received-SPF:" header field is added to the IANA
Permanent Message Header Field Registry. The following is the Permanent Message Header Field Registry. The following is the
registration template: registration template:
Header field name: Received-SPF Header field name: Received-SPF
Applicable protocol: mail ([RFC5322]) Applicable protocol: mail ([RFC5322])
Status: Standards Track Status: Standards Track
skipping to change at page 55, line 24 skipping to change at page 55, line 24
Updated informative references to the current versions. Updated informative references to the current versions.
Added definition for deprecated since there are questions. Added definition for deprecated since there are questions.
Start to rework section 9 with some RFC5598 terms. Start to rework section 9 with some RFC5598 terms.
Added mention of RFC 6552 feedback reports in section 9. Added mention of RFC 6552 feedback reports in section 9.
Added draft-ietf-spfbis-experiment as an informational reference. Added draft-ietf-spfbis-experiment as an informational reference.
Initial draft of wording to deprecate Type SPF. Drop Type SPF.
Try and clarify informational nature of RFC3696 Try and clarify informational nature of RFC3696
Author's Address Author's Address
Scott Kitterman Scott Kitterman
Agari Agari
3611 Scheel Dr 3611 Scheel Dr
Ellicott City, MD 21042 Ellicott City, MD 21042
United States of America United States of America
 End of changes. 11 change blocks. 
34 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart2386772.TyAdtBCW8h-- From vesely@tana.it Tue Jul 3 04:47:13 2012 Return-Path: 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 99F0E21F86FE for ; Tue, 3 Jul 2012 04:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 GKEMrVAMSkv8 for ; Tue, 3 Jul 2012 04:47:12 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8845021F882D for ; Tue, 3 Jul 2012 04:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1341316038; bh=0P5bW8eaICIQ79JXk+1OBEeT7XrR8F7ALJ3r/DHAuwY=; l=2453; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OU5n/3e4W5Q5m32o1v31FOQeGLPfL8flFbcBTMemj7FPUA7CBw0nmUMl/W6pX5jH5 NzKtY3GwE61+FI23TkFedT9ok4ivUaQ5Kmee+W+qkNZgYySjgSHrkuTQnRNEAFzQV3 J1nck73q4Xq6R8K7Q4B7j/uJIflkkD8oadQuHcKE= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 03 Jul 2012 13:47:18 +0200 id 00000000005DC039.000000004FF2DBC6.00003F1A Message-ID: <4FF2DBC6.3040906@tana.it> Date: Tue, 03 Jul 2012 13:47:18 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120629190443.9297.40140.idtracker@ietfa.amsl.com> <1610254.tmmhToiaLs@scott-latitude-e6320> <1567036.rU5QQqS7VH@scott-latitude-e6320> In-Reply-To: <1567036.rU5QQqS7VH@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-02.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 11:47:13 -0000 On Tue 03/Jul/2012 01:53:36 +0200 Scott Kitterman wrote: > > There seemed to be a general view that I had too much about Type SPF still in > the draft, so I've taken another whack at it and reduced it further. IMHO, that whack was a little bit too procrustean. The experiment I-D explains a good deal of background info, but does not anticipate what resolution is made at the protocol level --senders may publish, verifier should not query, IIRC. > In my last draft, I left the Type 99/SPF discussion in the IANA considerations > section. I did that on purpose because even though RFC 4408 will be obsolete > after 4408bis is published, we still want an active definition for the > assignment (to preserve it's use for SPF for the near future since people > won't immediately remove Type SPF records, to document that the code point > has been used and it not available, +1, that's needed. > and to make it easy for a future effort to pick up it's use again > if it were ever warranted). I'd keep neutral on this. We can divine neither what an incompatible change will want to do, nor how easy or difficult that will be. > I do think the body of the document needs to at least mention it for clarity, > but it should be more minimal than my original attempt. I'm attaching an > rfcdiff from the 02 draft to my current attempt. You'll see I moved some of > the information about type SPF to IANA considerations (not sure if I can do > that) and seriously slimmed down the discussion in the body of the draft. I'd keep something of the last paragraph of Section 3.1.1 (v -02). At least: An SPF-compliant domain name MUST have an SPF record of type TXT. Since the subsection's title is "DNS Resource Record Types", we might choose to concentrate the information on the move there, referring to Appendix A of [draft-ietf-spfbis-experiment] _for background_. Otherwise, we might drop the last word of the title. For the IANA considerations section, I'd limit to: IANA is requested to add an annotation to the SPF RRTYPE saying "(OBSOLETE - use TXT)" in the DNS Parameters registry. (to be changed to "has added" upon publication.) I wouldn't insist on "Version 1" more than necessary, since that is the same as 4408. US-ASCII should perhaps be changed to UTF-8 if we are going to allow that in mailbox names. See http://www.ietf.org/mail-archive/web/spfbis/current/msg01719.html jm2c From vesely@tana.it Tue Jul 3 04:49:28 2012 Return-Path: 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 25E9F21F8841 for ; Tue, 3 Jul 2012 04:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.534 X-Spam-Level: X-Spam-Status: No, score=-4.534 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 GG5eglrCSX74 for ; Tue, 3 Jul 2012 04:49:27 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A065621F8814 for ; Tue, 3 Jul 2012 04:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1341316172; bh=sV4CSGZHvP0pqvzfodOCt614ZssjLlcxLglEPTZJfZI=; l=984; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=e4CmFkMwYsmPkwLHnjhBM+pZfzEy/+BRHgSRmBA+hEUHHnRqE8Zzvnf1gUYgrqGYq iFeipHrL1L5LMYKN/vOrMDcLcSlecaRqMDYYAS9qwMhw481g30dhW/xq1BxkX+YKDz XUb11bfR+jW9yIROlugktJbns8f9MZGiS9pgtCgw= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 03 Jul 2012 13:49:32 +0200 id 00000000005DC039.000000004FF2DC4C.00003FB3 Message-ID: <4FF2DC4C.8040708@tana.it> Date: Tue, 03 Jul 2012 13:49:32 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <4FEB243F.50007@dcrocker.net> In-Reply-To: <4FEB243F.50007@dcrocker.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 11:49:28 -0000 On Wed 27/Jun/2012 17:18:23 +0200 Dave Crocker wrote: > > Small typo: > >> This alternate, is not intended to save further queries, which MUST >> be done according to RFC 2308, but to return a permanent negative >> completion reply code to the client, instead of a transient one, >> thereby shortening the queue time of messages that cannot be >> accepted. > > remove the first comma. > > > Howevever, for better readability and clarity, it would be a bit > cleaner to break the sentence up, along the lines of: > > This alternative is intended to shorten the queue time of messages > that cannot be accepted, by returning a permanent negative completion > reply code to the client, instead of a transient one. Saving queries > is accomplished according to [RFC2308]. +1, that sounds clearer to me. > (side point: there's no real need for a normative MUST here; it's not > really specifying basic DNS behavior, but instead pointing to a spec > that does.) From spf2@kitterman.com Tue Jul 3 06:35:12 2012 Return-Path: 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 A42A421F8777 for ; Tue, 3 Jul 2012 06:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 tnmmy2qabhoE for ; Tue, 3 Jul 2012 06:35:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 916FA21F8862 for ; Tue, 3 Jul 2012 06:35:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C6B9720E40BB; Tue, 3 Jul 2012 09:35:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341322518; bh=uxvncEkG7kHEW9tr8VCVgXEbg0deYIRbETkX5ZtQ8oQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JO+jPaOjLutPcxGb9pk8pMgQxUXdRSiYi1wy5E49o/3NQZC2zcTOimTynRnOsrBH5 ZdPYOXtxc8VGLyWGQ9HbHhP98wzLDSSjYvo13pQlYVHcxJRMUxyR0fBNbtS+5uk5Kk ghq6puB1iFHUpkNMBo7Q2O1Y7xTWqHs+6+O62IaU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ACE4620E409F; Tue, 3 Jul 2012 09:35:18 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Jul 2012 09:35:14 -0400 Message-ID: <41918716.FDGa5ArMJv@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FF2DC4C.8040708@tana.it> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <4FEB243F.50007@dcrocker.net> <4FF2DC4C.8040708@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 13:35:13 -0000 On Tuesday, July 03, 2012 01:49:32 PM Alessandro Vesely wrote: > On Wed 27/Jun/2012 17:18:23 +0200 Dave Crocker wrote: > > Small typo: > >> This alternate, is not intended to save further queries, which MUST > >> > >> be done according to RFC 2308, but to return a permanent > >> negative > >> completion reply code to the client, instead of a transient > >> one, > >> thereby shortening the queue time of messages that cannot be > >> accepted. > > > > remove the first comma. > > > > > > Howevever, for better readability and clarity, it would be a bit > > > > cleaner to break the sentence up, along the lines of: > > This alternative is intended to shorten the queue time of messages > > > > that cannot be accepted, by returning a permanent negative completion > > reply code to the client, instead of a transient one. Saving queries > > is accomplished according to [RFC2308]. > > +1, that sounds clearer to me. Changed locally for the next revision. Thanks. I also notice that I didn't have RFC 2308 listed as a proper reference. I've added it as an informative reference. Thanks, Scott K From spf2@kitterman.com Tue Jul 3 06:54:43 2012 Return-Path: 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 EF09621F87E2 for ; Tue, 3 Jul 2012 06:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 IYd8feBWMpxs for ; Tue, 3 Jul 2012 06:54:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E374F21F87B2 for ; Tue, 3 Jul 2012 06:54:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2B82120E40BB; Tue, 3 Jul 2012 09:54:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341323689; bh=beKdNSmmhmCtudTmpuRPXwyRPGIIJBOHwTLPbZMUoxI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cNx5aS0HRcfQgt7OlIzKH4t7PGDwYw9t5A1uSRY0FnkJNuRyvM7k7aa7/7kGj+tvh HfurMj3RfkX2rH+9CWt7g7/IXMdfxeB3ES5i+QvZDQAIvqHsyX6QKQPm7YE333kUoj cfhNn4DNS8ahhFPyV2X2wKN99hPcDfETWvgPBUMA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0C60620E409F; Tue, 3 Jul 2012 09:54:48 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Jul 2012 09:54:48 -0400 Message-ID: <4488420.DCBAqRgRYo@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FF2DBC6.3040906@tana.it> References: <20120629190443.9297.40140.idtracker@ietfa.amsl.com> <1567036.rU5QQqS7VH@scott-latitude-e6320> <4FF2DBC6.3040906@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-02.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 13:54:44 -0000 On Tuesday, July 03, 2012 01:47:18 PM Alessandro Vesely wrote: > On Tue 03/Jul/2012 01:53:36 +0200 Scott Kitterman wrote: > > There seemed to be a general view that I had too much about Type SPF still > > in the draft, so I've taken another whack at it and reduced it further. > IMHO, that whack was a little bit too procrustean. The experiment I-D > explains a good deal of background info, but does not anticipate what > resolution is made at the protocol level --senders may publish, > verifier should not query, IIRC. Please suggest text that you think would be reasonable. I think my latest attempt covers reasonably what implementors should do. If there is a gap in the why we decided that, I think it should probably be a sentence or two in sections 1.1 or 1.2. What are you thinking needs to be added? > > In my last draft, I left the Type 99/SPF discussion in the IANA > > considerations section. I did that on purpose because even though RFC > > 4408 will be obsolete after 4408bis is published, we still want an active > > definition for the assignment (to preserve it's use for SPF for the near > > future since people won't immediately remove Type SPF records, to > > document that the code point has been used and it not available, > > +1, that's needed. > > > and to make it easy for a future effort to pick up it's use again > > if it were ever warranted). > > I'd keep neutral on this. We can divine neither what an incompatible > change will want to do, nor how easy or difficult that will be. There are a number of people who believe that there is a need for a future SPF "Version 3" that will not have backward compatibility requirements. My view is that I'm not even going to think about it until after 4408bis is done. If we postulate such an incompatible update were to be desirable, then it should use type SPF from the beginning. There's nothing in the 4408bis drafts about potential future usage and I don't think there should be, so we don't need to divine anything. > > I do think the body of the document needs to at least mention it for > > clarity, but it should be more minimal than my original attempt. I'm > > attaching an rfcdiff from the 02 draft to my current attempt. You'll see > > I moved some of the information about type SPF to IANA considerations > > (not sure if I can do that) and seriously slimmed down the discussion in > > the body of the draft. > I'd keep something of the last paragraph of Section 3.1.1 (v -02). At > least: > > An SPF-compliant domain name MUST have an SPF record of type TXT. The first sentence of 3.1.1 is now (in my local copy/the diff I mailed): SPF records MUST be published as type TXT [RFC1035]. I think adding your proposed sentence back is redundant. What do you think it would add? > Since the subsection's title is "DNS Resource Record Types", we might > choose to concentrate the information on the move there, referring to > Appendix A of [draft-ietf-spfbis-experiment] _for background_. > Otherwise, we might drop the last word of the title. I fixed the title. > For the IANA considerations section, I'd limit to: > > IANA is requested to add an annotation to the SPF RRTYPE saying > "(OBSOLETE - use TXT)" in the DNS Parameters registry. > > (to be changed to "has added" upon publication.) I've added this, but not removed any of the existing text. > I wouldn't insist on "Version 1" more than necessary, since that is > the same as 4408. It's a bit difficult to know what to do here. Personally, I think the chances that a non-compatible future SPF revision will get significant deployment are small. Other people feel differently and so I think it is a good idea to be explicit that the obsoleteness is relative to version 1 here. > US-ASCII should perhaps be changed to UTF-8 if we are going to allow > that in mailbox names. See > http://www.ietf.org/mail-archive/web/spfbis/current/msg01719.html For now, I think it should stay US-ASCII. When we discuss IDN, then we can decide about that change. We'll need to look very carefully at the backward compatibility implications of such a change (I absolutely guarantee you not all current SPF libraries are UTF-8 clean). Scott K From spf2@kitterman.com Tue Jul 3 13:39:20 2012 Return-Path: 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 86DB511E8162 for ; Tue, 3 Jul 2012 13:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 HR+TXPI3Pcz4 for ; Tue, 3 Jul 2012 13:39:19 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B7C1011E8156 for ; Tue, 3 Jul 2012 13:39:19 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D186F20E40BB; Tue, 3 Jul 2012 16:39:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341347967; bh=JPiyVh5XgAQVX784yr0PEIxR4rykK2oFNxd3HslSNpA=; h=From:To:Subject:Date:From; b=UqGum/uRxUoJq9zjsbJ9f4+Hbr5qMkjHWrLGmhaBr3t76Q29kPTK5L49k9Zj8SGbl cL4FU7th/RemRlt3LnNiD8ajnEjgJb0GtPhGAo7g3SpD18vM0oQDOSwU1Or1Tm7Kqs Ny7WnksPaeMfJiqpmv9qQO+09ZjM3YCz7NgwTioU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B274D20E409F; Tue, 3 Jul 2012 16:39:27 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Jul 2012 16:39:27 -0400 Message-ID: <4155168.UcAXMpCzPG@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] New issue: ABNF Nits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 20:39:20 -0000 I ran the RFC 4408 collected ABNF through Bill's ABNF Parser. I collected a few potential issues, but no errors. Format: In the current ABNF, mechanisms an modifiers are all defined in a "name" "punctuation" styple. BIll's suggests combining the strings, i.e.: include = "include" ":" domain-spec would become: include = "include:" domain-spec Change these? Leave them? Don't care? Defined but not used: ; record defined but not used ; explain-string defined but not used ; header-field defined but not used ; identity defined but not used Record, explain-string, and header-field are all top level constructs that are used in the text, so I believe it's appropriate that they are not used. identity is, however, used in key, but it is (I believe) improperly quoted. I think (from the current draft): key = "client-ip" / "envelope-from" / "helo" / "problem" / "receiver" / "identity" / mechanism / name Should be changed to: key = "client-ip" / "envelope-from" / "helo" / "problem" / "receiver" / identity / mechanism / name I don't think this changes the ABNF, I think it corrects a defect. None of the other quoted keys are defined in the ABNF. Should they be? Undefined terms: ; SP UNDEFINED ; DIGIT UNDEFINED ; ALPHA UNDEFINED These should probably be defined (added to the imported definitions section). Where do I get them from? Scott K From johnl@iecc.com Tue Jul 3 14:47:08 2012 Return-Path: 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 6D01E11E8122 for ; Tue, 3 Jul 2012 14:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.098 X-Spam-Level: X-Spam-Status: No, score=-111.098 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 Z6yVGYWzkOna for ; Tue, 3 Jul 2012 14:47:07 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 859B611E80A3 for ; Tue, 3 Jul 2012 14:47:07 -0700 (PDT) Received: (qmail 55609 invoked from network); 3 Jul 2012 21:47:14 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Jul 2012 21:47:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4ff36862.xn--9vv.k1207; i=johnl@user.iecc.com; bh=sHMQwZ2wv03eWO+eL1/8kxI13F7I/5uIHoERhSLuKNE=; b=A/IkP1UTtCLF43cSvfwqLzz+mCOHPMnYawWkGZu9xk6l+lLBepjMvUvDm/+T1ENZLXwxv7pi4BUwnFLNGGN2ml7IecPfM17ofp5dBDGZzpT/u/natC/FZPMiF77sX+d6PumLeDbNJ+KM5dLF+JNPcVUNSVNRELudhbpPmOUBkpk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4ff36862.xn--9vv.k1207; olt=johnl@user.iecc.com; bh=sHMQwZ2wv03eWO+eL1/8kxI13F7I/5uIHoERhSLuKNE=; b=mwDI62/osm69H6JH0yvqdoWyrzf17qlOisglXJGKxPLRjOzd2dgOdWAJPitQPC4eaC15QTagFgbZPHWkzIuBjjlkKmewalxUcTDnvW4bT5jXTtA5kXmynVjr6gMB37WwkmX6Lv+fZuWCeAUnytopRgmgc9oz+Bzfd+25uNa1CL8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 3 Jul 2012 21:46:52 -0000 Message-ID: <20120703214652.98994.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4155168.UcAXMpCzPG@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] New issue: ABNF Nits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 21:47:08 -0000 >include = "include:" domain-spec > >Change these? Leave them? Don't care? If we were writing this from scratch, I'd say to change them, but since we aren't, as a general principle I would avoid changing things that we don't have to. If we leave them alone, people comparing 4408 and 4408bis can instantly tell that nothing changed. If we combine them, they have to figure out whether it was purely editorial or the syntax changed. >Should be changed to: > > key = "client-ip" / "envelope-from" / "helo" / > "problem" / "receiver" / identity / > mechanism / name > >I don't think this changes the ABNF, I think it corrects a defect. That's a bug, your fix looks correct. >Undefined terms: > >; SP UNDEFINED >; DIGIT UNDEFINED >; ALPHA UNDEFINED I'd suggest you import them from RFC 5234. R's, John From spf2@kitterman.com Tue Jul 3 15:15:54 2012 Return-Path: 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 E6C9421F860E for ; Tue, 3 Jul 2012 15:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 lfcqzSLh6pA8 for ; Tue, 3 Jul 2012 15:15:54 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 36B6B21F860B for ; Tue, 3 Jul 2012 15:15:54 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D461420E40BB; Tue, 3 Jul 2012 18:16:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341353762; bh=4H3H9Fe/g8fWxkdGQMDwb4URBkXRNACSn0ley2c2zEc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nEaO7x10EOQdTbPaCb5Fts2EqqAx4dEQMvW/fluDa3YjgnZhyWhU2eEe6P3QEjeuf ua12iB0YLqk1vB569mmL69Cd7vbZ3T5Rh3fjmnk+rO5YJnHx/UbfzjUlTp1qutyW0C DGbVgtJCqnKJ6VTS51Onnp7CHjBp3VhtJO4Q75SE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BA8A520E409F; Tue, 3 Jul 2012 18:16:02 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Jul 2012 18:16:02 -0400 Message-ID: <2445655.Qs2iHhvcP9@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120703214652.98994.qmail@joyce.lan> References: <20120703214652.98994.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart4458712.SgQFxqRWxK" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue: ABNF Nits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 22:15:55 -0000 --nextPart4458712.SgQFxqRWxK Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Tuesday, July 03, 2012 09:46:52 PM John Levine wrote: > >include = "include:" domain-spec > > > >Change these? Leave them? Don't care? > > If we were writing this from scratch, I'd say to change them, but since we > aren't, as a general principle I would avoid changing things that we don't > have to. If we leave them alone, people comparing 4408 and 4408bis can > instantly tell that nothing changed. If we combine them, they have to > figure out whether it was purely editorial or the syntax changed. That makes sense. I left them as they were. > >Should be changed to: > > key = "client-ip" / "envelope-from" / "helo" / > > > > "problem" / "receiver" / identity / > > > > mechanism / name > > > >I don't think this changes the ABNF, I think it corrects a defect. > > That's a bug, your fix looks correct. > > >Undefined terms: > > > >; SP UNDEFINED > >; DIGIT UNDEFINED > >; ALPHA UNDEFINED > > I'd suggest you import them from RFC 5234. Perfect. Changed those. Attached is the relevant diff I have locally. Thanks for the quick feedback, Scott K --nextPart4458712.SgQFxqRWxK Content-Disposition: attachment; filename="abnf.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="abnf.patch" --- draft-ietf-spfbis-4408bis-02.txt 2012-06-29 15:01:10.316355215 -0400 +++ draft-ietf-spfbis-4408bis-03.txt 2012-07-03 18:07:59.354907520 -0400 @@ -311,7 +311,9 @@ 1.3.2. Imported Definitions - The ABNF token "local-part" is defined in [RFC5321]. + The ABNF tokens "ALPHA", "DIGIT", and "SP" are defined in [RFC5234]. + + The token "local-part" is defined in [RFC5321]. "CFWS" and "FWS" are defined in [RFC5322] @@ -2780,25 +2780,81 @@ key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key = "client-ip" / "envelope-from" / "helo" / - "problem" / "receiver" / "identity" / + "problem" / "receiver" / identity / mechanism / name identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity / name ; other identities + ALPHA = + DIGIT = <0-9 as per [RFC5234]> + SP = dot-atom = quoted-string = comment = @@ -3048,7 +3106,8 @@ Try and clarify informational nature of RFC3696 + Fix ABNF nits per Bill's ABNF checker. --nextPart4458712.SgQFxqRWxK-- From spf2@kitterman.com Tue Jul 3 16:07:41 2012 Return-Path: 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 4FAE111E8087 for ; Tue, 3 Jul 2012 16:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Wj6mJsLgV5D2 for ; Tue, 3 Jul 2012 16:07:40 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC3211E80DB for ; Tue, 3 Jul 2012 16:07:40 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E8F2B20E40BB; Tue, 3 Jul 2012 19:07:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341356869; bh=BS7T/SaB+wme4YUBehSUgOEuoIhKbBvOeSz/njfYWA4=; h=From:To:Subject:Date:From; b=geTst+dGWEUsGhp09lP6ml1warw7wxQCWAah6odoUo0C2+mJzogSDSAd88jGz1Now QKvJSwWoITH1FGr8LxtOoulvxoQWN+jbZx9MMcAjFi+j46HPbEZjxYtZJXIsgJYszE DNYaHRdNfUtwZm2V4QjJNupQtKTN5FSBtcP05Fb4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CB2CA20E409F; Tue, 3 Jul 2012 19:07:48 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Jul 2012 19:07:48 -0400 Message-ID: <8827104.9HMQJuoa7q@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] New Issue (#31): Lookup Time Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 23:07:41 -0000 I'm currently working on issue #6, RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization. I came across one change that I think we should make (and can make within the charter), but it's not strictly editorial, so I'm raising it here for discussion. RFC 4408 says this about lookup time limits: MTAs or other processors MAY also impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be "temperror". I think every implementation ought to have some kind of time limit. It would be a DoS risk not to. I'd like to change the MAY above to SHOULD. It doesn't raise any incompatibilities and reflects common practice (and arguably fixes a clear bug in the spec). The new text would be: MTAs or other processors SHOULD impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be "temperror". Objections, comments? Scott K From spf2@kitterman.com Tue Jul 3 16:39:15 2012 Return-Path: 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 F06F711E80CE for ; Tue, 3 Jul 2012 16:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 9cIqB+vqBUSt for ; Tue, 3 Jul 2012 16:39:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2B54511E808D for ; Tue, 3 Jul 2012 16:39:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BD06E20E40BB; Tue, 3 Jul 2012 19:39:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341358762; bh=fr6ip7qcf2luWWGeZL9Z+2kXY9IaP6WoU7cPgemuqko=; h=From:To:Subject:Date:From; b=bGUBJ2G0iS/E+msutyYBTmgPtMSjzUVkMImydjr5dyydLDnv3e53DcaQH8bg18jdx oEjiKtZcSJ9m/mi6JUMwxRapJXzbLLWCPsXMgVxxhZkDi7mrc1RELzDDhVmDMkD+YJ swDAnUdxfvr+FXClmyfAyP2fT7uk2UtTdaNumMVw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9E11420E409F; Tue, 3 Jul 2012 19:39:22 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Jul 2012 19:39:22 -0400 Message-ID: <1545953.Y9VaoKsXxF@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] New Issue: #32 DNS data limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 23:39:15 -0000 The RFC 4408 processing limits suggest the following: SPF implementations SHOULD limit the total amount of data obtained from the DNS queries. For example, when DNS over TCP or EDNS0 are available, there might need to be an explicit limit to how much data will be accepted to prevent excessive bandwidth usage or memory usage and DoS attacks. Given the limits in record lookups and time (see my last new issue) do we also need a data limit? My problem is that this requirement is entirely unquantifiable. How much is too much? I'm not aware of any implementations that actually do data volume limits, just number of lookups and time. Can/should this be deleted as unused? Is anyone aware of its use? Scott K From spf2@kitterman.com Tue Jul 3 17:17:18 2012 Return-Path: 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 978FD21F86B1 for ; Tue, 3 Jul 2012 17:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 975zNKqf-bYw for ; Tue, 3 Jul 2012 17:17:17 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 38E3F21F86A6 for ; Tue, 3 Jul 2012 17:17:17 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0571020E40BB; Tue, 3 Jul 2012 20:17:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341361046; bh=9V3BcZ7XHS5wW94/VfkhRgPSvmsjS9QfpLd6xiIqsfg=; h=From:To:Subject:Date:From; b=CTEJmeWnH6RXzGnaOefEYSv1mOq+XIlNj58wScHLxhxvg5Tso4Z8PDJJaWmqKBNaO VIZizaDT6OORE/nyBQr5eqBEV3/8qsXQICnGzW4zsdaceYSK0RpvQh2Q08GmitynZH KEQDtJpSqAvLnSHcQ/fXITw/AmhZ796KvMUnwP/k= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DC22320E409F; Tue, 3 Jul 2012 20:17:25 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Jul 2012 20:17:25 -0400 Message-ID: <1977882.Ft2hpQpDVK@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Fwd: [spf-discuss] SPF and SERVFAIL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 00:17:19 -0000 Given where the WG stands on SERVFAIL (it's still a temperror with the option to escalate to a permerror) I thought this was worth forwarding to the group for consideration. Scott K ---------- Forwarded Message ---------- Subject: [spf-discuss] SPF and SERVFAIL Date: Wednesday, July 04, 2012, 09:36:26 AM From: Wayne Doust To: spf-discuss@listbox.com I perceive a 3-part problem with SPF and SERVFAIL. 1) Most SPF implementations treat any failure in resolving/retrieving/parsing an SPF record as a TEMPFAIL and issuing 4xx. On the surface, this appears to be a reasonable approach - unless something in that process is broken.... 2) Most mail sysadmins seem to have no idea on how to manage/tune/control their SPF mechanisms. They simply come bolted on to a mail filter appliance they own and they check the box that save "SPF Checking Enabled" and that's the end of the story. They also do not collect statistics; do no reporting and probably aren't aware of where (if any) log files are stored. This makes it difficult for them to resolve issues in part 1. 3) The technical competence of the organisation or ISP seems to be inversely proportional to its size. This generally means the greater the effect on your organisation, the more difficult it is to get the remote organisation to even recognise a problem exists. Over the past 12 months, I have had five incidences of remote mail servers rejecting email based on SERVFAIL. The problem has not been our DNS or our SPF record. It has been the problem of the remote mail server performing the SPF lookup and failing on "something". In most cases the other end has not been able to determine the cause and they have simply chosen to whitelist our domain - which IMO is not a solution and defeats the purpose of SPF. One recent case involves a very large ISP in Australia. It has taken four weeks for them to recognise a problem exists. That's four weeks of me calling them every day. I suspect the problem lies in the lesser utilised features of SPF. Our record adds an IP4 netblock. Another domain has an include statement. These are the only two domains that have experienced problems with SERVFAIL. We don't use macros but I wonder how well some of the implementations will handle that? IMO, the default and recommended response to an SPF SERVFAIL should be a NEUTRAL result. Ie treat the domain as if it had no SPF record at all. This would eliminate issues such as this which can only occur if the sending domain actually has an SPF record. From ajs@anvilwalrusden.com Tue Jul 3 18:47:33 2012 Return-Path: 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 951F021F85E0 for ; Tue, 3 Jul 2012 18:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 eWNFGOAnpjM7 for ; Tue, 3 Jul 2012 18:47:32 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8147721F85DB for ; Tue, 3 Jul 2012 18:47:32 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 6DF798A031 for ; Wed, 4 Jul 2012 01:47:40 +0000 (UTC) Date: Tue, 3 Jul 2012 21:47:24 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120704014723.GA12452@crankycanuck.ca> References: <1977882.Ft2hpQpDVK@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1977882.Ft2hpQpDVK@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Fwd: [spf-discuss] SPF and SERVFAIL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 01:47:33 -0000 Hi, No hat. On Tue, Jul 03, 2012 at 08:17:25PM -0400, Scott Kitterman wrote: > Given where the WG stands on SERVFAIL (it's still a temperror with the option > to escalate to a permerror) I thought this was worth forwarding to the group > for consideration. SPF depends on DNS. In the DNS, SERVFAIL means the server you are talking to failed, for some reason, you don't know what, and therefore you should probably try something else -- try again later, try one of the other authoritative servers, whatever. Servers return SERVFAIL when DNSSEC validation fails, when they're still loading the zone, when they've just crashed and are restarting, and all sorts of other reasons. Now, I have no difficulty if the WG wants to say that a SERVFAIL gives you no knowledge. So NEUTRAL might be all right. But presumably, that ought to be true for other DNS error codes other than 0 and 3, also, no? If you get (for instance) REFUSED or NOTIMP, shouldn't they be the same as SERVFAIL? Best, A > > Scott K > > ---------- Forwarded Message ---------- > > Subject: [spf-discuss] SPF and SERVFAIL > Date: Wednesday, July 04, 2012, 09:36:26 AM > From: Wayne Doust > To: spf-discuss@listbox.com > > I perceive a 3-part problem with SPF and SERVFAIL. > > 1) Most SPF implementations treat any failure in > resolving/retrieving/parsing an SPF record as a TEMPFAIL and issuing > 4xx. On the surface, this appears to be a reasonable approach - unless > something in that process is broken.... > > 2) Most mail sysadmins seem to have no idea on how to > manage/tune/control their SPF mechanisms. They simply come bolted on to > a mail filter appliance they own and they check the box that save "SPF > Checking Enabled" and that's the end of the story. They also do not > collect statistics; do no reporting and probably aren't aware of where > (if any) log files are stored. This makes it difficult for them to > resolve issues in part 1. > > 3) The technical competence of the organisation or ISP seems to be > inversely proportional to its size. This generally means the greater the > effect on your organisation, the more difficult it is to get the remote > organisation to even recognise a problem exists. > > Over the past 12 months, I have had five incidences of remote mail > servers rejecting email based on SERVFAIL. The problem has not been our > DNS or our SPF record. It has been the problem of the remote mail server > performing the SPF lookup and failing on "something". In most cases the > other end has not been able to determine the cause and they have simply > chosen to whitelist our domain - which IMO is not a solution and defeats > the purpose of SPF. > > One recent case involves a very large ISP in Australia. It has taken > four weeks for them to recognise a problem exists. > > That's four weeks of me calling them every day. > > I suspect the problem lies in the lesser utilised features of SPF. Our > record adds an IP4 netblock. Another domain has an include statement. > These are the only two domains that have experienced problems with > SERVFAIL. We don't use macros but I wonder how well some of the > implementations will handle that? > > IMO, the default and recommended response to an SPF SERVFAIL should be a > NEUTRAL result. Ie treat the domain as if it had no SPF record at all. > This would eliminate issues such as this which can only occur if the > sending domain actually has an SPF record. > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Andrew Sullivan ajs@crankycanuck.ca From ajs@anvilwalrusden.com Tue Jul 3 18:51:49 2012 Return-Path: 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 27E3611E80D9 for ; Tue, 3 Jul 2012 18:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 O0wxSAjM09X2 for ; Tue, 3 Jul 2012 18:51:48 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0327511E80AE for ; Tue, 3 Jul 2012 18:51:48 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 013798A031 for ; Wed, 4 Jul 2012 01:51:56 +0000 (UTC) Date: Tue, 3 Jul 2012 21:51:56 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120704015156.GB12452@crankycanuck.ca> References: <1545953.Y9VaoKsXxF@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1545953.Y9VaoKsXxF@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] New Issue: #32 DNS data limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 01:51:49 -0000 No hat. On Tue, Jul 03, 2012 at 07:39:22PM -0400, Scott Kitterman wrote: > SPF implementations SHOULD limit the total amount of data obtained > from the DNS queries. For example, when DNS over TCP or EDNS0 are > available, there might need to be an explicit limit to how much data > will be accepted to prevent excessive bandwidth usage or memory > usage and DoS attacks. I confess, I always found that passage mystifying. If you issue a query and fall back to TCP, there's no mechanism for you to "turn off" a big answer. Same thing with a large EDNS0 buffer (indeed, this problem is what makes reflector attacks so devastating in the DNS). > I'm not aware of any implementations that actually do data volume limits, just > number of lookups and time. Can/should this be deleted as unused? Is anyone > aware of its use? Given the above, there's no practical difference between "limit number of queries" and "data volume limit", I suspect. At the same time (and I emphasise, no hat), since the passage doesn't seem to be operative and removing it would be a change, perhaps it'd be better to leave it until a later update? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Jul 3 18:56:45 2012 Return-Path: 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 EECF411E80D9 for ; Tue, 3 Jul 2012 18:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 F4KawEMan0LQ for ; Tue, 3 Jul 2012 18:56:44 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8C611E80AE for ; Tue, 3 Jul 2012 18:56:44 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 5BA458A031 for ; Wed, 4 Jul 2012 01:56:53 +0000 (UTC) Date: Tue, 3 Jul 2012 21:56:53 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120704015653.GC12452@crankycanuck.ca> References: <8827104.9HMQJuoa7q@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8827104.9HMQJuoa7q@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] New Issue (#31): Lookup Time Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 01:56:45 -0000 No hat. On Tue, Jul 03, 2012 at 07:07:48PM -0400, Scott Kitterman wrote: > > MTAs or other processors MAY also impose a limit on the maximum > amount of elapsed time to evaluate check_host(). Such a limit > SHOULD allow at least 20 seconds. If such a limit is exceeded, the > result of authorization SHOULD be "temperror". > > I think every implementation ought to have some kind of time limit. It would > be a DoS risk not to. I'd like to change the MAY above to SHOULD. IMO, the purpose of a 2119 SHOULD is not "eat your broccoli; it's good for you." A good rule of thumb is, if you have a SHOULD, you ought to be able to say why it's not MUST (i.e. under what conditions it would be ok not to do the thing you SHOULD do). Since the IETF is about interoperability, this harm should be an interoperability issue. None of this is to disagree that implementations _ought to_ have a time limit. That's not what SHOULD in 2119 means, though, IMO, and as near as I can tell there is no interoperability reason why implementations really ought to do this almost always (but not always). Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Tue Jul 3 19:17:59 2012 Return-Path: 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 5CAA311E80BF for ; Tue, 3 Jul 2012 19:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 fFTA5SBXDeC7 for ; Tue, 3 Jul 2012 19:17:58 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8448D11E80AE for ; Tue, 3 Jul 2012 19:17:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8E26620E40BB; Tue, 3 Jul 2012 22:18:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341368287; bh=1O6txoZS294Z+2EVGwF2QKN0ZGfOQ+gz1XenjdwAOCk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lThJUy+GQqShYGzA4FrHh5Q3SYJONoifXM4w9KmpU8zzXYYaTB6d9/Bs88CmiVg7u E20qGMupXI8RhBKI1VLGQFHbWHod9I+bjY+x9QiHG+fhhOum3OEUrQZgnGVQ4Oau1V enVQMWCmSqT+5c5XYVzag/v2lsgX1U5VVP8RBc0E= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7123320E409F; Tue, 3 Jul 2012 22:18:07 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Jul 2012 22:18:06 -0400 Message-ID: <1977893.MDoye0cYQa@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120704015156.GB12452@crankycanuck.ca> References: <1545953.Y9VaoKsXxF@scott-latitude-e6320> <20120704015156.GB12452@crankycanuck.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue: #32 DNS data limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 02:17:59 -0000 On Tuesday, July 03, 2012 09:51:56 PM Andrew Sullivan wrote: > No hat. > > On Tue, Jul 03, 2012 at 07:39:22PM -0400, Scott Kitterman wrote: > > SPF implementations SHOULD limit the total amount of data > > obtained > > from the DNS queries. For example, when DNS over TCP or EDNS0 > > are > > available, there might need to be an explicit limit to how much > > data > > will be accepted to prevent excessive bandwidth usage or memory > > usage and DoS attacks. > > I confess, I always found that passage mystifying. If you issue a > query and fall back to TCP, there's no mechanism for you to "turn off" > a big answer. Same thing with a large EDNS0 buffer (indeed, this > problem is what makes reflector attacks so devastating in the DNS). > > > I'm not aware of any implementations that actually do data volume limits, > > just number of lookups and time. Can/should this be deleted as unused? > > Is anyone aware of its use? > > Given the above, there's no practical difference between "limit number > of queries" and "data volume limit", I suspect. At the same time (and > I emphasise, no hat), since the passage doesn't seem to be operative > and removing it would be a change, perhaps it'd be better to leave it > until a later update? The charter says we can remove things that are unused. Since this particular SHOULD is unimplementable, it's unused by definition. I think we can remove it. Is there a reason we should not? I agree that there's not a practical difference to leave/remove it, but removing it makes the document clearer and more concise. Scott K From spf2@kitterman.com Tue Jul 3 19:20:16 2012 Return-Path: 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 04CC011E80AE for ; Tue, 3 Jul 2012 19:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 I03nNDYfPd34 for ; Tue, 3 Jul 2012 19:20:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A13B011E8080 for ; Tue, 3 Jul 2012 19:20:07 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CB9E320E40BB; Tue, 3 Jul 2012 22:20:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341368416; bh=o9opTiSngI0oDYCHJfaEZz+4dbEAdA3en5cobael3BM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=k9Tm+2hWz8GiLeLbQ4jok+v/KMj+LaNokhfoDYi0YLsNkw69Ad9hESrGSMaWPaD66 InvhjXx5aRECDfxIDG/pjkPSHKKPbGI5lvxb1G7PBMA24L8qtHCnr3DdhGBMKiePVu xoDYYXuBtrWHhJ4vgDlvO3Q7TtYRim3sl7ztMn+k= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B1B0820E409F; Tue, 3 Jul 2012 22:20:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Jul 2012 22:20:16 -0400 Message-ID: <5885582.pHJZRIJaWf@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120704015653.GC12452@crankycanuck.ca> References: <8827104.9HMQJuoa7q@scott-latitude-e6320> <20120704015653.GC12452@crankycanuck.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue (#31): Lookup Time Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 02:20:16 -0000 On Tuesday, July 03, 2012 09:56:53 PM Andrew Sullivan wrote: > No hat. > > On Tue, Jul 03, 2012 at 07:07:48PM -0400, Scott Kitterman wrote: > > MTAs or other processors MAY also impose a limit on the maximum > > amount of elapsed time to evaluate check_host(). Such a limit > > SHOULD allow at least 20 seconds. If such a limit is exceeded, the > > result of authorization SHOULD be "temperror". > > > > I think every implementation ought to have some kind of time limit. It > > would be a DoS risk not to. I'd like to change the MAY above to SHOULD. > IMO, the purpose of a 2119 SHOULD is not "eat your broccoli; it's good > for you." A good rule of thumb is, if you have a SHOULD, you ought to > be able to say why it's not MUST (i.e. under what conditions it would > be ok not to do the thing you SHOULD do). Since the IETF is about > interoperability, this harm should be an interoperability issue. > > None of this is to disagree that implementations _ought to_ have a > time limit. That's not what SHOULD in 2119 means, though, IMO, and as > near as I can tell there is no interoperability reason why > implementations really ought to do this almost always (but not > always). I was thinking in terms of SHOULD (due to security considerations) do this, but not MUST because if you want to get eaten by a DoS attack you're welcome to do so. That's probably wrong thinking in 2119 terms, but OTOH, if you're DoS'ed you aren't interoperating with anyone. Scott K From superuser@gmail.com Tue Jul 3 20:52:21 2012 Return-Path: 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 D1B2721F8627 for ; Tue, 3 Jul 2012 20:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 nF2nGSWQRVuP for ; Tue, 3 Jul 2012 20:52:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 15DEE21F8621 for ; Tue, 3 Jul 2012 20:52:21 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12411747obb.31 for ; Tue, 03 Jul 2012 20:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wE4c8mr0dlUPh8maIcaV7DudlK8PmfDJdCN13Tbn72c=; b=qS/LkQg3TGF4jMeGLaYAByp7u6Rjejvf1Svue9nZ+qLxieM36jrXYLIMt36Dh5vndr OG399lNZnb10mf4fNluUxEdyDIPR0LAnjd8VDIzuuOJGoLvxCnbd9H1g5+AegosL8K+j 6t5N9hgGpgz8ZIQzuFGUw2MDaXx6xHlXeYzPE7lqUOQZilIT33p2F8Sn8pVhU0jKx+DE T3xqbbk92zPoMq5/HAnF2h7nhCiyN9iMND4C/80yemCVCi+AZiGIQVBH+wYPWwATKw6e yzitwCJ8oDLeHcS611U4kqvKyUiqysnKP8aAM75p4sT6EgYxzdbVfWRzYYIPFmPCNqpr IGMg== MIME-Version: 1.0 Received: by 10.182.111.39 with SMTP id if7mr15609135obb.56.1341373950532; Tue, 03 Jul 2012 20:52:30 -0700 (PDT) Received: by 10.182.28.65 with HTTP; Tue, 3 Jul 2012 20:52:30 -0700 (PDT) In-Reply-To: <4155168.UcAXMpCzPG@scott-latitude-e6320> References: <4155168.UcAXMpCzPG@scott-latitude-e6320> Date: Tue, 3 Jul 2012 20:52:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=14dae9399087d51c3e04c3f8f5e3 Cc: spfbis@ietf.org Subject: Re: [spfbis] New issue: ABNF Nits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 03:52:22 -0000 --14dae9399087d51c3e04c3f8f5e3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 3, 2012 at 1:39 PM, Scott Kitterman wrote: > I ran the RFC 4408 collected ABNF through Bill's ABNF Parser. I collected > a > few potential issues, but no errors. > > Format: > > In the current ABNF, mechanisms an modifiers are all defined in a "name" > "punctuation" styple. BIll's suggests combining the strings, i.e.: > > include = "include" ":" domain-spec > > would become: > > include = "include:" domain-spec > > Change these? Leave them? Don't care? > Combine them. > identity is, however, used in key, but it is (I believe) improperly > quoted. I > think (from the current draft): > > key = "client-ip" / "envelope-from" / "helo" / > "problem" / "receiver" / "identity" / > mechanism / name > > Should be changed to: > > key = "client-ip" / "envelope-from" / "helo" / > "problem" / "receiver" / identity / > mechanism / name > > I don't think this changes the ABNF, I think it corrects a defect. > +1. > > None of the other quoted keys are defined in the ABNF. Should they be? > If they're quoted, they don't need to be. > > Undefined terms: > > ; SP UNDEFINED > ; DIGIT UNDEFINED > ; ALPHA UNDEFINED > > These should probably be defined (added to the imported definitions > section). > Where do I get them from? > RFC5234. -MSK --14dae9399087d51c3e04c3f8f5e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2012 at 1:39 PM, Scott Kitterman <spf2@kitterman.com&g= t; wrote:
I ran the RFC 4408 collected ABNF through Bill's ABNF Parser. =A0I coll= ected a
few potential issues, but no errors.

Format:

In the current ABNF, mechanisms an modifiers are all defined in a "nam= e"
"punctuation" styple. =A0BIll's suggests combining the string= s, i.e.:

include =3D "include" =A0":" domain-spec

would become:

include =3D "include:" domain-spec

Change these? =A0Leave them? =A0Don't care?

Co= mbine them.
=A0
identity is, however, used in key, but it is (I believe) improperly quoted.= =A0I
think (from the current draft):

=A0 =A0 =A0 =A0 =A0 =A0key =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D "client-ip&q= uot; / "envelope-from" / "helo" /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "problem&q= uot; / "receiver" / "identity" /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mechanism / = name

Should be changed to:

=A0 =A0 =A0 =A0 =A0 =A0key =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D "client-ip&q= uot; / "envelope-from" / "helo" /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "problem&q= uot; / "receiver" / identity /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mechanism / = name

I don't think this changes the ABNF, I think it corrects a defect.
<= /blockquote>

+1.
=A0

None of the other quoted keys are defined in the ABNF. =A0Should they be?

If they're quoted, they don't need to be.=A0

Undefined terms:

; SP UNDEFINED
; DIGIT UNDEFINED
; ALPHA UNDEFINED

These should probably be defined (added to the imported definitions section= ).
Where do I get them from?

RFC5234.

-MSK
=
--14dae9399087d51c3e04c3f8f5e3-- From superuser@gmail.com Tue Jul 3 20:57:14 2012 Return-Path: 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 34BB711E80E9 for ; Tue, 3 Jul 2012 20:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 1vytpISemOkP for ; Tue, 3 Jul 2012 20:57:13 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 956FC21F8634 for ; Tue, 3 Jul 2012 20:57:13 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12417258obb.31 for ; Tue, 03 Jul 2012 20:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8pvhHxh2/lgpLHYxjBcxPeJL2MPWLK2vMNOPn/GzV4U=; b=0BDTveA764aIBFq+wYKsw9VZvinFNRYMlErh/Ohv8Pv2EJbPyeuKSAEdNNvVq6dAZU WBwIRIyzU57+z2IQprYLJb6d2q05LRZiEKPhh+egyxUVlUyMMUENxtNPPplymEGE83IM FeDUZ+5CMQwL4IrQe0fcStpZgBC4Re7dajGDJSdD9AH+sBJjADbClGTwrhSsSnOFiWnJ OsH3s51YEHZ4NCMnSNKgqVaXMbsuXf+jWfJ5GEOyZiqxzv5/+VzeqFhRqDuwaJblqBBg Qpnza8MMujeUN7xR8hGsPlTvL3wc7FMj0kGUYffDNyrwNqEvh4kcPACVzZltQGkIRoOS sGrw== MIME-Version: 1.0 Received: by 10.182.16.3 with SMTP id b3mr15542413obd.72.1341374242981; Tue, 03 Jul 2012 20:57:22 -0700 (PDT) Received: by 10.182.28.65 with HTTP; Tue, 3 Jul 2012 20:57:22 -0700 (PDT) In-Reply-To: <20120704014723.GA12452@crankycanuck.ca> References: <1977882.Ft2hpQpDVK@scott-latitude-e6320> <20120704014723.GA12452@crankycanuck.ca> Date: Tue, 3 Jul 2012 20:57:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=f46d04462f664388c104c3f90765 Cc: spfbis@ietf.org Subject: Re: [spfbis] Fwd: [spf-discuss] SPF and SERVFAIL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 03:57:14 -0000 --f46d04462f664388c104c3f90765 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 3, 2012 at 6:47 PM, Andrew Sullivan wrote: > SPF depends on DNS. In the DNS, SERVFAIL means the server you are > talking to failed, for some reason, you don't know what, and therefore > you should probably try something else -- try again later, try one of > the other authoritative servers, whatever. Servers return SERVFAIL > when DNSSEC validation fails, when they're still loading the zone, > when they've just crashed and are restarting, and all sorts of other > reasons. > > Now, I have no difficulty if the WG wants to say that a SERVFAIL gives > you no knowledge. So NEUTRAL might be all right. But presumably, > that ought to be true for other DNS error codes other than 0 and 3, > also, no? If you get (for instance) REFUSED or NOTIMP, shouldn't they > be the same as SERVFAIL? > > My preference would be to point out that SERVFAIL can happen for any reason other than total success of the query's resolution. The error could be transient, or it could be something severe. Unfortunately, there's no way to tell. SPF verifiers should be aware of this and respond accordingly. So basically, give implementers the knowledge they need to pick an intelligent course of action, but don't specify what that ought to be. I'd probably be comfortable advising against outright rejection, but I'm not sure I'd recommend a specific SPF result code or neutral+deliver vs. temp-fail. -MSK --f46d04462f664388c104c3f90765 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2012 at 6:47 PM, Andrew Sullivan <ajs@anvilwalrusden.c= om> wrote:
SPF depends on DNS. =A0In the DNS, SERVFAIL means the server you are
talking to failed, for some reason, you don't know what, and therefore<= br> you should probably try something else -- try again later, try one of
the other authoritative servers, whatever. =A0Servers return SERVFAIL
when DNSSEC validation fails, when they're still loading the zone,
when they've just crashed and are restarting, and all sorts of other reasons.

Now, I have no difficulty if the WG wants to say that a SERVFAIL gives
you no knowledge. =A0So NEUTRAL might be all right. =A0But presumably,
that ought to be true for other DNS error codes other than 0 and 3,
also, no? =A0If you get (for instance) REFUSED or NOTIMP, shouldn't the= y
be the same as SERVFAIL?


My preference would be to point out that SERVFAIL= can happen for any reason other than total success of the query's reso= lution.=A0 The error could be transient, or it could be something severe.= =A0 Unfortunately, there's no way to tell.=A0 SPF verifiers should be a= ware of this and respond accordingly.=A0 So basically, give implementers th= e knowledge they need to pick an intelligent course of action, but don'= t specify what that ought to be.

I'd probably be comfortable advising against outright r= ejection, but I'm not sure I'd recommend a specific SPF result code= or neutral+deliver vs. temp-fail.

-MSK
--f46d04462f664388c104c3f90765-- From superuser@gmail.com Tue Jul 3 20:59:26 2012 Return-Path: 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 CD1A021F8699 for ; Tue, 3 Jul 2012 20:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 PwMwAEGCy74Z for ; Tue, 3 Jul 2012 20:59:26 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4246211E80F5 for ; Tue, 3 Jul 2012 20:59:26 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12420008obb.31 for ; Tue, 03 Jul 2012 20:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p7A159XjeCuf4Saq9JFTjru33kKDfOq5GlXYOpEybSs=; b=LoEThZEivtNXGNP2gT9Yne8LXipdwYEOtbR89FrigSctkZ7fZCp2IF+BW4ar/waSh7 aH/6o7/+VvAJlKZqYRBJdzzkVSMH1teT2z6W1WSnewUIrWl3mLcbkkBJvVmqHA6rLBt1 nkTwqjmKO2nNMMijvY7QeFz2oZ2rknhJV/a9re+usOY7sqNhYoQELLXCRe+2RgXvRce9 CO6BNMlPoy1wGT8zpwhuW/QZxu7NY7z6RBAO8DsqmJdS30OpGhPYxcfjFMTowpVPsPry WKxiR0PlZrPQOhQTMiyvRvKyr8J56wPONQQqQg3MVP1pLpkiaSi5PIaKz0MzVrNvWR2J TPgA== MIME-Version: 1.0 Received: by 10.60.20.136 with SMTP id n8mr21067291oee.54.1341374375752; Tue, 03 Jul 2012 20:59:35 -0700 (PDT) Received: by 10.182.28.65 with HTTP; Tue, 3 Jul 2012 20:59:35 -0700 (PDT) In-Reply-To: <1977893.MDoye0cYQa@scott-latitude-e6320> References: <1545953.Y9VaoKsXxF@scott-latitude-e6320> <20120704015156.GB12452@crankycanuck.ca> <1977893.MDoye0cYQa@scott-latitude-e6320> Date: Tue, 3 Jul 2012 20:59:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=e89a8fb1fcde2d72c304c3f90f4a Cc: spfbis@ietf.org Subject: Re: [spfbis] New Issue: #32 DNS data limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 03:59:26 -0000 --e89a8fb1fcde2d72c304c3f90f4a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 3, 2012 at 7:18 PM, Scott Kitterman wrote: > > Given the above, there's no practical difference between "limit number > > of queries" and "data volume limit", I suspect. At the same time (and > > I emphasise, no hat), since the passage doesn't seem to be operative > > and removing it would be a change, perhaps it'd be better to leave it > > until a later update? > > The charter says we can remove things that are unused. Since this > particular > SHOULD is unimplementable, it's unused by definition. I think we can > remove > it. Is there a reason we should not? I agree that there's not a practical > difference to leave/remove it, but removing it makes the document clearer > and > more concise. > > I agree that it's both removable (in terms of the charter) and that it should be removed. -MSK --e89a8fb1fcde2d72c304c3f90f4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2012 at 7:18 PM, Scott Kitterman <spf2@kitterman.com&g= t; wrote:
> Given the above, there's no practical difference= between "limit number
> of queries" and "data volume limit", I suspect. =A0At t= he same time (and
> I emphasise, no hat), since the passage doesn't seem to be operati= ve
> and removing it would be a change, perhaps it'd be better to leave= it
> until a later update?

The charter says we can remove things that are unused. =A0Since this = particular
SHOULD is unimplementable, it's unused by definition. =A0I think we can= remove
it. =A0Is there a reason we should not? =A0I agree that there's not a p= ractical
difference to leave/remove it, but removing it makes the document clearer a= nd
more concise.


I agree that it's both removable (in terms of= the charter) and that it should be removed.

-MSK
--e89a8fb1fcde2d72c304c3f90f4a-- From superuser@gmail.com Tue Jul 3 22:29:14 2012 Return-Path: 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 B833921F87B2 for ; Tue, 3 Jul 2012 22:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 RgHp7ZrE6o+6 for ; Tue, 3 Jul 2012 22:29:14 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2595421F8794 for ; Tue, 3 Jul 2012 22:29:14 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12538704obb.31 for ; Tue, 03 Jul 2012 22:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u5Q5m82ze++YdUQ94Vgbt01X18RIGIGMOhDAJCEaUeQ=; b=G91Fx3zp/qIloThe1FhUw5Ow69E063b/OXywZxZmrqxLyclyKz+Ta+rCFLHgQ0K5Td nLmH7/XcXEeQ4JCKvisU/TOPfBABB0bwU1/Lw/LEHaKhMonOKlTqUXKtQb+nRyX0szNt ZeJyBCoJWmur/JYtzyfkp7b+J1wFpuLG4bKUF7IcpE6o4hkMso9Yvzg79WtyPR3M3K5A 7W0K1s6LyY7jqL9Npb5hyoBmaa/s52CfklYuEKOmAEj7gueJhstKN+X97X8Aeic6hrtJ OJFQFFtDgSGGIa6z7mk52y0HgVTkrGwoXZwM9X4YOOz7MwHtYvC9ro2cbu7QAXhu1MZM LXGg== MIME-Version: 1.0 Received: by 10.182.31.102 with SMTP id z6mr2250507obh.66.1341379763562; Tue, 03 Jul 2012 22:29:23 -0700 (PDT) Received: by 10.182.28.65 with HTTP; Tue, 3 Jul 2012 22:29:23 -0700 (PDT) In-Reply-To: <5885582.pHJZRIJaWf@scott-latitude-e6320> References: <8827104.9HMQJuoa7q@scott-latitude-e6320> <20120704015653.GC12452@crankycanuck.ca> <5885582.pHJZRIJaWf@scott-latitude-e6320> Date: Tue, 3 Jul 2012 22:29:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=14dae93b595a50e94004c3fa5046 Cc: spfbis@ietf.org Subject: Re: [spfbis] New Issue (#31): Lookup Time Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 05:29:14 -0000 --14dae93b595a50e94004c3fa5046 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 3, 2012 at 7:20 PM, Scott Kitterman wrote: > > None of this is to disagree that implementations _ought to_ have a > > time limit. That's not what SHOULD in 2119 means, though, IMO, and as > > near as I can tell there is no interoperability reason why > > implementations really ought to do this almost always (but not > > always). > > I was thinking in terms of SHOULD (due to security considerations) do this, > but not MUST because if you want to get eaten by a DoS attack you're > welcome > to do so. That's probably wrong thinking in 2119 terms, but OTOH, if > you're > DoS'ed you aren't interoperating with anyone. > > There are plenty of ways to push hard for something without using 2119 language. This is one of those. As you point out, what's being said here has nothing to do with interoperability, only vulnerability on the part of the implementation. That sounds a lot like Security Considerations to me. -MSK --14dae93b595a50e94004c3fa5046 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2012 at 7:20 PM, Scott Kitterman <spf2@kitterman.com&g= t; wrote:
> None of this is to disagree that implementations _ou= ght to_ have a
> time limit. =A0That's not what SHOULD in 2119 means, though, IMO, = and as
> near as I can tell there is no interoperability reason why
> implementations really ought to do this almost always (but not
> always).

I was thinking in terms of SHOULD (due to security considerations) do= this,
but not MUST because if you want to get eaten by a DoS attack you're we= lcome
to do so. =A0That's probably wrong thinking in 2119 terms, but OTOH, if= you're
DoS'ed you aren't interoperating with anyone.


There are plenty of ways to push hard for somethi= ng without using 2119 language.=A0 This is one of those.

As you poin= t out, what's being said here has nothing to do with interoperability, = only vulnerability on the part of the implementation.=A0 That sounds a lot = like Security Considerations to me.

-MSK

--14dae93b595a50e94004c3fa5046-- From spf2@kitterman.com Tue Jul 3 23:26:10 2012 Return-Path: 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 135F921F86B2 for ; Tue, 3 Jul 2012 23:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 8LXz54svPaKn for ; Tue, 3 Jul 2012 23:26:09 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7E921F864A for ; Tue, 3 Jul 2012 23:26:09 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D270120E40BB; Wed, 4 Jul 2012 02:26:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341383178; bh=SI6O5aoVLvWDLtcrAMKyDNcYqN6noDAHlHXked1aHMg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kX5KA2jM+xGKs2rwxV6cyHpuimglFnHEXqAZBW+gC9+H2NUQR0pSN4/I8/QrWvW2y 7H0+6R2NeAMn91DvNg7sSMcWdt/2RCkShbHaowCisC9QIVy6iw5tahizH/4r51SvPN KVVTOrmbRgMtKx4nGTJwWbIvT8SqYaND98V9FePg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B919320E409F; Wed, 4 Jul 2012 02:26:18 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 04 Jul 2012 02:26:18 -0400 Message-ID: <2937580.EUWvD1YYks@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <8827104.9HMQJuoa7q@scott-latitude-e6320> <5885582.pHJZRIJaWf@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue (#31): Lookup Time Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 06:26:10 -0000 On Tuesday, July 03, 2012 10:29:23 PM Murray S. Kucherawy wrote: > On Tue, Jul 3, 2012 at 7:20 PM, Scott Kitterman wrote: > > > None of this is to disagree that implementations _ought to_ have a > > > time limit. That's not what SHOULD in 2119 means, though, IMO, and as > > > near as I can tell there is no interoperability reason why > > > implementations really ought to do this almost always (but not > > > always). > > > > I was thinking in terms of SHOULD (due to security considerations) do > > this, > > but not MUST because if you want to get eaten by a DoS attack you're > > welcome > > to do so. That's probably wrong thinking in 2119 terms, but OTOH, if > > you're > > DoS'ed you aren't interoperating with anyone. > > There are plenty of ways to push hard for something without using 2119 > language. This is one of those. > > As you point out, what's being said here has nothing to do with > interoperability, only vulnerability on the part of the implementation. > That sounds a lot like Security Considerations to me. We'd previously discussed moving the 'how you implement it' bits of section 10.1 up into the main part of the spec, which is what I'm working on now. I think this flows better with the other functional limits that will now be in the record evaluation section (4.6), but if it needs to stay in security considerations, so be it. Scott K From spf2@kitterman.com Wed Jul 4 00:14:30 2012 Return-Path: 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 191F511E8129 for ; Wed, 4 Jul 2012 00:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 ehODUEJ3VMTZ for ; Wed, 4 Jul 2012 00:14:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 56D0121F8631 for ; Wed, 4 Jul 2012 00:14:29 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 74BE920E40BB; Wed, 4 Jul 2012 03:14:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341386078; bh=D6bsjULuVLRhddiieXUgcpvhyqskHAmSW9B4t13y5s8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RSY1it4sO5UpCSRZu5Gic2C7Aii0la2KPPkMLC8eGG5c814+iJ/BNd2WN5VJm6L1N Y6a1Nc4XJSqkvBzEi7iw0RypY7to58ITaQsBpf8hhGYVXmt6LSCd89RvTpgEa+/10N ktzLzow06Kitrp0efTI6uYBAGv/jV9m+rFCsZR+k= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 556ED20E409F; Wed, 4 Jul 2012 03:14:38 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 04 Jul 2012 03:14:37 -0400 Message-ID: <2495670.2QvzT6qeKb@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <4155168.UcAXMpCzPG@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue: ABNF Nits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 07:14:30 -0000 On Tuesday, July 03, 2012 08:52:30 PM Murray S. Kucherawy wrote: > On Tue, Jul 3, 2012 at 1:39 PM, Scott Kitterman wrote: > > I ran the RFC 4408 collected ABNF through Bill's ABNF Parser. I collected > > a > > few potential issues, but no errors. > > > > Format: > > > > In the current ABNF, mechanisms an modifiers are all defined in a "name" > > "punctuation" styple. BIll's suggests combining the strings, i.e.: > > > > include = "include" ":" domain-spec > > > > would become: > > > > include = "include:" domain-spec > > > > Change these? Leave them? Don't care? > > Combine them. I think John Levine had a good point about not adding meaningless noise to the ABNF diff. Are you sure? > > identity is, however, used in key, but it is (I believe) improperly > > quoted. I > > > > think (from the current draft): > > key = "client-ip" / "envelope-from" / "helo" / > > > > "problem" / "receiver" / "identity" / > > > > mechanism / name > > > > Should be changed to: > > key = "client-ip" / "envelope-from" / "helo" / > > > > "problem" / "receiver" / identity / > > > > mechanism / name > > > > I don't think this changes the ABNF, I think it corrects a defect. > > +1. Fixed locally. > > None of the other quoted keys are defined in the ABNF. Should they be? > > If they're quoted, they don't need to be. None of the other quoted terms are defined. Doesn't that mean they'd need to be? > > Undefined terms: > > > > ; SP UNDEFINED > > ; DIGIT UNDEFINED > > ; ALPHA UNDEFINED > > > > These should probably be defined (added to the imported definitions > > section). > > Where do I get them from? > > RFC5234. Done locally. Scott K From vesely@tana.it Wed Jul 4 02:18:05 2012 Return-Path: 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 1260121F85E1 for ; Wed, 4 Jul 2012 02:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.542 X-Spam-Level: X-Spam-Status: No, score=-4.542 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 vTY5QMdjkyok for ; Wed, 4 Jul 2012 02:18:03 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 397BD21F85D9 for ; Wed, 4 Jul 2012 02:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1341393491; bh=vHM4M0rhDjsS+PS8W7snD1ZE2Eks8vC3ZW8zEEGc6Pg=; l=1862; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Y+e8+0wboOHHiiQpDiSqwZby4fHoKWJPsXJUjqcOof90yW/DZmbsxeqmSsIWvFAty Tskivy9W0hr6ClozJSO38F/1ufChYrbnNNZwuVwUyaRrvG6KDT3AGenER9iI/Cg0C+ o1GX3Pj8wzhjqvYuYORpvhM8bHyv+4TNj42qz0PY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 04 Jul 2012 11:18:11 +0200 id 00000000005DC03F.000000004FF40A53.000073DD Message-ID: <4FF40A53.1050301@tana.it> Date: Wed, 04 Jul 2012 11:18:11 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <8827104.9HMQJuoa7q@scott-latitude-e6320> In-Reply-To: <8827104.9HMQJuoa7q@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New Issue (#31): Lookup Time Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 09:18:05 -0000 On Wed 04/Jul/2012 01:07:48 +0200 Scott Kitterman wrote: > > I think every implementation ought to have some kind of time limit. > It would be a DoS risk not to. I'd like to change the MAY above to > SHOULD. The interoperability issue derives from the fact that clients MUST have a time limit. Hence, a failure to impose a limit would seriously affect an MTA's ability to serve clients properly. An example where it would be ok not to do the thing an MTA SHOULD do is tarpitting a client who is repeatedly failing helo-checks. > It doesn't raise any incompatibilities and reflects common practice > (and arguably fixes a clear bug in the spec). The new text would > be: > > MTAs or other processors SHOULD impose a limit on the maximum > amount of elapsed time to evaluate check_host(). Such a limit > SHOULD allow at least 20 seconds. If such a limit is exceeded, the > result of authorization SHOULD be "temperror". I'd append to the second sentence: and at most 5 minutes, according to the relevant subsection of Section 4.5.3.2 of [RFC5321]. That should clarify that, when evaluating multiple identities, the limit can be understood as global or per-identity according to how the hosting MTA invokes the evaluation during the SMTP dialogue. (Time limits imply checking live: they don't apply to, say, manual postmortem evaluation based on Received: header fields, but only to the "typical" case, as Section 2.4. puts it.) BTW, s/to evaluate check_host()/for evaluation/? Or leave it as is until #11... BTW2, the final paragraphs, from "Domains publishing records..." to the end of the section, should be moved somewhere else, IMHO. You made a better example some time ago, and cases like outlook.com deserve further discussion because they tend to default to permerror when included from redirected records. From vesely@tana.it Wed Jul 4 02:20:20 2012 Return-Path: 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 1998E21F87D5 for ; Wed, 4 Jul 2012 02:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.55 X-Spam-Level: X-Spam-Status: No, score=-4.55 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 6Arr6HIl6nP9 for ; Wed, 4 Jul 2012 02:20:19 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0A02721F87D4 for ; Wed, 4 Jul 2012 02:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1341393621; bh=cxwbej4USKy+ulYxsKKM9hrCe+QXAaoFZIB2tKFoKiA=; l=577; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=QdrRJSWsZheK/4zMlbADCJWvBBXsBcQdIh9fs/MHwaDkynT0qPZm9Q7vTQSQKF5x2 BqBYg3gn/zOR0RlW00weMnRBDmNR7mRbs8gocStULlnZkXoDLW6x+b9o76SJTJjabB 6/jJFiS6ywWCva3DmYTgaLwY+4X7YrbZe+Cx82co= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 04 Jul 2012 11:20:21 +0200 id 00000000005DC03F.000000004FF40AD5.0000748C Message-ID: <4FF40AD4.2060108@tana.it> Date: Wed, 04 Jul 2012 11:20:20 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120703214652.98994.qmail@joyce.lan> <2445655.Qs2iHhvcP9@scott-latitude-e6320> In-Reply-To: <2445655.Qs2iHhvcP9@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: ABNF Nits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 09:20:20 -0000 On Wed 04/Jul/2012 00:16:02 +0200 Scott Kitterman wrote: > On Tuesday, July 03, 2012 09:46:52 PM John Levine wrote: > >>> Undefined terms: >>> >>> ; SP UNDEFINED >>> ; DIGIT UNDEFINED >>> ; ALPHA UNDEFINED >> >> I'd suggest you import them from RFC 5234. > > Perfect. Changed those. Attached is the relevant diff I have locally. Besides all of them being collected in Appendix A, many also appear in Section 7. Why? Shouldn't they go to Section 1.3.2 instead? Scott, would you please post -03? We'll hardly reach version -99 if you keep changes locally :-) From spf2@kitterman.com Wed Jul 4 07:37:06 2012 Return-Path: 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 060C021F877C for ; Wed, 4 Jul 2012 07:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 lZBK4+TzPUjw for ; Wed, 4 Jul 2012 07:37:05 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E07C221F876F for ; Wed, 4 Jul 2012 07:37:04 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0379920E40BB; Wed, 4 Jul 2012 10:37:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341412635; bh=esJDLvqhQX8a/cYso7ORtDV7f72Baekxe7vpNc4jU9Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WbkJePIn3A/5+23G7YgT6AGXf8olCUEb1Xy2VhfHjS5N+6NrjsCsk8eM0Mx+Xu7pY MOEYnClwtBnSTfkGALSUj8c/jbfmTm9lHh66amuaRplWI95cToTqAPICmDCGLoLQgo XLeG1qpQAHwmBPbvJoYyeAG6ECAluUdLME2l2Pfo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D8FE720E409D; Wed, 4 Jul 2012 10:37:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 04 Jul 2012 10:30:34 -0400 Message-ID: <8827468.DOCLQWqKXo@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FF40A53.1050301@tana.it> References: <8827104.9HMQJuoa7q@scott-latitude-e6320> <4FF40A53.1050301@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue (#31): Lookup Time Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 14:37:06 -0000 On Wednesday, July 04, 2012 11:18:11 AM Alessandro Vesely wrote: > On Wed 04/Jul/2012 01:07:48 +0200 Scott Kitterman wrote: > > I think every implementation ought to have some kind of time limit. > > It would be a DoS risk not to. I'd like to change the MAY above to > > SHOULD. > > The interoperability issue derives from the fact that clients MUST > have a time limit. Hence, a failure to impose a limit would seriously > affect an MTA's ability to serve clients properly. An example where > it would be ok not to do the thing an MTA SHOULD do is tarpitting a > client who is repeatedly failing helo-checks. > > > It doesn't raise any incompatibilities and reflects common practice > > (and arguably fixes a clear bug in the spec). The new text would > > > > be: > > MTAs or other processors SHOULD impose a limit on the maximum > > amount of elapsed time to evaluate check_host(). Such a limit > > SHOULD allow at least 20 seconds. If such a limit is exceeded, the > > result of authorization SHOULD be "temperror". > > I'd append to the second sentence: > > and at most 5 minutes, according to the relevant subsection of > Section 4.5.3.2 of [RFC5321]. Since having a limit at all is at most a SHOULD, I don't see a reason to specify a maximum. Also there's neither an interoperability nor a security considerations reason to specify a maximum. > That should clarify that, when evaluating multiple identities, the > limit can be understood as global or per-identity according to how the > hosting MTA invokes the evaluation during the SMTP dialogue. > (Time limits imply checking live: they don't apply to, say, manual > postmortem evaluation based on Received: header fields, but only to > the "typical" case, as Section 2.4. puts it.) Is it unclear now? > BTW, s/to evaluate check_host()/for evaluation/? Or leave it as is > until #11... One issue at a time. > BTW2, the final paragraphs, from "Domains publishing records..." to > the end of the section, should be moved somewhere else, IMHO. You > made a better example some time ago, and cases like outlook.com > deserve further discussion because they tend to default to permerror > when included from redirected records. Yes. I'm moving the "here's stuff to think about" parts to section 9. Scott K From spf2@kitterman.com Wed Jul 4 07:45:53 2012 Return-Path: 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 B27B021F8838 for ; Wed, 4 Jul 2012 07:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 tb96Z3g6i0Zh for ; Wed, 4 Jul 2012 07:45:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B7A7221F881B for ; Wed, 4 Jul 2012 07:45:51 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 48C6D20E40BB; Wed, 4 Jul 2012 10:46:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341413162; bh=ONMNZ8NRz+PFwpW7+ladvr6psH1l3ArjIngHdWZZfn0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KUQHH/CGAGsslSSjhgrrhNrVaWd4sjlYDIzHvrp0TAbAtn8MfXTmNEAENxu98/B4w TslBWA5bWdyLVkKmyJhhwRaiQ6n+5NAULDvlX7CBFwC3ZePdP9tuaB/FbkCy6bdWuU oPfxBCzflES6xtNyHfy6YePweeCltIjlH1/4Fb3E= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8263520E409D; Wed, 4 Jul 2012 10:46:01 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 04 Jul 2012 10:46:01 -0400 Message-ID: <6916888.ND0Bd3P2jQ@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FF40AD4.2060108@tana.it> References: <20120703214652.98994.qmail@joyce.lan> <2445655.Qs2iHhvcP9@scott-latitude-e6320> <4FF40AD4.2060108@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue: ABNF Nits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 14:45:53 -0000 On Wednesday, July 04, 2012 11:20:20 AM Alessandro Vesely wrote: > On Wed 04/Jul/2012 00:16:02 +0200 Scott Kitterman wrote: > > On Tuesday, July 03, 2012 09:46:52 PM John Levine wrote: > >>> Undefined terms: > >>> > >>> ; SP UNDEFINED > >>> ; DIGIT UNDEFINED > >>> ; ALPHA UNDEFINED > >> > >> I'd suggest you import them from RFC 5234. > > > > Perfect. Changed those. Attached is the relevant diff I have locally. > > Besides all of them being collected in Appendix A, many also appear in > Section 7. Why? Shouldn't they go to Section 1.3.2 instead? RFC 4408 didn't have an imported definitions section. Each imported token was listed in the relevant portion of the document. Appendix A is a collection of everything else. SP, DIGIT, and ALPHA are used in multiple places, so there's no single place in the main body to put them. You are correct that it's a bit inconsistent now in terms of where imports are defined. I've added the items from section 7 to 1.3.2. I didn't remove them from section 7 in the interests of keeping noise out of the ABNF diff (which I think is useful for making it clear what did or did not change between 4408 and 4408bis). > Scott, would you please post -03? We'll hardly reach version -99 if > you keep changes locally :-) I want to finish reorganizing the security considerations section first, issue #6, then I'll post. Probably later today. Scott K From superuser@gmail.com Wed Jul 4 07:47:43 2012 Return-Path: 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 D4F6C21F8839 for ; Wed, 4 Jul 2012 07:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 4ELJ6FkCqNpd for ; Wed, 4 Jul 2012 07:47:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C215421F883A for ; Wed, 4 Jul 2012 07:47:42 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so11551938lbb.31 for ; Wed, 04 Jul 2012 07:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0P9WowSjgpofn1R5jnFSmjnROfQ/tdl7lAQDXE3WUg0=; b=wAbIVJWdGWqS1DfwPHL5a/qXoCVaSwTaOaNozzAmKlEHfy5upBBv+xr4+BrqYCqVYw ZkD0fVebAbuJI3fRE4hcXbBfB8SC+gw4j4KyAn/r1x+s8yhVXu9ccZ0KMRErzieoe9oq wbboB9JBjb81PzGl5czrULy1mZo0SO/kCtjv/DtarHtEpjLyIFq+8Hj6JzoSVUiTaafd 8/2h5K8OwMI7mcgxJO0FXNcjD3HsdhsFpb3soZryHRW4g3dGmJQA+wibaxt1Kvgu2erb E3YFRpy1JhZ8Q8XAps+5bG1qBtrdziDVRB0Ondct0cjlTObcZKRvJgHCAhjyYCF6Gb5l t4lg== MIME-Version: 1.0 Received: by 10.152.112.138 with SMTP id iq10mr22214461lab.13.1341413272805; Wed, 04 Jul 2012 07:47:52 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 4 Jul 2012 07:47:52 -0700 (PDT) In-Reply-To: <2495670.2QvzT6qeKb@scott-latitude-e6320> References: <4155168.UcAXMpCzPG@scott-latitude-e6320> <2495670.2QvzT6qeKb@scott-latitude-e6320> Date: Wed, 4 Jul 2012 07:47:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0408da079f5fae04c4021d38 Cc: spfbis@ietf.org Subject: Re: [spfbis] New issue: ABNF Nits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 14:47:44 -0000 --f46d0408da079f5fae04c4021d38 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 4, 2012 at 12:14 AM, Scott Kitterman wrote: > > > In the current ABNF, mechanisms an modifiers are all defined in a > "name" > > > "punctuation" styple. BIll's suggests combining the strings, i.e.: > > > > > > include = "include" ":" domain-spec > > > > > > would become: > > > > > > include = "include:" domain-spec > > > > > > Change these? Leave them? Don't care? > > > > Combine them. > > I think John Levine had a good point about not adding meaningless noise to > the > ABNF diff. Are you sure? > The IESG has the discretion to be extra-sticky about getting ABNF right. Although the change doesn't alter what productions are permitted, that the BNF checker whined might be enough to set someone off. I prefer the change. But, to quote Andrew, I'm not going to die on that particular hill. > > None of the other quoted keys are defined in the ABNF. Should they be? > > > > If they're quoted, they don't need to be. > > None of the other quoted terms are defined. Doesn't that mean they'd need > to > be? > I meant "defined" in the ABNF sense. I think we ought to define them in prose to explain what they should mean to consumers that see them. -MSK --f46d0408da079f5fae04c4021d38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 4, 2012 at 12:14 AM, Scott Kitterman <spf2@kitterman.com&= gt; wrote:
> > In the current ABNF, mechanisms an modifiers ar= e all defined in a "name"
> > "punctuation" styple. =A0BIll's suggests combining = the strings, i.e.:
> >
> > include =3D "include" =A0":" domain-spec
> >
> > would become:
> >
> > include =3D "include:" domain-spec
> >
> > Change these? =A0Leave them? =A0Don't care?
>
> Combine them.

I think John Levine had a good point about not adding meaningless noi= se to the
ABNF diff. =A0Are you sure?


The IESG has the d= iscretion to be extra-sticky about getting ABNF right.=A0 Although the chan= ge doesn't alter what productions are permitted, that the BNF checker w= hined might be enough to set someone off.=A0 I prefer the change.=A0 But, t= o quote Andrew, I'm not going to die on that particular hill.

> > None of the other quoted keys are defined in th= e ABNF. =A0Should they be?
>
> If they're quoted, they don't need to be.

None of the other quoted terms are defined. =A0Doesn't that mean = they'd need to
be?

I meant "defined" in the ABNF sense.= =A0 I think we ought to define them in prose to explain what they should me= an to consumers that see them.

-MSK

--f46d0408da079f5fae04c4021d38-- From superuser@gmail.com Wed Jul 4 07:50:22 2012 Return-Path: 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 8BA0F21F8841 for ; Wed, 4 Jul 2012 07:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 dR0F8+Pal9kq for ; Wed, 4 Jul 2012 07:50:22 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AAC5421F883F for ; Wed, 4 Jul 2012 07:50:21 -0700 (PDT) Received: by bkty8 with SMTP id y8so6909021bkt.31 for ; Wed, 04 Jul 2012 07:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G2scDDUMI0gStBh+JwUE84hfzUX8fidLcuXB1FUds4g=; b=0cSwHFJ6EoOMV61W/XHjSPftlSaNV0f3oAn4P0o1GMiV0VETfKXMApEvQ5eljtl4/x TGJKVHI72wxWlSOBA7jM0X7l1TQbkgGJx0cLcyk+h41x6OhgNJG94KH83zSU42HAtDVc YtxdRk9NSFjc13EQCSXeUOq+O61v8Gwv/RqZYbgKlKaiDPpgmsCKbVVFEf2SZ83z4NVR 4LRDRAyE9jmCb8Eq9dojbqUQPx5KH0Hgccsb7Vtv52Wb3pITXqs9hYh86hkfUFW28dxy Ndcod8i6XTgm3b6Z4isWzP3BRnCyGy0P+z1JtWUwE4w+Qwjlld0jF4s/ZDVKSGjvLDm6 DpqA== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr21920368lab.40.1341413431635; Wed, 04 Jul 2012 07:50:31 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 4 Jul 2012 07:50:31 -0700 (PDT) In-Reply-To: <4FF40A53.1050301@tana.it> References: <8827104.9HMQJuoa7q@scott-latitude-e6320> <4FF40A53.1050301@tana.it> Date: Wed, 4 Jul 2012 07:50:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d040838d316eded04c402274b Cc: spfbis@ietf.org Subject: Re: [spfbis] New Issue (#31): Lookup Time Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 14:50:22 -0000 --f46d040838d316eded04c402274b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 4, 2012 at 2:18 AM, Alessandro Vesely wrote: > On Wed 04/Jul/2012 01:07:48 +0200 Scott Kitterman wrote: > > > > I think every implementation ought to have some kind of time limit. > > It would be a DoS risk not to. I'd like to change the MAY above to > > SHOULD. > > The interoperability issue derives from the fact that clients MUST > have a time limit. Hence, a failure to impose a limit would seriously > affect an MTA's ability to serve clients properly. An example where > it would be ok not to do the thing an MTA SHOULD do is tarpitting a > client who is repeatedly failing helo-checks. > MTA timeouts are defined in other documents already. If it makes the picture more complete we could make reference to those and remind people they are to be observed when adding SPF checking to an MTA, but I don't think we need to provide SPF-specific timeouts. -MSK --f46d040838d316eded04c402274b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 4, 2012 at 2:18 AM, Alessandro Vesely <vesely@tana.it> wrote:
On Wed 04/Jul/2012 01:07:48 +0200 Scott Kitterman wrote:<= br> >
> I think every implementation ought to have some kind of time limit. > It would be a DoS risk not to. =A0I'd like to change the MAY above= to
> SHOULD.

The interoperability issue derives from the fact that clients MUST have a time limit. =A0Hence, a failure to impose a limit would seriously affect an MTA's ability to serve clients properly. =A0An example where<= br> it would be ok not to do the thing an MTA SHOULD do is tarpitting a
client who is repeatedly failing helo-checks.

MTA = timeouts are defined in other documents already.=A0 If it makes the picture= more complete we could make reference to those and remind people they are = to be observed when adding SPF checking to an MTA, but I don't think we= need to provide SPF-specific timeouts.

-MSK

--f46d040838d316eded04c402274b-- From spf2@kitterman.com Wed Jul 4 07:54:10 2012 Return-Path: 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 2348B21F87D3 for ; Wed, 4 Jul 2012 07:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 U283plXyOth9 for ; Wed, 4 Jul 2012 07:54:09 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4199421F87CA for ; Wed, 4 Jul 2012 07:54:09 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E60A820E40BB; Wed, 4 Jul 2012 10:54:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341413659; bh=jkprxP7Zx1g9jVfTqjsQcMpV9t4uervtQHXX2M+v0fk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dL+RP+Jecth5yxbQCOld5ESskztjCPukyciMjYZS0HmI8Kpo406N1pBCRVqlVQn54 EpgD78mTuvdtDrfWuq9VGYisd8pl12kk9eE/+NwnR+sJP6/429hPJS5N98AV61VeWD NvslVLjfkfxsYSkOYsgYzuXpgZqlcXAGlH7ctcRY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C7C9620E409D; Wed, 4 Jul 2012 10:54:19 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 04 Jul 2012 10:54:19 -0400 Message-ID: <3347559.kt8jl5XyG8@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <1977882.Ft2hpQpDVK@scott-latitude-e6320> <20120704014723.GA12452@crankycanuck.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Fwd: [spf-discuss] SPF and SERVFAIL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 14:54:10 -0000 On Tuesday, July 03, 2012 08:57:22 PM Murray S. Kucherawy wrote: > On Tue, Jul 3, 2012 at 6:47 PM, Andrew Sullivan wrote: > > SPF depends on DNS. In the DNS, SERVFAIL means the server you are > > talking to failed, for some reason, you don't know what, and therefore > > you should probably try something else -- try again later, try one of > > the other authoritative servers, whatever. Servers return SERVFAIL > > when DNSSEC validation fails, when they're still loading the zone, > > when they've just crashed and are restarting, and all sorts of other > > reasons. > > > > Now, I have no difficulty if the WG wants to say that a SERVFAIL gives > > you no knowledge. So NEUTRAL might be all right. But presumably, > > that ought to be true for other DNS error codes other than 0 and 3, > > also, no? If you get (for instance) REFUSED or NOTIMP, shouldn't they > > be the same as SERVFAIL? > > My preference would be to point out that SERVFAIL can happen for any reason > other than total success of the query's resolution. The error could be > transient, or it could be something severe. Unfortunately, there's no way > to tell. SPF verifiers should be aware of this and respond accordingly. > So basically, give implementers the knowledge they need to pick an > intelligent course of action, but don't specify what that ought to be. > > I'd probably be comfortable advising against outright rejection, but I'm > not sure I'd recommend a specific SPF result code or neutral+deliver vs. > temp-fail. Currently we say this is temperror on the first instance (which is consistent with the 4408) and then give the option to convert recurrences from the same domain as permerror on the theory they won't go away. What receivers should do with a permerror is left unspecified. I don't think it's unreasonable to treat REFUSED or NOTIMP similarly, I've just never seen those come up in practice. Equally, I don't think it's unreasonable to convert to none instead of permerror. I think we should leave the initial temperror both because theses things do go away sometimes and for compatibility reasons. I think none is preferable over neutral because when these cases occur on initial lookup we don't even know if the domain has an SPF record. Scott K From spf2@kitterman.com Wed Jul 4 07:57:02 2012 Return-Path: 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 AE64021F87DE for ; Wed, 4 Jul 2012 07:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 pWQbPFlP-yKJ for ; Wed, 4 Jul 2012 07:57:02 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E1F6621F87D3 for ; Wed, 4 Jul 2012 07:57:01 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 95F1520E40BB; Wed, 4 Jul 2012 10:57:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341413832; bh=+lXexFK7JCxbmfaMRNCkJlGO84g32lyPi7nMETTbJt0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CStNDcPzrZ2dXdNu9stedwgFQa5woy5omeZbPG8h9V/SudkaFF6PEsghlfWNIU7rz YyYP3IbULq+MZShAf+sWSj6Uf2tfIUbOAUZLUAEr9aYtJ5zXmDoNdKFs7xN1bdu1KG EyC5uazv8oJOMhj9FrJOEyHbfrp9oyZ/0z79RZT4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 78E0620E409D; Wed, 4 Jul 2012 10:57:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 04 Jul 2012 10:57:12 -0400 Message-ID: <9382904.cGHli4ocfd@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <4155168.UcAXMpCzPG@scott-latitude-e6320> <2495670.2QvzT6qeKb@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue: ABNF Nits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 14:57:02 -0000 On Wednesday, July 04, 2012 07:47:52 AM Murray S. Kucherawy wrote: > > > None of the other quoted keys are defined in the ABNF. Should they be? > > > > > > If they're quoted, they don't need to be. > > > > None of the other quoted terms are defined. Doesn't that mean they'd need > > to > > be? > > I meant "defined" in the ABNF sense. I think we ought to define them in > prose to explain what they should mean to consumers that see them. I see I misread your comment. I inferred the word after "need to be." was quoted, not defined. We do define them in a prose sense, so I think it's good. Scott K From internet-drafts@ietf.org Thu Jul 5 13:17:34 2012 Return-Path: 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 DD00E21F86B5; Thu, 5 Jul 2012 13:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 xbfJ9DR8Ga00; Thu, 5 Jul 2012 13:17:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B44E21F86C3; Thu, 5 Jul 2012 13:17:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30 Message-ID: <20120705201733.28743.65891.idtracker@ietfa.amsl.com> Date: Thu, 05 Jul 2012 13:17:33 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 20:17:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Dom= ains in Email, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-03.txt Pages : 57 Date : 2012-07-05 Abstract: E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a domain can explicitly authorize the hosts that are allowed to use its domain name, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Thu Jul 5 13:33:47 2012 Return-Path: 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 7C61321F855F for ; Thu, 5 Jul 2012 13:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Vd8zaCuGciAo for ; Thu, 5 Jul 2012 13:33:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6281521F8559 for ; Thu, 5 Jul 2012 13:33:46 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E31B220E4134; Thu, 5 Jul 2012 16:33:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341520436; bh=Uaou2bz5tV+8kDCVtox3DzqSSVuuwB2wZXaXq5w5LPM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AnV9g9ymOkG+dH3zaxEfZWBgKjcTxf+fOw/oiNGbn/nAZ392k1W3tCzF0dAjt/Kzs Dzv06gvxaohTXdFGJTzGPj3k1pnhlNyDStkSqRSP/Bzy2gEpZRyce+YhaFS5wbhp/w NjinYT2m3XQ/FooAzvG4i0mTLJH5B9eIMT1jFEjs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C35C120E4091; Thu, 5 Jul 2012 16:33:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 05 Jul 2012 16:33:56 -0400 Message-ID: <1894507.GlTVbDqI8c@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120705201733.28743.65891.idtracker@ietfa.amsl.com> References: <20120705201733.28743.65891.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 20:33:47 -0000 On Thursday, July 05, 2012 01:17:33 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the SPF Update Working Group of > the IETF. > > Title : Sender Policy Framework (SPF) for Authorizing Use of > Domains in Email, Version 1 Author(s) : Scott Kitterman > Filename : draft-ietf-spfbis-4408bis-03.txt > Pages : 57 > Date : 2012-07-05 Based on our recent discussion, I don't think anything in this revision will be a surprise: Update changes for Type SPF removal based on list feedback. Fix ABNF nits and add missing definitions per Bill's ABNF checker. Make DNS lookup time limit SHOULD instead of MAY. Reorganize and clarify processing limits. Move hard limits to new section 4.6.4, Evaluation Limits. Move advice to non-normative section 9. Removed paragraph in section 10.1 about limiting total data volumes as it is unused (and removable per the charter) and serves no purpose (it isn't something that actually can be implemented in any reasonable way). I would particularly appreciate review on the reorganization/clarification of the processing limits as it's a significant editorial change (there are no intentional technical changes except the separately mentioned timeout MAY/SHOULD) and the refinement of the Type SPF language. The rest I think it relatively uncontroversial. Scott K From vesely@tana.it Fri Jul 6 04:23:07 2012 Return-Path: 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 83F1921F86FD for ; Fri, 6 Jul 2012 04:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.558 X-Spam-Level: X-Spam-Status: No, score=-4.558 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 CjWOfHHkcPs5 for ; Fri, 6 Jul 2012 04:23:06 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 75EC321F86F7 for ; Fri, 6 Jul 2012 04:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1341573800; bh=1dPfY+2SXNZrrhFwDl0Cj9s+iUd5rX9RIkKvYPx9VQo=; l=3144; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=i1DEl1uhpsWWj734RX7CvXEtk8P/714t/QjAHDbfDS5mf9MCR7yCukmw7kLrBjrkv VSs72OvdYWaGtKifvZnWJu+aNJavs7qz3+sKrCTLXrrMI81AAfLDfNNJIUxmjzgeoQ GvqtJF6ok3Xqw7qztZ7IfmZxbtTOrq0L+X4b2Vrk= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 06 Jul 2012 13:23:20 +0200 id 00000000005DC045.000000004FF6CAA8.000033E9 Message-ID: <4FF6CAA7.7070901@tana.it> Date: Fri, 06 Jul 2012 13:23:19 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120705201733.28743.65891.idtracker@ietfa.amsl.com> <1894507.GlTVbDqI8c@scott-latitude-e6320> In-Reply-To: <1894507.GlTVbDqI8c@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 11:23:07 -0000 On Thu 05/Jul/2012 22:33:56 +0200 Scott Kitterman wrote: > > I would particularly appreciate review on the reorganization/clarification of > the processing limits as it's a significant editorial change (there are no > intentional technical changes except the separately mentioned timeout > MAY/SHOULD) and the refinement of the Type SPF language. The rest I think it > relatively uncontroversial. I like how the document is getting shaped up. 3. *SPF Records* I'd move the example away. The rest could be merged with the following subsection, possibly merging also the titles into, say, "Publishing SPF Records". 3.1. *Publishing* Ditto for the example. There is too much redundancy among the first paragraphs of Sections 3, 3.1, and 3.1.1. There is a lowercase "must publish". Finally, "publishing via TXT" is the only way now. I'd propose: An SPF record is a DNS Resource Record (RR) that declares which hosts are, and are not, authorized to use a domain name for the "MAIL FROM" and "HELO" identities. For each identity, an SPF evaluation starting at the relevant domain name associates an authorization result to each possible sender, based on the authentication token provided by lower level protocols, the IP address. Therefore, SPF records to authorize the "MAIL FROM" identity have to be published in the DNS tree at the domain name corresponding to the domain part of the email address; for the "HELO" identity, at the domain used (or abused) in the EHLO or HELO SMTP commands. Domains publishing records SHOULD keep the number of "include" mechanisms and chained "redirect" modifiers to a minimum, albeit a single redirect might sometimes help size limits (see Section 3.1.4). Domains SHOULD also minimize the amount of other DNS information needed to evaluate a record. Section 9.1.1 provides some suggestions on how to achieve this. 4.6.4. *Evaluation Limits* There is a typo in the phrase "at most 10 per during SPF record evaluation". Saying "per SPF record" might convey the false impression that the count is reset upon loading a new (included or redirected) record. How about "per SPF evaluation", where an SPF evaluation is defined elsewhere as a run of the check_host algorithm? The title "Evaluation Limits" is very similar to, but different from "Processing Limits" of Section 10.1. Putting exactly the same title would convey that they treat the same subject from different angles. In that case, the more-normative-than-explanatory last paragraph of 10.1 could be moved to 4.6.4. Otherwise, "DNS Lookup Limits" would seem to be more appropriate for the latter section. 9.1.1. *DNS Resource Considerations* The first example is difficult to read, as it is not clear what are a, b, and c.example.com. I'd propose to make three figures with the relevant part of the explanatory paragraph appearing as caption to each one. The second example doesn't say what mechanism to use. s/'MX"/"mx"/. A third example might be worth. I'm going to write a separate message for it. 9.3. *Mail Services* I think you mean ESP, not MSP. From vesely@tana.it Fri Jul 6 05:58:30 2012 Return-Path: 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 9B1C621F86FF for ; Fri, 6 Jul 2012 05:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.264 X-Spam-Level: X-Spam-Status: No, score=-4.264 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] 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 hmOuVIKzXsnU for ; Fri, 6 Jul 2012 05:58:30 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C902021F86EA for ; Fri, 6 Jul 2012 05:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1341579524; bh=BYKSCmxI6819f+Bqrmzb5w7x4QWfJJkJhVkmzysnWE4=; l=1055; h=Message-ID:Date:From:MIME-Version:To:Content-Transfer-Encoding; b=F35WJYGsS8PUrSMMERjI1oG4v9S/hu94POlyhCUAcDK28OUxlmSRNmJIw1UqurDIW ugJXts37+bmRjdhlD/AnWuRNVF0EQNpKehCStUm1MaXdV5HYCDcmQhXY/IH3VLTiAu wSL1VV1+wsltiWe7niijC/0xEwAnizB9CHMB2Pps= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 06 Jul 2012 14:58:44 +0200 id 00000000005DC033.000000004FF6E104.000048FE Message-ID: <4FF6E104.2000906@tana.it> Date: Fri, 06 Jul 2012 14:58:44 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] New issue: limit recursive use of the include mechanism X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 12:58:30 -0000 9.1.1. *DNS Resource Considerations* Is it worth to add an example for very large organizations that need to split authorization management into a number of departments? If they "include" internally the chains grow too long. IMHO, they'd better use "exists" and move authorization management to a purposely implemented whitelist-publishing tool. Consider a domain with three external smart hosts, corresponding to as many organizations. Thus we may have: domain.example. TXT "v=spf1 redirect=_spf.domain.example" _spf.domain.example. TXT ( "v=spf1 ip4:192.0.2.3 " "include:org1.example " "include:org2.example " "include:org3.example " "-all" ) Each orgX.example may use up to two queries, because using three or more would exceed the limit of 10. The client domain, who is publishing three "include"s, must not in turn provide relaying services to third parties. Before doing that, it should set up a mashup of the relevant zones and use "exists". Ditto if they want more than three external smart hosts. Thoughts? From spf2@kitterman.com Fri Jul 6 06:46:43 2012 Return-Path: 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 98EFD21F86D4 for ; Fri, 6 Jul 2012 06:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6] 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 xL4JkT2038Gc for ; Fri, 6 Jul 2012 06:46:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C0AF621F86D0 for ; Fri, 6 Jul 2012 06:46:34 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3739C20E4134; Fri, 6 Jul 2012 09:46:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341582410; bh=7xYRw0f9GBmI6AskS3FQjW4EZYSE6LguWjfYuaL+EsA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UFYhcmPJTUjcJ3r9oDZKP9bIyvNHQGBtJgCTgzrj7cgMDCGtipa6zTKBMaqjIJoei 7Cjj0zg0l0B+KF5glv44YMwzfReTX12ipMIP1gc/s5kjV7zIoR1nDESHVoOyfzAGBB 6170yinkyhViqphjLrwA+pomWH0+4B7itRT8H4+8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1919F20E4064; Fri, 6 Jul 2012 09:46:49 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 06 Jul 2012 09:46:46 -0400 Message-ID: <13155142.Bg5h4a9Ja9@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FF6E104.2000906@tana.it> References: <4FF6E104.2000906@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue: limit recursive use of the include mechanism X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 13:46:44 -0000 On Friday, July 06, 2012 02:58:44 PM Alessandro Vesely wrote: > 9.1.1. *DNS Resource Considerations* > > Is it worth to add an example for very large organizations that need > to split authorization management into a number of departments? If > they "include" internally the chains grow too long. IMHO, they'd > better use "exists" and move authorization management to a purposely > implemented whitelist-publishing tool. > > Consider a domain with three external smart hosts, corresponding to as > many organizations. Thus we may have: > > domain.example. TXT "v=spf1 redirect=_spf.domain.example" > _spf.domain.example. TXT ( "v=spf1 ip4:192.0.2.3 " > "include:org1.example " > "include:org2.example " > "include:org3.example " > "-all" ) > > Each orgX.example may use up to two queries, because using three or > more would exceed the limit of 10. > > The client domain, who is publishing three "include"s, must not in > turn provide relaying services to third parties. Before doing that, > it should set up a mashup of the relevant zones and use "exists". > Ditto if they want more than three external smart hosts. I don't object to additional examples. I'm not sure that we should specifically recommend exists: as it brings it's own set of burdens. I think it's worthwhile to say that in these cases the included records really ought to use ip4/ip6 mechanisms. Similarly, we should probably say something similar in section 9.3. If your record is going to be included in someone else's record ip4/ip6 is essential. I had this exact problem come up with an ISP server I used to use. Their record was OK, but it used the exact limit of 10, so if anyone included it, that record failed. Fortunately I was able explain it to them and fix it, but some guidance on this seems prudent. Scott K From spf2@kitterman.com Fri Jul 6 11:50:34 2012 Return-Path: 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 2502F11E80A1 for ; Fri, 6 Jul 2012 11:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 4R9-TKsN2+aK for ; Fri, 6 Jul 2012 11:50:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CECB011E809F for ; Fri, 6 Jul 2012 11:50:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 74B4420E4134; Fri, 6 Jul 2012 14:50:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341600649; bh=gtw7SE9mdvryrEMXMdpbad60e/cDVvt4/7jMcPZvGE8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ppzsznMvv7lyKQSHlPWjJ3TvqwD6AvSept4kYJs+E3WyBTNx03Pagdj73bYPnYzjm I5P2qt6aJSoG1Ug4n2Ty7C0IQ4RVl4TpldubslkvW8AuQn8hritXQMNTZD4Jj/Bzm7 RDSb/OfzsMs53xodluLoyeI8uzDGHL5ena8Lbnnc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 589BD20E4064; Fri, 6 Jul 2012 14:50:49 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 06 Jul 2012 14:50:48 -0400 Message-ID: <53688255.pZATy2LdB1@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FF6CAA7.7070901@tana.it> References: <20120705201733.28743.65891.idtracker@ietfa.amsl.com> <1894507.GlTVbDqI8c@scott-latitude-e6320> <4FF6CAA7.7070901@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-03.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:50:34 -0000 On Friday, July 06, 2012 01:23:19 PM Alessandro Vesely wrote: > On Thu 05/Jul/2012 22:33:56 +0200 Scott Kitterman wrote: > > I would particularly appreciate review on the reorganization/clarification > > of the processing limits as it's a significant editorial change (there > > are no intentional technical changes except the separately mentioned > > timeout MAY/SHOULD) and the refinement of the Type SPF language. The > > rest I think it relatively uncontroversial. > > I like how the document is getting shaped up. > > 3. *SPF Records* > > I'd move the example away. The rest could be merged with the > following subsection, possibly merging also the titles into, say, > "Publishing SPF Records". I think this section is important because it explains what an SPF record is. Introducing such an important concept for the protocol is very important and it's worth some text to make it clear, but I think a 3.1 without a 3.2 is a good sign the organization is poor. > 3.1. *Publishing* > > Ditto for the example. There is too much redundancy among the first > paragraphs of Sections 3, 3.1, and 3.1.1. There is a lowercase "must > publish". Finally, "publishing via TXT" is the only way now. I'd > propose: I fixed the publishing via TXT sentence to start "Since TXT records have multiple uses, beware ..." locally. Good catch. > An SPF record is a DNS Resource Record (RR) that declares which > hosts are, and are not, authorized to use a domain name for the > "MAIL FROM" and "HELO" identities. For each identity, an SPF > evaluation starting at the relevant domain name associates an > authorization result to each possible sender, based on the > authentication token provided by lower level protocols, the IP > address. Therefore, SPF records to authorize the "MAIL FROM" > identity have to be published in the DNS tree at the domain name > corresponding to the domain part of the email address; for the > "HELO" identity, at the domain used (or abused) in the EHLO or HELO > SMTP commands. > > Domains publishing records SHOULD keep the number of "include" > mechanisms and chained "redirect" modifiers to a minimum, albeit a > single redirect might sometimes help size limits (see Section > 3.1.4). Domains SHOULD also minimize the amount of other DNS > information needed to evaluate a record. Section 9.1.1 provides > some suggestions on how to achieve this. Let's try combining 3 and 3.1 (and then the third digit 3.1.x numbers move up a level). I think it reads pretty well that way. I don't think we ought to rewrite though unless we really need to. > 4.6.4. *Evaluation Limits* > > There is a typo in the phrase "at most 10 per during SPF record > evaluation". Saying "per SPF record" might convey the false > impression that the count is reset upon loading a new (included or > redirected) record. How about "per SPF evaluation", where an SPF > evaluation is defined elsewhere as a run of the check_host algorithm? Make sense. I think that's clearly better. If I change the word "interprets" to "evaluates" in the first sentence of section 4, then it flows nicely. Fixed the typo too. > The title "Evaluation Limits" is very similar to, but different from > "Processing Limits" of Section 10.1. Putting exactly the same title > would convey that they treat the same subject from different angles. > In that case, the more-normative-than-explanatory last paragraph of > 10.1 could be moved to 4.6.4. Otherwise, "DNS Lookup Limits" would > seem to be more appropriate for the latter section. I think "DNS Lookup Limits" is good. > 9.1.1. *DNS Resource Considerations* > > The first example is difficult to read, as it is not clear what are a, > b, and c.example.com. I'd propose to make three figures with the > relevant part of the explanatory paragraph appearing as caption to > each one. Please provide text. I'm not sure what you're suggesting. > The second example doesn't say what mechanism to use. s/'MX"/"mx"/. Text here too. Fixed the typo. > A third example might be worth. I'm going to write a separate message > for it. > > 9.3. *Mail Services* > > I think you mean ESP, not MSP. I would have thought that too, but I'm trying to stick to RFC5598, "Internet Mail Architecture", terms and it uses MSP, not ESP. If 5598 is wrong, it should be fixed. Scott K From sm@elandsys.com Sat Jul 7 11:53:21 2012 Return-Path: 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 96AC421F8627 for ; Sat, 7 Jul 2012 11:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 0urmeGZBh6S9 for ; Sat, 7 Jul 2012 11:53:17 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D12221F857D for ; Sat, 7 Jul 2012 11:53:16 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.49]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q67IrKmL009331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 7 Jul 2012 11:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341687214; bh=Ee6veqDRS/LDySp8XODWfIoC27AWjsjoIjYkMEOOo9s=; h=Date:To:From:Subject:Cc; b=Bz4B7lpW8Z4FAU5LImCYx8H9d5zdMEkLo3f+ujMXm5dT6DYDcMJPHBNaz0h2lnBDu 8FfIbHIpHx6sp1cMSp4qqemaOmjy+L9fN3jzH2aJwVsqx8PvJWbpfXf1UsKxY3JPOJ Rte2ZyqZpIt0FP0C5+bBY1AsL2YViYxKiN/YFmk4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1341687214; i=@elandsys.com; bh=Ee6veqDRS/LDySp8XODWfIoC27AWjsjoIjYkMEOOo9s=; h=Date:To:From:Subject:Cc; b=CADqF7VgxSDMXSGJMbyDL94pnGUMotHiYRKSLR2nZshJVSAkHIdxlqETfSXhNqpbT 4Rz8i9NuTGIXSXRVnTxPo5/Ofmc39h5yS3GXGAYio4M0vxZh8WigJ7YtCcm7X15Z64 CTJo9Tl3VCHPPG3rUYOHIvURFHt3sqvXaTT7hb3U= Message-Id: <6.2.5.6.2.20120707115155.09b544a0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 07 Jul 2012 11:53:10 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Fwd: NomCom 2012-13 Call for Volunteers X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 18:53:21 -0000 ---------- Forwarded message ---------- From: NomCom Chair Date: Friday, July 6, 2012 Subject: NomCom 2012-13 Call for Volunteers To: IETF Announcement List The IETF nominating committee process for 2012-13 has begun. The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 3777. To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out. That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you qualify, and if you will not be seeking appointment to any of the open positions that this nomcom will be filling, please consider volunteering. The list of people whose terms end with the March 2013 IETF meeting, and thus the positions for which the nominating committee is responsible for filling, are as follows: IAOC: -------- Dave Crocker IAB: -------- Alissa Cooper Joel Halpern David Kessens Danny McPherson Jon Peterson Dave Thaler IESG: -------- Russ Housley (General Area) Pete Resnick (Applications Area) Ralph Droms (Internet Area) Ronald Bonica (Operations and Management Area) Robert Sparks (Real-Time Applications and Infrastructure Area) Adrian Farrel (Routing Area) Stephen Farrell (Security Area) Wesley Eddy (Transport Area) The primary activity for this nomcom will begin in August 2012 and should be completed in January 2013. The nomcom will be collecting requirements from the community, as well as talking to candidates and obtaining feedback from community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email before 11:59 pm EDT (UTC - 4 hours) August 5, 2012 as follows: To: mlepinski.ietf@gmail.com Subject: Nomcom 2012-13 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing toward that goal. I will be publishing a more detailed timetable for nomcom activities, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you, Matthew Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org From ajs@anvilwalrusden.com Tue Jul 10 04:12:46 2012 Return-Path: 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 F2BFA21F876C for ; Tue, 10 Jul 2012 04:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=-1.669, BAYES_20=-0.74, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 PK60b3DHDp6x for ; Tue, 10 Jul 2012 04:12:45 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6F10A21F8763 for ; Tue, 10 Jul 2012 04:12:42 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 6085C8A031 for ; Tue, 10 Jul 2012 11:13:09 +0000 (UTC) Date: Tue, 10 Jul 2012 07:13:09 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120710111308.GC79014@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 11:12:46 -0000 Dear colleagues, The Vancouver IETF meeting is approaching, as is the deadline for a WG meeting agenda. Speaking only for myself, I haven't seen a great deal of discussion here of the sort that seems to require face to face time. Are there particular issues people think we need to discuss in person, or should we cede the time back to the rest of the IETF? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dotis@mail-abuse.org Tue Jul 10 16:03:25 2012 Return-Path: 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 2B37B11E80BE for ; Tue, 10 Jul 2012 16:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 o7J3-kYmSqaA for ; Tue, 10 Jul 2012 16:03:21 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9EB11E809F for ; Tue, 10 Jul 2012 16:03:21 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 7C6E817403B3 for ; Tue, 10 Jul 2012 23:03:49 +0000 (UTC) Message-ID: <4FFCB4D5.4020905@mail-abuse.org> Date: Tue, 10 Jul 2012 16:03:49 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120710111308.GC79014@mail.yitter.info> In-Reply-To: <20120710111308.GC79014@mail.yitter.info> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 23:03:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/12 4:13 AM, Andrew Sullivan wrote: > Dear colleagues, > > The Vancouver IETF meeting is approaching, as is the deadline for a > WG meeting agenda. > > Speaking only for myself, I haven't seen a great deal of > discussion here of the sort that seems to require face to face > time. Are there particular issues people think we need to discuss > in person, or should we cede the time back to the rest of the > IETF? Dear Andrew, Asia represents a significant market ignored by this draft as it fails to accommodate current email practices in this region. http://tools.ietf.org/html/rfc6530 This change even discourages A-label encoding of mail parameters. UTF-8 mail parameters will break SPF libraries that lack necessary conversion utilities, and where use of RFC3492/RFC5890 may not be sufficient without checks for illegal UTF-8 code-points. Email addresses should be conveyed in the sender's native language where possible, with assurances proper conversion methods have been applied. This update ignores security concerns likely to affect a large population likely to prefer email-addresses not expressed in US-ASCII. Leaving DNS look-up handling undefined or suggesting A-labels should be retained in the in the return path is not acceptable. Perhaps this issue might be worthy of some discussion. Regards, Douglas Otis -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP/LTVAAoJEHXVwboCjGt0COIIAIqKoByonF8Mu37jkLmxlxo7 R75AVseQqb2Pvn9f1m89AOCa11FDciTlz93qtBDK+JQgRMaf9PfOngT31Kp95bj5 de+tdG3BRFIMzNgzCgUlhQn4E2JFSgLkzsRvN+NEOuzwwp2JJt1sO6WHlYsoZL8Y p5D7CC0TKt4pjUUORso0EAXS3A1GtD2tLB8op7Ix6mggyUVRDels9dtoLdpBENKg yPaoc81bJZwWfAtoKodxM1tTp0ztYrqu2zd0eLMhxSoCnk6TYxz6sg8GR3gFmGY1 OcWa80v0MQ30ddMgVi2gdrmxXhuZK/KH1Gi+MXtk7s7VmTe+G9xpx/EycS6gDiM= =h28k -----END PGP SIGNATURE----- From spf2@kitterman.com Tue Jul 10 16:07:57 2012 Return-Path: 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 1316211E80BF for ; Tue, 10 Jul 2012 16:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 aied70Gr0Ztm for ; Tue, 10 Jul 2012 16:07:56 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 597A311E809F for ; Tue, 10 Jul 2012 16:07:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 926B020E40A6; Tue, 10 Jul 2012 19:08:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341961704; bh=riWZOuTyfCvFo6ZeRYceEO/iC/YmaC1LFGAjZ1zUduc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MfuZJ7tVUIUkXJHUctwBCV9c23vyUba0xNJadU9uS8sPnKlAgDLxG8Ulo0zIkbpyF vGwJkro2N85jN0v+Q0bXi79a6wj6yS2qo1nL5rsyZsWIqr6JTTbgBZ91Pheztyw68K QZbAh4Z1PUNcw5LjlQveSHyKNeTl899BDjmlg1a0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7521720E409F; Tue, 10 Jul 2012 19:08:24 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 10 Jul 2012 19:08:23 -0400 Message-ID: <1378759.Dysn1Vkq9B@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FFCB4D5.4020905@mail-abuse.org> References: <20120710111308.GC79014@mail.yitter.info> <4FFCB4D5.4020905@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 23:07:57 -0000 On Tuesday, July 10, 2012 04:03:49 PM Douglas Otis wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/10/12 4:13 AM, Andrew Sullivan wrote: > > Dear colleagues, > > > > The Vancouver IETF meeting is approaching, as is the deadline for a > > WG meeting agenda. > > > > Speaking only for myself, I haven't seen a great deal of > > discussion here of the sort that seems to require face to face > > time. Are there particular issues people think we need to discuss > > in person, or should we cede the time back to the rest of the > > IETF? > > Dear Andrew, > > Asia represents a significant market ignored by this draft as it fails > to accommodate current email practices in this region. > > http://tools.ietf.org/html/rfc6530 > > This change even discourages A-label encoding of mail parameters. UTF-8 > mail parameters will break SPF libraries that lack necessary conversion > utilities, and where use of RFC3492/RFC5890 may not be sufficient > without checks for illegal UTF-8 code-points. > > Email addresses should be conveyed in the sender's native language > where possible, with assurances proper conversion methods have been > applied. This update ignores security concerns likely to affect a > large population likely to prefer email-addresses not expressed in > US-ASCII. Leaving DNS look-up handling undefined or suggesting > A-labels should be retained in the in the return path is not acceptable. > > Perhaps this issue might be worthy of some discussion. We have an open issue to work on this issue that no one has gotten to yet: http://trac.tools.ietf.org/wg/spfbis/trac/ticket/28 Given that we haven't gotten to it yet, it's hard to know if it needs face to face discussion. Scott K From sm@elandsys.com Tue Jul 10 17:05:13 2012 Return-Path: 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 96EAE11E814A for ; Tue, 10 Jul 2012 17:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 B2UEJgTutG7c for ; Tue, 10 Jul 2012 17:05:09 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 948BC11E8087 for ; Tue, 10 Jul 2012 17:05:09 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.172]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6B05P8V020827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2012 17:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341965136; bh=YmUMKR0drgx10GbUJfpspm/nyLbYWeJzfk+gudIjlUA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=X1Jp4P+eOqjoE3FWRkX+uS0vlJrZYkyQuC/9lm1M7IXbRNQfRTK56uHnO4ND7fB46 fr4mniNTa/Cpr9pwSBZM3WMAvGzmmu1SrevNhwX2zf6OsD5TxX5KYx3LMWTyV4fClt NrdkiYeHnr+KACnak5r1bEbBOM2MFa9Ow6/h3sS0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1341965136; i=@elandsys.com; bh=YmUMKR0drgx10GbUJfpspm/nyLbYWeJzfk+gudIjlUA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=of8Uc7B4tUl27Y/Tcq8PRaFB4VNx/pszpXj5i3JFvHdTmkHFhamoU4XtNunB2Xfm4 FCEYzv8/o6V/Y7fkMQDWc8/Wn4m8/N5Ua5WK7tNsa9g3czSYP+c6DGR4cBE5h32/JC kHg6lzknFS3LyxewXp/5iJzanoA54U9k+rNjrz/M= Message-Id: <6.2.5.6.2.20120710162304.090ef140@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Jul 2012 17:00:13 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4FFCB4D5.4020905@mail-abuse.org> References: <20120710111308.GC79014@mail.yitter.info> <4FFCB4D5.4020905@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 00:05:13 -0000 At 16:03 10-07-2012, Douglas Otis wrote: >Asia represents a significant market ignored by this draft as it fails >to accommodate current email practices in this region. > >This change even discourages A-label encoding of mail parameters. UTF-8 >mail parameters will break SPF libraries that lack necessary conversion >utilities, and where use of RFC3492/RFC5890 may not be sufficient >without checks for illegal UTF-8 code-points. The draft is work in progress. Scott Kitterman pointed out that there is an open issue in the tracker ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01782.html ). My individual opinion is that the working group is not ignoring issues. >Perhaps this issue might be worthy of some discussion. There was a working session for the last IETF meeting as the face to face discussion was viewed as conducive to attempt to resolve the open issues which have generated substantial discussion on this mailing list. In my individual opinion an issue is worthy of a face to face discussion if it was previously discussed on the mailing list and it is difficult to resolve. regards, S. Moonesamy From vesely@tana.it Wed Jul 11 09:59:03 2012 Return-Path: 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 6B70921F8522 for ; Wed, 11 Jul 2012 09:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.565 X-Spam-Level: X-Spam-Status: No, score=-5.565 tagged_above=-999 required=5 tests=[AWL=1.154, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 cxq0ojdYbPrU for ; Wed, 11 Jul 2012 09:59:02 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 36A0B21F8514 for ; Wed, 11 Jul 2012 09:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342025969; bh=pvffZKYRJq9uTBNdR4yWgl+UtI5XJZ8IWK9p2by2DDk=; l=3648; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=iek98GUrognamU1HoQ/Nz6Yw7ySXzrSJ2k7mauKNcS4dDwio8qluklyBaCNQ5q0Fk IvrGaAjTujvsWU1yz73OemdBYrI5BA8Q36NBBojAUPzqEmmJ9D9dDxavF2wQ+4UY/K xDD/X3YCKoyFz2G/IRvgITA35axXw8LkfHyOT9RM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 11 Jul 2012 18:59:29 +0200 id 00000000005DC035.000000004FFDB0F1.0000643F Message-ID: <4FFDB0F1.5060803@tana.it> Date: Wed, 11 Jul 2012 18:59:29 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Dave Crocker References: <20120711073359.5924572F655@rfc-editor.org> <4FFD91C6.6070301@bbiw.net> In-Reply-To: <4FFD91C6.6070301@bbiw.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: spfbis Subject: [spfbis] Terminology (new issue?) was [Editorial Errata Reported] RFC5598 (3282) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:59:03 -0000 Thank you for your open-mindedness, Dave. The issue originated from the decision to use RFC 5598 terms in http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-03#section-9.3 See http://www.ietf.org/mail-archive/web/spfbis/current/msg01630.html (last paragraphs) I propose to gently introduce non-common RFC 5598 terms in order to increase comprehensibility, e.g. like so: OLD MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail services to third-party domains, such as sending of bulk mail, might want to adjust their setup in light of the authorization check described in this document. NEW Email Service Providers (ESPs), Mailing List Managers (MLMs), and other operators that send mail on behalf of third parties --they are named Mail Service Providers (MSPs) by [RFC5598] Section 2.3-- might want to adjust their setup in light of the authorization check described in this document. I don't think the above is correct, but illustrates my proposals and can hopefully serve as a starting point for a WG-driven refinement of that text. On Wed 11/Jul/2012 16:46:30 +0200 Dave Crocker wrote: > Alessandro is raising an interesting, but I think complicated, issue. > > The terms he introduces are indeed in popular use, but I believe they > do not quite align with the role described in the document as an MSP. > > Merely to record my own view on the terms, but not to suggest a > resolution to the errata: Mailbox Providers are a form of 'edge' > service cited in the document. Email Service Providers is a term > typically used to refer to bulk-sending services, such as for > marketing and newsletters. The document's term, MSP, cites 'transit', > value-added services. It might be that this includes MSPs. It was > also meant to include mailing list operators, and possibly others. > > That is, I think this issue needs some community discussion and > consensus. I expect it will produce some changes to the text whenever > the document is revised. > > As I recall, there's an errata label to fit that status? > > d/ > > > On 7/11/2012 12:33 AM, RFC Errata System wrote: >> The following errata report has been submitted for RFC5598, >> "Internet Mail Architecture". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5598&eid=3282 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Alessandro Vesely >> >> Section: 2.3 >> >> Original Text >> ------------- >> Mail Service Providers (MSPs) >> >> Corrected Text >> -------------- >> either: >> Mailbox Providers (MPs) >> or: >> Email Service Providers (ESPs) >> >> >> Notes >> ----- >> The ambiguity between the two concepts possibly indicated with >> similar terms is frequent. The distinction reported here is due to >> JD Falk, and it seems to be taking roots. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5598 (draft-crocker-email-arch-14) >> -------------------------------------- >> Title : Internet Mail Architecture >> Publication Date : July 2009 >> Author(s) : D. Crocker >> Category : INFORMATIONAL >> Source : IETF - NON WORKING GROUP >> Area : N/A >> Stream : IETF >> Verifying Party : IESG >> >> > From dotis@mail-abuse.org Wed Jul 11 11:18:29 2012 Return-Path: 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 F3D1B21F85B1 for ; Wed, 11 Jul 2012 11:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 SthxyBdVtA15 for ; Wed, 11 Jul 2012 11:18:24 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id E933C21F85AF for ; Wed, 11 Jul 2012 11:18:24 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 18BB21740409 for ; Wed, 11 Jul 2012 18:18:56 +0000 (UTC) Message-ID: <4FFDC38F.4080208@mail-abuse.org> Date: Wed, 11 Jul 2012 11:18:55 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120710111308.GC79014@mail.yitter.info> <4FFCB4D5.4020905@mail-abuse.org> <6.2.5.6.2.20120710162304.090ef140@resistor.net> In-Reply-To: <6.2.5.6.2.20120710162304.090ef140@resistor.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 18:18:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/12 5:00 PM, S Moonesamy wrote: > At 16:03 10-07-2012, Douglas Otis wrote: >> Asia represents a significant market ignored by this draft as it >> fails to accommodate current email practices in this region. >> >> This change even discourages A-label encoding of mail parameters. >> UTF-8 mail parameters will break SPF libraries that lack >> necessary conversion utilities, and where use of RFC3492/RFC5890 >> may not be sufficient without checks for illegal UTF-8 >> code-points. > > The draft is work in progress. Scott Kitterman pointed out that > there is an open issue in the tracker ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01782.html > ). My individual opinion is that the working group is not ignoring > issues. > >> Perhaps this issue might be worthy of some discussion. > > There was a working session for the last IETF meeting as the face > to face discussion was viewed as conducive to attempt to resolve > the open issues which have generated substantial discussion on this > mailing list. In my individual opinion an issue is worthy of a > face to face discussion if it was previously discussed on the > mailing list and it is difficult to resolve. Dear SM, Updates to older documents often confront difficult issues when security in conjunction with evolved infrastructure is considered. This evolution permits users an ability to recognize message sources without reliance on non-validated display names. Should the current document which fails to address current infrastructure assert SMTPUTF8 exchanges be prohibited when SPF might be used? How will local-part macros handle UTF-8 encoded local-parts? What process will ensure valid A-labels can be derived from UTF-8 encoded mail parameters? Will WG documents remain work-in-progress until security issues have been resolved? Security should not be considered a "future" feature. Security should be considered essential for any protocol. Regards, Douglas Otis -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP/cOPAAoJEHXVwboCjGt0+JAIAJW/bxnj3FP5NsJfVMzU7dOQ nqn4g7Y4FdoaWj+yZQMMQNvTBZMfsiqLphyEJc9fIOxTPwMYRXVe4tKD/NrbBOVw B9TfXQfsMgyqN5/iTrRjFq7tIojIuhbktbnmnVBxheAUBCPJxLzg053I9n8ME/lf 4FlkrYoVNcX1HarF7ReslkEshSmgqQcoHckxgdCTwMU9Xh1s1J69Ll3tNt31ThxE x3iyRVukwoIvjxIpb46yvNTF6Eakw80U+8kxEo6Wj6O8a2R32wvITjiQ1qHJcxju 3NB+xK3sIJhyadiO5XT90qImH6ycKlHLIznzlbzNmJgyMXVLSJPRS/9Sf3+O/rY= =MHFj -----END PGP SIGNATURE----- From spf2@kitterman.com Wed Jul 11 11:27:07 2012 Return-Path: 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 4310B11E813E for ; Wed, 11 Jul 2012 11:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 GsllBWEpA7tb for ; Wed, 11 Jul 2012 11:27:06 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4716911E8139 for ; Wed, 11 Jul 2012 11:27:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9A40C20E40A6; Wed, 11 Jul 2012 14:27:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342031256; bh=tlXjuYc17gh/6UxVwXPd0n053QELcNcNqQ1WikqTVlQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EC/fR/bf0kT1e2BzAHJCnXwOdBruPw7wQmvjpIpmyi9A2NrnSbe2HnSj0+YXYRlYM X5/WZgVhKWo8hBLdBw+X+17dIWMGHEqPbxw2bO8Y0oNB/hSh/oqALWqF9dY0yPNilW h33IV/VIft0sucF07qVGE0j98KigiY2mb7Vhn7yE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7D5D320E4081; Wed, 11 Jul 2012 14:27:36 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 11 Jul 2012 14:27:35 -0400 Message-ID: <2234946.KazgRRUpNx@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FFDC38F.4080208@mail-abuse.org> References: <20120710111308.GC79014@mail.yitter.info> <6.2.5.6.2.20120710162304.090ef140@resistor.net> <4FFDC38F.4080208@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 18:27:07 -0000 On Wednesday, July 11, 2012 11:18:55 AM Douglas Otis wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/10/12 5:00 PM, S Moonesamy wrote: > > At 16:03 10-07-2012, Douglas Otis wrote: > >> Asia represents a significant market ignored by this draft as it > >> fails to accommodate current email practices in this region. > >> > >> This change even discourages A-label encoding of mail parameters. > >> UTF-8 mail parameters will break SPF libraries that lack > >> necessary conversion utilities, and where use of RFC3492/RFC5890 > >> may not be sufficient without checks for illegal UTF-8 > >> code-points. > > > > The draft is work in progress. Scott Kitterman pointed out that > > there is an open issue in the tracker ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg01782.html > > ). My individual opinion is that the working group is not ignoring > > issues. > > > >> Perhaps this issue might be worthy of some discussion. > > > > There was a working session for the last IETF meeting as the face > > to face discussion was viewed as conducive to attempt to resolve > > the open issues which have generated substantial discussion on this > > mailing list. In my individual opinion an issue is worthy of a > > face to face discussion if it was previously discussed on the > > mailing list and it is difficult to resolve. > > Dear SM, > > Updates to older documents often confront difficult issues when > security in conjunction with evolved infrastructure is considered. > This evolution permits users an ability to recognize message sources > without reliance on non-validated display names. > > Should the current document which fails to address current > infrastructure assert SMTPUTF8 exchanges be prohibited when SPF might > be used? How will local-part macros handle UTF-8 encoded local-parts? > What process will ensure valid A-labels can be derived from UTF-8 > encoded mail parameters? > > Will WG documents remain work-in-progress until security issues have > been resolved? Security should not be considered a "future" feature. > Security should be considered essential for any protocol. No one intends to ignore actual security issues. If you have a change to propose, please provide text. Scott K From sm@elandsys.com Wed Jul 11 13:10:36 2012 Return-Path: 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 0789D21F84AF for ; Wed, 11 Jul 2012 13:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 lb2QHWJam93n for ; Wed, 11 Jul 2012 13:10:33 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF2121F852B for ; Wed, 11 Jul 2012 13:10:33 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.172]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6BKAf8k021250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2012 13:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342037455; bh=TOesgf86ezAd537Cf2Hw2PJwij9cXlG7WKfDGLdg5pQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wkZgcjBZJhYNZ1WM7ql0bOUis8TKd09K+jgrTnObi2KKsT9N+DdsZp/LdpJ1C7Clc qJldM7Lk31zQXlnqUGjxeWZpSHMiEuwC6SyZyX8U6nAAzdWIf9R6mOovUTp7jpwe+A zu77nEqPIHRWgPwCH87Ls9iJKTUdOffGKrVQosv0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342037455; i=@elandsys.com; bh=TOesgf86ezAd537Cf2Hw2PJwij9cXlG7WKfDGLdg5pQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BaGIrF/hoQU9VHbM8ymZNN39yibOcMoEygiVcYSwVWBl0fE19rteV0AYNn8zUMHAE jxSgt/xt2Umk6uv0JJxPTxwEGibMXHy92vVNiJW1ViXBJSCkYWO9iw2rO+CAv92zDz lFEykDZxPgGG+xiSYxQmumLwV2UPGZnVDi3NWKZI= Message-Id: <6.2.5.6.2.20120711115349.095197a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jul 2012 13:01:51 -0700 To: Douglas Otis From: S Moonesamy In-Reply-To: <4FFDC38F.4080208@mail-abuse.org> References: <20120710111308.GC79014@mail.yitter.info> <4FFCB4D5.4020905@mail-abuse.org> <6.2.5.6.2.20120710162304.090ef140@resistor.net> <4FFDC38F.4080208@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 20:10:36 -0000 Hi Doug, At 11:18 11-07-2012, Douglas Otis wrote: >Updates to older documents often confront difficult issues when >security in conjunction with evolved infrastructure is considered. Yes. That is why there is a working group to discuss and decide what it wants to do about the issues. >Should the current document which fails to address current >infrastructure assert SMTPUTF8 exchanges be prohibited when SPF might >be used? How will local-part macros handle UTF-8 encoded local-parts? > What process will ensure valid A-labels can be derived from UTF-8 >encoded mail parameters? As an example, let's say local-part macros handle UTF-8 encoded local-parts is raised as a security issue. I have to explain clearly why I think it is a security issue. If the working group does not share my opinion, I can still raise it during the Last Call if I believe that the working group did give due consideration to the issue. >Will WG documents remain work-in-progress until security issues have >been resolved? Security should not be considered a "future" feature. >Security should be considered essential for any protocol. The current deliverable is open for discussion. Once the issues have been resolved it should be ready for a WGLC. If issues have been missed people can raise still them. The working group gets to decide on changes or non-changes. There is an IETF-wide Last Call after that. Can you imagine me saying to the Responsible Area Director that "security should be considered as a future feature"? :-) Regards, S. Moonesamy From superuser@gmail.com Wed Jul 11 13:18:52 2012 Return-Path: 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 1822611E80A2 for ; Wed, 11 Jul 2012 13:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 7Ich1UT1Pq1Y for ; Wed, 11 Jul 2012 13:18:51 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA4221F8541 for ; Wed, 11 Jul 2012 13:18:51 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2379794lbb.31 for ; Wed, 11 Jul 2012 13:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=drVyVVhZnjrX8EsuN/cj9+V+r7BQh2hFSE445w5S5Q8=; b=CzFdrvwa6jzwqVYAk7CeqU7uqzq3GZ2RkDPjfVfLzBKRDj6eFvxw+BVmnHdQJnLxTY cVD2azzo8hCZkMam4g2UMG6Q9wQPaRNgjPvOiPsFAmBI3nn/IEkUUaP/Fw50s1DnqRWn Ewpg5YF7IygzIeZIdtcZtQY5lHWjjPV0v1cd5IkzqsY32xnCuY4ZFhpb6v62aSWlJZVq e4ScuebcmVl80Bsp9xnsqLFjEZjCFG0sRTPECMO7JW/OX3wqCz9WwdwemX/ydwuXOoFo By7CodoLO2ib9inrIrC26IYGT3fPnlarEAoSZH/btltn9OUAAaHXROJE8YoLatO21Hxr 6X7Q== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr50151726lab.47.1342037961723; Wed, 11 Jul 2012 13:19:21 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 11 Jul 2012 13:19:21 -0700 (PDT) In-Reply-To: <20120710111308.GC79014@mail.yitter.info> References: <20120710111308.GC79014@mail.yitter.info> Date: Wed, 11 Jul 2012 13:19:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=f46d0435c1d2fbd09604c4938f57 Cc: spfbis@ietf.org Subject: Re: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 20:18:52 -0000 --f46d0435c1d2fbd09604c4938f57 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 10, 2012 at 4:13 AM, Andrew Sullivan wrote: > The Vancouver IETF meeting is approaching, as is the deadline for a WG > meeting agenda. > > Speaking only for myself, I haven't seen a great deal of discussion > here of the sort that seems to require face to face time. Are there > particular issues people think we need to discuss in person, or should > we cede the time back to the rest of the IETF? > > I'm part way through a top-down review of the -03 4408bis draft. I have quite a lot in there in terms of comments and edits to suggest but none of it is "major" and all of it is in the tracker already so far. I think it would be convenient to talk to people in Vancouver about some or all of it, but I don't think doing so is critical to progress. We can do it over the list just as easily. I'll push to finish that review today and send it so we can figure out as a group whether it warrants use of the slot. Otherwise I'm happy to have less to do in Vancouver versus more. -MSK --f46d0435c1d2fbd09604c4938f57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2012 at 4:13 AM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
The Vancouver IETF meeting is approaching, as is the deadline for a WG
meeting agenda.

Speaking only for myself, I haven't seen a great deal of discussion
here of the sort that seems to require face to face time. =A0Are there
particular issues people think we need to discuss in person, or should
we cede the time back to the rest of the IETF?


I'm part way through a top-down review of the= -03 4408bis draft.=A0 I have quite a lot in there in terms of comments and= edits to suggest but none of it is "major" and all of it is in t= he tracker already so far.=A0 I think it would be convenient to talk to peo= ple in Vancouver about some or all of it, but I don't think doing so is= critical to progress.=A0 We can do it over the list just as easily.

I'll push to finish that review today and send it so we can figure = out as a group whether it warrants use of the slot.=A0 Otherwise I'm ha= ppy to have less to do in Vancouver versus more.

-MSK

=A0

--f46d0435c1d2fbd09604c4938f57-- From spf2@kitterman.com Wed Jul 11 13:31:39 2012 Return-Path: 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 3FDC621F85EF for ; Wed, 11 Jul 2012 13:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 a0dnfz0ua79c for ; Wed, 11 Jul 2012 13:31:38 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6138421F85EA for ; Wed, 11 Jul 2012 13:31:38 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5CB3920E40A6; Wed, 11 Jul 2012 16:32:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342038729; bh=m4PJsd1GKI4+jvpqsoRNl3UqSFra41YNUEzfLbA1r8E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LmerF4DSvj226Z3E6Rfkpem+fNhtDuUHDE6cDpGeNZ3/yOh/bR5ARjpB4Y3bft88B X0NGmheyA4DO9IjajK5cZ5i7GtQQXmjnDy67aVF02zgiH+qAxxORYzE+hL1Bt1jgkD NpXkSXW1k9GGRQR/TK1yCV/Go8sliw1QseSY1Guo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3DBE720E4081; Wed, 11 Jul 2012 16:32:09 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 11 Jul 2012 16:32:08 -0400 Message-ID: <3239094.TvJNA7ATiO@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <20120710111308.GC79014@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 20:31:39 -0000 On Wednesday, July 11, 2012 01:19:21 PM Murray S. Kucherawy wrote: > On Tue, Jul 10, 2012 at 4:13 AM, Andrew Sullivan wrote: > > The Vancouver IETF meeting is approaching, as is the deadline for a WG > > meeting agenda. > > > > Speaking only for myself, I haven't seen a great deal of discussion > > here of the sort that seems to require face to face time. Are there > > particular issues people think we need to discuss in person, or should > > we cede the time back to the rest of the IETF? > > I'm part way through a top-down review of the -03 4408bis draft. I have > quite a lot in there in terms of comments and edits to suggest but none of > it is "major" and all of it is in the tracker already so far. I think it > would be convenient to talk to people in Vancouver about some or all of it, > but I don't think doing so is critical to progress. We can do it over the > list just as easily. > > I'll push to finish that review today and send it so we can figure out as a > group whether it warrants use of the slot. Otherwise I'm happy to have > less to do in Vancouver versus more. I won't be in Vancouver, so I do prefer on the list unless we hit some kind of roadblock. If we do, I'll participate remotely like I did last time. Scott K From dotis@mail-abuse.org Wed Jul 11 13:57:59 2012 Return-Path: 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 EAC5611E814B for ; Wed, 11 Jul 2012 13:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 TqilP74ySuYZ for ; Wed, 11 Jul 2012 13:57:59 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6C49F11E813A for ; Wed, 11 Jul 2012 13:57:59 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 0702517400F8 for ; Wed, 11 Jul 2012 20:58:27 +0000 (UTC) Message-ID: <4FFDE8F2.3000809@mail-abuse.org> Date: Wed, 11 Jul 2012 13:58:26 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120710111308.GC79014@mail.yitter.info> <6.2.5.6.2.20120710162304.090ef140@resistor.net> <4FFDC38F.4080208@mail-abuse.org> <2234946.KazgRRUpNx@scott-latitude-e6320> In-Reply-To: <2234946.KazgRRUpNx@scott-latitude-e6320> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 20:58:00 -0000 On 7/11/12 11:27 AM, Scott Kitterman wrote: > On Wednesday, July 11, 2012 11:18:55 AM Douglas Otis wrote: >> Security should be considered essential for any protocol. > > No one intends to ignore actual security issues. > > If you have a change to propose, please provide text. Dear Scott, SMTPUTF8 represents an important security aspect when the recipient considers US-ASCII encoding to be opaque. The display name is not checked and can not act as an alternative validation method. Many approaches might be taken to handle SMTPUTF8. IMHO, local-part macro should be deprecated just like the ptr mechanism. Deprecating local-part macros will better protect DNS caches and eliminate most DDoS amplification vulnerabilities. The supporting services would be more effective when SPF queries do not vary when different local-parts are present. Otherwise, UTF-8 local-parts will likely require encoding to function with most SPF macro libraries. Any macro based upon the domain should use its A-label form, where sub-domains offer a reasonable alternative to the use of local-part macros. Since there have been changes in how A-labels are generated, some text needs to explain how invalid UTF-8 code points are disallowed. Perhaps this could be specified as a conversion symmetry check, or by using a function that detects illegal code-points. Do you see a better way to handle this issue? Regards, Douglas Otis From spf2@kitterman.com Wed Jul 11 17:39:49 2012 Return-Path: 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 9C58211E814F for ; Wed, 11 Jul 2012 17:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 Dsyv50D3NTBB for ; Wed, 11 Jul 2012 17:39:48 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5173411E80A4 for ; Wed, 11 Jul 2012 17:39:48 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id C8690D0407D; Wed, 11 Jul 2012 19:40:16 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342053616; bh=GEh55txWMaJxdcj0vPT5D95RG2p9x+WpAurEoidxHME=; h=References:In-Reply-To:Subject:From:Date:To:From; b=PzZop/4lAv+KE6bny8wal2UU8LPwtcj6vOHW/uafSH6ZM6JnRKb4kcKMAbCWod6Uh D3oJy1iJmbjha1QmLJ+ilHPyvjggOcQZ764jUqOGO+zKjgkM+fD4NG3khoW2xyme91 SqEpKp9rPakW2xtnyIhQy8IVs6MCynz/melOoZws= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 21B25D04058; Wed, 11 Jul 2012 19:40:15 -0500 (CDT) References: <20120710111308.GC79014@mail.yitter.info> <6.2.5.6.2.20120710162304.090ef140@resistor.net> <4FFDC38F.4080208@mail-abuse.org> <2234946.KazgRRUpNx@scott-latitude-e6320> <4FFDE8F2.3000809@mail-abuse.org> User-Agent: K-9 Mail for Android In-Reply-To: <4FFDE8F2.3000809@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 11 Jul 2012 20:40:14 -0400 To: spfbis@ietf.org Message-ID: <4f17802a-dd91-4f0f-b24f-7a1bdff8ab75@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 00:39:49 -0000 Douglas Otis wrote: >On 7/11/12 11:27 AM, Scott Kitterman wrote: >> On Wednesday, July 11, 2012 11:18:55 AM Douglas Otis wrote: >>> Security should be considered essential for any protocol. >> >> No one intends to ignore actual security issues. >> >> If you have a change to propose, please provide text. > >Dear Scott, > >SMTPUTF8 represents an important security aspect when the recipient >considers US-ASCII encoding to be opaque. The display name is not >checked and can not act as an alternative validation method. Many >approaches might be taken to handle SMTPUTF8. IMHO, local-part macro >should be deprecated just like the ptr mechanism. > >Deprecating local-part macros will better protect DNS caches and >eliminate most DDoS amplification vulnerabilities. The supporting >services would be more effective when SPF queries do not vary when >different local-parts are present. Otherwise, UTF-8 local-parts will >likely require encoding to function with most SPF macro libraries. > >Any macro based upon the domain should use its A-label form, where >sub-domains offer a reasonable alternative to the use of local-part >macros. Since there have been changes in how A-labels are generated, >some text needs to explain how invalid UTF-8 code points are >disallowed. > Perhaps this could be specified as a conversion symmetry check, or by >using a function that detects illegal code-points. > >Do you see a better way to handle this issue? I haven't considered it yet. I do notice that you are consistently in favor of deprecating or removing localpart macros for other reasons than internationalization. Is it possible you've jumped to that conclusion and if you stepped back and looked at it again, you might find a better alternative solution for this issue (independent of the broader question of are localpart macros a good idea)? Scott K From johnl@iecc.com Wed Jul 11 17:45:19 2012 Return-Path: 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 6B07411E816D for ; Wed, 11 Jul 2012 17:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.106 X-Spam-Level: X-Spam-Status: No, score=-111.106 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 XK7UXo9vKAdY for ; Wed, 11 Jul 2012 17:45:18 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7E77311E8138 for ; Wed, 11 Jul 2012 17:45:18 -0700 (PDT) Received: (qmail 82385 invoked from network); 12 Jul 2012 00:45:49 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Jul 2012 00:45:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=4ffe1e3d.xn--yuvv84g.k1207; i=johnl@user.iecc.com; bh=lEusce/V9uurD3wq1r0eZX7c38w9i91VK7VpD+J2Tzw=; b=eDE8AO4k7p8Jf7YWmGPveXTooCtLVU8dxigl+0c5gmFVUJLDE2J7AUXrVTbiDLKEpU536lxB+rZ3bwzAc4lpMBr8JcZCkfi5BlzjQEHHmD/nug978qX7040nM7+CIT1GLky+SMq3ZigAF5eI4j75ZBa1gP9mVe8BvKwya3Vm5+M= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=4ffe1e3d.xn--yuvv84g.k1207; olt=johnl@user.iecc.com; bh=lEusce/V9uurD3wq1r0eZX7c38w9i91VK7VpD+J2Tzw=; b=RNA8PJExbnah5aKn6Fr5ghSUECIneA5eT72GEUT61LIOHZtaCPIij7htnBBfuXFMb35RLEru+dxxzjhSsjkOPoiBScErjQH341T/r89c35gSPE6zpeSLoDH9hJstjJwTBVpS+gc8tiMOtRga0eoVIDdMrp6ehEM3h5G03JfwNNg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Jul 2012 00:45:27 -0000 Message-ID: <20120712004527.57320.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 00:45:19 -0000 Since Doug's brought up EAI, here's a few comments from someone who's been active in the EAI WG. Executive summary: we have a problem. An EAI (now officially called SMTPUTF8) address has a UTF-8 localpart and a UTF-8 domain. The domain has to a U-label, that is, limited to characters that can be translated to an A-label (xn--whatever) and looked up in the DNS. There is no such restriction on the localpart. It can be any UTF-8 that fits in 64 octets. Technically, the definition of A-labels changed between 2003 and 2008, in practice the difference only affects two obscure characters that nobody has seen in the wild, so we can ignore it. It is reasonable to say that the macros that expand to domain names, o d p h r and their various transformations are turned into A-labels, since as I understand it, the main reason to use macros is to concoct a name that is to be looked up in the DNS. For macros that expand to local parts, s l and their variants, you can't do that. The local part does not have to be a U-label, so in general, you can't turn it into a domain name. This isn't entirely a new problem; ASCII localparts can contain arbitrary characters that no sane person would put into a domain name, e.g. A#$!%")z, and localparts are in principle case sensitive and domain names aren't, so localpart macros have always been ambiguous. My suggestion would be to say that the domain names are turned into A-labels, but s and l macros are deprecated, since there's no way to turn them into domain names short of some crock like base64 encoding them which would not be backward compatible. R's, John From spf2@kitterman.com Wed Jul 11 18:28:58 2012 Return-Path: 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 3A45F21F8592 for ; Wed, 11 Jul 2012 18:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 pufGpIAbq30G for ; Wed, 11 Jul 2012 18:28:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 80CE621F854A for ; Wed, 11 Jul 2012 18:28:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A401A20E40A6; Wed, 11 Jul 2012 21:29:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342056568; bh=hzj5CTexaWkrwJQ9fpB37NPcq5hGOzG92ew1kbZk9Bo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FlQ2JF+v90KAaiOEZq8jCclAQXYBiqLJciSi4wj6pNqKHYSz9uHG37xgA6EtpukaR g683R75XrVxElrOwYABp2ZuCPJU7L+gDyweghJGsMJy1DckcOLCYXiibJ5JARQEg3T 5kAvW6XRcwILUiLtCt7dIJuQSHjijTcgOLhw9zDU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7677820E4081; Wed, 11 Jul 2012 21:29:28 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 11 Jul 2012 21:29:27 -0400 Message-ID: <1593789.OFTZimiIpU@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120712004527.57320.qmail@joyce.lan> References: <20120712004527.57320.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 01:28:58 -0000 On Thursday, July 12, 2012 12:45:27 AM John Levine wrote: > Since Doug's brought up EAI, here's a few comments from someone who's > been active in the EAI WG. > > Executive summary: we have a problem. > > An EAI (now officially called SMTPUTF8) address has a UTF-8 localpart > and a UTF-8 domain. The domain has to a U-label, that is, limited to > characters that can be translated to an A-label (xn--whatever) and > looked up in the DNS. There is no such restriction on the localpart. > It can be any UTF-8 that fits in 64 octets. Technically, the > definition of A-labels changed between 2003 and 2008, in practice the > difference only affects two obscure characters that nobody has seen in > the wild, so we can ignore it. > > It is reasonable to say that the macros that expand to domain names, o > d p h r and their various transformations are turned into A-labels, > since as I understand it, the main reason to use macros is to concoct > a name that is to be looked up in the DNS. > > For macros that expand to local parts, s l and their variants, you > can't do that. The local part does not have to be a U-label, so in > general, you can't turn it into a domain name. This isn't entirely a > new problem; ASCII localparts can contain arbitrary characters that no > sane person would put into a domain name, e.g. A#$!%")z, and > localparts are in principle case sensitive and domain names aren't, so > localpart macros have always been ambiguous. > > My suggestion would be to say that the domain names are turned into > A-labels, but s and l macros are deprecated, since there's no way to > turn them into domain names short of some crock like base64 encoding > them which would not be backward compatible. Localpart macros that can't be represented as A labels are pointless, ASCII or UTF-8. Rather than deprecate them why not just limit them to things that can be represented that way? Yes, it imposes some limitations on theoretical future use, but I think it would be backward compatible and support about as much of SMTPUTF8 as we can without having to recharter. Scott K From dhc@dcrocker.net Wed Jul 11 18:57:40 2012 Return-Path: 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 DEA0221F85E4 for ; Wed, 11 Jul 2012 18:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HoFYKssIb1-d for ; Wed, 11 Jul 2012 18:57:40 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 87BEE21F85E3 for ; Wed, 11 Jul 2012 18:57:35 -0700 (PDT) Received: from [192.168.1.9] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6C1w6UT007002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jul 2012 18:58:06 -0700 Message-ID: <4FFE2F29.8040102@dcrocker.net> Date: Wed, 11 Jul 2012 18:58:01 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Levine References: <20120712004527.57320.qmail@joyce.lan> In-Reply-To: <20120712004527.57320.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 11 Jul 2012 18:58:06 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 01:57:41 -0000 On 7/11/2012 5:45 PM, John Levine wrote: > Executive summary: we have a problem. Eventually, perhaps. On the average, it is not wise to make any significant adjustments for new standards that have yet to achieve widespread deployment. EAI has a very, very rocky history. Perhaps this latest round of effort will indeed gain traction. In spite of the obvious and major need for something like EAI, we are nonetheless left with a poor history -- both before and during the current effort -- and with specifications that remain a bit troubling. My advice is that the current SPFbis effort should continue focus on actual SPF experience. If there are small changes that can aid in EAI use, then it's probably safe to add them. I doubt there are any however. Save the larger changes for when EAI has established its operational success. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Wed Jul 11 19:20:43 2012 Return-Path: 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 01A5011E809A for ; Wed, 11 Jul 2012 19:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.11 X-Spam-Level: X-Spam-Status: No, score=-111.11 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 BCHI7rGu5lyr for ; Wed, 11 Jul 2012 19:20:42 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 099BF11E80FA for ; Wed, 11 Jul 2012 19:20:41 -0700 (PDT) Received: (qmail 98553 invoked from network); 12 Jul 2012 02:21:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Jul 2012 02:21:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4ffe3499.xn--hew.k1207; i=johnl@user.iecc.com; bh=MMs2V1+6vN/zq0N7zGD0fz3+pBcB+ww+wCuocvfy8hE=; b=f7RAH8qa78Vm5ptR6EZ4H+F0ugVKrRiVmkpLeJOiTPc9ZrM+99VIhNx6lPBdOAHWIXsulWtW7AiAN1CYViZEGpASpkgMfAe8SawYflejZre4GZaHZ7qIWUZGLC6JqHEsKsgWEnq9X7SzxHy2xKH7aGTck9dpM8yyV0O2NUyj4Rs= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4ffe3499.xn--hew.k1207; olt=johnl@user.iecc.com; bh=MMs2V1+6vN/zq0N7zGD0fz3+pBcB+ww+wCuocvfy8hE=; b=gw0g1XUH1C7ZLRkgpR1DGG9uJe2aIJLAs12zrBFgQUm779WImJK+lgvROZVn/UB6yexm9q8ov8oPuZZOUMlB0sjqk93m8iZnGg0X/P6HmgNlJLzLGiSXUFwiZt1BpkPqC/QRaq22yGO1lrXAkDcdPpHZL56MkcM8OjFFJtU0xaY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Jul 2012 02:20:51 -0000 Message-ID: <20120712022051.60587.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1593789.OFTZimiIpU@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 02:20:43 -0000 >Localpart macros that can't be represented as A labels are pointless, ASCII or >UTF-8. Rather than deprecate them why not just limit them to things that can >be represented that way? Well, OK. If an address shows up with a local part that's not a U-label, and the SPF record contains %l, what happens? For that matter, if the local part is @*#&$)(! "; what happens now? R's, John From spf2@kitterman.com Wed Jul 11 19:59:42 2012 Return-Path: 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 AB57611E8100 for ; Wed, 11 Jul 2012 19:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 U6+G1ugD3ePK for ; Wed, 11 Jul 2012 19:59:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E728711E80A1 for ; Wed, 11 Jul 2012 19:59:40 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 637A920E40A6; Wed, 11 Jul 2012 23:00:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342062012; bh=2Ew6+JJMia16mbqaDNGszo/DMTtXwv1UPXTMm62vyPI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nFWwrHo3vi9DUQ+IyG2Dd6ohvXahKyzbHI9wBONOygX33LV10FpXwnXlYjxQNfpXj uW1JmfwAEFlfzPCv9WIVltsCAnkDN9nQBMw9fbMxtrlQ3hufdwu1jnrEABiwIy8Ehr VeqUpYn02UXj3TIx7LRZODsZc9B726c6LcJnbsYg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 461AD20E4081; Wed, 11 Jul 2012 22:59:42 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 11 Jul 2012 22:59:41 -0400 Message-ID: <44748439.FJPUX3FY8g@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120712022051.60587.qmail@joyce.lan> References: <20120712022051.60587.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 02:59:42 -0000 On Thursday, July 12, 2012 02:20:51 AM John Levine wrote: > >Localpart macros that can't be represented as A labels are pointless, ASCII > >or UTF-8. Rather than deprecate them why not just limit them to things > >that can be represented that way? > > Well, OK. If an address shows up with a local part that's not a U-label, > and the SPF record contains %l, what happens? > > For that matter, if the local part is @*#&$)(! "; what happens now? It won't match, so it's not a pass/neutral/etc. I think it's the same for this. At least this is my interpretation. IIRC it doesn't explicitly say that, but given the way it all works, I don't see how it could be anything else. I think localpart macros are rare enough that no one need any sleep over them not supporting the full range of UTF-8, but they are in use so it's out of scope to ditch them (I believe we resolved that already). Clearly we need some clarification on exactly how to go about this, but I don't see a major issue. Since a localpart that can't be represented as an A label can't work as a localpart macro, the worst is there are some localparts that you can't use. There is no case where the limitation causes things to fail open. Scott K From superuser@gmail.com Wed Jul 11 23:47:14 2012 Return-Path: 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 DD6DD11E80E9 for ; Wed, 11 Jul 2012 23:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 0PG-BQzdH2bm for ; Wed, 11 Jul 2012 23:47:14 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 50AC511E80CE for ; Wed, 11 Jul 2012 23:47:14 -0700 (PDT) Received: by yenq13 with SMTP id q13so2228911yen.31 for ; Wed, 11 Jul 2012 23:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F5Q7hZZDe86tZv+LUotnTFqsOajArkoysgeiU1cn8h0=; b=SLo+5qF1gSFCh1dbbfFdoq5cIDD/13e39ZT2FsG0BnkVMPcRIfLvMPr4Ifb7ENI5II ReqEKcCb/80wZB93bs9LJ7Xphxqcihk8XPbBHLtDoPRtPDz+c1qNICA2EtTqGIQmAdL0 3K665+4Wxfs6F7/A4uh3MI0o6ICFIcbAavb80s8P89YNprfkK531XxdBFgs/Eps1wIZ+ F+wmngp6+4aJb0hetRMd2LAGG/+m+Q6vhwdlcbMl45vD60gN72gNyfmbPAD/u6oD49B6 ByOeoCba3gi1134dOebZktCK1uKeSGwwkA1oaEuniA4tk8+AbeL0HD9C45yiupj95sTw b0SA== MIME-Version: 1.0 Received: by 10.60.168.230 with SMTP id zz6mr53415398oeb.11.1342075666603; Wed, 11 Jul 2012 23:47:46 -0700 (PDT) Received: by 10.182.28.65 with HTTP; Wed, 11 Jul 2012 23:47:46 -0700 (PDT) In-Reply-To: <44748439.FJPUX3FY8g@scott-latitude-e6320> References: <20120712022051.60587.qmail@joyce.lan> <44748439.FJPUX3FY8g@scott-latitude-e6320> Date: Wed, 11 Jul 2012 23:47:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=bcaec54ee8cc5e9e4a04c49c571d Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 06:47:15 -0000 --bcaec54ee8cc5e9e4a04c49c571d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 11, 2012 at 7:59 PM, Scott Kitterman wrote: > I think localpart macros are rare enough that no one need any sleep over > them > not supporting the full range of UTF-8, but they are in use so it's out of > scope to ditch them (I believe we resolved that already). > My data from the experiment document show 220 records using macros of any kind, out of over 150,000 responding. Only 18 of those contain local part macros. I haven't checked Philip's data but I expect it to be similar. I would support deprecating them if this is a real problem. I'm also fine with Scott's proposed solution, if we can agree on it. -MSK --bcaec54ee8cc5e9e4a04c49c571d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 11, 2012 at 7:59 PM, Scott Kitterman <spf2@kitterman.com&= gt; wrote:
I think localpart macros are rare enough that no one need any sleep over th= em
not supporting the full range of UTF-8, but they are in use so it's out= of
scope to ditch them (I believe we resolved that already).
<= div>
My data from the experiment document show 220 records using macros = of any kind, out of over 150,000 responding.=A0 Only 18 of those contain lo= cal part macros.=A0 I haven't checked Philip's data but I expect it= to be similar.

I would support deprecating them if this is a real problem.

I= 9;m also fine with Scott's proposed solution, if we can agree on it.
-MSK

--bcaec54ee8cc5e9e4a04c49c571d-- From dhc@dcrocker.net Thu Jul 12 07:41:06 2012 Return-Path: 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 71D7921F8759 for ; Thu, 12 Jul 2012 07:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 U1cfZ-ZGRBKt for ; Thu, 12 Jul 2012 07:41:05 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A44FF21F86FE for ; Thu, 12 Jul 2012 07:41:05 -0700 (PDT) Received: from [192.168.1.9] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6CEfREp019024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 07:41:33 -0700 Message-ID: <4FFEE210.8040505@dcrocker.net> Date: Thu, 12 Jul 2012 07:41:20 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120712022051.60587.qmail@joyce.lan> <44748439.FJPUX3FY8g@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 12 Jul 2012 07:41:37 -0700 (PDT) Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 14:41:06 -0000 On 7/11/2012 11:47 PM, Murray S. Kucherawy wrote: > > I would support deprecating them if this is a real problem. given how little they are used and the inherent complexity added by macros, wouldn't it make sense to deprecate them anyhow? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Thu Jul 12 07:42:44 2012 Return-Path: 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 A01C921F87D6 for ; Thu, 12 Jul 2012 07:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 QhW+fU5SmkQE for ; Thu, 12 Jul 2012 07:42:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2547921F86FE for ; Thu, 12 Jul 2012 07:42:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D7C0220E40A6; Thu, 12 Jul 2012 10:43:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342104196; bh=NK4CWswCxN6PZ27dGpAaly6MHmpOyHGqQCoZzLdT1RE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KwQWRNx1jnTekzUfalfX/64Bt2I2TmnLcUyjviUo+kocdVbqjyGKKs+k9gMxroGxT nAIygNtkPKgy1TqCOK6ZwFCEJrInkVFvPxLk5FvknTZz3CDyDUNgOGL+rzSirEtp8W g8rKV7NH3WzSKAOFEBcGBdQe7Z8Y2gKgCb0zOKXE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B854820E4091; Thu, 12 Jul 2012 10:43:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 12 Jul 2012 10:43:16 -0400 Message-ID: <1580918.8gPlF2dls6@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FFEE210.8040505@dcrocker.net> References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 14:42:44 -0000 On Thursday, July 12, 2012 07:41:20 AM Dave Crocker wrote: > On 7/11/2012 11:47 PM, Murray S. Kucherawy wrote: > > I would support deprecating them if this is a real problem. > > given how little they are used and the inherent complexity added by > macros, wouldn't it make sense to deprecate them anyhow? We already went through this once and decided not. I don't think EAI changes that. Scott K From dhc@dcrocker.net Thu Jul 12 07:59:05 2012 Return-Path: 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 40FBE21F8681 for ; Thu, 12 Jul 2012 07:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hZYcIZoTVOkk for ; Thu, 12 Jul 2012 07:59:04 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE5E21F866E for ; Thu, 12 Jul 2012 07:58:57 -0700 (PDT) Received: from [192.168.1.9] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6CExUvo020061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 07:59:30 -0700 Message-ID: <4FFEE64C.6000308@dcrocker.net> Date: Thu, 12 Jul 2012 07:59:24 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> In-Reply-To: <1580918.8gPlF2dls6@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 12 Jul 2012 07:59:31 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 14:59:05 -0000 On 7/12/2012 7:43 AM, Scott Kitterman wrote: > We already went through this once and decided not. I don't think EAI changes > that. I am reacting to the statistic that Murray provided, not to EAI issues. A feature that adds significantly complexity in design, development and operation (debugging) but has gained so little use is a feature worth dropping. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Thu Jul 12 08:11:43 2012 Return-Path: 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 12D0921F87F5 for ; Thu, 12 Jul 2012 08:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 wtuzySl08kdT for ; Thu, 12 Jul 2012 08:11:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC1721F87BC for ; Thu, 12 Jul 2012 08:11:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id ACCCE20E40A6; Thu, 12 Jul 2012 11:12:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342105935; bh=i4kgb6eg0wOOTAivKDRxpj26vQQbs/EsDqKPBwnu204=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Grov76UxtAZR5hVeKK96JW1jdTtKUfVX6uu6D/V1zHgxo7j/Ds4N/+W04dTnS5wME dLg/24jSO8nsPUS879UxSAfCqfLBrPeRge9Ad3lS9hDMHSdJ4oPwYFyx2SvQdTiNRb UKckb9p/A9p8HVI7ZPu7n/ARkgQcsJZc3dkQ00ZQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8E87F20E4091; Thu, 12 Jul 2012 11:12:15 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 12 Jul 2012 11:12:14 -0400 Message-ID: <3489998.IRH7rCGsD1@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FFEE64C.6000308@dcrocker.net> References: <20120712022051.60587.qmail@joyce.lan> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 15:11:43 -0000 On Thursday, July 12, 2012 07:59:24 AM Dave Crocker wrote: > On 7/12/2012 7:43 AM, Scott Kitterman wrote: > > We already went through this once and decided not. I don't think EAI > > changes that. > > I am reacting to the statistic that Murray provided, not to EAI issues. > > A feature that adds significantly complexity in design, development and > operation (debugging) but has gained so little use is a feature worth > dropping. We've already been through this once. It's issue http://trac.tools.ietf.org/wg/spfbis/trac/ticket/14 and the chairs marked it closed/wontfix. We have enough to do just doing everything once, I'd ask we try and avoid repeats. Scott K From vesely@tana.it Thu Jul 12 09:06:28 2012 Return-Path: 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 41BB811E80B3 for ; Thu, 12 Jul 2012 09:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.608 X-Spam-Level: X-Spam-Status: No, score=-4.608 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 IGtpY6bV5rch for ; Thu, 12 Jul 2012 09:06:27 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 79A9B11E8073 for ; Thu, 12 Jul 2012 09:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342109214; bh=6JX0gnad9RjZrQewo4olZ/Tq4kdiGx9CDp47HedZbyg=; l=1855; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=PkiZxf5Rx/H+Ep0Jweegg5troWe7rPiEZ8TIdjTRO+a3Jtxrw8/G+ovKwQo96gNfy VeLW00YPuyuk2G8GXv6XMLHJfJ3BoU2e/bTRlNXDPir7zKFf40hmr12QHUrSBSC+Ic oF5uVrJ8emqmM+JkznO3S8bwwfJyQTSxxnO4iXI8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 12 Jul 2012 18:06:54 +0200 id 00000000005DC035.000000004FFEF61E.00002EE7 Message-ID: <4FFEF61E.2040104@tana.it> Date: Thu, 12 Jul 2012 18:06:54 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120712022051.60587.qmail@joyce.lan> <44748439.FJPUX3FY8g@scott-latitude-e6320> In-Reply-To: <44748439.FJPUX3FY8g@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 16:06:28 -0000 On Thu 12/Jul/2012 04:59:41 +0200 Scott Kitterman wrote: > On Thursday, July 12, 2012 02:20:51 AM John Levine wrote: >>> Localpart macros that can't be represented as A labels are pointless, ASCII >>> or UTF-8. Rather than deprecate them why not just limit them to things >>> that can be represented that way? >> >> Well, OK. If an address shows up with a local part that's not a U-label, >> and the SPF record contains %l, what happens? >> >> For that matter, if the local part is @*#&$)(! "; what happens now? > > It won't match, so it's not a pass/neutral/etc. I think it's the same for > this. No, wait. That makes sense for constructs like (Section 9.1.2) v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all However, a local part may also appear in an explanation (Section 6.2) "See http://%{d}/why.html?s=%{S}&i=%{I}" Since SPF is not giving a possibility to URL-encode @*#&$)(! "; it is not going to add it now for UTF-8. However, what if an SPF implementation needs to return an UTF-8 reply from a server which does not implement SMTPUTF8? > Clearly we need some clarification on exactly how to go about this, but I don't > see a major issue. Since a localpart that can't be represented as an A label > can't work as a localpart macro, the worst is there are some localparts that > you can't use. There is no case where the limitation causes things to fail > open. Agreed. How about s/US-ASCII/UTF-8/? It makes sense to try and convert to an A-label whatever string is not US-ASCII /just before/ doing a query, as a general rule. Failed conversions result in permerror. With such kind of rule, SPF can accept either encoding in input, both for parameters and SPF records. Mail admins who are so savvy as to limit local parts to U-labels can expect the above "exists" to work untouched. From ajs@anvilwalrusden.com Thu Jul 12 17:08:32 2012 Return-Path: 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 131B111E80BD for ; Thu, 12 Jul 2012 17:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 veQhKbf0OngR for ; Thu, 12 Jul 2012 17:08:30 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECFD11E80B6 for ; Thu, 12 Jul 2012 17:08:29 -0700 (PDT) Received: from mail.yitter.info (74-92-33-113-NewEngland.hfc.comcastbusiness.net [74.92.33.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4F1628A034 for ; Fri, 13 Jul 2012 00:09:02 +0000 (UTC) Date: Thu, 12 Jul 2012 20:09:01 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120713000901.GB92752@mail.yitter.info> References: <20120710111308.GC79014@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120710111308.GC79014@mail.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 00:08:32 -0000 Dear colleagues, Unless I missed something significant, the disucussion has not revealed anything that should be handled face to face instead of in person. So our plan is to cancel this session. If you object to this very strongly, please propose a clear agenda item with questions to be answered in the face to face meeting by 17:00 EDT tomorrow (that's 21:00 UTC). Otherwise, we'll inform the secretariat. Thanks for the productive discussion on the list. Best, A On Tue, Jul 10, 2012 at 07:13:09AM -0400, Andrew Sullivan wrote: > Dear colleagues, > > The Vancouver IETF meeting is approaching, as is the deadline for a WG > meeting agenda. > > Speaking only for myself, I haven't seen a great deal of discussion > here of the sort that seems to require face to face time. Are there > particular issues people think we need to discuss in person, or should > we cede the time back to the rest of the IETF? > > Best, > > A > -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Thu Jul 12 20:48:46 2012 Return-Path: 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 F237211E8115 for ; Thu, 12 Jul 2012 20:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Esb4JXapV67j for ; Thu, 12 Jul 2012 20:48:45 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA26511E8113 for ; Thu, 12 Jul 2012 20:48:44 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4392331lbb.31 for ; Thu, 12 Jul 2012 20:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C0FPANQSjeP/z978ejtM6EB7HA424v1ujy7quhRdbcc=; b=pY0lKgqmsDsmo/Vzu0BuaYe7uoSE0104n96BFa81WWLbgOid/4SmzQ5vcmKbJ+IWxs gaXPAZaLZXbW0Vr7MgLfLw3H9ybAXQOHEKp+bjRXBgX9K9RvITzbMABkPtfPvJ4ioVt9 vXe/5IDkP4ygpU0naSpUYPK5GCarbDhFgPekbS+rf7VutgD4eJUdVzaXEZyx58JUtfs7 2O/gxoMNprmrg2D6A6aM+EFz+rv4LbL1fNGLCHNXDp8JILqJHhweVNj+Lbd6xAVVfvLL eeBWtxw7fnS0ik93wfUwQMGtwZcsJBmcuxdFr3Bx3y5bcAS1ciAkwltKZlUqgvKzy8u1 A2Ww== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr18718lbn.10.1342151358918; Thu, 12 Jul 2012 20:49:18 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 12 Jul 2012 20:49:18 -0700 (PDT) In-Reply-To: <3489998.IRH7rCGsD1@scott-latitude-e6320> References: <20120712022051.60587.qmail@joyce.lan> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <3489998.IRH7rCGsD1@scott-latitude-e6320> Date: Thu, 12 Jul 2012 20:49:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=bcaec554d63cfbb10204c4adf6da Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 03:48:46 -0000 --bcaec554d63cfbb10204c4adf6da Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 12, 2012 at 8:12 AM, Scott Kitterman wrote: > On Thursday, July 12, 2012 07:59:24 AM Dave Crocker wrote: > > On 7/12/2012 7:43 AM, Scott Kitterman wrote: > > > We already went through this once and decided not. I don't think EAI > > > changes that. > > > > I am reacting to the statistic that Murray provided, not to EAI issues. > > > > A feature that adds significantly complexity in design, development and > > operation (debugging) but has gained so little use is a feature worth > > dropping. > > We've already been through this once. It's issue > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/14 and the chairs marked > it > closed/wontfix. We have enough to do just doing everything once, I'd ask > we > try and avoid repeats. > > I believe that ticket was closed based on the argument that originally opened it, namely that local part macros are a DNS load or security consideration. I agree that this argument failed to gain traction, and we closed it on that basis. What I'm talking about (and Dave is agreeing to) is that macros in general, and local-part macros in particular, see even less use than Sender ID, so it's within charter to remove them in RFC4408bis on that basis alone. It has nothing to do with the original argument in tracker item 14. -MSK --bcaec554d63cfbb10204c4adf6da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 12, 2012 at 8:12 AM, Scott Kitterman= <spf2@kitterman.com> wrote:
On Thursday, July 12, 2012 07:59:24 AM Dave Crocker wrote= :
> On 7/12/2012 7:43 AM, Scott Kitterman wrote:
> > We already went through this once and decided not. =A0I don't= think EAI
> > changes that.
>
> I am reacting to the statistic that Murray provided, not to EAI issues= .
>
> A feature that adds significantly complexity in design, development an= d
> operation (debugging) but has gained so little use is a feature worth<= br> > dropping.

We've already been through this once. =A0It's issue
http://trac.tools.ietf.org/wg/spfbis/trac/ticket/14 and the chai= rs marked it
closed/wontfix. =A0We have enough to do just doing everything once, I'd= ask we
try and avoid repeats.


I believe that ticket was closed based on the arg= ument that originally opened it, namely that local part macros are a DNS lo= ad or security consideration.=A0 I agree that this argument failed to gain = traction, and we closed it on that basis.

What I'm talking about (and Dave is agreeing to) is that macros in = general, and local-part macros in particular, see even less use than Sender= ID, so it's within charter to remove them in RFC4408bis on that basis = alone.=A0 It has nothing to do with the original argument in tracker item 1= 4.

-MSK

--bcaec554d63cfbb10204c4adf6da-- From spf2@kitterman.com Thu Jul 12 21:10:17 2012 Return-Path: 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 E635C11E811A for ; Thu, 12 Jul 2012 21:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 qVSmK2E45QYR for ; Thu, 12 Jul 2012 21:10:17 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 19C9F11E80CF for ; Thu, 12 Jul 2012 21:10:17 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8C80F20E40A6; Fri, 13 Jul 2012 00:10:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342152651; bh=s8Wix0xLGPgKa7pGxP53rAgEJvzWmWYXrcHXdcJfpS8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=R27DplHJQTJJFisbXG6g2xlU/bJ3OVYac/vAhvYShMSI36zBnSalSCDdvQAlvC60N pYljfBMeHsk0fgBFmoosyddcuymvQdPXoZHCXUDl7l69YsqMaNmWuaqkmKpT1eBnWv i75RzyzhCdTUpmom8ka9/bfEGje42pzVvjBoJtTY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7056D20E4091; Fri, 13 Jul 2012 00:10:51 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Jul 2012 00:10:50 -0400 Message-ID: <2786082.683g7oVmD0@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <20120712022051.60587.qmail@joyce.lan> <3489998.IRH7rCGsD1@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 04:10:18 -0000 On Thursday, July 12, 2012 08:49:18 PM Murray S. Kucherawy wrote: > On Thu, Jul 12, 2012 at 8:12 AM, Scott Kitterman wrote: > > On Thursday, July 12, 2012 07:59:24 AM Dave Crocker wrote: > > > On 7/12/2012 7:43 AM, Scott Kitterman wrote: > > > > We already went through this once and decided not. I don't think EAI > > > > changes that. > > > > > > I am reacting to the statistic that Murray provided, not to EAI issues. > > > > > > A feature that adds significantly complexity in design, development and > > > operation (debugging) but has gained so little use is a feature worth > > > dropping. > > > > We've already been through this once. It's issue > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/14 and the chairs marked > > it > > closed/wontfix. We have enough to do just doing everything once, I'd ask > > we > > try and avoid repeats. > > I believe that ticket was closed based on the argument that originally > opened it, namely that local part macros are a DNS load or security > consideration. I agree that this argument failed to gain traction, and we > closed it on that basis. > > What I'm talking about (and Dave is agreeing to) is that macros in general, > and local-part macros in particular, see even less use than Sender ID, so > it's within charter to remove them in RFC4408bis on that basis alone. It > has nothing to do with the original argument in tracker item 14. The charter says "removal of unused features". This is different than type SPF because type SPF was redundant, this is not. I don't think it's in our charter to break existing, published SPF record without a compelling case. I don't think rarely used is at all compelling. I don't think simplification is at all compelling either. Yes, writing an SPF library would be simpler without macros, but I don't think there's a lot of new library writing going on today. It was done 5 - 7 years ago, so whatever theoretical benefit simplification would bring, in practice there won't be any. I checked and in pyspf there are, by my count (and including blank lines, comments, and tests), 169 lines out of 1,986 related in any way to macros. Removing macros would make things slightly simpler for whatever future library writers there may be, but it removes a tool from the box that some people find useful. Scott K From superuser@gmail.com Thu Jul 12 21:58:00 2012 Return-Path: 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 C282421F86B4 for ; Thu, 12 Jul 2012 21:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 UlrOi8R3eKvv for ; Thu, 12 Jul 2012 21:57:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 22DC221F86AA for ; Thu, 12 Jul 2012 21:57:58 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4453370lbb.31 for ; Thu, 12 Jul 2012 21:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YZmcaZB4rUmN1sQrr/+NAdgoXBZqsg6SyWVJqvV+b24=; b=yPPqv8sW8sJLLa1fKeNOVHd13dvXR0SGtM7QPqq0LvEz0vXQij45x0YId7PfwscCmv X+VVe0VCshgQwLG8mhpFYxKbl4z8NcYVWrOH1o2C+ip+8fYgQv5SZ4bRIvGZu8nYMuMq zFty4Zpiv2EgvE/MPEzbT8kgr8WYxLmfVu+cxQl0D5AQRU0MWqCEP5Vy42J7uTDFiBbW TT+fCetIP8A+N88BHNtqqVzbZX7u/vOvJT/gyPuSkUCnI7svr+KLVjCVHh/AsmPep9vR mkQujuXvULyPCWzQPiaqC6BZCBiKZEjXzXsUX0vHFGnIgPqd8buAmtqgGlWUhGDxJt76 NEBw== MIME-Version: 1.0 Received: by 10.112.83.169 with SMTP id r9mr59429lby.66.1342155513246; Thu, 12 Jul 2012 21:58:33 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 12 Jul 2012 21:58:33 -0700 (PDT) In-Reply-To: <2786082.683g7oVmD0@scott-latitude-e6320> References: <20120712022051.60587.qmail@joyce.lan> <3489998.IRH7rCGsD1@scott-latitude-e6320> <2786082.683g7oVmD0@scott-latitude-e6320> Date: Thu, 12 Jul 2012 21:58:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0401fc4399b2cb04c4aeee48 Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 04:58:00 -0000 --f46d0401fc4399b2cb04c4aeee48 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2012 at 9:10 PM, Scott Kitterman wrote= : > The charter says "removal of unused features". This is different than > type SPF > because type SPF was redundant, this is not. > I think the issue of redundancy is inapposite. It's an unused feature, pure and simple. The statistics show far less less than 1% use. Why do we need to keep something as complicated as macro expansion when almost nobody is using it? Perhaps more importantly: Why was it okay for us to decide Sender ID is de facto obsolete, while even stronger evidence (by orders of magnitude) against macros must be disregarded? If it would help, I could add up the number of lines in sid-milter that added Sender ID support for comparison. It, too, was relatively small. I don't think it's in our charter to break existing, published SPF record > without a compelling case. I don't think rarely used is at all > compelling. I > don't think simplification is at all compelling either. > Purely from a procedural standpoint, I disagree. SPF is currently Experimental, and moving to Proposed Standard is an ideal time to chop out things that fewer than two tenths of one percent of the deployed base is using. That comprises part of what we learned from the experiment. I don't agree that we are mandated to cater to such a tiny number of sites. The remaining question is whether the working group believes use by 200 out of 150,000 warrants keeping the feature. To use your own argument, if in 5-7 years we've seen only this much use of SPF macros, I'm doubtful it's going to increase. But, to be fair, we don't have a hard-and-fast definition of "unused" when going through this exercise, so it's left to consensus. Others will have to weigh in. We do have precedent, however, as a guide. For example, when DKIM went to Draft Standard, we chopped a few things (most notably "g=3D") because they had seen almost zero adoption. According to the RFC4871 interoperability report, after 8.1M signed messages were processed, only 434 of keys were found that had "g=3D" tags in them. So the use wasn't zero, and someone apparently found them potentially useful, but the decision was made that there was not enough adoption to warrant keeping the complexity in the specification. However, we didn't remove "l=3D", much as we wanted to, because its use was around 3.7%. Same with "x=3D" (3.4%) and "z=3D" (5.9%). Use of SPF macros falls somewhere in between those and "g=3D". There are other examples of this tactic going back as far as RFC821 (SAML and SOML). You argued that the complexity isn't that big based on lines of code. It wasn't for "g=3D" either. I removed 162 lines of code that time from OpenDKIM, and we removed a small section of the RFC. As is often quoted around these parts: "=93Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away." -MSK --f46d0401fc4399b2cb04c4aeee48 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2012 at 9:10 PM, Scott Kitterman <spf2@kitterman.com&= gt; wrote:
The charter says "removal of unused features". =A0This is differe= nt than type SPF
because type SPF was redundant, this is not.

I thi= nk the issue of redundancy is inapposite.=A0 It's an unused feature, pu= re and simple.=A0 The statistics show far less less than 1% use.

Why= do we need to keep something as complicated as macro expansion when almost= nobody is using it?

Perhaps more importantly: Why was it okay for us to decide Sender ID is= de facto obsolete, while even stronger evidence (by orders of magnitude) a= gainst macros must be disregarded?=A0 If it would help, I could add up the = number of lines in sid-milter that added Sender ID support for comparison.= =A0 It, too, was relatively small.

I don't think it's in our charter to break existing, published SPF = record
without a compelling case. =A0I don't think rarely used is at all compe= lling. =A0I
don't think simplification is at all compelling either.

Purely from a procedural standpoint, I disagree.=A0 SPF is curren= tly Experimental, and moving to Proposed Standard is an ideal time to chop = out things that fewer than two tenths of one percent of the deployed base i= s using.=A0 That comprises part of what we learned from the experiment.=A0 = I don't agree that we are mandated to cater to such a tiny number of si= tes.

The remaining question is whether the working group believes use by 200= out of 150,000 warrants keeping the feature.=A0 To use your own argument, = if in 5-7 years we've seen only this much use of SPF macros, I'm do= ubtful it's going to increase.

But, to be fair, we don't have a hard-and-fast definition of "= unused" when going through this exercise, so it's left to consensu= s. Others will have to weigh in.

We do have precedent, however, as a= guide.=A0 For example, when DKIM went to Draft Standard, we chopped a few = things (most notably "g=3D") because they had seen almost zero ad= option.=A0 According to the RFC4871 interoperability report, after 8.1M sig= ned messages were processed, only 434 of keys were found that had "g= =3D" tags in them.=A0 So the use wasn't zero, and someone apparent= ly found them potentially useful, but the decision was made that there was = not enough adoption to warrant keeping the complexity in the specification.=

However, we didn't remove "l=3D", much as we wanted to, b= ecause its use was around 3.7%.=A0 Same with "x=3D" (3.4%) and &q= uot;z=3D" (5.9%).=A0 Use of SPF macros falls somewhere in between thos= e and "g=3D".

There are other examples of this tactic going back as far as RFC821 (SA= ML and SOML).

You argued that the complexity isn't that big base= d on lines of code.=A0 It wasn't for "g=3D" either.=A0 I remo= ved 162 lines of code that time from OpenDKIM, and we removed a small secti= on of the RFC.

As is often quoted around these parts: "=93Perfection is achieved = not when there is nothing left to=20 add, but when there is nothing left to take away."

-MSK
--f46d0401fc4399b2cb04c4aeee48-- From spf2@kitterman.com Thu Jul 12 22:45:23 2012 Return-Path: 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 AB1B021F876D for ; Thu, 12 Jul 2012 22:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] 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 irFPUd+qGGDO for ; Thu, 12 Jul 2012 22:45:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 993B121F8734 for ; Thu, 12 Jul 2012 22:45:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 32A8A20E40A6; Fri, 13 Jul 2012 01:45:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342158357; bh=ubOUDu/b/Sz7m9Y5cSAK0N4jOCroFfZdPsHniDd9bHQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kmZcIpeSx+hF4MxJU5CLy5PUvYsI3kCBEfoPZF/q7Ogng71dMowl6tssuRzLhVUVC 3j4w1tNkodjsQK+G2GrZW3ohvgqkNyEMvUDz+qHvyzYnLCB1jfHe8ZNCysBImL/flM lHm/xTeB45l3XxXKOXEe122K+m8l0BRyuk4qxOM4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1759F20E4091; Fri, 13 Jul 2012 01:45:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Jul 2012 01:45:56 -0400 Message-ID: <7553255.LjjZa8jCz8@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <20120712022051.60587.qmail@joyce.lan> <2786082.683g7oVmD0@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 05:45:23 -0000 On Thursday, July 12, 2012 09:58:33 PM Murray S. Kucherawy wrote: > On Thu, Jul 12, 2012 at 9:10 PM, Scott Kitterman = wrote: > > The charter says "removal of unused features". This is different t= han > > type SPF > > because type SPF was redundant, this is not. >=20 > I think the issue of redundancy is inapposite. It's an unused featur= e, > pure and simple. The statistics show far less less than 1% use. >=20 > Why do we need to keep something as complicated as macro expansion wh= en > almost nobody is using it? We gain nothing from dropping it and we break a small number of existin= g=20 records. > Perhaps more importantly: Why was it okay for us to decide Sender ID = is de > facto obsolete, while even stronger evidence (by orders of magnitude)= > against macros must be disregarded? If it would help, I could add up= the > number of lines in sid-milter that added Sender ID support for compar= ison. > It, too, was relatively small. We didn't decide that. It says right in the charter that Sender ID has= been=20 judged not to merit further development. If some group has the energy = to go=20 work on SenderID and can get a working group chartered, more power to t= hem. =20 They'll first have to get some standards incompatibilities out of the w= ay (and=20 I don't think they can - this is discussed in the various appeals assoc= iated=20 with it when it was published). In any case, should Sender ID live or = die=20 isn't this working group's call and by whatever mechanism that was deci= ded,=20 it's irrelevant to the work of this group (the charter even says it had= =20 enjoyed wide scale deployment - deployment wasn't the issue). > > I don't think it's in our charter to break existing, published SPF = record > > without a compelling case. I don't think rarely used is at all > > compelling. I > > don't think simplification is at all compelling either. >=20 > Purely from a procedural standpoint, I disagree. SPF is currently > Experimental, and moving to Proposed Standard is an ideal time to cho= p out > things that fewer than two tenths of one percent of the deployed base= is > using. That comprises part of what we learned from the experiment. = I > don't agree that we are mandated to cater to such a tiny number of si= tes. It seems a bit odd that if we learned that as a lesson of the experimen= t, we=20 didn't think important enough to mention in draft-ietf-spfbis-experimen= t. >From a purely procedural standpoint you are right. For largely politic= al=20 reasons it was put in Experimental. The reason the charter is written = as=20 tightly as it is though is to keep people from using that excuse to bre= ak the=20 protocol. It's going from experimental to standards track, but it's no= t a=20 normal case. > The remaining question is whether the working group believes use by 2= 00 out > of 150,000 warrants keeping the feature. To use your own argument, i= f in > 5-7 years we've seen only this much use of SPF macros, I'm doubtful i= t's > going to increase. Because there's no compelling reason to remove it. It's not unused and= for=20 whatever corner cases it is used for, I believe it's important (it's no= t easy=20 to use well, so anyone who's using it does, I think need it). While ca= tering=20 to corner cases isn't something we should focus on, I see no need to go= out of=20 our way to break them either. > But, to be fair, we don't have a hard-and-fast definition of "unused"= when > going through this exercise, so it's left to consensus. Others will h= ave to > weigh in. >=20 > We do have precedent, however, as a guide. For example, when DKIM we= nt to > Draft Standard, we chopped a few things (most notably "g=3D") because= they > had seen almost zero adoption. According to the RFC4871 interoperabi= lity > report, after 8.1M signed messages were processed, only 434 of keys w= ere > found that had "g=3D" tags in them. So the use wasn't zero, and some= one > apparently found them potentially useful, but the decision was made t= hat > there was not enough adoption to warrant keeping the complexity in th= e > specification. >=20 > However, we didn't remove "l=3D", much as we wanted to, because its u= se was > around 3.7%. Same with "x=3D" (3.4%) and "z=3D" (5.9%). Use of SPF = macros > falls somewhere in between those and "g=3D". >=20 > There are other examples of this tactic going back as far as RFC821 (= SAML > and SOML). Did any of these precedents involve working groups where the charter sa= id only=20 unused features could be removed? If not, I don't think they are releva= nt. > You argued that the complexity isn't that big based on lines of code.= It > wasn't for "g=3D" either. I removed 162 lines of code that time from= > OpenDKIM, and we removed a small section of the RFC. >=20 > As is often quoted around these parts: "=E2=80=9CPerfection is achiev= ed not when > there is nothing left to add, but when there is nothing left to take = away." I'm well aware of that, but nothing left to take away can be defined in= =20 different ways. IMO, if (absent some really compelling evidence of whi= ch I've=20 seen no sign) anyone has to go republish SPF records after we're finish= ed we=20 haven't lived up to the spirit of the charter no matter how finely peop= le want=20 to parse the words to claim we have. Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language.=20 I don't think any of those apply here. I think the benefits of removal are almost entirely theoretical and the= benefits=20 of keeping macros in general and "l" specifically are very practical. =20= Scott K From superuser@gmail.com Thu Jul 12 23:32:15 2012 Return-Path: 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 A1E3021F8762 for ; Thu, 12 Jul 2012 23:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 TqmTjrG7d-YS for ; Thu, 12 Jul 2012 23:32:14 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACED21F875E for ; Thu, 12 Jul 2012 23:32:14 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4552203lbb.31 for ; Thu, 12 Jul 2012 23:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uAGT0b1FsO45eqyGDMhg5DbjQpTNCVNNAscLay7VHeM=; b=wkhheOThKMDdiVdvgkLcK8xdgcntk1Ee7/Qd3NPDYqiD/iPjIM2f3msBdjOI7dKx+O 0PpKrqxqNVWZQUrS5nr/Bltq6L7NE3T5ZRRGQVKcFxXQl0M7Bgvt5Uvgjhhha2PdKqv8 cN9BItG69YuecjwKDGDeBwulIF87G8Pd2mkaZPImgvC9nTP3q5oH5AuTA9//XPrdykOW FP04IRFvFMh/vBmK4GBb9PEsdJPqlzFbyA2DkefQJmpJEz7lAr88gHq2OrNMHcd0U9xh 5TM6b/U3+Opj3S8ScPWK2G+O9Wrfb4Uw4BLgHVsEjcFG+AgLKqanDRGbgfUgBsHg1vKs X8Tg== MIME-Version: 1.0 Received: by 10.152.124.180 with SMTP id mj20mr1121432lab.43.1342161168849; Thu, 12 Jul 2012 23:32:48 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 12 Jul 2012 23:32:48 -0700 (PDT) In-Reply-To: <7553255.LjjZa8jCz8@scott-latitude-e6320> References: <20120712022051.60587.qmail@joyce.lan> <2786082.683g7oVmD0@scott-latitude-e6320> <7553255.LjjZa8jCz8@scott-latitude-e6320> Date: Thu, 12 Jul 2012 23:32:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0434bfdeb3590f04c4b03f10 Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 06:32:15 -0000 --f46d0434bfdeb3590f04c4b03f10 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 12, 2012 at 10:45 PM, Scott Kitterman wrote: > We gain nothing from dropping it and we break a small number of existing > records. > I don't agree that we gain nothing from dropping it. We gain simplicity. Perhaps the value of simplicity in a Proposed Standard is being underestimated. > > It seems a bit odd that if we learned that as a lesson of the experiment, > we > didn't think important enough to mention in draft-ietf-spfbis-experiment. > Why would use of SPF macros be germane to a document whose function is to compare adoption rates of SPF versus Sender ID, and not their specific components? As it happens, the data collection we did for that effort includes something that's interesting to this one. I don't think that's odd at all. Because there's no compelling reason to remove it. But there is. > Did any of these precedents involve working groups where the charter said > only > unused features could be removed? If not, I don't think they are relevant. > Yes, all of them, since it's normal IETF procedure when upgrading the status of something on the standards track. You might want to review RFC6410 Section 2.2, which covers advancement from Proposed Standard to Internet Standard (Draft Standard has been eliminated since DKIM was updated), as it includes as one of the criteria: (3) There are no unused features in the specification that greatly increase implementation complexity. Macros are both relatively unused and increase complexity. I'm trudging through Section 8 in my review now. The only "outs" here to me are the facts that (a) we're moving from Experimental to Proposed Standard, which RFC6410 doesn't cover (although I believe it's still useful to apply these criteria as good practice), and (b) the definition of "unused" in this context is fuzzy. I believe we have a stronger Proposed Standard by removing this or anything else that yields no operational or community benefit. Section 8 is not a trivial piece of work for an implementer to follow and get right. No, it's not impossible, but I don't agree that it's at all straightforward either. > > Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language. > > I don't think any of those apply here. > > I don't agree. The statistics speak clearly to me that macros are an unused feature, and "removal of unused features" appears in the very charter text you cited. I've said my piece here. Others will have to weigh in. However, I ask that the co-chairs open this as a new tracker item as a separate issue from #14. -MSK --f46d0434bfdeb3590f04c4b03f10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2012 at 10:45 PM, Scott Kitterman <spf2@kitterman.com= > wrote:
We gain nothing from dropping it and we break a small number of existing records.

I don't agree that we gain nothing fr= om dropping it.=A0 We gain simplicity.=A0 Perhaps the value of simplicity i= n a Proposed Standard is being underestimated.
=A0

It seems a bit odd that if we learned that as a lesson of the experimen= t, we
didn't think important enough to mention in draft-ietf-spfbis-experimen= t.

Why would use of SPF macros be germane to a doc= ument whose function is to compare adoption rates of SPF versus Sender ID, = and not their specific components?

As it happens, the data collection we did for that effort include= s something that's interesting to this one.=A0 I don't think that&#= 39;s odd at all.

Because there's no co= mpelling reason to remove it.

But there is.
=A0
=
Did any of these preceden= ts involve working groups where the charter said only
unused features could be removed? If not, I don't think they are releva= nt.

Yes, all of them, since it's normal IETF p= rocedure when upgrading the status of something on the standards track.=A0 = You might want to review RFC6410 Section 2.2, which covers advancement from= Proposed Standard to Internet Standard (Draft Standard has been eliminated= since DKIM was updated), as it includes as one of the criteria:

   (3) There are no unused features in the speci=
fication that greatly
       increase implementation complexity.

Macros are both relatively unused and increase complexity.=A0= I'm trudging through Section 8 in my review now.

The only "= ;outs" here to me are the facts that (a) we're moving from Experim= ental to Proposed Standard, which RFC6410 doesn't cover (although I bel= ieve it's still useful to apply these criteria as good practice), and (= b) the definition of "unused" in this context is fuzzy.

I believe we have a stronger Proposed Standard by removing this or anyt= hing else that yields no operational or community benefit.=A0 Section 8 is = not a trivial piece of work for an implementer to follow and get right.=A0 = No, it's not impossible, but I don't agree that it's at all str= aightforward either.
=A0

=A0 =A0Changes to the SPF specification will be limited to the correction =A0 =A0of errors, removal of unused features, addition of any enhancements<= br> =A0 =A0that have already gained widespread support, and addition of
=A0 clarifying language.

I don't think any of those apply here.


I d= on't agree.=A0 The statistics speak clearly to me that macros are an un= used feature, and "removal of unused features" appears in the ver= y charter text you cited.

I've said my piece here.=A0 Others will have to weigh in.=A0 Howeve= r, I ask that the co-chairs open this as a new tracker item as a separate i= ssue from #14.
=A0
-MSK
--f46d0434bfdeb3590f04c4b03f10-- From spf2@kitterman.com Thu Jul 12 23:52:33 2012 Return-Path: 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 0E79321F8790 for ; Thu, 12 Jul 2012 23:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] 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 u+dsqSRVLDhk for ; Thu, 12 Jul 2012 23:52:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 55FF421F877D for ; Thu, 12 Jul 2012 23:52:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 609E620E40A6; Fri, 13 Jul 2012 02:53:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342162387; bh=EBL00Ve24t4nQ9+a0bIh3PLHSA/kQtghQIjOKrOHjPQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LZL6gZkp9lZtrTk5LGReqkydEehKGfCyV82cflH7YxtLrb99pMblvL/zd37obAvf0 bny92MKNkVE6Zu6cu6uMH/F9wL+leSr1FTe0K1HZrAPvgm01TYO+W6a/rnX2anAHJC YYhHeTQwVfQ93oXdiMOtX9SEhn7N1IoH3vI+zUrQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 42A6320E4091; Fri, 13 Jul 2012 02:53:07 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Jul 2012 02:53:06 -0400 Message-ID: <25336858.gnRrL7ieMU@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <20120712022051.60587.qmail@joyce.lan> <7553255.LjjZa8jCz8@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 06:52:33 -0000 On Thursday, July 12, 2012 11:32:48 PM Murray S. Kucherawy wrote: > > Did any of these precedents involve working groups where the charter said > > only > > unused features could be removed? If not, I don't think they are relevant. > > Yes, all of them, since it's normal IETF procedure when upgrading the > status of something on the standards track. You might want to review > RFC6410 Section 2.2, which covers advancement from Proposed Standard to > Internet Standard (Draft Standard has been eliminated since DKIM was > updated), as it includes as one of the criteria: > > (3) There are no unused features in the specification that greatly > increase implementation complexity. Requiring unused features to be removed is not at all the same thing as requiring used features be kept (which is what the SPFbis charter says). Additionally, while I agree that macros increase complexity, I wouldn't agree with the idea that they greatly increase complexity. (and with that, I'll leave it be too) Scott K From superuser@gmail.com Fri Jul 13 01:20:07 2012 Return-Path: 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 3F4C021F8734 for ; Fri, 13 Jul 2012 01:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.66 X-Spam-Level: X-Spam-Status: No, score=-3.66 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] 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 oInZ3F8YH7Ct for ; Fri, 13 Jul 2012 01:19:56 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37CDE21F86F6 for ; Fri, 13 Jul 2012 01:19:54 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4694933lbb.31 for ; Fri, 13 Jul 2012 01:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5lf3mWnbTahKEaUfVTbUU5KKhGuAI1Qc8EvQ7zbKCBM=; b=ONpaweNRFXZEYNhLeoXvkEVapf05OP3xU48AB1kHm0qS2bnzjP9kMlMmfj7GcMUrr+ KMHhi6lmb2sD99gap8wD923NhxVxHchVjUKSYLMLC+shjrpHbgKEeco5AFhSFK70AhrV 4wV75gsC+jGnehSPyBNlbzNWryKUVLXHdQv3aClkCH/VgJ5S4ISG9G7XK0ANJKEHx8Pm CIKv0fdCl4w674v2H4f/jGR0PTo0o7t62A9N/ev5pl2n4SvMZ8vIv8kBUoOue5K3maxo Ktpr+BuQ/zitXjxQ7PQK3MI4+2YBa0f4zAsbrCWMPBs1/dFUaR1mqBm7WfIPmv1hX/Y2 GVHQ== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr210446lab.40.1342167628664; Fri, 13 Jul 2012 01:20:28 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Fri, 13 Jul 2012 01:20:28 -0700 (PDT) Date: Fri, 13 Jul 2012 01:20:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: spfbis@ietf.org Content-Type: multipart/mixed; boundary=f46d040838d3bc507a04c4b1c040 Subject: [spfbis] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 08:20:08 -0000 --f46d040838d3bc507a04c4b1c040 Content-Type: multipart/alternative; boundary=f46d040838d3bc507504c4b1c03e --f46d040838d3bc507504c4b1c03e Content-Type: text/plain; charset=ISO-8859-1 Attached is a top-down review of the RFC4408bis document. Apologies that it took so long, but it's a big document. The majority of the things I've tagged in there are editorial in nature. Some refer to things that are open in the tracker as well, including my suggestion for making "check_host()" not look so much like an API definition. Note that it's only a suggestion; I'm happy to discuss other ways to resolve that issue. tl;dr version: It's well on its way to being ready, but we need to spend some more time polishing it as well as resolving the open issues. None of it creates a need for face time in Vancouver. Comments welcome. -MSK --f46d040838d3bc507504c4b1c03e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Attached is a top-down review of the RFC4408bis document.=A0 Apologies that= it took so long, but it's a big document.

The majority of the t= hings I've tagged in there are editorial in nature.=A0 Some refer to th= ings that are open in the tracker as well, including my suggestion for maki= ng "check_host()" not look so much like an API definition.=A0 Not= e that it's only a suggestion; I'm happy to discuss other ways to r= esolve that issue.

tl;dr version: It's well on its way to being ready, but we need to = spend some more time polishing it as well as resolving the open issues.=A0 = None of it creates a need for face time in Vancouver.

Comments welco= me.

-MSK
--f46d040838d3bc507504c4b1c03e-- --f46d040838d3bc507a04c4b1c040 Content-Type: text/plain; name="draft-ietf-spfbis-4408bis-03.txt" Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-03.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h4kzwgb60 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUy4gS2l0dGVybWFuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBZ2FyaQpPYnNvbGV0ZXM6IDQ0MDggKGlmIGFw cHJvdmVkKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdWx5IDUsIDIwMTIKSW50ZW5k ZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sKRXhwaXJlczogSmFudWFyeSA2LCAyMDEzCgoKIFNl bmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpIGZvciBBdXRob3JpemluZyBVc2Ugb2YgRG9tYWlu cyBpbiBFbWFpbCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZlcnNpb24gMQogICAg ICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtc3BmYmlzLTQ0MDhiaXMtMDMudHh0CgpBYnN0cmFj dAoKICAgRS1tYWlsIG9uIHRoZSBJbnRlcm5ldCBjYW4gYmUgZm9yZ2VkIGluIGEgbnVtYmVyIG9m IHdheXMuICBJbgoKW01TSzogcy9FLW1haWwvRW1haWwvXQoKICAgcGFydGljdWxhciwgZXhpc3Rp bmcgcHJvdG9jb2xzIHBsYWNlIG5vIHJlc3RyaWN0aW9uIG9uIHdoYXQgYSBzZW5kaW5nCiAgIGhv c3QgY2FuIHVzZSBhcyB0aGUgcmV2ZXJzZS1wYXRoIG9mIGEgbWVzc2FnZSBvciB0aGUgZG9tYWlu IGdpdmVuIG9uCgpbTVNLOiBzL3JldmVyc2UtcGF0aC9hdXRob3IncyBhZGRyZXNzL10KCiAgIHRo ZSBTTVRQIEhFTE8vRUhMTyBjb21tYW5kcy4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHZlcnNp b24gMSBvZgogICB0aGUgU2VuZGVyIFBvbGljeSBGcmFtZXdvcmsgKFNQRikgcHJvdG9jb2wsIHdo ZXJlYnkgYSBkb21haW4gY2FuCiAgIGV4cGxpY2l0bHkgYXV0aG9yaXplIHRoZSBob3N0cyB0aGF0 IGFyZSBhbGxvd2VkIHRvIHVzZSBpdHMgZG9tYWluCiAgIG5hbWUsIGFuZCBhIHJlY2VpdmluZyBo b3N0IGNhbiBjaGVjayBzdWNoIGF1dGhvcml6YXRpb24uICBUaGlzCiAgIGRvY3VtZW50IG9ic29s ZXRlcyBSRkM0NDA4LgoKW01TSzogU3VnZ2VzdCB0aGF0IHRoZSBsYXN0IHNlbnRlbmNlIGJlIGlu IGl0cyBvd24gcGFyYWdyYXBoLiAgVGhlcmUncyBiZWVuIHNvbWUgZW5lcmdldGljIGRlYmF0ZSwg YXQgbGVhc3QgaW4gYXBwc2F3ZywgYWJvdXQgd2hldGhlciB0aGlzIG5lZWRzIHRvIGJlIGhlcmUg YXQgYWxsIGdpdmVuIHRoYXQgaXQgYXBwZWFycyBhdCB0aGUgdG9wIGxlZnQgb2YgdGhlIHRpdGxl IHBhZ2UuXQoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBz dWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJD UCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50 cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3Rl IHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAg RHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8u CgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhp bXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jz b2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJ bnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKYW51YXJ5IDYsIDIwMTMuCgpDb3B5cmlnaHQg Tm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTIgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMg aWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2 ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBU cnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAg KGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBk YXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRo ZXNlIGRvY3VtZW50cwoKCgpLaXR0ZXJtYW4gICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5 IDYsIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg U2VuZGVyIFBvbGljeSBGcmFtZXdvcmsgKFNQRikgICAgICAgICAgICBKdWx5IDIwMTIKCgogICBj YXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3 aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0 ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNl bnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdh bCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNj cmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgogICBUaGlzIGRvY3VtZW50IG1h eSBjb250YWluIG1hdGVyaWFsIGZyb20gSUVURiBEb2N1bWVudHMgb3IgSUVURgogICBDb250cmli dXRpb25zIHB1Ymxpc2hlZCBvciBtYWRlIHB1YmxpY2x5IGF2YWlsYWJsZSBiZWZvcmUgTm92ZW1i ZXIKICAgMTAsIDIwMDguICBUaGUgcGVyc29uKHMpIGNvbnRyb2xsaW5nIHRoZSBjb3B5cmlnaHQg aW4gc29tZSBvZiB0aGlzCiAgIG1hdGVyaWFsIG1heSBub3QgaGF2ZSBncmFudGVkIHRoZSBJRVRG IFRydXN0IHRoZSByaWdodCB0byBhbGxvdwogICBtb2RpZmljYXRpb25zIG9mIHN1Y2ggbWF0ZXJp YWwgb3V0c2lkZSB0aGUgSUVURiBTdGFuZGFyZHMgUHJvY2Vzcy4KICAgV2l0aG91dCBvYnRhaW5p bmcgYW4gYWRlcXVhdGUgbGljZW5zZSBmcm9tIHRoZSBwZXJzb24ocykgY29udHJvbGxpbmcKICAg dGhlIGNvcHlyaWdodCBpbiBzdWNoIG1hdGVyaWFscywgdGhpcyBkb2N1bWVudCBtYXkgbm90IGJl IG1vZGlmaWVkCiAgIG91dHNpZGUgdGhlIElFVEYgU3RhbmRhcmRzIFByb2Nlc3MsIGFuZCBkZXJp dmF0aXZlIHdvcmtzIG9mIGl0IG1heQogICBub3QgYmUgY3JlYXRlZCBvdXRzaWRlIHRoZSBJRVRG IFN0YW5kYXJkcyBQcm9jZXNzLCBleGNlcHQgdG8gZm9ybWF0CiAgIGl0IGZvciBwdWJsaWNhdGlv biBhcyBhbiBSRkMgb3IgdG8gdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2VzIG90aGVyCiAgIHRo YW4gRW5nbGlzaC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCktpdHRlcm1hbiAg ICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgICBbUGFn ZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BG KSAgICAgICAgICAgIEp1bHkgMjAxMgoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9k dWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDUKICAgICAxLjEuICBQcm90b2NvbCBTdGF0dXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA1CiAgICAgMS4yLiAgRXhwZXJpbWVudGFsIEhpc3RvcnkgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAgIDEuMy4gIFRlcm1pbm9sb2d5 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYKICAgICAg IDEuMy4xLiAgS2V5d29yZHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA2CiAgICAgICAxLjMuMi4gIEltcG9ydGVkIERlZmluaXRpb25zIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAgICAgMS4zLjMuICBNYWlsIEZyb20gRGVmaW5p dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYKICAgICAgIDEuMy40LiAg RGVwcmVjYXRlZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3 CiAgIDIuICBPcGVyYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgOAogICAgIDIuMS4gIFRoZSBIRUxPIElkZW50aXR5ICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgICAyLjIuICBUaGUgTUFJTCBGUk9N IElkZW50aXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4CiAgICAgMi4z LiAgUHVibGlzaGluZyBBdXRob3JpemF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgOAogICAgIDIuNC4gIENoZWNraW5nIEF1dGhvcml6YXRpb24gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICAyLjUuICBJbnRlcnByZXRpbmcgdGhlIFJlc3Vs dCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgICAgICAyLjUuMS4gIE5v bmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAog ICAgICAgMi41LjIuICBOZXV0cmFsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTEKICAgICAgIDIuNS4zLiAgUGFzcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgICAyLjUuNC4gIEZhaWwgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAgICAgMi41 LjUuICBTb2Z0ZmFpbCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTEKICAgICAgIDIuNS42LiAgVGVtcEVycm9yICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDEyCiAgICAgICAyLjUuNy4gIFBlcm1FcnJvciAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMgogICAzLiAgU1BGIFJlY29yZHMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAg ICAzLjEuICBQdWJsaXNoaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDEzCiAgICAgICAzLjEuMS4gIEROUyBSZXNvdXJjZSBSZWNvcmRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgICAgMy4xLjIuICBNdWx0aXBsZSBETlMg UmVjb3JkcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQKICAgICAgIDMuMS4z LiAgTXVsdGlwbGUgU3RyaW5ncyBpbiBhIFNpbmdsZSBETlMgcmVjb3JkICAuIC4gLiAuIC4gLiAu IDE0CiAgICAgICAzLjEuNC4gIFJlY29yZCBTaXplICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxNAogICAgICAgMy4xLjUuICBXaWxkY2FyZCBSZWNvcmRzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQKICAgNC4gIFRoZSBjaGVja19ob3N0 KCkgRnVuY3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgICAg NC4xLiAgQXJndW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxNgogICAgIDQuMi4gIFJlc3VsdHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgICA0LjMuICBJbml0aWFsIFByb2Nlc3Npbmcg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgICAgNC40LiAgUmVj b3JkIExvb2t1cCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx NwogICAgIDQuNS4gIFNlbGVjdGluZyBSZWNvcmRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTcKICAgICA0LjYuICBSZWNvcmQgRXZhbHVhdGlvbiAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3CiAgICAgICA0LjYuMS4gIFRlcm0gRXZh bHVhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOAogICAgICAg NC42LjIuICBNZWNoYW5pc21zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTgKICAgICAgIDQuNi4zLiAgTW9kaWZpZXJzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5CiAgICAgICA0LjYuNC4gIEV2YWx1YXRpb24gTGltaXRz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQogICAgIDQuNy4gIERlZmF1 bHQgUmVzdWx0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkK ICAgICA0LjguICBEb21haW4gU3BlY2lmaWNhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDIwCiAgIDUuICBNZWNoYW5pc20gRGVmaW5pdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMQogICAgIDUuMS4gICJhbGwiICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjEKICAgICA1LjIu ICAiaW5jbHVkZSIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDIyCiAgICAgNS4zLiAgImEiICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyMwogICAgIDUuNC4gICJteCIgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMKCgoKS2l0dGVybWFuICAgICAg ICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDNd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpICAg ICAgICAgICAgSnVseSAyMDEyCgoKICAgICA1LjUuICAicHRyIiAoZGVwcmVjYXRlZCkgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0CiAgICAgNS42LiAgImlwNCIgYW5k ICJpcDYiICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNQogICAg IDUuNy4gICJleGlzdHMiIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMjYKICAgNi4gIE1vZGlmaWVyIERlZmluaXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3CiAgICAgNi4xLiAgcmVkaXJlY3Q6IFJlZGlyZWN0 ZWQgUXVlcnkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNwogICAgIDYuMi4gIGV4 cDogRXhwbGFuYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MjgKICAgNy4gIFRoZSBSZWNlaXZlZC1TUEYgSGVhZGVyIEZpZWxkICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDMwCiAgIDguICBNYWNyb3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMgogICAgIDguMS4gIE1hY3JvIERlZmlu aXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzIKICAgICA4 LjIuICBFeHBhbnNpb24gRXhhbXBsZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDM1CiAgIDkuICBJbXBsaWNhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNgogICAgIDkuMS4gIFNlbmRpbmcgRG9tYWlucyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzYKICAgICAgIDkuMS4xLiAg RE5TIFJlc291cmNlIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM2 CiAgICAgICA5LjEuMi4gIEFkbWluaXN0cmF0b3IncyBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAzNwogICAgIDkuMi4gIE1lZGlhdG9ycyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzcKICAgICAgIDkuMi4xLiAgTWFpbGluZyBM aXN0cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM3CiAgICAgICA5 LjIuMi4gIEZvcndhcmRpbmcgU2VydmljZXMgYW5kIEFsaWFzZXMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAzNwogICAgIDkuMy4gIE1haWwgU2VydmljZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMzkKICAgICA5LjQuICBNVEEgUmVsYXlzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQwCiAgIDEwLiBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MQog ICAgIDEwLjEuIFByb2Nlc3NpbmcgTGltaXRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNDEKICAgICAxMC4yLiBTUEYtQXV0aG9yaXplZCBFbWFpbCBNYXkgQ29udGFp biBPdGhlciBGYWxzZSBJZGVudGl0aWVzICAuIDQxCiAgICAgMTAuMy4gU3Bvb2ZlZCBETlMgYW5k IElQIERhdGEgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MgogICAgIDEwLjQu IENyb3NzLVVzZXIgRm9yZ2VyeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNDIKICAgICAxMC41LiBVbnRydXN0ZWQgSW5mb3JtYXRpb24gU291cmNlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDQyCiAgICAgMTAuNi4gUHJpdmFjeSBFeHBvc3VyZSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MwogICAxMS4gQ29udHJpYnV0b3Jz IGFuZCBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDQKICAg MTIuIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDQ1CiAgICAgMTIuMS4gVGhlIFNQRiBETlMgUmVjb3JkIFR5cGUgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NQogICAgIDEyLjIuIFRoZSBSZWNlaXZlZC1TUEYg TWFpbCBIZWFkZXIgRmllbGQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDUKICAgMTMuIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDQ2CiAgICAgMTMuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA0NgogICAgIDEzLjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDcKICAgQXBwZW5kaXggQS4gIENvbGxl Y3RlZCBBQk5GICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ5CiAgIEFw cGVuZGl4IEIuICBFeHRlbmRlZCBFeGFtcGxlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA1MgogICAgIEIuMS4gIFNpbXBsZSBFeGFtcGxlcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTIKICAgICBCLjIuICBNdWx0aXBsZSBEb21haW4gRXhh bXBsZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUzCiAgICAgQi4zLiAgRE5T QkwgU3R5bGUgRXhhbXBsZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1 NAogICAgIEIuNC4gIE11bHRpcGxlIFJlcXVpcmVtZW50cyBFeGFtcGxlICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gNTQKICAgQXBwZW5kaXggQy4gIENoYW5nZSBIaXN0b3J5ICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU1CiAgIEF1dGhvcidzIEFkZHJlc3MgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NwoKCgoKCgoK CgoKS2l0dGVybWFuICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAg ICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kg RnJhbWV3b3JrIChTUEYpICAgICAgICAgICAgSnVseSAyMDEyCgoKMS4gIEludHJvZHVjdGlvbgoK ICAgVGhlIGN1cnJlbnQgZW1haWwgaW5mcmFzdHJ1Y3R1cmUgaGFzIHRoZSBwcm9wZXJ0eSB0aGF0 IGFueSBob3N0CiAgIGluamVjdGluZyBtYWlsIGludG8gdGhlIG1haWwgc3lzdGVtIGNhbiBpZGVu dGlmeSBpdHNlbGYgYXMgYW55IGRvbWFpbgogICBuYW1lIGl0IHdhbnRzLiAgSG9zdHMgY2FuIGRv IHRoaXMgYXQgYSB2YXJpZXR5IG9mIGxldmVsczogaW4KICAgcGFydGljdWxhciwgdGhlIHNlc3Np b24sIHRoZSBlbnZlbG9wZSwgYW5kIHRoZSBtYWlsIGhlYWRlcnMuCgpbTVNLOiBEb2VzICJ0aGUg c2Vzc2lvbiIgcmVmZXIgdG8gSEVMTy9FSExPLCByRE5TLCBvciBzb21ldGhpbmcgZWxzZT9dCgog ICBBbHRob3VnaCB0aGlzIGZlYXR1cmUgaXMgZGVzaXJhYmxlIGluIHNvbWUgY2lyY3Vtc3RhbmNl cywgaXQgaXMgYQogICBtYWpvciBvYnN0YWNsZSB0byByZWR1Y2luZyBVbnNvbGljaXRlZCBCdWxr IGVtYWlsIChVQkUsIGFrYSBzcGFtKS4KICAgRnVydGhlcm1vcmUsIG1hbnkgZG9tYWluIG5hbWUg aG9sZGVycyBhcmUgdW5kZXJzdGFuZGFibHkgY29uY2VybmVkCiAgIGFib3V0IHRoZSBlYXNlIHdp dGggd2hpY2ggb3RoZXIgZW50aXRpZXMgY2FuIG1ha2UgdXNlIG9mIHRoZWlyIGRvbWFpbgogICBu YW1lcywgb2Z0ZW4gd2l0aCBtYWxpY2lvdXMgaW50ZW50LgoKW01TSzogV291bGQgQURNRCBmcm9t IFJGQzU1OTggYmUgaGVscGZ1bCBpbiBwbGFjZSBvZiAiZG9tYWluIG5hbWUgaG9sZGVycyIgYWJv dmUgb3IgImRvbWFpbiBvd25lcnMiIGJlbG93P10KCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBh IHByb3RvY29sIGJ5IHdoaWNoIGRvbWFpbiBvd25lcnMgY2FuIGF1dGhvcml6ZQogICBob3N0cyB0 byB1c2UgdGhlaXIgZG9tYWluIG5hbWUgaW4gdGhlICJNQUlMIEZST00iIG9yICJIRUxPIiBpZGVu dGl0eS4KCltNU0s6IHMvZG9tYWluIG5hbWUvZG9tYWluIG5hbWVzLywgb3RoZXJ3aXNlICJkb21h aW4gb3duZXJzIiBhbGwgb3duIGEgc2luZ2xlICJkb21haW4gbmFtZSJdCgogICBDb21wbGlhbnQg ZG9tYWluIGhvbGRlcnMgcHVibGlzaCBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BGKQogICBy ZWNvcmRzIHNwZWNpZnlpbmcgd2hpY2ggaG9zdHMgYXJlIHBlcm1pdHRlZCB0byB1c2UgdGhlaXIg bmFtZXMsIGFuZAoKW01TSzogcHVibGlzaCDigKYgcmVjb3JkcyBpbiB0aGUgRE5TXQoKICAgY29t cGxpYW50IG1haWwgcmVjZWl2ZXJzIHVzZSB0aGUgcHVibGlzaGVkIFNQRiByZWNvcmRzIHRvIHRl c3QgdGhlCiAgIGF1dGhvcml6YXRpb24gb2Ygc2VuZGluZyBNYWlsIFRyYW5zZmVyIEFnZW50cyAo TVRBcykgdXNpbmcgYSBnaXZlbgogICAiSEVMTyIgb3IgIk1BSUwgRlJPTSIgaWRlbnRpdHkgZHVy aW5nIGEgbWFpbCB0cmFuc2FjdGlvbi4KCiAgIEFuIGFkZGl0aW9uYWwgYmVuZWZpdCB0byBtYWls IHJlY2VpdmVycyBpcyB0aGF0IGFmdGVyIHRoZSB1c2Ugb2YgYW4KICAgaWRlbnRpdHkgaXMgdmVy aWZpZWQsIGxvY2FsIHBvbGljeSBkZWNpc2lvbnMgYWJvdXQgdGhlIG1haWwgY2FuIGJlCiAgIG1h ZGUgYmFzZWQgb24gdGhlIHNlbmRlcidzIGRvbWFpbiwgcmF0aGVyIHRoYW4gdGhlIGhvc3QncyBJ UCBhZGRyZXNzLgogICBUaGlzIGlzIGFkdmFudGFnZW91cyBiZWNhdXNlIHJlcHV0YXRpb24gb2Yg ZG9tYWluIG5hbWVzIGlzIGxpa2VseSB0bwogICBiZSBtb3JlIGFjY3VyYXRlIHRoYW4gcmVwdXRh dGlvbiBvZiBob3N0IElQIGFkZHJlc3Nlcy4gIEZ1cnRoZXJtb3JlLAogICBpZiBhIGNsYWltZWQg aWRlbnRpdHkgZmFpbHMgdmVyaWZpY2F0aW9uLCBsb2NhbCBwb2xpY3kgY2FuIHRha2UKICAgc3Ry b25nZXIgYWN0aW9uIGFnYWluc3Qgc3VjaCBlbWFpbCwgc3VjaCBhcyByZWplY3RpbmcgaXQuCgox LjEuICBQcm90b2NvbCBTdGF0dXMKCiAgIFNQRiBoYXMgYmVlbiBpbiBkZXZlbG9wbWVudCBzaW5j ZSB0aGUgc3VtbWVyIG9mIDIwMDMgYW5kIGhhcyBzZWVuCiAgIGRlcGxveW1lbnQgYmV5b25kIHRo ZSBkZXZlbG9wZXJzIGJlZ2lubmluZyBpbiBEZWNlbWJlciAyMDAzLiAgVGhlCiAgIGRlc2lnbiBv ZiBTUEYgc2xvd2x5IGV2b2x2ZWQgdW50aWwgdGhlIHNwcmluZyBvZiAyMDA0IGFuZCBoYXMgc2lu Y2UKICAgc3RhYmlsaXplZC4gIFRoZXJlIGhhdmUgYmVlbiBxdWl0ZSBhIG51bWJlciBvZiBmb3Jt cyBvZiBTUEYsIHNvbWUKICAgd3JpdHRlbiB1cCBhcyBkb2N1bWVudHMsIHNvbWUgc3VibWl0dGVk IGFzIEludGVybmV0IERyYWZ0cywgYW5kIG1hbnkKICAgZGlzY3Vzc2VkIGFuZCBkZWJhdGVkIGlu IGRldmVsb3BtZW50IGZvcnVtcy4gIFRoZSBwcm90b2NvbCB3YXMKICAgb3JpZ2luYWxseSBkb2N1 bWVudGVkIGluIFtSRkM0NDA4XSwgd2hpY2ggdGhpcyBtZW1vIHJlcGxhY2VzLgoKW01TSzogQURz IHNlZW0gdG8gcHJlZmVyICJkb2N1bWVudCIgaW5zdGVhZCBvZiAibWVtbyIgdGhlc2UgZGF5cy5d CgogICBUaGUgZ29hbCBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIGNsZWFybHkgZG9jdW1lbnQgdGhl IHByb3RvY29sIGRlZmluZWQKCltNU0s6IFVzZSBvZiAiZG9jdW1lbnQiIHR3aWNlIHNvIGNsb3Nl IHRvZ2V0aGVyIGlzIGF3a3dhcmQuICBTdWdnZXN0IGNoYW5naW5nIHRoZSBmaXJzdCBvbmUgdG8g IndvcmsiIG9yIHNpbWlsYXIuXQoKICAgYnkgZWFybGllciBkcmFmdCBzcGVjaWZpY2F0aW9ucyBv ZiBTUEYgYXMgdXNlZCBpbiBleGlzdGluZwogICBpbXBsZW1lbnRhdGlvbnMuICBUaGlzIGNvbmNl cHRpb24gb2YgU1BGIGlzIHNvbWV0aW1lcyBjYWxsZWQgIlNQRgogICBDbGFzc2ljIi4gIEl0IGlz IHVuZGVyc3Rvb2QgdGhhdCBwYXJ0aWN1bGFyIGltcGxlbWVudGF0aW9ucyBhbmQKICAgZGVwbG95 bWVudHMgd2lsbCBkaWZmZXIgZnJvbSwgYW5kIGJ1aWxkIHVwb24sIHRoaXMgd29yay4gIEl0IGlz IGhvcGVkCiAgIHRoYXQgd2UgaGF2ZSBub25ldGhlbGVzcyBjYXB0dXJlZCB0aGUgY29tbW9uIHVu ZGVyc3RhbmRpbmcgb2YgU1BGCiAgIHZlcnNpb24gMS4KCgoKCgoKS2l0dGVybWFuICAgICAgICAg ICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpICAgICAg ICAgICAgSnVseSAyMDEyCgoKMS4yLiAgRXhwZXJpbWVudGFsIEhpc3RvcnkKCiAgIFRoaXMgZG9j dW1lbnQgdXBkYXRlcyBhbmQgcmVwbGFjZXMgUkZDIDQ0MDggdGhhdCB3YXMgcGFydCBvZiBhIGdy b3VwCiAgIG9mIHNpbXVsdGFuZW91c2x5IHB1Ymxpc2hlZCBFeHBlcmltZW50YWwgUkZDcyAoUkZD IDQ0MDUsIFJGQyA0NDA2LAogICBSRkMgNDQwNywgYW5kIFJGQyA0NDA4KSBpbiAyMDA2LiAgQXQg dGhhdCB0aW1lIHRoZSBJRVNHIHJlcXVlc3RlZCB0aGUKICAgY29tbXVuaXR5IG9ic2VydmUgdGhl IHN1Y2Nlc3Mgb3IgZmFpbHVyZSBvZiB0aGUgdHdvIGFwcHJvYWNoZXMKICAgZG9jdW1lbnRlZCBp biB0aGVzZSBSRkNzIGR1cmluZyB0aGUgdHdvIHllYXJzIGZvbGxvd2luZyBwdWJsaWNhdGlvbiwK ICAgaW4gb3JkZXIgdGhhdCBhIGNvbW11bml0eSBjb25zZW5zdXMgY2FuIGJlIHJlYWNoZWQgaW4g dGhlIGZ1dHVyZS4KCiAgIFNQRiBpcyB3aWRlbHkgZGVwbG95ZWQgYnkgbGFyZ2UgYW5kIHNtYWxs IGVtYWlsIHByb3ZpZGVycyBhbGlrZS4KICAgVGhlcmUgYXJlIG11bHRpcGxlLCBpbnRlcm9wZXJh YmxlIGltcGxlbWVudGF0aW9ucy4KCiAgIEZvciBTUEYgKGFzIGRvY3VtZW50ZWQgaW4gUkZDIDQ0 MDgpIGEgY2FyZWZ1bCBlZmZvcnQgd2FzIG1hZGUgdG8KICAgY29sbGVjdCBhbmQgZG9jdW1lbnQg bGVzc29ucyBsZWFybmVkIGFuZCBlcnJhdGEgZHVyaW5nIHRoZSB0d28geWVhcgogICBwZXJpb2Qu ICBUaGUgZXJyYXRhIGxpc3QgaGFzIGJlZW4gc3RhYmxlIChubyBuZXcgc3VibWlzc2lvbnMpIGFu ZAogICBvbmx5IG1pbm9yIHByb3RvY29sIGxlc3NvbnMgbGVhcm5lZCB3ZXJlIGlkZW50aWZpZWQu ICBSZXNvbHV0aW9uIG9mCiAgIHRoZSBJRVNHJ3MgZXhwZXJpbWVudCBpcyBkb2N1bWVudGVkIGlu CiAgIFtkcmFmdC1pZXRmLXNwZmJpcy1leHBlcmltZW50XS4KCjEuMy4gIFRlcm1pbm9sb2d5Cgox LjMuMS4gIEtleXdvcmRzCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJF UVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIs ICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kCiAgICJPUFRJT05B TCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGlu CiAgIFtSRkMyMTE5XS4KCjEuMy4yLiAgSW1wb3J0ZWQgRGVmaW5pdGlvbnMKCiAgIFRoZSBBQk5G IHRva2VucyAiQUxQSEEiLCAiRElHSVQiLCBhbmQgIlNQIiBhcmUgZGVmaW5lZCBpbiBbUkZDNTIz NF0uCgogICBUaGUgdG9rZW4gImxvY2FsLXBhcnQiIGlzIGRlZmluZWQgaW4gW1JGQzUzMjFdLgoK ICAgImRvdC1hdG9tIiwgInF1b3RlZC1zdHJpbmciLCAiY29tbWVudCIsICJDRldTIiwgIkZXUyIs IGFuZCAiQ1JMRiIgYXJlCiAgIGRlZmluZWQgaW4gW1JGQzUzMjJdCgpbTVNLOiBNaXNzaW5nIHBl cmlvZC5dCgoxLjMuMy4gIE1haWwgRnJvbSBEZWZpbml0aW9uCgogICBUaGlzIGRvY3VtZW50IGlz IGNvbmNlcm5lZCB3aXRoIHRoZSBwb3J0aW9uIG9mIGEgbWFpbCBtZXNzYWdlCiAgIGNvbW1vbmx5 IGNhbGxlZCAiZW52ZWxvcGUgc2VuZGVyIiwgInJldHVybiBwYXRoIiwgInJldmVyc2UgcGF0aCIs CiAgICJib3VuY2UgYWRkcmVzcyIsICI1MzIxIEZST00iLCBvciAiTUFJTCBGUk9NIi4gIFNpbmNl IHRoZXNlIHRlcm1zIGFyZQogICBlaXRoZXIgbm90IHdlbGwgZGVmaW5lZCBvciBvZnRlbiB1c2Vk IGNhc3VhbGx5LCB0aGlzIGRvY3VtZW50IGRlZmluZXMKICAgdGhlICJNQUlMIEZST00iIGlkZW50 aXR5IGluIFNlY3Rpb24gMi4yLiAgTm90ZSB0aGF0IG90aGVyIHRlcm1zIHRoYXQKICAgbWlnaHQg c3VwZXJmaWNpYWxseSBsb29rIGxpa2UgdGhlIGNvbW1vbiB0ZXJtcywgc3VjaCBhcyAicmV2ZXJz ZS0KICAgcGF0aCIsIGFyZSB1c2VkIG9ubHkgd2l0aCB0aGUgZGVmaW5lZCBtZWFuaW5ncyBmcm9t IG5vcm1hdGl2ZQogICBkb2N1bWVudHMuCgpbTVNLOiBDb3VsZCB3ZSBwZXJoYXBzIHVzZSBSRkM1 MzIxLk1haWxGcm9tLCBhcyBkZWZpbmVkIGluIFJGQzU1OTg/XQoKCgoKS2l0dGVybWFuICAgICAg ICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDZd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpICAg ICAgICAgICAgSnVseSAyMDEyCgoKMS4zLjQuICBEZXByZWNhdGVkCgogICBUaGVyZSBhcmUgc2V2 ZXJhbCBbUkZDNDQwOF0gZmVhdHVyZXMgdGhhdCBhcmUgbWFya2VkICJkZXByZWNhdGVkIi4KICAg SW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1bWVudCwgZGVwcmVjYXRlZCBtZWFucyB0aGF0IHNl bmRlcnMgU0hPVUxECiAgIE5PVCBwdWJsaXNoIFNQRiByZWNvcmRzIHRoYXQgbWFrZSB1c2Ugb2Yg dGhlIGZlYXR1cmUgaW4gcXVlc3Rpb24uCiAgIEl0cyB1c2UgaXMgTk9UIFJFQ09NTUVOREVEIGFu ZCBpdCBtaWdodCBiZSByZW1vdmVkIGVudGlyZWx5IGluIGZ1dHVyZQogICB1cGRhdGVzIHRvIHRo ZSBwcm90b2NvbC4gIFN1Y2ggZmVhdHVyZXMgZG8sIGhvd2V2ZXIsIHJlbWFpbiBwYXJ0IG9mCiAg IHRoZSBTUEYgcHJvdG9jb2wgYW5kIHJlY2VpdmluZyBzeXN0ZW1zIE1VU1Qgc3VwcG9ydCB0aGVt IHVubGVzcyB0aGlzCiAgIHNwZWNpZmljYXRpb24gc2F5cyBvdGhlcndpc2UuCgpbTVNLOiBUaGUg Tk9UIFJFQ09NTUVOREVEIGlzIHJlZHVuZGFudCB0byB0aGUgU0hPVUxELCBJIGJlbGlldmUuICBB bHNvLCB0aGUgcHJvc2UgaGFzIHN1ZGRlbmx5IHN3aXRjaGVkIGZyb20gcGx1cmFsIHRvIHNpbmd1 bGFyIGFuZCBiYWNrLiAgU3VnZ2VzdCBpbiB0aGUgbWlkZGxlOiAiVXNlIG9mIHRoZXNlIGZlYXR1 cmVzIGlzIG5vdCBhZHZpc2VkLCBhcyB0aGV5IG1pZ2h0IGJlIHJlbW92ZWQgZW50aXJlbHkgaW4g ZnV0dXJlIHVwZGF0ZXMgdG8gdGhlIHByb3RvY29sLiJdCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgpLaXR0ZXJtYW4gICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5 IDYsIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg U2VuZGVyIFBvbGljeSBGcmFtZXdvcmsgKFNQRikgICAgICAgICAgICBKdWx5IDIwMTIKCgoyLiAg T3BlcmF0aW9uCgoyLjEuICBUaGUgSEVMTyBJZGVudGl0eQoKICAgVGhlICJIRUxPIiBpZGVudGl0 eSBkZXJpdmVzIGZyb20gZWl0aGVyIHRoZSBTTVRQIEhFTE8gb3IgRUhMTyBjb21tYW5kCiAgIChz ZWUgW1JGQzUzMjFdKS4gIFRoZXNlIGNvbW1hbmRzIHN1cHBseSB0aGUgU01UUCBjbGllbnQgKHNl bmRpbmcKICAgaG9zdCkgZm9yIHRoZSBTTVRQIHNlc3Npb24uCgpbTVNLOiBTYW1lIHF1ZXN0aW9u IGFzIGJlZm9yZSBhYm91dCB1c2luZyBSRkM1NTk4IG5vdGF0aW9uLl0KCltNU0s6IFRoZXkgZG9u J3Qgc3VwcGx5IHRoZSBjbGllbnQsIHRoZXkgc3VwcGx5IGFuIGlkZW50aXR5IG9mIHRoZSBjbGll bnQuXQoKICAgTm90ZSB0aGF0IHJlcXVpcmVtZW50cyBmb3IgdGhlIGRvbWFpbgogICBwcmVzZW50 ZWQgaW4gdGhlIEVITE8gb3IgSEVMTyBjb21tYW5kIGFyZSBub3QgYWx3YXlzIGNsZWFyIHRvIHRo ZQogICBzZW5kaW5nIHBhcnR5LCBhbmQgU1BGIGNsaWVudHMgbXVzdCBiZSBwcmVwYXJlZCBmb3Ig dGhlICJIRUxPIgogICBpZGVudGl0eSB0byBiZSBtYWxmb3JtZWQgb3IgYW4gSVAgYWRkcmVzcyBs aXRlcmFsLiAgQXQgdGhlIHRpbWUgb2YKICAgdGhpcyB3cml0aW5nLCBtYW55IGxlZ2l0aW1hdGUg ZW1haWxzIGFyZSBkZWxpdmVyZWQgd2l0aCBpbnZhbGlkIEhFTE8KICAgZG9tYWlucy4KCltNU0s6 IFVzZSBvZiBhIGxvd2VyY2FzZSAibXVzdCIuICBOZWVkIHRvIG1ha2UgaXQgYWxsLWNhcHMgb3Ig cGljayBhIGRpZmZlcmVudCB3b3JkLiAgQWxzbyBwdXQgYW4gImVpdGhlciIgYWZ0ZXIgInRvIGJl Ii4gIEFsc28gc3VnZ2VzdCBzL0hFTE8gZG9tYWlucy9IRUxPIHBhcmFtZXRlcnMuXQoKICAgSXQg aXMgUkVDT01NRU5ERUQgdGhhdCBTUEYgY2xpZW50cyBub3Qgb25seSBjaGVjayB0aGUgIk1BSUwg RlJPTSIKICAgaWRlbnRpdHksIGJ1dCBhbHNvIHNlcGFyYXRlbHkgY2hlY2sgdGhlICJIRUxPIiBp ZGVudGl0eSBieSBhcHBseWluZwogICB0aGUgY2hlY2tfaG9zdCgpIGZ1bmN0aW9uIChTZWN0aW9u IDQpIHRvIHRoZSAiSEVMTyIgaWRlbnRpdHkgYXMgdGhlCiAgIDxzZW5kZXI+LgoKW01TSzogV2Ug bmVlZCB0byBleHBsYWluIHdoeSB0aGlzIGlzIFJFQ09NTUVOREVELiAgV2UgbWlnaHQgbGF0ZXIs IGJ1dCBJIGhhdmVuJ3QgZ290dGVuIHRoYXQgZmFyIHlldCBhbmQgSSBtaWdodCBmb3JnZXQgdG8g Y29tZSBiYWNrIGFuZCBkZWxldGUgdGhpcy4gIDotKV0KCjIuMi4gIFRoZSBNQUlMIEZST00gSWRl bnRpdHkKCiAgIFRoZSAiTUFJTCBGUk9NIiBpZGVudGl0eSBkZXJpdmVzIGZyb20gdGhlIFNNVFAg TUFJTCBjb21tYW5kIChzZWUKICAgW1JGQzUzMjFdKS4gIFRoaXMgY29tbWFuZCBzdXBwbGllcyB0 aGUgInJldmVyc2UtcGF0aCIgZm9yIGEgbWVzc2FnZSwKICAgd2hpY2ggZ2VuZXJhbGx5IGNvbnNp c3RzIG9mIHRoZSBzZW5kZXIgbWFpbGJveCwgYW5kIGlzIHRoZSBtYWlsYm94IHRvCiAgIHdoaWNo IG5vdGlmaWNhdGlvbiBtZXNzYWdlcyBhcmUgdG8gYmUgc2VudCBpZiB0aGVyZSBhcmUgcHJvYmxl bXMKICAgZGVsaXZlcmluZyB0aGUgbWVzc2FnZS4KCltNU0s6IFNhbWUgcXVlc3Rpb24gYXMgYmVm b3JlIGFib3V0IHVzaW5nIFJGQzU1OTggbm90YXRpb24uXQoKICAgW1JGQzUzMjFdIGFsbG93cyB0 aGUgcmV2ZXJzZS1wYXRoIHRvIGJlIG51bGwgKHNlZSBTZWN0aW9uIDQuNS41IGluCiAgIFJGQyA1 MzIxKS4gIEluIHRoaXMgY2FzZSwgdGhlcmUgaXMgbm8gZXhwbGljaXQgc2VuZGVyIG1haWxib3gs IGFuZAogICBzdWNoIGEgbWVzc2FnZSBjYW4gYmUgYXNzdW1lZCB0byBiZSBhIG5vdGlmaWNhdGlv biBtZXNzYWdlIGZyb20gdGhlCiAgIG1haWwgc3lzdGVtIGl0c2VsZi4gIFdoZW4gdGhlIHJldmVy c2UtcGF0aCBpcyBudWxsLCB0aGlzIGRvY3VtZW50CiAgIGRlZmluZXMgdGhlICJNQUlMIEZST00i IGlkZW50aXR5IHRvIGJlIHRoZSBtYWlsYm94IGNvbXBvc2VkIG9mIHRoZQogICBsb2NhbHBhcnQg InBvc3RtYXN0ZXIiIGFuZCB0aGUgIkhFTE8iIGlkZW50aXR5ICh3aGljaCBtaWdodCBvciBtaWdo dAogICBub3QgaGF2ZSBiZWVuIGNoZWNrZWQgc2VwYXJhdGVseSBiZWZvcmUpLgoKICAgU1BGIGNs aWVudHMgTVVTVCBjaGVjayB0aGUgIk1BSUwgRlJPTSIgaWRlbnRpdHkgaWYgYSBjb21wbGV0ZWQg IkhFTE8iCiAgIGNoZWNrIGhhcyBub3QgcmVhY2hlZCBhIGRlZmluaXRpdmUgcG9saWN5IHJlc3Vs dCBieSBhcHBseWluZyB0aGUKICAgY2hlY2tfaG9zdCgpIGZ1bmN0aW9uIHRvIHRoZSAiTUFJTCBG Uk9NIiBpZGVudGl0eSBhcyB0aGUgPHNlbmRlcj4uCgoyLjMuICBQdWJsaXNoaW5nIEF1dGhvcml6 YXRpb24KCiAgIEFuIFNQRi1jb21wbGlhbnQgZG9tYWluIE1VU1QgcHVibGlzaCBhIHZhbGlkIFNQ RiByZWNvcmQgYXMgZGVzY3JpYmVkCiAgIGluIFNlY3Rpb24gMy4gIFRoaXMgcmVjb3JkIGF1dGhv cml6ZXMgdGhlIHVzZSBvZiB0aGUgZG9tYWluIG5hbWUgaW4KICAgdGhlICJIRUxPIiBhbmQgIk1B SUwgRlJPTSIgaWRlbnRpdGllcyBieSB0aGUgTVRBcyBpdCBzcGVjaWZpZXMuCgogICBJZiBkb21h aW4gb3duZXJzIGNob29zZSB0byBwdWJsaXNoIFNQRiByZWNvcmRzLCBpdCBpcyBSRUNPTU1FTkRF RAogICB0aGF0IHRoZXkgZW5kIGluICItYWxsIiwgb3IgcmVkaXJlY3QgdG8gb3RoZXIgcmVjb3Jk cyB0aGF0IGRvLCBzbwogICB0aGF0IGEgZGVmaW5pdGl2ZSBkZXRlcm1pbmF0aW9uIG9mIGF1dGhv cml6YXRpb24gY2FuIGJlIG1hZGUuCgpbTVNLOiBSRUNPTU1FTkRFRCBpbiBSRkMyMTE5IHRlcm1z IGlzIGVmZmVjdGl2ZWx5IGEgU0hPVUxELiAgSSBkb24ndCB0aGluayB3ZSBzaG91bGQgZG8gdGhp cywgYXMgdGhhdCdzIHN0cmljdGx5IGEgbG9jYWwgcG9saWN5IG1hdHRlciBhbmQgbm90IG9uZSBv ZiBpbnRlcm9wZXJhYmlsaXR5Ll0KCgoKS2l0dGVybWFuICAgICAgICAgICAgICAgIEV4cGlyZXMg SmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpICAgICAgICAgICAgSnVseSAyMDEy CgoKICAgRG9tYWluIGhvbGRlcnMgY2FuIHB1Ymxpc2ggU1BGIHJlY29yZHMgdGhhdCBleHBsaWNp dGx5IGF1dGhvcml6ZSBubwogICBob3N0cyBpZiBtYWlsIHNob3VsZCBuZXZlciBvcmlnaW5hdGUg dXNpbmcgdGhhdCBkb21haW4uCgpbTVNLOiBBdm9pZCBub24tbm9ybWF0aXZlICJzaG91bGQiLiAg U3VnZ2VzdCAiaXMgbm90IGV4cGVjdGVkIHRvIGV2ZXIgb3JpZ2luYXRlIi5dCgogICBXaGVuIGNo YW5naW5nIFNQRiByZWNvcmRzLCBjYXJlIG11c3QgYmUgdGFrZW4gdG8gZW5zdXJlIHRoYXQgdGhl cmUgaXMKICAgYSB0cmFuc2l0aW9uIHBlcmlvZCBzbyB0aGF0IHRoZSBvbGQgcG9saWN5IHJlbWFp bnMgdmFsaWQgdW50aWwgYWxsCiAgIGxlZ2l0aW1hdGUgZW1haWwgaGFzIGJlZW4gY2hlY2tlZC4K CltNU0s6IFRoZXJlJ3Mgbm8gd2F5IHRvIGV2ZXIga25vdyB0aGlzLiAgV2hvJ3MgdG8gc2F5IHRo YXQgYSBtZXNzYWdlIGhhc24ndCBzYXQgcXVldWVkIGZvciBhIG1vbnRoIGFuZCBmaW5hbGx5IGdv ZXMgdGhyb3VnaCwgb3Igc29tZXRoaW5nIGVycm9uZW91c2x5IGJlZ2lucyByZWxheWluZyBhbmQg dGh1cyByZS1ldmFsdWF0aW5nIGEgdG9uIG9mIG9sZCBtYWlsPyAgV2Ugc2F3IHRoYXQgYWxsIHRo ZSB0aW1lIGF0IENsb3VkbWFyaywgd2hlcmUgc29tZW9uZSB3b3VsZCByZXBvcnQgYW4gZW50aXJl IGNodW5rIG9mIGhpcy9oZXIgaW5ib3ggYXMgInNwYW0iIGFsbCBhdCBvbmNlLiAgUmUtZXZhbHVh dGlvbnMgbGlrZSB0aGF0IGNvdWxkIGhhdmUgdW5kZXNpcmFibGUgZWZmZWN0cy4gIFRodXMsIEkg dGhpbmsgdGhhdCBsYXN0IGJpdCBpc24ndCBhY3Rpb25hYmxlLiAgREtJTSB0YWxrZWQgYWJvdXQg b3ZlcmxhcHBpbmcgc2VsZWN0b3JzIGFzIGEgdHJhbnNpdGlvbiBwb2xpY3ksIGJ1dCBJJ20gbm90 IHN1cmUgaXQgYXBwbGllcyBoZXJlLiAgRG9uJ3Qga25vdyB3aGF0IHRvIHN1Z2dlc3QgZWl0aGVy Ll0KCjIuNC4gIENoZWNraW5nIEF1dGhvcml6YXRpb24KCiAgIEEgbWFpbCByZWNlaXZlciBjYW4g cGVyZm9ybSBhIHNldCBvZiBTUEYgY2hlY2tzIGZvciBlYWNoIG1haWwgbWVzc2FnZQogICBpdCBy ZWNlaXZlcy4gIEFuIFNQRiBjaGVjayB0ZXN0cyB0aGUgYXV0aG9yaXphdGlvbiBvZiBhIGNsaWVu dCBob3N0CiAgIHRvIGVtaXQgbWFpbCB3aXRoIGEgZ2l2ZW4gaWRlbnRpdHkuICBUeXBpY2FsbHks IHN1Y2ggY2hlY2tzIGFyZSBkb25lCiAgIGJ5IGEgcmVjZWl2aW5nIE1UQSwgYnV0IGNhbiBiZSBw ZXJmb3JtZWQgZWxzZXdoZXJlIGluIHRoZSBtYWlsCiAgIHByb2Nlc3NpbmcgY2hhaW4gc28gbG9u ZyBhcyB0aGUgcmVxdWlyZWQgaW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlIGFuZAogICByZWxpYWJs ZS4gIEF0IGxlYXN0IHRoZSAiTUFJTCBGUk9NIiBpZGVudGl0eSBNVVNUIGJlIGNoZWNrZWQsIGJ1 dCBpdAogICBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSAiSEVMTyIgaWRlbnRpdHkgYWxzbyBiZSBj aGVja2VkIGJlZm9yZWhhbmQuCgogICBXaXRob3V0IGV4cGxpY2l0IGFwcHJvdmFsIG9mIHRoZSBk b21haW4gb3duZXIsIGNoZWNraW5nIG90aGVyCiAgIGlkZW50aXRpZXMgYWdhaW5zdCBTUEYgdmVy c2lvbiAxIHJlY29yZHMgaXMgTk9UIFJFQ09NTUVOREVEIGJlY2F1c2UKICAgdGhlcmUgYXJlIGNh c2VzIHRoYXQgYXJlIGtub3duIHRvIGdpdmUgaW5jb3JyZWN0IHJlc3VsdHMuICBGb3IKICAgZXhh bXBsZSwgYWxtb3N0IGFsbCBtYWlsaW5nIGxpc3RzIHJld3JpdGUgdGhlICJNQUlMIEZST00iIGlk ZW50aXR5CiAgIChzZWUgU2VjdGlvbiA5LjIuMSksIGJ1dCBzb21lIGRvIG5vdCBjaGFuZ2UgYW55 IG90aGVyIGlkZW50aXRpZXMgaW4KICAgdGhlIG1lc3NhZ2UuICBUaGUgc2NlbmFyaW8gZGVzY3Jp YmVkIGluIFNlY3Rpb24gOS4yLjIsIHN1Yi1zZWN0aW9uCiAgIDEuMiwgaXMgYW5vdGhlciBleGFt cGxlLiAgRG9jdW1lbnRzIHRoYXQgZGVmaW5lIG90aGVyIGlkZW50aXRpZXMKICAgc2hvdWxkIGRl ZmluZSB0aGUgbWV0aG9kIGZvciBleHBsaWNpdCBhcHByb3ZhbC4KCltNU0s6IFJlcGxhY2Ugbm9u LW5vcm1hdGl2ZSAic2hvdWxkIi5dCgogICBJdCBpcyBwb3NzaWJsZSB0aGF0IG1haWwgcmVjZWl2 ZXJzIHdpbGwgdXNlIHRoZSBTUEYgY2hlY2sgYXMgcGFydCBvZgogICBhIGxhcmdlciBzZXQgb2Yg dGVzdHMgb24gaW5jb21pbmcgbWFpbC4gIFRoZSByZXN1bHRzIG9mIG90aGVyIHRlc3RzCiAgIG1p Z2h0IGluZmx1ZW5jZSB3aGV0aGVyIG9yIG5vdCBhIHBhcnRpY3VsYXIgU1BGIGNoZWNrIGlzIHBl cmZvcm1lZC4KICAgRm9yIGV4YW1wbGUsIGZpbmRpbmcgdGhlIHNlbmRpbmcgaG9zdCdzIElQIGFk ZHJlc3Mgb24gYSBsb2NhbCB3aGl0ZQogICBsaXN0IG1pZ2h0IGNhdXNlIGFsbCBvdGhlciB0ZXN0 cyB0byBiZSBza2lwcGVkIGFuZCBhbGwgbWFpbCBmcm9tIHRoYXQKICAgaG9zdCB0byBiZSBhY2Nl cHRlZC4KCiAgIFdoZW4gYSBtYWlsIHJlY2VpdmVyIGRlY2lkZXMgdG8gcGVyZm9ybSBhbiBTUEYg Y2hlY2ssIGl0IE1VU1QgdXNlIGEKICAgY29ycmVjdGx5LWltcGxlbWVudGVkIGNoZWNrX2hvc3Qo KSBmdW5jdGlvbiAoU2VjdGlvbiA0KSBldmFsdWF0ZWQKICAgd2l0aCB0aGUgY29ycmVjdCBwYXJh bWV0ZXJzLiAgQWx0aG91Z2ggdGhlIHRlc3QgYXMgYSB3aG9sZSBpcwogICBvcHRpb25hbCwgb25j ZSBpdCBoYXMgYmVlbiBkZWNpZGVkIHRvIHBlcmZvcm0gYSB0ZXN0IGl0IG11c3QgYmUKICAgcGVy Zm9ybWVkIGFzIHNwZWNpZmllZCBzbyB0aGF0IHRoZSBjb3JyZWN0IHNlbWFudGljcyBhcmUgcHJl c2VydmVkCiAgIGJldHdlZW4gcHVibGlzaGVyIGFuZCByZWNlaXZlci4KCiAgIFRvIG1ha2UgdGhl IHRlc3QsIHRoZSBtYWlsIHJlY2VpdmVyIE1VU1QgZXZhbHVhdGUgdGhlIGNoZWNrX2hvc3QoKQog ICBmdW5jdGlvbiB3aXRoIHRoZSBhcmd1bWVudHMgc2V0IGFzIGZvbGxvd3M6CgogICA8aXA+ICAg ICAtIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBTTVRQIGNsaWVudCB0aGF0IGlzIGVtaXR0aW5nIHRo ZQogICAgICAgICAgICAgIG1haWwsIGVpdGhlciBJUHY0IG9yIElQdjYuCgoKCgoKCktpdHRlcm1h biAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgICBb UGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAo U1BGKSAgICAgICAgICAgIEp1bHkgMjAxMgoKCiAgIDxkb21haW4+IC0gdGhlIGRvbWFpbiBwb3J0 aW9uIG9mIHRoZSAiTUFJTCBGUk9NIiBvciAiSEVMTyIgaWRlbnRpdHkuCgogICA8c2VuZGVyPiAt IHRoZSAiTUFJTCBGUk9NIiBvciAiSEVMTyIgaWRlbnRpdHkuCgogICBOb3RlIHRoYXQgdGhlIDxk b21haW4+IGFyZ3VtZW50IG1pZ2h0IG5vdCBiZSBhIHdlbGwtZm9ybWVkIGRvbWFpbgogICBuYW1l LiAgRm9yIGV4YW1wbGUsIGlmIHRoZSByZXZlcnNlLXBhdGggd2FzIG51bGwsIHRoZW4gdGhlIEVI TE8vSEVMTwogICBkb21haW4gaXMgdXNlZCwgd2l0aCBpdHMgYXNzb2NpYXRlZCBwcm9ibGVtcyAo c2VlIFNlY3Rpb24gMi4xKS4gIEluCiAgIHRoZXNlIGNhc2VzLCBjaGVja19ob3N0KCkgaXMgZGVm aW5lZCBpbiBTZWN0aW9uIDQuMyB0byByZXR1cm4gYQogICAibm9uZSIgcmVzdWx0LgoKICAgQWx0 aG91Z2ggaW52YWxpZCwgbWFsZm9ybWVkLCBvciBub24tZXhpc3RlbnQgZG9tYWlucyBjYXVzZSBT UEYgY2hlY2tzCiAgIHRvIHJldHVybiAibm9uZSIgYmVjYXVzZSBubyBTUEYgcmVjb3JkIGNhbiBi ZSBmb3VuZCwgaXQgaGFzIGxvbmcgYmVlbgogICB0aGUgcG9saWN5IG9mIG1hbnkgTVRBcyB0byBy ZWplY3QgZW1haWwgZnJvbSBzdWNoIGRvbWFpbnMsIGVzcGVjaWFsbHkKICAgaW4gdGhlIGNhc2Ug b2YgaW52YWxpZCAiTUFJTCBGUk9NIi4gIFJlamVjdGluZyBlbWFpbCB3aWxsIHByZXZlbnQgb25l CiAgIG1ldGhvZCBvZiBjaXJjdW12ZW50aW5nIG9mIFNQRiByZWNvcmRzLgoKICAgSW1wbGVtZW50 YXRpb25zIG11c3QgdGFrZSBjYXJlIHRvIGNvcnJlY3RseSBleHRyYWN0IHRoZSA8ZG9tYWluPiBm cm9tCgpbTVNLOiBBdm9pZCBub24tbm9ybWF0aXZlICJtdXN0Ii4gIEF0IHRoaXMgcG9pbnQgaXQn cyB3b3J0aCBtZW50aW9uaW5nIEJhcnJ5J3Mgc3VnZ2VzdGlvbiwgdGhvdWdoIGNvbnRyb3ZlcnNp YWwsIG9mIG1lbnRpb25pbmcgYWJvdmUgdGhhdCB0aGUga2V5IHdvcmRzIG9ubHkgaGF2ZSBtZWFu aW5nIHdoZW4gdGhleSBhcmUgaW4gYWxsLWNhcHMuICBXZSBtaWdodCB0cnkgdGhhdCwgYnV0IEkg a25vdyBhdCBsZWFzdCBEYXZlIGRvZXNuJ3QgbGlrZSBpdCBtdWNoLl0KCiAgIHRoZSBkYXRhIGdp dmVuIHdpdGggdGhlIFNNVFAgTUFJTCBGUk9NIGNvbW1hbmQgYXMgbWFueSBNVEFzIHdpbGwKICAg c3RpbGwgYWNjZXB0IHN1Y2ggdGhpbmdzIGFzIHNvdXJjZSByb3V0ZXMgKHNlZSBbUkZDNTMyMV0s IEFwcGVuZGl4CiAgIEMpLCB0aGUgJS1oYWNrIChzZWUgW1JGQzExMjNdKSwgYW5kIGJhbmcgcGF0 aHMgKHNlZSBbUkZDMTk4M10pLgogICBUaGVzZSBhcmNoYWljIGZlYXR1cmVzIGhhdmUgYmVlbiBt YWxpY2lvdXNseSB1c2VkIHRvIGJ5cGFzcyBzZWN1cml0eQogICBzeXN0ZW1zLgoKMi41LiAgSW50 ZXJwcmV0aW5nIHRoZSBSZXN1bHQKCiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgaG93IHNvZnR3 YXJlIHRoYXQgcGVyZm9ybXMgdGhlIGF1dGhvcml6YXRpb24KICAgc2hvdWxkIGludGVycHJldCB0 aGUgcmVzdWx0cyBvZiB0aGUgY2hlY2tfaG9zdCgpIGZ1bmN0aW9uLiAgVGhlCiAgIGF1dGhvcml6 YXRpb24gY2hlY2sgU0hPVUxEIGJlIHBlcmZvcm1lZCBkdXJpbmcgdGhlIHByb2Nlc3Npbmcgb2Yg dGhlCiAgIFNNVFAgdHJhbnNhY3Rpb24gdGhhdCBzZW5kcyB0aGUgbWFpbC4gIFRoaXMgYWxsb3dz IGVycm9ycyB0byBiZQogICByZXR1cm5lZCBkaXJlY3RseSB0byB0aGUgc2VuZGluZyBNVEEgYnkg d2F5IG9mIFNNVFAgcmVwbGllcy4KCltNU0s6IEkgaGF2ZSBhbiBvcGVuIHRpY2tldCBpbiB0aGUg dHJhY2tlciBhYm91dCBjaGVja19ob3N0KCksIHNvIEknbGwgbWFrZSBteSBmaXJzdCBjb21tZW50 IGFib3V0IGl0IGhlcmUgdGhvdWdoIHRoZXJlIHdpbGwgYmUgbWFueSBtb3JlIGxhdGVyLiAgVGhl IHZlcnkgc3RyaW5nICJjaGVja19ob3N0KCkiIGxvb2tzIGxpa2UgYSBmdW5jdGlvbiBkZWZpbml0 aW9uLCBhbmQgYXMgSSBzYWlkIGluIHRoZSB0cmFja2VyIGl0ZW0sIHRoZSBJRVRGIHByZWZlcnMg dG8gYXZvaWQgdGhlIGJ1c2luZXNzIG9mIEFQSSBkZWZpbml0aW9ucy4gIEl0J3MgcG9zc2libGUg dGhhdCBJIG1pZ2h0IGJlIGFibGUgdG8gc2VhcmNoLWFuZC1yZXBsYWNlIGl0IGludG8gc29tZXRo aW5nIG1vcmUgcGFsYXRhYmxlLiAgVGhpcyBpcyBqdXN0IGEgcGxhY2Vob2xkZXIgY29tbWVudCB0 byBub3RlIHRoYXQgSSBzdGlsbCB0aGluayBpdCdzIGFuIGlzc3VlIGFuZCBJJ20gZmlndXJpbmcg b3V0IGhvdyB0byBzdWdnZXN0IHdlIGRlYWwgd2l0aCBpdC5dCgogICBQZXJmb3JtaW5nIHRoZSBh dXRob3JpemF0aW9uIGFmdGVyIHRoZSBTTVRQIHRyYW5zYWN0aW9uIGhhcyBmaW5pc2hlZAogICBj YW4gY2F1c2UgcHJvYmxlbXMsIHN1Y2ggYXMgdGhlIGZvbGxvd2luZzogKDEpIEl0IG1pZ2h0IGJl IGRpZmZpY3VsdAogICB0byBhY2N1cmF0ZWx5IGV4dHJhY3QgdGhlIHJlcXVpcmVkIGluZm9ybWF0 aW9uIGZyb20gcG90ZW50aWFsbHkKICAgZGVjZXB0aXZlIGhlYWRlcnM7ICgyKSBsZWdpdGltYXRl IGVtYWlsIG1pZ2h0IGZhaWwgYmVjYXVzZSB0aGUKICAgc2VuZGVyJ3MgcG9saWN5IGhhZCBzaW5j ZSBjaGFuZ2VkLgoKW01TSzogSG93IGlzICgxKSBhYm92ZSBzcGVjaWZpYyB0byBwb3N0LXRyYW5z YWN0aW9uIHByb2Nlc3Npbmc/ICBTZWVtcyB0byBtZSBpdCdzIGEgcHJvYmxlbSBhdCB0aGUgZW5k IG9mIERBVEEgYXMgd2VsbC5dCgogICBHZW5lcmF0aW5nIG5vbi1kZWxpdmVyeSBub3RpZmljYXRp b25zIHRvIGZvcmdlZCBpZGVudGl0aWVzIHRoYXQgaGF2ZQogICBmYWlsZWQgdGhlIGF1dGhvcml6 YXRpb24gY2hlY2sgaXMgZ2VuZXJhbGx5IGFidXNpdmUgYW5kIGFnYWluc3QgdGhlCiAgIGV4cGxp Y2l0IHdpc2hlcyBvZiB0aGUgaWRlbnRpdHkgb3duZXIuCgpbTVNLOiBJIHRoaW5rIHdlIHNob3Vs ZCBzYXkgbW9yZSBoZXJlLiAgRm9yIGV4YW1wbGUsIGhvdyBleGFjdGx5IGlzIGl0IGFidXNpdmU/ ICBUaGUgcmVjaXBpZW50IGhhcyBkb25lIGV4YWN0bHkgd2hhdCBpdCB3YXMgYXNrZWQgdG8gZG8s IHlldCBpdCdzIGFidXNpbmcgc29tZW9uZT8gIFJhdGhlciB0aGFuIHNheWluZyBpdCdzIGFidXNp dmUsIEkgc3VnZ2VzdCB3ZSBzYXkgaXQgaW50cm9kdWNlcyBiYWNrc2NhdHRlciwgYW5kIHRoZW4g ZGVmaW5lIHRoYXQgdGVybS5dCgoyLjUuMS4gIE5vbmUKCiAgIEEgcmVzdWx0IG9mICJub25lIiBt ZWFucyB0aGF0IG5vIHJlY29yZHMgd2VyZSBwdWJsaXNoZWQgYnkgdGhlIGRvbWFpbgogICBvciB0 aGF0IG5vIGNoZWNrYWJsZSBzZW5kZXIgZG9tYWluIGNvdWxkIGJlIGRldGVybWluZWQgZnJvbSB0 aGUgZ2l2ZW4KICAgaWRlbnRpdHkuICBUaGUgY2hlY2tpbmcgc29mdHdhcmUgY2Fubm90IGFzY2Vy dGFpbiB3aGV0aGVyIG9yIG5vdCB0aGUKICAgY2xpZW50IGhvc3QgaXMgYXV0aG9yaXplZC4KCltN U0s6IHMvbWVhbnMgdGhhdC9tZWFucy8sIHMvb3IgdGhhdC9vci9dCgpbTVNLOiBXaGF0IGNvbnN0 aXR1dGVzICJjaGVja2FibGUiP10KCltNU0s6IHMvd2hldGhlciBvciBub3Qvd2hldGhlci9dCgoK CktpdHRlcm1hbiAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAg ICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZy YW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1bHkgMjAxMgoKCjIuNS4yLiAgTmV1dHJhbAoKICAg VGhlIGRvbWFpbiBvd25lciBoYXMgZXhwbGljaXRseSBzdGF0ZWQgdGhhdCBoZSBjYW5ub3Qgb3Ig ZG9lcyBub3QKICAgd2FudCB0byBhc3NlcnQgd2hldGhlciBvciBub3QgdGhlIElQIGFkZHJlc3Mg aXMgYXV0aG9yaXplZC4gIEEKICAgIm5ldXRyYWwiIHJlc3VsdCBNVVNUIGJlIHRyZWF0ZWQgZXhh Y3RseSBsaWtlIHRoZSAibm9uZSIgcmVzdWx0OyB0aGUKICAgZGlzdGluY3Rpb24gZXhpc3RzIG9u bHkgZm9yIGluZm9ybWF0aW9uYWwgcHVycG9zZXMuICBUcmVhdGluZwogICAibmV1dHJhbCIgbW9y ZSBoYXJzaGx5IHRoYW4gIm5vbmUiIHdvdWxkIGRpc2NvdXJhZ2UgZG9tYWluIG93bmVycwogICBm cm9tIHRlc3RpbmcgdGhlIHVzZSBvZiBTUEYgcmVjb3JkcyAoc2VlIFNlY3Rpb24gOS4xKS4KCltN U0s6IHMvaGUvaXQvLCBzL3doZXRoZXIgb3Igbm90L3doZXRoZXIvXQoKMi41LjMuICBQYXNzCgog ICBBICJwYXNzIiByZXN1bHQgbWVhbnMgdGhhdCB0aGUgY2xpZW50IGlzIGF1dGhvcml6ZWQgdG8g aW5qZWN0IG1haWwKICAgd2l0aCB0aGUgZ2l2ZW4gaWRlbnRpdHkuICBUaGUgZG9tYWluIGNhbiBu b3csIGluIHRoZSBzZW5zZSBvZgogICByZXB1dGF0aW9uLCBiZSBjb25zaWRlcmVkIHJlc3BvbnNp YmxlIGZvciBzZW5kaW5nIHRoZSBtZXNzYWdlLgogICBGdXJ0aGVyIHBvbGljeSBjaGVja3MgY2Fu IG5vdyBwcm9jZWVkIHdpdGggY29uZmlkZW5jZSBpbiB0aGUKICAgbGVnaXRpbWF0ZSB1c2Ugb2Yg dGhlIGlkZW50aXR5LgoKW01TSzogcy9tZWFucyB0aGF0L21lYW5zL10KCjIuNS40LiAgRmFpbAoK ICAgQSAiZmFpbCIgcmVzdWx0IGlzIGFuIGV4cGxpY2l0IHN0YXRlbWVudCB0aGF0IHRoZSBjbGll bnQgaXMgbm90CiAgIGF1dGhvcml6ZWQgdG8gdXNlIHRoZSBkb21haW4gaW4gdGhlIGdpdmVuIGlk ZW50aXR5LiAgVGhlIGNoZWNraW5nCiAgIHNvZnR3YXJlIGNhbiBjaG9vc2UgdG8gbWFyayB0aGUg bWFpbCBiYXNlZCBvbiB0aGlzIG9yIHRvIHJlamVjdCB0aGUKICAgbWFpbCBvdXRyaWdodC4KCltN U0s6IFdlIHNob3VsZCBwcm9iYWJseSBnaXZlIGEgc2VudGVuY2Ugc29tZXdoZXJlIGFib3ZlIHRo aXMgYWJvdXQgd2hhdCdzIG1lYW50IGJ5ICJtYXJrIHRoZSBtYWlsIi4gIE1heWJlIGV2ZW4gYSBz bWFsbCBzZWN0aW9uIGFib3V0IHBvc3NpYmxlICJmYWlsIiBhY3Rpb25zIHRoYXQgdW5kZXJzY29y ZXMgdGhlIGZhY3QgdGhhdCByZWplY3Rpb24gdnMuIG1hcmtpbmcgaXMgYSBjaG9pY2UgYW5kIG5l aXRoZXIgaXMgc3BlY2lmaWNhbGx5IHJlcXVpcmVkIHdvdWxkIGJlIGEgZ29vZCBpZGVhLl0KCiAg IElmIHRoZSBjaGVja2luZyBzb2Z0d2FyZSBjaG9vc2VzIHRvIHJlamVjdCB0aGUgbWFpbCBkdXJp bmcgdGhlIFNNVFAKICAgdHJhbnNhY3Rpb24sIHRoZW4gaXQgU0hPVUxEIHVzZSBhbiBTTVRQIHJl cGx5IGNvZGUgb2YgNTUwIChzZWUKICAgW1JGQzUzMjFdKSBhbmQsIGlmIHN1cHBvcnRlZCwgdGhl IDUuNy4xIGVuaGFuY2VkIHN0YXR1cyBjb2RlIChzZWUKICAgW1JGQzM0NjNdKSwgaW4gYWRkaXRp b24gdG8gYW4gYXBwcm9wcmlhdGUgcmVwbHkgdGV4dC4gIFRoZQogICBjaGVja19ob3N0KCkgZnVu Y3Rpb24gd2lsbCByZXR1cm4gZWl0aGVyIGEgZGVmYXVsdCBleHBsYW5hdGlvbiBzdHJpbmcKICAg b3Igb25lIGZyb20gdGhlIGRvbWFpbiB0aGF0IHB1Ymxpc2hlZCB0aGUgU1BGIHJlY29yZHMgKHNl ZQoKW01TSzogcy9mcm9tL3Byb3ZpZGVkIGJ5L10KCiAgIFNlY3Rpb24gNi4yKS4gIElmIHRoZSBp bmZvcm1hdGlvbiBkb2VzIG5vdCBvcmlnaW5hdGUgd2l0aCB0aGUKICAgY2hlY2tpbmcgc29mdHdh cmUsIGl0IHNob3VsZCBiZSBtYWRlIGNsZWFyIHRoYXQgdGhlIHRleHQgaXMgcHJvdmlkZWQKICAg YnkgdGhlIHNlbmRlcidzIGRvbWFpbi4gIEZvciBleGFtcGxlOgoKICAgICAgIDU1MC01LjcuMSBT UEYgTUFJTCBGUk9NIGNoZWNrIGZhaWxlZDoKICAgICAgIDU1MC01LjcuMSBUaGUgZG9tYWluIGV4 YW1wbGUuY29tIGV4cGxhaW5zOgogICAgICAgNTUwIDUuNy4xIFBsZWFzZSBzZWUgaHR0cDovL3d3 dy5leGFtcGxlLmNvbS9tYWlscG9saWN5Lmh0bWwKCjIuNS41LiAgU29mdGZhaWwKCiAgIEEgInNv ZnRmYWlsIiByZXN1bHQgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgc29tZXdoZXJlIGJldHdlZW4gYSAi ZmFpbCIKICAgYW5kIGEgIm5ldXRyYWwiLiAgVGhlIGRvbWFpbiBiZWxpZXZlcyB0aGUgaG9zdCBp cyBub3QgYXV0aG9yaXplZCBidXQKICAgaXMgbm90IHdpbGxpbmcgdG8gbWFrZSB0aGF0IHN0cm9u ZyBvZiBhIHN0YXRlbWVudC4gIFJlY2VpdmluZwogICBzb2Z0d2FyZSBTSE9VTEQgTk9UIHJlamVj dCB0aGUgbWVzc2FnZSBiYXNlZCBzb2xlbHkgb24gdGhpcyByZXN1bHQsCiAgIGJ1dCBNQVkgc3Vi amVjdCB0aGUgbWVzc2FnZSB0byBjbG9zZXIgc2NydXRpbnkgdGhhbiBub3JtYWwuCgpbTVNLOiBz L3RoYXQgc3Ryb25nIG9mIGEvYSBzdHJvbmcgcG9saWN5L10KCiAgIFRoZSBkb21haW4gb3duZXIg d2FudHMgdG8gZGlzY291cmFnZSB0aGUgdXNlIG9mIHRoaXMgaG9zdCBhbmQgdGh1cwogICBkZXNp cmVzIGxpbWl0ZWQgZmVlZGJhY2sgd2hlbiBhICJzb2Z0ZmFpbCIgcmVzdWx0IG9jY3Vycy4gIEZv cgoKCgpLaXR0ZXJtYW4gICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDYsIDIwMTMgICAg ICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgU2VuZGVyIFBvbGlj eSBGcmFtZXdvcmsgKFNQRikgICAgICAgICAgICBKdWx5IDIwMTIKCgogICBleGFtcGxlLCB0aGUg cmVjaXBpZW50J3MgTWFpbCBVc2VyIEFnZW50IChNVUEpIGNvdWxkIGhpZ2hsaWdodCB0aGUKICAg InNvZnRmYWlsIiBzdGF0dXMsIG9yIHRoZSByZWNlaXZpbmcgTVRBIGNvdWxkIGdpdmUgdGhlIHNl bmRlciBhCiAgIG1lc3NhZ2UgdXNpbmcgZ3JleWxpc3RpbmcsIFtSRkM2NjQ3XSwgd2l0aCBhIG5v dGUgdGhlIGZpcnN0IHRpbWUgdGhlCiAgIG1lc3NhZ2UgaXMgcmVjZWl2ZWQsIGJ1dCBhY2NlcHQg aXQgb24gYSBsYXRlciBhdHRlbXB0IGJhc2VkIG9uCiAgIHJlY2VpdmVyIHBvbGljeS4KCltNU0s6 IEFyZSB0aGVyZSBhbnkgaW1wbGVtZW50YXRpb25zIHRoYXQgZG8gdGhpcz9dCgoyLjUuNi4gIFRl bXBFcnJvcgoKICAgQSAidGVtcGVycm9yIiByZXN1bHQgbWVhbnMgdGhhdCB0aGUgU1BGIGNsaWVu dCBlbmNvdW50ZXJlZCBhCiAgIHRyYW5zaWVudCBlcnJvciB3aGlsZSBwZXJmb3JtaW5nIHRoZSBj aGVjay4gIENoZWNraW5nIHNvZnR3YXJlIGNhbgogICBjaG9vc2UgdG8gYWNjZXB0IG9yIHRlbXBv cmFyaWx5IHJlamVjdCB0aGUgbWVzc2FnZS4gIElmIHRoZSBtZXNzYWdlCiAgIGlzIHJlamVjdGVk IGR1cmluZyB0aGUgU01UUCB0cmFuc2FjdGlvbiBmb3IgdGhpcyByZWFzb24sIHRoZSBzb2Z0d2Fy ZQogICBTSE9VTEQgdXNlIGFuIFNNVFAgcmVwbHkgY29kZSBvZiA0NTEgYW5kLCBpZiBzdXBwb3J0 ZWQsIHRoZSA0LjQuMwogICBlbmhhbmNlZCBzdGF0dXMgY29kZS4KCltNU0s6IHMvbWVhbnMgdGhh dC9tZWFucy9dCgpbTVNLOiBEbyB3ZSByZWFsbHkgbmVlZCB0byBzcGVsbCBvdXQgU01UUCByZXBs eSBjb2RlcyBhbmQgZW5oYW5jZWQgc3RhdHVzIGNvZGVzPyAgSXNuJ3QgaXQgZW5vdWdoIHRvIHNh eSB0aG9zZSBjb2RlcyBhcmUgZGVmaW5lZCBpbiBSRkM1MzIxIGFuZCBSRkMzNDYzLCBhbmQgbGVh dmUgaXQgYXQgdGhhdD9dCgoyLjUuNy4gIFBlcm1FcnJvcgoKICAgQSAicGVybWVycm9yIiByZXN1 bHQgbWVhbnMgdGhhdCB0aGUgZG9tYWluJ3MgcHVibGlzaGVkIHJlY29yZHMgY291bGQKICAgbm90 IGJlIGNvcnJlY3RseSBpbnRlcnByZXRlZC4gIFRoaXMgc2lnbmFscyBhbiBlcnJvciBjb25kaXRp b24gdGhhdAogICByZXF1aXJlcyBtYW51YWwgaW50ZXJ2ZW50aW9uIHRvIGJlIHJlc29sdmVkLCBh cyBvcHBvc2VkIHRvIHRoZQogICB0ZW1wZXJyb3IgcmVzdWx0LiAgSWYgdGhlIG1lc3NhZ2UgaXMg cmVqZWN0ZWQgZHVyaW5nIHRoZSBTTVRQCiAgIHRyYW5zYWN0aW9uIGZvciB0aGlzIHJlYXNvbiwg dGhlIHNvZnR3YXJlIFNIT1VMRCB1c2UgYW4gU01UUCByZXBseQogICBjb2RlIG9mIDU1MCBhbmQs IGlmIHN1cHBvcnRlZCwgdGhlIDUuNS4yIGVuaGFuY2VkIHN0YXR1cyBjb2RlLiAgQmUKICAgYXdh cmUgdGhhdCBpZiB0aGUgZG9tYWluIG93bmVyIHVzZXMgbWFjcm9zIChTZWN0aW9uIDgpLCBpdCBp cwogICBwb3NzaWJsZSB0aGF0IHRoaXMgcmVzdWx0IGlzIGR1ZSB0byB0aGUgY2hlY2tlZCBpZGVu dGl0aWVzIGhhdmluZyBhbgogICB1bmV4cGVjdGVkIGZvcm1hdC4KCltNU0s6IHMvbWVhbnMgdGhh dC9tZWFucy9dCgpbTVNLOiBTYW1lIHBvaW50IGFzIGFib3ZlIGFib3V0IHJlcGx5IGNvZGVzLCBl dGMuXQoKW01TSzogSWYgbm90IGNvdmVyZWQgZWxzZXdoZXJlLCB3ZSBuZWVkIHRvIGluZGljYXRl IHdoaWNoIG9mIHRoZXNlIGlzIGFuIGFwcHJvcHJpYXRlIHJldHVybiB3aGVuIGEgRE5TIGVycm9y IG9jY3Vycy4gIEl0IG1heSBiZSB0aGUgY2FzZSB0aGF0IHdlIGxlYXZlIHRoaXMgYXMgYW4gaW1w bGVtZW50YXRpb24gZGV0YWlsLCBidXQgSSdkIHByZWZlciB3ZSBzYXkgdGhhdC5dCgoKCgoKCgoK CgoKCgoKCgoKCgpLaXR0ZXJtYW4gICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDYsIDIw MTMgICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgU2VuZGVy IFBvbGljeSBGcmFtZXdvcmsgKFNQRikgICAgICAgICAgICBKdWx5IDIwMTIKCgozLiAgU1BGIFJl Y29yZHMKCiAgIEFuIFNQRiByZWNvcmQgaXMgYSBETlMgUmVzb3VyY2UgUmVjb3JkIChSUikgdGhh dCBkZWNsYXJlcyB3aGljaCBob3N0cwoKW01TSzogVGhpcyBuZWVkcyB0byBiZSBhZGp1c3RlZCwg YmVjYXVzZSB0aGVyZSdzIGFuIFNQRiBSUlRZUEUsIGJ1dCBhbHNvIGEgVFhUIFJSVFlQRSwgYW5k IGFzIG9mIHRoaXMgZHJhZnQgd2UgcHJlZmVyIG9ubHkgdGhlIGxhdHRlci4gIFN1Z2dlc3QgYWRk aW5nICJUWFQgKHR5cGUgMTYpIiBhZnRlciAiRE5TIiBoZXJlLl0KCiAgIGFyZSwgYW5kIGFyZSBu b3QsIGF1dGhvcml6ZWQgdG8gdXNlIGEgZG9tYWluIG5hbWUgZm9yIHRoZSAiSEVMTyIgYW5kCiAg ICJNQUlMIEZST00iIGlkZW50aXRpZXMuICBMb29zZWx5LCB0aGUgcmVjb3JkIHBhcnRpdGlvbnMg YWxsIGhvc3RzCiAgIGludG8gcGVybWl0dGVkIGFuZCBub3QtcGVybWl0dGVkIHNldHMgKHRob3Vn aCBzb21lIGhvc3RzIG1pZ2h0IGZhbGwKICAgaW50byBuZWl0aGVyIGNhdGVnb3J5KS4KCltNU0s6 IFRoYXQgc291bmRzIGNvbmZ1c2luZy4gIEhvdyBpcyB0aGF0IHBvc3NpYmxlP10KCiAgIFRoZSBT UEYgcmVjb3JkIGlzIGEgc2luZ2xlIHN0cmluZyBvZiB0ZXh0LiAgQW4gZXhhbXBsZSByZWNvcmQg aXMgdGhlCiAgIGZvbGxvd2luZzoKCiAgICAgIHY9c3BmMSArbXggYTpjb2xvLmV4YW1wbGUuY29t LzI4IC1hbGwKCiAgIFRoaXMgcmVjb3JkIGhhcyBhIHZlcnNpb24gb2YgInNwZjEiIGFuZCB0aHJl ZSBkaXJlY3RpdmVzOiAiK214IiwKICAgImE6Y29sby5leGFtcGxlLmNvbS8yOCIgKHRoZSArIGlz IGltcGxpZWQpLCBhbmQgIi1hbGwiLgoKMy4xLiAgUHVibGlzaGluZwoKICAgRG9tYWluIG93bmVy cyB3aXNoaW5nIHRvIGJlIFNQRiBjb21wbGlhbnQgbXVzdCBwdWJsaXNoIFNQRiByZWNvcmRzCgpb TVNLOiBzL211c3QvTVVTVC9dCgogICBmb3IgdGhlIGhvc3RzIHRoYXQgYXJlIHVzZWQgaW4gdGhl ICJNQUlMIEZST00iIGFuZCAiSEVMTyIgaWRlbnRpdGllcy4KICAgVGhlIFNQRiByZWNvcmRzIGFy ZSBwbGFjZWQgaW4gdGhlIEROUyB0cmVlIGF0IHRoZSBob3N0IG5hbWUgaXQKICAgcGVydGFpbnMg dG8sIG5vdCBhIHN1YmRvbWFpbiB1bmRlciBpdCwgc3VjaCBhcyBpcyBkb25lIHdpdGggU1JWCiAg IHJlY29yZHMuCgpbTVNLOiBTdWdnZXN0IGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byB3aGVy ZXZlciBTUlYgcmVjb3JkcyBhcmUgZGVmaW5lZC5dCgogICBUaGUgZXhhbXBsZSBhYm92ZSBpbiBT ZWN0aW9uIDMgbWlnaHQgYmUgcHVibGlzaGVkIHZpYSB0aGVzZSBsaW5lcyBpbgoKW01TSzogcy9h Ym92ZSAvL10KCiAgIGEgZG9tYWluIHpvbmUgZmlsZToKCiAgICAgIGV4YW1wbGUuY29tLiAgICAg ICAgICBUWFQgInY9c3BmMSArbXggYTpjb2xvLmV4YW1wbGUuY29tLzI4IC1hbGwiCiAgICAgIHNt dHAtb3V0LmV4YW1wbGUuY29tLiBUWFQgInY9c3BmMSBhIC1hbGwiCgogICBXaGVuIHB1Ymxpc2hp bmcgdmlhIFRYVCByZWNvcmRzLCBiZXdhcmUgb2Ygb3RoZXIgVFhUIHJlY29yZHMKICAgcHVibGlz aGVkIHRoZXJlIGZvciBvdGhlciBwdXJwb3Nlcy4gIFRoZXkgbWlnaHQgY2F1c2UgcHJvYmxlbXMg d2l0aAogICBzaXplIGxpbWl0cyAoc2VlIFNlY3Rpb24gMy4xLjQpLgoKW01TSzogTm93IHRoYXQg U1BGIFJSVFlQRSBpcyBkZXByZWNhdGVkLCB0aGUgIldoZW4iIGNsYXVzZSBzaG91bGQgcHJvYmFi bHkgZ28uXQoKICAgRG9tYWlucyBwdWJsaXNoaW5nIHJlY29yZHMgU0hPVUxEIHRyeSB0byBrZWVw IHRoZSBudW1iZXIgb2YgImluY2x1ZGUiCiAgIG1lY2hhbmlzbXMgYW5kIGNoYWluZWQgInJlZGly ZWN0IiBtb2RpZmllcnMgdG8gYSBtaW5pbXVtLiAgRG9tYWlucwogICBTSE9VTEQgYWxzbyB0cnkg dG8gbWluaW1pemUgdGhlIGFtb3VudCBvZiBvdGhlciBETlMgaW5mb3JtYXRpb24KICAgbmVlZGVk IHRvIGV2YWx1YXRlIGEgcmVjb3JkLiAgU2VjdGlvbiA5LjEuMSBwcm92aWRlcyBzb21lIHN1Z2dl c3Rpb25zCiAgIG9uIGhvdyB0byBhY2hpZXZlIHRoaXMuCgozLjEuMS4gIEROUyBSZXNvdXJjZSBS ZWNvcmRzCgogICBTUEYgcmVjb3JkcyBNVVNUIGJlIHB1Ymxpc2hlZCBhcyB0eXBlIFRYVCBbUkZD MTAzNV0uICBUaGUgY2hhcmFjdGVyCiAgIGNvbnRlbnQgb2YgdGhlIHJlY29yZCBpcyBlbmNvZGVk IGFzIFtVUy1BU0NJSV0uICBVc2Ugb2YgYWx0ZXJuYXRlIEROUwogICBSUiB0eXBlcyBoYXMgYmVl biBkcm9wcGVkLiAgU2VlIEFwcGVuZGl4IEEgb2YKICAgW2RyYWZ0LWlldGYtc3BmYmlzLWV4cGVy aW1lbnRdLgoKW01TSzogcy9oYXMgYmVlbiBkcm9wcGVkL3dhcyBzdXBwb3J0ZWQgaW4gU1BGJ3Mg ZXhwZXJpbWVudGFsIHBoYXNlLCBidXQgaGFzIGJlZW4gZGlzY29udGludWVkL10KCltNU0s6IEFk ZCAiIGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uIiB0byB0aGUgZW5kIG9mIHRoZSBsYXN0IHNlbnRl bmNlLl0KCgoKCktpdHRlcm1hbiAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAx MyAgICAgICAgICAgICAgIFtQYWdlIDEzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIg UG9saWN5IEZyYW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1bHkgMjAxMgoKCjMuMS4yLiAgTXVs dGlwbGUgRE5TIFJlY29yZHMKCiAgIEEgZG9tYWluIG5hbWUgTVVTVCBOT1QgaGF2ZSBtdWx0aXBs ZSByZWNvcmRzIHRoYXQgd291bGQgY2F1c2UgYW4KICAgYXV0aG9yaXphdGlvbiBjaGVjayB0byBz ZWxlY3QgbW9yZSB0aGFuIG9uZSByZWNvcmQuICBTZWUgU2VjdGlvbiA0LjUKICAgZm9yIHRoZSBz ZWxlY3Rpb24gcnVsZXMuCgozLjEuMy4gIE11bHRpcGxlIFN0cmluZ3MgaW4gYSBTaW5nbGUgRE5T IHJlY29yZAoKICAgQXMgZGVmaW5lZCBpbiBbUkZDMTAzNV0gc2VjdGlvbnMgMy4zLjE0IGFuZCAz LjMsIGEgc2luZ2xlIHRleHQgRE5TCiAgIHJlY29yZCAoZWl0aGVyIFRYVCBvciBTUEYgUlIgdHlw ZXMpIGNhbiBiZSBjb21wb3NlZCBvZiBtb3JlIHRoYW4gb25lCiAgIHN0cmluZy4gIElmIGEgcHVi bGlzaGVkIHJlY29yZCBjb250YWlucyBtdWx0aXBsZSBzdHJpbmdzLCB0aGVuIHRoZQoKW01TSzog cy9zdHJpbmcvY2hhcmFjdGVyLXN0cmluZy8sIHRvIGNpdGUgdGhlIEFCTkYgb3ZlciB0aGVyZV0K CgogICByZWNvcmQgTVVTVCBiZSB0cmVhdGVkIGFzIGlmIHRob3NlIHN0cmluZ3MgYXJlIGNvbmNh dGVuYXRlZCB0b2dldGhlcgogICB3aXRob3V0IGFkZGluZyBzcGFjZXMuICBGb3IgZXhhbXBsZToK CiAgICAgIElOIFRYVCAidj1zcGYxIC4uLi4gZmlyc3QiICJzZWNvbmQgc3RyaW5nLi4uIgoKICAg TVVTVCBiZSB0cmVhdGVkIGFzIGVxdWl2YWxlbnQgdG8KCiAgICAgIElOIFRYVCAidj1zcGYxIC4u Li4gZmlyc3RzZWNvbmQgc3RyaW5nLi4uIgoKICAgVFhUIHJlY29yZHMgY29udGFpbmluZyBtdWx0 aXBsZSBzdHJpbmdzIGFyZSB1c2VmdWwgaW4gY29uc3RydWN0aW5nCiAgIHJlY29yZHMgdGhhdCB3 b3VsZCBleGNlZWQgdGhlIDI1NS1ieXRlIG1heGltdW0gbGVuZ3RoIG9mIGEgc3RyaW5nCgpbTVNL OiBzL3N0cmluZy9jaGFyYWN0ZXItc3RyaW5nL10KCiAgIHdpdGhpbiBhIHNpbmdsZSBUWFQgcmVj b3JkLgoKMy4xLjQuICBSZWNvcmQgU2l6ZQoKICAgVGhlIHB1Ymxpc2hlZCBTUEYgcmVjb3JkIGZv ciBhIGdpdmVuIGRvbWFpbiBuYW1lIFNIT1VMRCByZW1haW4gc21hbGwKICAgZW5vdWdoIHRoYXQg dGhlIHJlc3VsdHMgb2YgYSBxdWVyeSBmb3IgaXQgd2lsbCBmaXQgd2l0aGluIDUxMiBvY3RldHMu CgpbTVNLOiBTdWdnZXN0IHJlZmVyZW5jaW5nIFJGQzEwM1s0NV0gd2hlcmUgdGhhdCBsaW1pdCBp cyBlc3RhYmxpc2hlZC5dCgogICBUaGlzIHdpbGwga2VlcCBldmVuIG9sZGVyIEROUyBpbXBsZW1l bnRhdGlvbnMgZnJvbSBmYWxsaW5nIG92ZXIgdG8KCltNU0s6IFdlIHNob3VsZCBleHBsYWluIHdo eSB3ZSB3YW50IHRvIGF2b2lkIFRDUC5dCgogICBUQ1AuICBTaW5jZSB0aGUgYW5zd2VyIHNpemUg aXMgZGVwZW5kZW50IG9uIG1hbnkgdGhpbmdzIG91dHNpZGUgdGhlCiAgIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnQsIGl0IGlzIG9ubHkgcG9zc2libGUgdG8gZ2l2ZSB0aGlzIGd1aWRlbGluZToKICAg SWYgdGhlIGNvbWJpbmVkIGxlbmd0aCBvZiB0aGUgRE5TIG5hbWUgYW5kIHRoZSB0ZXh0IG9mIGFs bCB0aGUKICAgcmVjb3JkcyBvZiBhIGdpdmVuIHR5cGUgaXMgdW5kZXIgNDUwIGNoYXJhY3RlcnMs IHRoZW4gRE5TIGFuc3dlcnMKICAgc2hvdWxkIGZpdCBpbiBVRFAgcGFja2V0cy4gIE5vdGUgdGhh dCB3aGVuIGNvbXB1dGluZyB0aGUgc2l6ZXMgZm9yCgpbTVNLOiBzL3Nob3VsZC9uZWVkcyB0by9d CgogICBxdWVyaWVzIG9mIHRoZSBUWFQgZm9ybWF0LCBvbmUgbXVzdCB0YWtlIGludG8gYWNjb3Vu dCBhbnkgb3RoZXIgVFhUCiAgIHJlY29yZHMgcHVibGlzaGVkIGF0IHRoZSBkb21haW4gbmFtZS4g IFJlY29yZHMgdGhhdCBhcmUgdG9vIGxvbmcgdG8KICAgZml0IGluIGEgc2luZ2xlIFVEUCBwYWNr ZXQgTUFZIGJlIHNpbGVudGx5IGlnbm9yZWQgYnkgU1BGIGNsaWVudHMuCgpbTVNLOiBBcyBJIGZv dW5kIGluIHRoZSBleHBlcmltZW50IHN1cnZleSwgdGhlcmUgYXJlIHNvbWUgZG9tYWlucyB0aGF0 IGhhdmUgYXMgbWFueSBhcyAzNyByZWNvcmRzIGF0IHRoZSBkb21haW4gbGV2ZWwuICBXZSBtaWdo dCB3YW50IHRvIGluY2x1ZGUgYW55IG90aGVyIHBlcm1hbmVudCByZWZlcmVuY2VzIHdlIGNhbiBm aW5kIHRoYXQgZXN0YWJsaXNoIG90aGVyIFRYVCByZWNvcmRzIHB1Ymxpc2hlZCBhdCB0aGUgZG9t YWluIGxldmVsIHRoYXQgbWlnaHQgaW50ZXJmZXJlIHdpdGggdGhlc2UgZ3VpZGVsaW5lcy5dCgoz LjEuNS4gIFdpbGRjYXJkIFJlY29yZHMKCiAgIFVzZSBvZiB3aWxkY2FyZCByZWNvcmRzIGZvciBw dWJsaXNoaW5nIGlzIG5vdCByZWNvbW1lbmRlZC4gIENhcmUgbXVzdAoKW01TSzogcy9ub3QgcmVj b21tZW5kZWQvTk9UIFJFQ09NTUVOREVEL10KCiAgIGJlIHRha2VuIGlmIHdpbGRjYXJkIHJlY29y ZHMgYXJlIHVzZWQuICBJZiBhIGRvbWFpbiBwdWJsaXNoZXMKICAgd2lsZGNhcmQgTVggcmVjb3Jk cywgaXQgbWlnaHQgd2FudCB0byBwdWJsaXNoIHdpbGRjYXJkIGRlY2xhcmF0aW9ucywKICAgc3Vi amVjdCB0byB0aGUgc2FtZSByZXF1aXJlbWVudHMgYW5kIHByb2JsZW1zLiAgSW4gcGFydGljdWxh ciwgdGhlCiAgIGRlY2xhcmF0aW9uIG11c3QgYmUgcmVwZWF0ZWQgZm9yIGFueSBob3N0IHRoYXQg aGFzIGFueSBSUiByZWNvcmRzIGF0CgpbTVNLOiBlaXRoZXIgcy9tdXN0L01VU1QvIG9yIHMvbXVz dC9uZWVkcyB0by8sIGFzIGFwcHJvcHJpYXRlXQoKICAgYWxsLCBhbmQgZm9yIHN1YmRvbWFpbnMg dGhlcmVvZi4gIEZvciBleGFtcGxlLCB0aGUgZXhhbXBsZSBnaXZlbiBpbgogICBbUkZDMTAzNF0s IFNlY3Rpb24gNC4zLjMsIGNvdWxkIGJlIGV4dGVuZGVkIHdpdGggdGhlIGZvbGxvd2luZzoKCgoK CktpdHRlcm1hbiAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAg ICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZy YW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1bHkgMjAxMgoKCiAgICAgICBYLkNPTS4gICAgICAg ICAgTVggICAgICAxMCAgICAgIEEuWC5DT00KICAgICAgIFguQ09NLiAgICAgICAgICBUWFQgICAg ICJ2PXNwZjEgYTpBLlguQ09NIC1hbGwiCgogICAgICAgKi5YLkNPTS4gICAgICAgIE1YICAgICAg MTAgICAgICBBLlguQ09NCiAgICAgICAqLlguQ09NLiAgICAgICAgVFhUICAgICAidj1zcGYxIGE6 QS5YLkNPTSAtYWxsIgoKICAgICAgIEEuWC5DT00uICAgICAgICBBICAgICAgIDEuMi4zLjQKICAg ICAgIEEuWC5DT00uICAgICAgICBNWCAgICAgIDEwICAgICAgQS5YLkNPTQogICAgICAgQS5YLkNP TS4gICAgICAgIFRYVCAgICAgInY9c3BmMSBhOkEuWC5DT00gLWFsbCIKCiAgICAgICAqLkEuWC5D T00uICAgICAgTVggICAgICAxMCAgICAgIEEuWC5DT00KICAgICAgICouQS5YLkNPTS4gICAgICBU WFQgICAgICJ2PXNwZjEgYTpBLlguQ09NIC1hbGwiCgogICBOb3RpY2UgdGhhdCBTUEYgcmVjb3Jk cyBtdXN0IGJlIHJlcGVhdGVkIHR3aWNlIGZvciBldmVyeSBuYW1lIHdpdGhpbgoKW01TSzogcy9t dXN0L01VU1QvIG9yIHMvbXVzdC9uZWVkcyB0by8sIGFzIGFwcHJvcHJpYXRlXQoKICAgdGhlIGRv bWFpbjogb25jZSBmb3IgdGhlIG5hbWUsIGFuZCBvbmNlIHdpdGggYSB3aWxkY2FyZCB0byBjb3Zl ciB0aGUKICAgdHJlZSB1bmRlciB0aGUgbmFtZS4KCiAgIFVzZSBvZiB3aWxkY2FyZHMgaXMgZGlz Y291cmFnZWQgaW4gZ2VuZXJhbCBhcyB0aGV5IGNhdXNlIGV2ZXJ5IG5hbWUKICAgdW5kZXIgdGhl IGRvbWFpbiB0byBleGlzdCBhbmQgcXVlcmllcyBhZ2FpbnN0IGFyYml0cmFyeSBuYW1lcyB3aWxs CiAgIG5ldmVyIHJldHVybiBSQ09ERSAzIChOYW1lIEVycm9yKS4KCltNU0s6IFN1Z2dlc3QgIndo aWNoIHdpbGwgaW50ZXJmZXJlIHdpdGggZXhpc3RlbmNlIHRlc3RzIHN1Y2ggYXMgdGhlIG9uZSBk ZXNjcmliZWQgaW4gW1JGQzU2MTddIl0KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpL aXR0ZXJtYW4gICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDYsIDIwMTMgICAgICAgICAg ICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgU2VuZGVyIFBvbGljeSBGcmFt ZXdvcmsgKFNQRikgICAgICAgICAgICBKdWx5IDIwMTIKCgo0LiAgVGhlIGNoZWNrX2hvc3QoKSBG dW5jdGlvbgoKW01TSzogSSdtIHJlYWRpbmcgdGhpcyBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0ICJj aGVja19ob3N0KCkiIGlzIHJlcGxhY2VkIGJ5ICJDaGVja0hvc3QiLiAgTGV0J3Mgc2VlIGlmIHRo YXQgd29ya3MuXQoKICAgVGhlIGNoZWNrX2hvc3QoKSBmdW5jdGlvbiBmZXRjaGVzIFNQRiByZWNv cmRzLCBwYXJzZXMgdGhlbSwgYW5kCiAgIGludGVycHJldHMgdGhlbSB0byBkZXRlcm1pbmUgd2hl dGhlciBhIHBhcnRpY3VsYXIgaG9zdCBpcyBvciBpcyBub3QKICAgcGVybWl0dGVkIHRvIHNlbmQg bWFpbCB3aXRoIGEgZ2l2ZW4gaWRlbnRpdHkuICBNYWlsIHJlY2VpdmVycyB0aGF0CiAgIHBlcmZv cm0gdGhpcyBjaGVjayBNVVNUIGNvcnJlY3RseSBldmFsdWF0ZSB0aGUgY2hlY2tfaG9zdCgpIGZ1 bmN0aW9uCiAgIGFzIGRlc2NyaWJlZCBoZXJlLgoKICAgSW1wbGVtZW50YXRpb25zIE1BWSB1c2Ug YSBkaWZmZXJlbnQgYWxnb3JpdGhtIHRoYW4gdGhlIGNhbm9uaWNhbAogICBhbGdvcml0aG0gZGVm aW5lZCBoZXJlLCBzbyBsb25nIGFzIHRoZSByZXN1bHRzIGFyZSB0aGUgc2FtZSBpbiBhbGwKICAg Y2FzZXMuCgo0LjEuICBBcmd1bWVudHMKCiAgIFRoZSBjaGVja19ob3N0KCkgZnVuY3Rpb24gdGFr ZXMgdGhlc2UgYXJndW1lbnRzOgoKW01TSzogIlRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIHBy b2NlZHVyZSBmb3IgZXZhbHVhdGluZyBhbiBTTVRQIGNsaWVudCdzIGF1dGhvcml6YXRpb24gdG8g dXNlIGEgZG9tYWluIG5hbWUgYXMgYW4gaWRlbnRpdHkgaW4gdGhlIFNNVFAgc2Vzc2lvbiBiYXNl ZCBvbiBTUEYgcG9saWN5IHJldHJpZXZlZCBmcm9tIHRoZSBETlMuICBUaGUgcHJvY2VkdXJlIGlz IHJlZmVycmVkIHRvIGFzIHRoZSAiQ2hlY2tIb3N0IGZ1bmN0aW9uIi4gIEl0IHVzZXMgdGhlc2Ug aW5wdXRzOiJdCgogICA8aXA+ICAgICAtIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBTTVRQIGNsaWVu dCB0aGF0IGlzIGVtaXR0aW5nIHRoZQogICAgICAgICAgICAgIG1haWwsIGVpdGhlciBJUHY0IG9y IElQdjYuCgogICA8ZG9tYWluPiAtIHRoZSBkb21haW4gdGhhdCBwcm92aWRlcyB0aGUgc291Z2h0 LWFmdGVyIGF1dGhvcml6YXRpb24KICAgICAgICAgICAgICBpbmZvcm1hdGlvbjsgaW5pdGlhbGx5 LCB0aGUgZG9tYWluIHBvcnRpb24gb2YgdGhlICJNQUlMCiAgICAgICAgICAgICAgRlJPTSIgb3Ig IkhFTE8iIGlkZW50aXR5LgoKICAgPHNlbmRlcj4gLSB0aGUgIk1BSUwgRlJPTSIgb3IgIkhFTE8i IGlkZW50aXR5LgoKW01TSzogIihUaGUgbmFtZXMgaW4gYW5nbGUgYnJhY2tldHMgYXJlIHN5bWJv bGljIG5hbWVzIGZvciB0aGVzZSBpbnB1dHMsIGFuZCBhcmUgZGlzY3Vzc2VkIHVzaW5nIHRoZXNl IHN5bWJvbHMgZWxzZXdoZXJlIGluIHRoaXMgZG9jdW1lbnQuKSJdCgogICBUaGUgZG9tYWluIHBv cnRpb24gb2YgPHNlbmRlcj4gd2lsbCB1c3VhbGx5IGJlIHRoZSBzYW1lIGFzIHRoZQogICA8ZG9t YWluPiBhcmd1bWVudCB3aGVuIGNoZWNrX2hvc3QoKSBpcyBpbml0aWFsbHkgZXZhbHVhdGVkLiAg SG93ZXZlciwKICAgdGhpcyB3aWxsIGdlbmVyYWxseSBub3QgYmUgdHJ1ZSBmb3IgcmVjdXJzaXZl IGV2YWx1YXRpb25zIChzZWUKICAgU2VjdGlvbiA1LjIgYmVsb3cpLgoKICAgQWN0dWFsIGltcGxl bWVudGF0aW9ucyBvZiB0aGUgY2hlY2tfaG9zdCgpIGZ1bmN0aW9uIG1pZ2h0IG5lZWQKICAgYWRk aXRpb25hbCBhcmd1bWVudHMuCgpbTVNLOiAiU3BlY2lmaWMgaW1wbGVtZW50YXRpb25zIG9mIENo ZWNrSG9zdCBtYXksIG9mIGNvdXJzZSwgY29uc2lkZXIgb3RoZXIgcGFyYW1ldGVycyBhcyBpbnB1 dHMgaW4gYWRkaXRpb24gdG8gdGhlc2UuIl0KCjQuMi4gIFJlc3VsdHMKCiAgIFRoZSBmdW5jdGlv biBjaGVja19ob3N0KCkgY2FuIHJldHVybiBvbmUgb2Ygc2V2ZXJhbCByZXN1bHRzIGRlc2NyaWJl ZAoKW01TSzogIkNoZWNrSG9zdCBwcm9kdWNlcyBvbmUgb2Ygc2V2ZXJhbCByZXN1bHRz4oCmIl0K CiAgIGluIFNlY3Rpb24gMi41LiAgQmFzZWQgb24gdGhlIHJlc3VsdCwgdGhlIGFjdGlvbiB0byBi ZSB0YWtlbiBpcwogICBkZXRlcm1pbmVkIGJ5IHRoZSBsb2NhbCBwb2xpY2llcyBvZiB0aGUgcmVj ZWl2ZXIuCgo0LjMuICBJbml0aWFsIFByb2Nlc3NpbmcKCiAgIElmIHRoZSA8ZG9tYWluPiBpcyBt YWxmb3JtZWQgKGxhYmVsIGxvbmdlciB0aGFuIDYzIGNoYXJhY3RlcnMsIHplcm8tCiAgIGxlbmd0 aCBsYWJlbCBub3QgYXQgdGhlIGVuZCwgZXRjLikgb3IgaXMgbm90IGEgZnVsbHkgcXVhbGlmaWVk IGRvbWFpbgogICBuYW1lLCBvciBpZiB0aGUgRE5TIGxvb2t1cCByZXR1cm5zICJkb21haW4gZG9l cyBub3QgZXhpc3QiIChSQ09ERSAzKSwKICAgY2hlY2tfaG9zdCgpIGltbWVkaWF0ZWx5IHJldHVy bnMgdGhlIHJlc3VsdCAibm9uZSIuCgpbTVNLOiBJIHN1Z2dlc3QgPGRvbWFpbj4gYmUgZGVmaW5l ZCBpbiB0ZXJtcyBvZiB3aGF0ZXZlciBhIGxlZ2FsIGRvbWFpbiBuYW1lIGlzIGluIFtSRkM1MzIx XSwgYXMgYW1lbmRlZCBieSBFQUksIGFuZCBmdXJ0aGVyIHJlcXVpcmUgdGhhdCBpdCBiZSBmdWxs eS1xdWFsaWZpZWQuICBJbiB0ZXJtcyBvZiBJMThOLCB3ZSBzaG91bGQganVzdCBkbyB3aGF0IERL SU0gZGlkIHRvIGhhbmRsZSB0aGlzIGNhc2UuXQoKW01TSzogcy9jaGVja19ob3N0KCkvQ2hlY2tI b3N0L10KCiAgIElmIHRoZSA8c2VuZGVyPiBoYXMgbm8gbG9jYWxwYXJ0LCBzdWJzdGl0dXRlIHRo ZSBzdHJpbmcgInBvc3RtYXN0ZXIiCiAgIGZvciB0aGUgbG9jYWxwYXJ0LgoKW01TSzogUkZDNTMy MSBjYWxscyBpdCBhICJsb2NhbC1wYXJ0Ii5dCgoKCktpdHRlcm1hbiAgICAgICAgICAgICAgICBF eHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDE2XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1 bHkgMjAxMgoKCjQuNC4gIFJlY29yZCBMb29rdXAKCiAgIEluIGFjY29yZGFuY2Ugd2l0aCBob3cg dGhlIHJlY29yZHMgYXJlIHB1Ymxpc2hlZCAoc2VlIFNlY3Rpb24gMy4xCiAgIGFib3ZlKSwgYSBE TlMgcXVlcnkgbmVlZHMgdG8gYmUgbWFkZSBmb3IgdGhlIDxkb21haW4+IG5hbWUsIHF1ZXJ5aW5n CiAgIGZvciB0eXBlIFRYVCBvbmx5LgoKICAgSWYgYWxsIEROUyBsb29rdXBzIHRoYXQgYXJlIG1h ZGUgcmV0dXJuIGEgc2VydmVyIGZhaWx1cmUgKFJDT0RFIDIpLAogICBvciBvdGhlciBlcnJvciAo UkNPREUgb3RoZXIgdGhhbiAwIG9yIDMpLCBvciB0aW1lIG91dCwgdGhlbgogICBjaGVja19ob3N0 KCkgZXhpdHMgaW1tZWRpYXRlbHkgd2l0aCB0aGUgcmVzdWx0ICJ0ZW1wZXJyb3IiLgoKW01TSzog cy9jaGVja19ob3N0KCkvQ2hlY2tIb3N0Lywgcy9leGl0cy90ZXJtaW5hdGVzL10KCiAgIEFsdGVy bmF0aXZlbHksIGZvciBhIHNlcnZlciBmYWlsdXJlIChSQ09ERSAyKSByZXN1bHQsIGNoZWNrX2hv c3QoKQoKW01TSzogcy9jaGVja19ob3N0KCkvQ2hlY2tIb3N0L10KCiAgIE1BWSB0cmFjayBmYWls dXJlcyBhbmQgdHJlYXQgbXVsdGlwbGUgZmFpbHVyZXMgd2l0aGluIDI0IGhvdXJzIGZvcgogICB0 aGUgc2FtZSBkb21haW4gYXMgInBlcm1lcnJvciIuCgogICBUaGlzIGFsdGVybmF0aXZlIGlzIGlu dGVuZGVkIHRvIHNob3J0ZW4gdGhlIHF1ZXVlIHRpbWUgb2YgbWVzc2FnZXMKICAgdGhhdCBjYW5u b3QgYmUgYWNjZXB0ZWQsIGJ5IHJldHVybmluZyBhIHBlcm1hbmVudCBuZWdhdGl2ZSBjb21wbGV0 aW9uCiAgIHJlcGx5IGNvZGUgdG8gdGhlIGNsaWVudCwgaW5zdGVhZCBvZiBhIHRyYW5zaWVudCBv bmUuICBTYXZpbmcgcXVlcmllcwogICBpcyBhY2NvbXBsaXNoZWQgYWNjb3JkaW5nIHRvIFtSRkMy MzA4XS4KCltNU0s6IFN1Z2dlc3QgIltSRkMyMzA4XSBzdWdnZXN0cyBvbiBhbiBhbGdvcml0aG0g Zm9yIGRvaW5nIHN1Y2ggdHJhY2tpbmcgYW5kIGhhbmRsaW5nIG9mIHNlcnZlciBmYWlsdXJlIGNv ZGVzLiJdCgo0LjUuICBTZWxlY3RpbmcgUmVjb3JkcwoKICAgUmVjb3JkcyBiZWdpbiB3aXRoIGEg dmVyc2lvbiBzZWN0aW9uOgoKICAgcmVjb3JkICAgICAgICAgICA9IHZlcnNpb24gdGVybXMgKlNQ CiAgIHZlcnNpb24gICAgICAgICAgPSAidj1zcGYxIgoKICAgU3RhcnRpbmcgd2l0aCB0aGUgc2V0 IG9mIHJlY29yZHMgdGhhdCB3ZXJlIHJldHVybmVkIGJ5IHRoZSBsb29rdXAsCiAgIGRpc2NhcmQg cmVjb3JkcyB0aGF0IGRvIG5vdCBiZWdpbiB3aXRoIGEgdmVyc2lvbiBzZWN0aW9uIG9mIGV4YWN0 bHkKICAgInY9c3BmMSIuICBOb3RlIHRoYXQgdGhlIHZlcnNpb24gc2VjdGlvbiBpcyB0ZXJtaW5h dGVkIGVpdGhlciBieSBhbgogICBTUCBjaGFyYWN0ZXIgb3IgdGhlIGVuZCBvZiB0aGUgcmVjb3Jk LiAgQSByZWNvcmQgd2l0aCBhIHZlcnNpb24KICAgc2VjdGlvbiBvZiAidj1zcGYxMCIgZG9lcyBu b3QgbWF0Y2ggYW5kIG11c3QgYmUgZGlzY2FyZGVkLgoKICAgVGhlcmUgc2hvdWxkIGJlIGV4YWN0 bHkgb25lIHJlY29yZCByZW1haW5pbmcgYW5kIGV2YWx1YXRpb24gY2FuCiAgIHByb2NlZWQuICBJ ZiB0aGVyZSBhcmUgdHdvIG9yIG1vcmUgcmVjb3JkcyByZW1haW5pbmcsIHRoZW4KICAgY2hlY2tf aG9zdCgpIGV4aXRzIGltbWVkaWF0ZWx5IHdpdGggdGhlIHJlc3VsdCBvZiAicGVybWVycm9yIi4K CiAgIElmIG5vIG1hdGNoaW5nIHJlY29yZHMgYXJlIHJldHVybmVkLCBhbiBTUEYgY2xpZW50IE1V U1QgYXNzdW1lIHRoYXQKICAgdGhlIGRvbWFpbiBtYWtlcyBubyBTUEYgZGVjbGFyYXRpb25zLiAg U1BGIHByb2Nlc3NpbmcgTVVTVCBzdG9wIGFuZAogICByZXR1cm4gIm5vbmUiLgoKW01TSzogUmVw bGFjZSB0aGUgYWJvdmUgdHdvIHBhcmFncmFwaHMgd2l0aDogIklmIHRoZSByZXN1bHRhbnQgcmVj b3JkIHNldCBpbmNsdWRlcyBubyByZWNvcmRzLCBDaGVja0hvc3QgcHJvZHVjZXMgdGhlICJub25l IiByZXN1bHQuICBJZiB0aGUgcmVzdWx0YW50IHJlY29yZCBzZXQgaW5jbHVkZXMgbW9yZSB0aGFu IG9uZSByZWNvcmQsIENoZWNrSG9zdCBwcm9kdWNlcyB0aGUgInBlcm1lcnJvciIgcmVzdWx0LiJd Cgo0LjYuICBSZWNvcmQgRXZhbHVhdGlvbgoKICAgQWZ0ZXIgb25lIFNQRiByZWNvcmQgaGFzIGJl ZW4gc2VsZWN0ZWQsIHRoZSBjaGVja19ob3N0KCkgZnVuY3Rpb24KCltNU0s6IHMvdGhlIGNoZWNr X2hvc3QoKSBmdW5jdGlvbi9DaGVja0hvc3QvXQoKICAgcGFyc2VzIGFuZCBpbnRlcnByZXRzIGl0 IHRvIGZpbmQgYSByZXN1bHQgZm9yIHRoZSBjdXJyZW50IHRlc3QuICBJZgogICB0aGVyZSBhcmUg YW55IHN5bnRheCBlcnJvcnMsIGNoZWNrX2hvc3QoKSByZXR1cm5zIGltbWVkaWF0ZWx5IHdpdGgK ICAgdGhlIHJlc3VsdCAicGVybWVycm9yIi4KCltNU0s6IHMvY2hlY2tfaG9zdCgpL0NoZWNrSG9z dC9dCgogICBJbXBsZW1lbnRhdGlvbnMgTUFZIGNob29zZSB0byBwYXJzZSB0aGUgZW50aXJlIHJl Y29yZCBmaXJzdCBhbmQKICAgcmV0dXJuICJwZXJtZXJyb3IiIGlmIHRoZSByZWNvcmQgaXMgbm90 IHN5bnRhY3RpY2FsbHkgd2VsbCBmb3JtZWQuCgoKCktpdHRlcm1hbiAgICAgICAgICAgICAgICBF eHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1 bHkgMjAxMgoKCiAgIEhvd2V2ZXIsIGluIGFsbCBjYXNlcywgYW55IHN5bnRheCBlcnJvcnMgYW55 d2hlcmUgaW4gdGhlIHJlY29yZCBNVVNUCiAgIGJlIGRldGVjdGVkLgoKNC42LjEuICBUZXJtIEV2 YWx1YXRpb24KCiAgIFRoZXJlIGFyZSB0d28gdHlwZXMgb2YgdGVybXM6IG1lY2hhbmlzbXMgYW5k IG1vZGlmaWVycy4gIEEgcmVjb3JkCiAgIGNvbnRhaW5zIGFuIG9yZGVyZWQgbGlzdCBvZiB0aGVz ZSBhcyBzcGVjaWZpZWQgaW4gdGhlIGZvbGxvd2luZwogICBBdWdtZW50ZWQgQmFja3VzLU5hdXIg Rm9ybSAoQUJORikuCgogICB0ZXJtcyAgICAgICAgICAgID0gKiggMSpTUCAoIGRpcmVjdGl2ZSAv IG1vZGlmaWVyICkgKQoKICAgZGlyZWN0aXZlICAgICAgICA9IFsgcXVhbGlmaWVyIF0gbWVjaGFu aXNtCiAgIHF1YWxpZmllciAgICAgICAgPSAiKyIgLyAiLSIgLyAiPyIgLyAifiIKICAgbWVjaGFu aXNtICAgICAgICA9ICggYWxsIC8gaW5jbHVkZQogICAgICAgICAgICAgICAgICAgICAgLyBBIC8g TVggLyBQVFIgLyBJUDQgLyBJUDYgLyBleGlzdHMgKQogICBtb2RpZmllciAgICAgICAgID0gcmVk aXJlY3QgLyBleHBsYW5hdGlvbiAvIHVua25vd24tbW9kaWZpZXIKICAgdW5rbm93bi1tb2RpZmll ciA9IG5hbWUgIj0iIG1hY3JvLXN0cmluZwogICAgICAgICAgICAgICAgICAgICAgOyB3aGVyZSBu YW1lIGlzIG5vdCBhbnkga25vd24gbW9kaWZpZXIKCiAgIG5hbWUgICAgICAgICAgICAgPSBBTFBI QSAqKCBBTFBIQSAvIERJR0lUIC8gIi0iIC8gIl8iIC8gIi4iICkKCiAgIE1vc3QgbWVjaGFuaXNt cyBhbGxvdyBhICI6IiBvciAiLyIgY2hhcmFjdGVyIGFmdGVyIHRoZSBuYW1lLgoKICAgTW9kaWZp ZXJzIGFsd2F5cyBjb250YWluIGFuIGVxdWFscyAoJz0nKSBjaGFyYWN0ZXIgaW1tZWRpYXRlbHkg YWZ0ZXIKICAgdGhlIG5hbWUsIGFuZCBiZWZvcmUgYW55ICI6IiBvciAiLyIgY2hhcmFjdGVycyB0 aGF0IG1pZ2h0IGJlIHBhcnQgb2YKICAgdGhlIG1hY3JvLXN0cmluZy4KCiAgIFRlcm1zIHRoYXQg ZG8gbm90IGNvbnRhaW4gYW55IG9mICI9IiwgIjoiLCBvciAiLyIgYXJlIG1lY2hhbmlzbXMsIGFz CiAgIGRlZmluZWQgaW4gU2VjdGlvbiA1LgoKICAgQXMgcGVyIHRoZSBkZWZpbml0aW9uIG9mIHRo ZSBBQk5GIG5vdGF0aW9uIGluIFtSRkM1MjM0XSwgbWVjaGFuaXNtCiAgIGFuZCBtb2RpZmllciBu YW1lcyBhcmUgY2FzZS1pbnNlbnNpdGl2ZS4KCjQuNi4yLiAgTWVjaGFuaXNtcwoKICAgRWFjaCBt ZWNoYW5pc20gaXMgY29uc2lkZXJlZCBpbiB0dXJuIGZyb20gbGVmdCB0byByaWdodC4gIElmIHRo ZXJlCiAgIGFyZSBubyBtb3JlIG1lY2hhbmlzbXMsIHRoZSByZXN1bHQgaXMgc3BlY2lmaWVkIGlu IFNlY3Rpb24gNC43LgoKICAgV2hlbiBhIG1lY2hhbmlzbSBpcyBldmFsdWF0ZWQsIG9uZSBvZiB0 aHJlZSB0aGluZ3MgY2FuIGhhcHBlbjogaXQgY2FuCiAgIG1hdGNoLCBub3QgbWF0Y2gsIG9yIHRo cm93IGFuIGV4Y2VwdGlvbi4KCiAgIElmIGl0IG1hdGNoZXMsIHByb2Nlc3NpbmcgZW5kcyBhbmQg dGhlIHF1YWxpZmllciB2YWx1ZSBpcyByZXR1cm5lZCBhcwogICB0aGUgcmVzdWx0IG9mIHRoYXQg cmVjb3JkLiAgSWYgaXQgZG9lcyBub3QgbWF0Y2gsIHByb2Nlc3NpbmcKICAgY29udGludWVzIHdp dGggdGhlIG5leHQgbWVjaGFuaXNtLiAgSWYgaXQgdGhyb3dzIGFuIGV4Y2VwdGlvbiwKICAgbWVj aGFuaXNtIHByb2Nlc3NpbmcgZW5kcyBhbmQgdGhlIGV4Y2VwdGlvbiB2YWx1ZSBpcyByZXR1cm5l ZC4KCiAgIFRoZSBwb3NzaWJsZSBxdWFsaWZpZXJzLCBhbmQgdGhlIHJlc3VsdHMgdGhleSByZXR1 cm4gYXJlIGFzIGZvbGxvd3M6CgpbTVNLOiAiYW5kIHRoZSByZXN1bHRzIHRoZXkgY2F1c2UgQ2hl Y2tIb3N0IHRvIHJldHVybiBhcmUgYXMgZm9sbG93czoiXQoKCgpLaXR0ZXJtYW4gICAgICAgICAg ICAgICAgRXhwaXJlcyBKYW51YXJ5IDYsIDIwMTMgICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgU2VuZGVyIFBvbGljeSBGcmFtZXdvcmsgKFNQRikgICAgICAg ICAgICBKdWx5IDIwMTIKCgogICAgICAiKyIgcGFzcwogICAgICAiLSIgZmFpbAogICAgICAifiIg c29mdGZhaWwKICAgICAgIj8iIG5ldXRyYWwKCiAgIFRoZSBxdWFsaWZpZXIgaXMgb3B0aW9uYWwg YW5kIGRlZmF1bHRzIHRvICIrIi4KCiAgIFdoZW4gYSBtZWNoYW5pc20gbWF0Y2hlcyBhbmQgdGhl IHF1YWxpZmllciBpcyAiLSIsIHRoZW4gYSAiZmFpbCIKICAgcmVzdWx0IGlzIHJldHVybmVkIGFu ZCB0aGUgZXhwbGFuYXRpb24gc3RyaW5nIGlzIGNvbXB1dGVkIGFzCiAgIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDYuMi4KCiAgIFRoZSBzcGVjaWZpYyBtZWNoYW5pc21zIGFyZSBkZXNjcmliZWQgaW4g U2VjdGlvbiA1LgoKNC42LjMuICBNb2RpZmllcnMKCiAgIE1vZGlmaWVycyBhcmUgbm90IG1lY2hh bmlzbXM6IHRoZXkgZG8gbm90IHJldHVybiBtYXRjaCBvciBub3QtbWF0Y2guCgpbTVNLOiBzLzov Oy8sIG9yIHMvdGhleS9UaGV5L10KCiAgIEluc3RlYWQgdGhleSBwcm92aWRlIGFkZGl0aW9uYWwg aW5mb3JtYXRpb24uICBBbHRob3VnaCBtb2RpZmllcnMgZG8KCltNU0s6IEFkZCBhIGNvbW1hIGFm dGVyICJJbnN0ZWFkIl0KCiAgIG5vdCBkaXJlY3RseSBhZmZlY3QgdGhlIGV2YWx1YXRpb24gb2Yg dGhlIHJlY29yZCwgdGhlICJyZWRpcmVjdCIKICAgbW9kaWZpZXIgaGFzIGFuIGVmZmVjdCBhZnRl ciBhbGwgdGhlIG1lY2hhbmlzbXMgaGF2ZSBiZWVuIGV2YWx1YXRlZC4KCjQuNi40LiAgRXZhbHVh dGlvbiBMaW1pdHMKCiAgIFNQRiBpbXBsZW1lbnRhdGlvbnMgTVVTVCBsaW1pdCB0aGUgbnVtYmVy IG9mIG1lY2hhbmlzbXMgYW5kIG1vZGlmaWVycwogICAoInRlcm1zIikgdGhhdCBkbyBETlMgbG9v a3VwcyB0byBhdCBtb3N0IDEwIHBlciBkdXJpbmcgU1BGIHJlY29yZAoKW01TSzogZGVsZXRlICJw ZXIiXQoKICAgZXZhbHVhdGlvbi4gIFNwZWNpZmljYWxseSwgdGhlICJpbmNsdWRlIiwgImEiLCAi bXgiLCAicHRyIiwgYW5kCiAgICJleGlzdHMiIG1lY2hhbmlzbXMgYXMgd2VsbCBhcyB0aGUgInJl ZGlyZWN0IiBtb2RpZmllciBjb3VudCBhZ2FpbnN0CiAgIHRoaXMgbGltaXQuICBUaGUgImFsbCIs ICJpcDQiLCBhbmQgImlwNiIgbWVjaGFuaXNtcyBkbyBub3QgY291bnQKICAgYWdhaW5zdCB0aGlz IGxpbWl0LiAgSWYgdGhpcyBudW1iZXIgaXMgZXhjZWVkZWQgZHVyaW5nIGEgY2hlY2ssIGEKICAg cGVybWVycm9yIE1VU1QgYmUgcmV0dXJuZWQuICBUaGUgImV4cCIgbW9kaWZpZXIgZG9lcyBub3Qg Y291bnQKICAgYWdhaW5zdCB0aGlzIGxpbWl0IGJlY2F1c2UgdGhlIEROUyBsb29rdXAgdG8gZmV0 Y2ggdGhlIGV4cGxhbmF0aW9uCiAgIHN0cmluZyBvY2N1cnMgYWZ0ZXIgdGhlIFNQRiByZWNvcmQg ZXZhbHVhdGF0aW9uIGhhcyBiZWVuIGNvbXBsZXRlZC4KCltNU0s6IHMvZXZhbHVhdGF0aW9uL2V2 YWx1YXRpb24vXQoKCiAgIFdoZW4gZXZhbHVhdGluZyB0aGUgIm14IiBhbmQgInB0ciIgbWVjaGFu aXNtcywgb3IgdGhlICV7cH0gbWFjcm8sCiAgIHRoZXJlIE1VU1QgYmUgYSBsaW1pdCBvZiBubyBt b3JlIHRoYW4gMTAgTVggb3IgUFRSIFJScyBsb29rZWQgdXAgYW5kCiAgIGNoZWNrZWQuICBJZiBt b3JlIHRoYW4gMTAgIm14IiBvciAicHRyIiByZWNvcmRzIGFyZSByZXR1cm5lZCBmb3IgdGhpcwog ICBmdXJ0aGVyIGxvb2t1cCwgYSBwZXJtZXJyb3IgTVVTVCBiZSByZXR1cm5lZC4gIFRoaXMgbGlt aXQgaXMgcGVyCiAgIG1lY2hhbmlzbSBvciBtYWNybyBpbiB0aGUgcmVjb3JkIGFuZCBpbiBhZGRp dGlvbiB0byB0aGUgbG9va3VwIGxpbWl0cwogICBhYm92ZS4KCltNU0s6IFNvIHRoaXMgaXMgd2hl cmUgdGhlIGNvbmNlcm4gYWJvdXQgMTEwIHF1ZXJpZXMgY29tZXMgZnJvbS4gIFRoZSBtaW51dGVz IGZyb20gdGhlIFBhcmlzIG1lZXRpbmcgc2F5IHdlIHdvdWxkIGFzayB0aGUgRE5TIERpcmVjdG9y YXRlIGZvciBndWlkYW5jZSBoZXJlIGFzIHRvIHdoZXRoZXIgd2Ugc2hvdWxkIGJlIGNvbmNlcm5l ZCBhYm91dCBpdC4gIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIGhhcHBlbmVkIHlldC4gIFNvbWVvbmUg c2hvdWxkIHB1dCB0aGF0IHF1ZXN0aW9uIHRvZ2V0aGVyIGFuZCBzZW5kIGl0IG92ZXIgdG8gdGhl bSBBU0FQLl0KCgo0LjcuICBEZWZhdWx0IFJlc3VsdAoKICAgSWYgbm9uZSBvZiB0aGUgbWVjaGFu aXNtcyBtYXRjaCBhbmQgdGhlcmUgaXMgbm8gInJlZGlyZWN0IiBtb2RpZmllciwKICAgdGhlbiB0 aGUgY2hlY2tfaG9zdCgpIHJldHVybnMgYSByZXN1bHQgb2YgIm5ldXRyYWwiLCBqdXN0IGFzIGlm CgpbTVNLOiBzL3RoZSBjaGVja19ob3N0KCkvQ2hlY2tIb3N0L10KCiAgICI/YWxsIiB3ZXJlIHNw ZWNpZmllZCBhcyB0aGUgbGFzdCBkaXJlY3RpdmUuICBJZiB0aGVyZSBpcyBhCiAgICJyZWRpcmVj dCIgbW9kaWZpZXIsIGNoZWNrX2hvc3QoKSBwcm9jZWVkcyBhcyBkZWZpbmVkIGluIFNlY3Rpb24g Ni4xLgoKW01TSzogcy9jaGVja19ob3N0KCkvQ2hlY2tIb3N0L10KCiAgIE5vdGUgdGhhdCByZWNv cmRzIFNIT1VMRCBhbHdheXMgdXNlIGVpdGhlciBhICJyZWRpcmVjdCIgbW9kaWZpZXIgb3IKICAg YW4gImFsbCIgbWVjaGFuaXNtIHRvIGV4cGxpY2l0bHkgdGVybWluYXRlIHByb2Nlc3NpbmcuCgpb TVNLOiBTbyB0aGVyZSdzIGEgZGVmYXVsdCwgYnV0IHBlb3BsZSBTSE9VTEQgTk9UIHJlbHkgb24g aXQ/ICBUaGF0IHNlZW1zIGF3a3dhcmQuXQoKCktpdHRlcm1hbiAgICAgICAgICAgICAgICBFeHBp cmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDE5XQoMCkludGVybmV0LURy YWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1bHkg MjAxMgoKCiAgIEZvciBleGFtcGxlOgoKICAgICAgdj1zcGYxICtteCAtYWxsCiAgIG9yCiAgICAg IHY9c3BmMSArbXggcmVkaXJlY3Q9X3NwZi5leGFtcGxlLmNvbQoKNC44LiAgRG9tYWluIFNwZWNp ZmljYXRpb24KCiAgIFNldmVyYWwgb2YgdGhlc2UgbWVjaGFuaXNtcyBhbmQgbW9kaWZpZXJzIGhh dmUgYSBkb21haW4tc3BlYyBzZWN0aW9uLgogICBUaGUgZG9tYWluLXNwZWMgc3RyaW5nIGlzIG1h Y3JvIGV4cGFuZGVkIChzZWUgU2VjdGlvbiA4KS4gIFRoZQoKW01TSzogcy9tYWNybyBleHBhbmRl ZC9hbiBleHBhbmRlZCBtYWNyby9dCgogICByZXN1bHRpbmcgc3RyaW5nIGlzIHRoZSBjb21tb24g cHJlc2VudGF0aW9uIGZvcm0gb2YgYSBmdWxseS1xdWFsaWZpZWQKICAgRE5TIG5hbWU6IGEgc2Vy aWVzIG9mIGxhYmVscyBzZXBhcmF0ZWQgYnkgcGVyaW9kcy4gIFRoaXMgZG9tYWluIGlzCiAgIGNh bGxlZCB0aGUgPHRhcmdldC1uYW1lPiBpbiB0aGUgcmVzdCBvZiB0aGlzIGRvY3VtZW50LgoKICAg Tm90ZTogVGhlIHJlc3VsdCBvZiB0aGUgbWFjcm8gZXhwYW5zaW9uIGlzIG5vdCBzdWJqZWN0IHRv IGFueSBmdXJ0aGVyCiAgIGVzY2FwaW5nLiAgSGVuY2UsIHRoaXMgZmFjaWxpdHkgY2Fubm90IHBy b2R1Y2UgYWxsIGNoYXJhY3RlcnMgdGhhdAogICBhcmUgbGVnYWwgaW4gYSBETlMgbGFiZWwgKGUu Zy4sIHRoZSBjb250cm9sIGNoYXJhY3RlcnMpLiAgSG93ZXZlciwKICAgdGhpcyBmYWNpbGl0eSBp cyBwb3dlcmZ1bCBlbm91Z2ggdG8gZXhwcmVzcyBsZWdhbCBob3N0IG5hbWVzIGFuZAogICBjb21t b24gdXRpbGl0eSBsYWJlbHMgKHN1Y2ggYXMgIl9zcGYiKSB0aGF0IGFyZSB1c2VkIGluIEROUy4K CiAgIEZvciBzZXZlcmFsIG1lY2hhbmlzbXMsIHRoZSA8ZG9tYWluLXNwZWM+IGlzIG9wdGlvbmFs LiAgSWYgaXQgaXMgbm90CiAgIHByb3ZpZGVkLCB0aGUgPGRvbWFpbj4gaXMgdXNlZCBhcyB0aGUg PHRhcmdldC1uYW1lPi4KCltNU0s6IEhvdyBhcmUgPGRvbWFpbi1zcGVjPiBhbmQgPGRvbWFpbj4g ZGlmZmVyZW50PyAgRG8gd2UgbmVlZCB0aGVtIGJvdGg/XQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCktpdHRlcm1hbiAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAg ICAgICAgICAgICAgIFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9s aWN5IEZyYW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1bHkgMjAxMgoKCjUuICBNZWNoYW5pc20g RGVmaW5pdGlvbnMKCiAgIFRoaXMgc2VjdGlvbiBkZWZpbmVzIHR3byB0eXBlcyBvZiBtZWNoYW5p c21zLgoKICAgQmFzaWMgbWVjaGFuaXNtcyBjb250cmlidXRlIHRvIHRoZSBsYW5ndWFnZSBmcmFt ZXdvcmsuICBUaGV5IGRvIG5vdAogICBzcGVjaWZ5IGEgcGFydGljdWxhciB0eXBlIG9mIGF1dGhv cml6YXRpb24gc2NoZW1lLgoKICAgICAgYWxsCiAgICAgIGluY2x1ZGUKCiAgIERlc2lnbmF0ZWQg c2VuZGVyIG1lY2hhbmlzbXMgYXJlIHVzZWQgdG8gZGVzaWduYXRlIGEgc2V0IG9mIDxpcD4KICAg YWRkcmVzc2VzIGFzIGJlaW5nIHBlcm1pdHRlZCBvciBub3QgcGVybWl0dGVkIHRvIHVzZSB0aGUg PGRvbWFpbj4gZm9yCiAgIHNlbmRpbmcgbWFpbC4KCiAgICAgIGEKICAgICAgbXgKICAgICAgcHRy IChkZXByZWNhdGVkKQogICAgICBpcDQKICAgICAgaXA2CiAgICAgIGV4aXN0cwoKICAgVGhlIGZv bGxvd2luZyBjb252ZW50aW9ucyBhcHBseSB0byBhbGwgbWVjaGFuaXNtcyB0aGF0IHBlcmZvcm0g YQogICBjb21wYXJpc29uIGJldHdlZW4gPGlwPiBhbmQgYW4gSVAgYWRkcmVzcyBhdCBhbnkgcG9p bnQ6CgogICBJZiBubyBDSURSLWxlbmd0aCBpcyBnaXZlbiBpbiB0aGUgZGlyZWN0aXZlLCB0aGVu IDxpcD4gYW5kIHRoZSBJUAogICBhZGRyZXNzIGFyZSBjb21wYXJlZCBmb3IgZXF1YWxpdHkuICAo SGVyZSwgQ0lEUiBpcyBDbGFzc2xlc3MgSW50ZXItCiAgIERvbWFpbiBSb3V0aW5nLikKCltNU0s6 IFByb3ZpZGUgYSByZWZlcmVuY2UgdG8gdGhlIGRlZmluaXRpb24gb2YgQ0lEUiwgYW5kIG1ha2Ug c3VyZSAiQ0lEUi1sZW5ndGgiIGlzIGRlZmluZWQgdGhlcmUgb3IgdXNlIHRoZSB0ZXJtIHRoYXQg ZG9jdW1lbnQgdXNlcy5dCgogICBJZiBhIENJRFItbGVuZ3RoIGlzIHNwZWNpZmllZCwgdGhlbiBv bmx5IHRoZSBzcGVjaWZpZWQgbnVtYmVyIG9mCiAgIGhpZ2gtb3JkZXIgYml0cyBvZiA8aXA+IGFu ZCB0aGUgSVAgYWRkcmVzcyBhcmUgY29tcGFyZWQgZm9yIGVxdWFsaXR5LgoKW01TSzogRG8gd2Ug bmVlZCB0byBtZW50aW9uIG5ldHdvcmsgYnl0ZSBvcmRlcj8gIFByb2JhYmx5IG5vdCwganVzdCBh c2tpbmcuXQoKICAgV2hlbiBhbnkgbWVjaGFuaXNtIGZldGNoZXMgaG9zdCBhZGRyZXNzZXMgdG8g Y29tcGFyZSB3aXRoIDxpcD4sIHdoZW4KICAgPGlwPiBpcyBhbiBJUHY0IGFkZHJlc3MsIEEgcmVj b3JkcyBhcmUgZmV0Y2hlZCwgd2hlbiA8aXA+IGlzIGFuIElQdjYKCltNU0s6IE1ha2UgdGhlIHNl Y29uZCBjb21tYSBpbnRvIGEgc2VtaS1jb2xvbi5dCgogICBhZGRyZXNzLCBBQUFBIHJlY29yZHMg YXJlIGZldGNoZWQuICBFdmVuIGlmIHRoZSBTTVRQIGNvbm5lY3Rpb24gaXMKICAgdmlhIElQdjYs IGFuIElQdjQtbWFwcGVkIElQdjYgSVAgYWRkcmVzcyAoc2VlIFtSRkM0MjkxXSwgU2VjdGlvbgoK W01TSzogcy9pcyB2aWEvdXNlcy9dCgogICAyLjUuNSkgTVVTVCBzdGlsbCBiZSBjb25zaWRlcmVk IGFuIElQdjQgYWRkcmVzcyBhbmQgTVVTVCBiZSBldmFsdWF0ZWQKICAgdXNpbmcgSVB2NCBtZWNo YW5pc21zIChpLmUuICJpcDQiIGFuZCAiYSIpLgoKICAgU2V2ZXJhbCBtZWNoYW5pc21zIHJlbHkg b24gaW5mb3JtYXRpb24gZmV0Y2hlZCBmcm9tIEROUy4gIEZvciB0aGVzZQoKW01TSzogcy9ETlMv dGhlIEROUy9dCgogICBETlMgcXVlcmllcywgZXhjZXB0IHdoZXJlIG5vdGVkLCBpZiB0aGUgRE5T IHNlcnZlciByZXR1cm5zIGFuIGVycm9yCiAgIChSQ09ERSBvdGhlciB0aGFuIDAgb3IgMykgb3Ig dGhlIHF1ZXJ5IHRpbWVzIG91dCwgdGhlIG1lY2hhbmlzbQogICB0aHJvd3MgdGhlIGV4Y2VwdGlv biAidGVtcGVycm9yIi4gIElmIHRoZSBzZXJ2ZXIgcmV0dXJucyAiZG9tYWluIGRvZXMKICAgbm90 IGV4aXN0IiAoUkNPREUgMyksIHRoZW4gZXZhbHVhdGlvbiBvZiB0aGUgbWVjaGFuaXNtIGNvbnRp bnVlcyBhcwogICBpZiB0aGUgc2VydmVyIHJldHVybmVkIG5vIGVycm9yIChSQ09ERSAwKSBhbmQg emVybyBhbnN3ZXIgcmVjb3Jkcy4KCjUuMS4gICJhbGwiCgogICBhbGwgICAgICAgICAgICAgID0g ImFsbCIKCgoKS2l0dGVybWFuICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEz ICAgICAgICAgICAgICAgW1BhZ2UgMjFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQ b2xpY3kgRnJhbWV3b3JrIChTUEYpICAgICAgICAgICAgSnVseSAyMDEyCgoKICAgVGhlICJhbGwi IG1lY2hhbmlzbSBpcyBhIHRlc3QgdGhhdCBhbHdheXMgbWF0Y2hlcy4gIEl0IGlzIHVzZWQgYXMg dGhlCiAgIHJpZ2h0bW9zdCBtZWNoYW5pc20gaW4gYSByZWNvcmQgdG8gcHJvdmlkZSBhbiBleHBs aWNpdCBkZWZhdWx0LgoKICAgRm9yIGV4YW1wbGU6CgogICAgICB2PXNwZjEgYSBteCAtYWxsCgog ICBNZWNoYW5pc21zIGFmdGVyICJhbGwiIHdpbGwgbmV2ZXIgYmUgdGVzdGVkLiAgQW55ICJyZWRp cmVjdCIgbW9kaWZpZXIKICAgKFNlY3Rpb24gNi4xKSBoYXMgbm8gZWZmZWN0IHdoZW4gdGhlcmUg aXMgYW4gImFsbCIgbWVjaGFuaXNtLgoKW01TSzogVW5sZXNzIGl0IGFwcGVhcnMgYmVmb3JlICJh bGwiLCByaWdodD9dCgo1LjIuICAiaW5jbHVkZSIKCiAgIGluY2x1ZGUgICAgICAgICAgPSAiaW5j bHVkZSIgICI6IiBkb21haW4tc3BlYwoKICAgVGhlICJpbmNsdWRlIiBtZWNoYW5pc20gdHJpZ2dl cnMgYSByZWN1cnNpdmUgZXZhbHVhdGlvbiBvZgogICBjaGVja19ob3N0KCkuICBUaGUgZG9tYWlu LXNwZWMgaXMgZXhwYW5kZWQgYXMgcGVyIFNlY3Rpb24gOC4gIFRoZW4KICAgY2hlY2tfaG9zdCgp IGlzIGV2YWx1YXRlZCB3aXRoIHRoZSByZXN1bHRpbmcgc3RyaW5nIGFzIHRoZSA8ZG9tYWluPi4K ICAgVGhlIDxpcD4gYW5kIDxzZW5kZXI+IGFyZ3VtZW50cyByZW1haW4gdGhlIHNhbWUgYXMgaW4g dGhlIGN1cnJlbnQKICAgZXZhbHVhdGlvbiBvZiBjaGVja19ob3N0KCkuCgpbTVNLOiByZXBsYWNl IHdpdGg6CgpUaGUgImluY2x1ZGUiIG1lY2hhbmlzbSB0cmlnZ2VycyBhIHJlY3Vyc2l2ZSBldmFs dWF0aW9uIG9mIENoZWNrSG9zdC4gIFNwZWNpZmljYWxseToKCjEuIFRoZSBkb21haW4tc3BlYyBp cyBleHBhbmRlZCBhcyBwZXIgU2VjdGlvbiA4LgoKMi4gQ2hlY2tIb3N0IGlzIHJlLXN0YXJ0ZWQs IHdpdGggdGhlIG91dHB1dCBvZiB0aGUgcHJldmlvdXMgc3RlcCByZXBsYWNpbmcgdGhlIHZhbHVl IG9mIDxkb21haW4+IGluIHRoYXQgY29udGV4dCwgYW5kIG90aGVyIGlucHV0cyB0byBDaGVja0hv c3QgdW5jaGFuZ2VkLgoKMy4gVGhlIHBhcmVudCBDaGVja0hvc3QgcmVzdW1lcyBwcm9jZXNzaW5n IGFzIHBlciB0aGUgdGFibGUgYmVsb3csIHdpdGggdGhlIHByZXZpb3VzIHZhbHVlIG9mIDxkb21h aW4+IHJlc3RvcmVkLgpdCgogICBJbiBoaW5kc2lnaHQsIHRoZSBuYW1lICJpbmNsdWRlIiB3YXMg cG9vcmx5IGNob3Nlbi4gIE9ubHkgdGhlCiAgIGV2YWx1YXRlZCByZXN1bHQgb2YgdGhlIHJlZmVy ZW5jZWQgU1BGIHJlY29yZCBpcyB1c2VkLCByYXRoZXIgdGhhbgogICBhY3RpbmcgYXMgaWYgdGhl IHJlZmVyZW5jZWQgU1BGIHJlY29yZCB3YXMgbGl0ZXJhbGx5IGluY2x1ZGVkIGluIHRoZQogICBm aXJzdC4gIEZvciBleGFtcGxlLCBldmFsdWF0aW5nIGEgIi1hbGwiIGRpcmVjdGl2ZSBpbiB0aGUg cmVmZXJlbmNlZAogICByZWNvcmQgZG9lcyBub3QgdGVybWluYXRlIHRoZSBvdmVyYWxsIHByb2Nl c3NpbmcgYW5kIGRvZXMgbm90CiAgIG5lY2Vzc2FyaWx5IHJlc3VsdCBpbiBhbiBvdmVyYWxsICJm YWlsIi4gIChCZXR0ZXIgbmFtZXMgZm9yIHRoaXMKICAgbWVjaGFuaXNtIHdvdWxkIGhhdmUgYmVl biAiaWYtcGFzcyIsICJvbi1wYXNzIiwgZXRjLikKCltNU0s6IEludGVyZXN0aW5nLiAgU2hvdWxk IHdlIG1ha2UgYSBuZXcgbmFtZSBmb3IgaXQsIHN5bm9ueW1vdXMgd2l0aCAiaW5jbHVkZSIsIHRv IGZhY2lsaXRhdGUgaW50cm9kdWN0aW9uIG9mIGEgbmV3IG5hbWUgaW4gYSBmdXR1cmUgdmVyc2lv bj9dCgogICBUaGUgImluY2x1ZGUiIG1lY2hhbmlzbSBtYWtlcyBpdCBwb3NzaWJsZSBmb3Igb25l IGRvbWFpbiB0byBkZXNpZ25hdGUKICAgbXVsdGlwbGUgYWRtaW5pc3RyYXRpdmVseS1pbmRlcGVu ZGVudCBkb21haW5zLiAgRm9yIGV4YW1wbGUsIGEgdmFuaXR5CiAgIGRvbWFpbiAiZXhhbXBsZS5u ZXQiIG1pZ2h0IHNlbmQgbWFpbCB1c2luZyB0aGUgc2VydmVycyBvZgogICBhZG1pbmlzdHJhdGl2 ZWx5LWluZGVwZW5kZW50IGRvbWFpbnMgZXhhbXBsZS5jb20gYW5kIGV4YW1wbGUub3JnLgoKICAg RXhhbXBsZS5uZXQgY291bGQgc2F5CgogICAgICBJTiBUWFQgInY9c3BmMSBpbmNsdWRlOmV4YW1w bGUuY29tIGluY2x1ZGU6ZXhhbXBsZS5vcmcgLWFsbCIKCiAgIFRoaXMgd291bGQgZGlyZWN0IGNo ZWNrX2hvc3QoKSB0bywgaW4gZWZmZWN0LCBjaGVjayB0aGUgcmVjb3JkcyBvZgoKW01TSzogcy9j aGVja19ob3N0KCkvQ2hlY2tIb3N0L10KCiAgIGV4YW1wbGUuY29tIGFuZCBleGFtcGxlLm9yZyBm b3IgYSAicGFzcyIgcmVzdWx0LiAgT25seSBpZiB0aGUgaG9zdAogICB3ZXJlIG5vdCBwZXJtaXR0 ZWQgZm9yIGVpdGhlciBvZiB0aG9zZSBkb21haW5zIHdvdWxkIHRoZSByZXN1bHQgYmUKICAgImZh aWwiLgoKICAgV2hldGhlciB0aGlzIG1lY2hhbmlzbSBtYXRjaGVzLCBkb2VzIG5vdCBtYXRjaCwg b3IgdGhyb3dzIGFuCiAgIGV4Y2VwdGlvbiBkZXBlbmRzIG9uIHRoZSByZXN1bHQgb2YgdGhlIHJl Y3Vyc2l2ZSBldmFsdWF0aW9uIG9mCiAgIGNoZWNrX2hvc3QoKToKCltNU0s6IHMvZXZhbHVhdGlv biBvZiBjaGVja19ob3N0KCkvQ2hlY2tIb3N0IGluc3RhbmNlL10KCgoKCgoKCktpdHRlcm1hbiAg ICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdl IDIyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BG KSAgICAgICAgICAgIEp1bHkgMjAxMgoKCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8IEEgcmVjdXJzaXZl IGNoZWNrX2hvc3QoKSByZXN1bHQgfCBDYXVzZXMgdGhlICJpbmNsdWRlIiBtZWNoYW5pc20gIHwK CltNU0s6IHMvY2hlY2tfaG9zdCgpL0NoZWNrSG9zdC9dCgogICB8IG9mOiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCB0bzogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rCiAgIHwgcGFzcyAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IG1hdGNoICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCBmYWlsICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgbm90IG1hdGNoICAgICAgICAgICAgICAgICAgICAgICB8 CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICB8IHNvZnRmYWlsICAgICAgICAgICAgICAgICAgICAgICAgfCBu b3QgbWF0Y2ggICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgbmV1 dHJhbCAgICAgICAgICAgICAgICAgICAgICAgICB8IG5vdCBtYXRjaCAgICAgICAgICAgICAgICAg ICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgfCB0ZW1wZXJyb3IgICAgICAgICAgICAgICAgICAg ICAgIHwgdGhyb3cgdGVtcGVycm9yICAgICAgICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICB8IHBlcm1lcnJvciAgICAgICAgICAgICAgICAgICAgICAgfCB0aHJvdyBwZXJtZXJyb3IgICAg ICAgICAgICAgICAgIHwKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgIHwgbm9uZSAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IHRocm93IHBlcm1lcnJvciAgICAgICAgICAgICAgICAgfAogICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsKCiAgIFRoZSAiaW5jbHVkZSIgbWVjaGFuaXNtIGlzIGludGVuZGVkIGZvciBjcm9zc2lu ZyBhZG1pbmlzdHJhdGl2ZQogICBib3VuZGFyaWVzLiAgQWx0aG91Z2ggaXQgaXMgcG9zc2libGUg dG8gdXNlIGluY2x1ZGVzIHRvIGNvbnNvbGlkYXRlCiAgIG11bHRpcGxlIGRvbWFpbnMgdGhhdCBz aGFyZSB0aGUgc2FtZSBzZXQgb2YgZGVzaWduYXRlZCBob3N0cywgZG9tYWlucwogICBhcmUgZW5j b3VyYWdlZCB0byB1c2UgcmVkaXJlY3RzIHdoZXJlIHBvc3NpYmxlLCBhbmQgdG8gbWluaW1pemUg dGhlCiAgIG51bWJlciBvZiBpbmNsdWRlcyB3aXRoaW4gYSBzaW5nbGUgYWRtaW5pc3RyYXRpdmUg ZG9tYWluLiAgRm9yCiAgIGV4YW1wbGUsIGlmIGV4YW1wbGUuY29tIGFuZCBleGFtcGxlLm9yZyB3 ZXJlIG1hbmFnZWQgYnkgdGhlIHNhbWUKICAgZW50aXR5LCBhbmQgaWYgdGhlIHBlcm1pdHRlZCBz ZXQgb2YgaG9zdHMgZm9yIGJvdGggZG9tYWlucyB3YXMKICAgIm14OmV4YW1wbGUuY29tIiwgaXQg d291bGQgYmUgcG9zc2libGUgZm9yIGV4YW1wbGUub3JnIHRvIHNwZWNpZnkKICAgImluY2x1ZGU6 ZXhhbXBsZS5jb20iLCBidXQgaXQgd291bGQgYmUgcHJlZmVyYWJsZSB0byBzcGVjaWZ5CiAgICJy ZWRpcmVjdD1leGFtcGxlLmNvbSIgb3IgZXZlbiAibXg6ZXhhbXBsZS5jb20iLgoKW01TSzogSSBn ZXQgdGhhdCBpdCdzIHByZWZlcmFibGUsIGJ1dCBJIGRvbid0IHNlZSB3aHkuICBXaGF0IGRpZmZl cmVuY2UgZG9lcyBpdCBtYWtlP10KCjUuMy4gICJhIgoKICAgVGhpcyBtZWNoYW5pc20gbWF0Y2hl cyBpZiA8aXA+IGlzIG9uZSBvZiB0aGUgPHRhcmdldC1uYW1lPidzIElQCiAgIGFkZHJlc3Nlcy4K CiAgIEEgICAgICAgICAgICAgICAgPSAiYSIgICAgICBbICI6IiBkb21haW4tc3BlYyBdIFsgZHVh bC1jaWRyLWxlbmd0aCBdCgogICBBbiBhZGRyZXNzIGxvb2t1cCBpcyBkb25lIG9uIHRoZSA8dGFy Z2V0LW5hbWU+LiAgVGhlIDxpcD4gaXMgY29tcGFyZWQKICAgdG8gdGhlIHJldHVybmVkIGFkZHJl c3MoZXMpLiAgSWYgYW55IGFkZHJlc3MgbWF0Y2hlcywgdGhlIG1lY2hhbmlzbQogICBtYXRjaGVz LgoKNS40LiAgIm14IgoKICAgVGhpcyBtZWNoYW5pc20gbWF0Y2hlcyBpZiA8aXA+IGlzIG9uZSBv ZiB0aGUgTVggaG9zdHMgZm9yIGEgZG9tYWluCiAgIG5hbWUuCgogICBNWCAgICAgICAgICAgICAg ID0gIm14IiAgICAgWyAiOiIgZG9tYWluLXNwZWMgXSBbIGR1YWwtY2lkci1sZW5ndGggXQoKCgoK S2l0dGVybWFuICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAg ICAgICAgW1BhZ2UgMjNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJh bWV3b3JrIChTUEYpICAgICAgICAgICAgSnVseSAyMDEyCgoKICAgY2hlY2tfaG9zdCgpIGZpcnN0 IHBlcmZvcm1zIGFuIE1YIGxvb2t1cCBvbiB0aGUgPHRhcmdldC1uYW1lPi4gIFRoZW4KCltNU0s6 IHMvY2hlY2tfaG9zdCgpL0NoZWNrSG9zdC9dCgogICBpdCBwZXJmb3JtcyBhbiBhZGRyZXNzIGxv b2t1cCBvbiBlYWNoIE1YIG5hbWUgcmV0dXJuZWQuICBUaGUgPGlwPiBpcwogICBjb21wYXJlZCB0 byBlYWNoIHJldHVybmVkIElQIGFkZHJlc3MuICBUbyBwcmV2ZW50IERlbmlhbCBvZiBTZXJ2aWNl CiAgIChEb1MpIGF0dGFja3MsIG1vcmUgdGhhbiAxMCBNWCBuYW1lcyBNVVNUIE5PVCBiZSBsb29r ZWQgdXAgZHVyaW5nIHRoZQogICBldmFsdWF0aW9uIG9mIGFuICJteCIgbWVjaGFuaXNtIChzZWUg U2VjdGlvbiAxMCkuICBJZiBhbnkgYWRkcmVzcwogICBtYXRjaGVzLCB0aGUgbWVjaGFuaXNtIG1h dGNoZXMuCgogICBOb3RlIHJlZ2FyZGluZyBpbXBsaWNpdCBNWHM6IElmIHRoZSA8dGFyZ2V0LW5h bWU+IGhhcyBubyBNWCByZWNvcmRzLAogICBjaGVja19ob3N0KCkgTVVTVCBOT1QgcHJldGVuZCB0 aGUgdGFyZ2V0IGlzIGl0cyBzaW5nbGUgTVgsIGFuZCBNVVNUCgpbTVNLOiBzL2NoZWNrX2hvc3Qo KS9DaGVja0hvc3QvXQoKICAgTk9UIGRlZmF1bHQgdG8gYW4gQSBvciBBQUFBIGxvb2t1cCBvbiB0 aGUgPHRhcmdldC1uYW1lPiBkaXJlY3RseS4KICAgVGhpcyBiZWhhdmlvciBicmVha3Mgd2l0aCB0 aGUgbGVnYWN5ICJpbXBsaWNpdCBNWCIgcnVsZS4gIFNlZQogICBbUkZDNTMyMV0sIFNlY3Rpb24g NS4gIElmIHN1Y2ggYmVoYXZpb3IgaXMgZGVzaXJlZCwgdGhlIHB1Ymxpc2hlcgogICBzaG91bGQg c3BlY2lmeSBhbiAiYSIgZGlyZWN0aXZlLgoKW01TSzogVGhlICJTZWXigKYiIHNlbnRlbmNlIHNo b3VsZCBiZSBpbiBwYXJlbnRoZXNlcy5dCgo1LjUuICAicHRyIiAoZGVwcmVjYXRlZCkKCltNU0s6 IFdvdWxkbid0IGl0IGJlIGVhc2llciB0byBkcm9wIHRoaXMgc2VjdGlvbj9dCgogICBUaGlzIG1l Y2hhbmlzbSB0ZXN0cyB3aGV0aGVyIHRoZSBETlMgcmV2ZXJzZS1tYXBwaW5nIGZvciA8aXA+IGV4 aXN0cwogICBhbmQgY29ycmVjdGx5IHBvaW50cyB0byBhIGRvbWFpbiBuYW1lIHdpdGhpbiBhIHBh cnRpY3VsYXIgZG9tYWluLgogICBUaGlzIG1lY2hhbmlzbSBpcyBkZXByZWNhdGVkIGFuZCBTSE9V TEQgTk9UIGJlIHVzZWQuCgogICBQVFIgICAgICAgICAgICAgID0gInB0ciIgICAgWyAiOiIgZG9t YWluLXNwZWMgXQoKICAgRmlyc3QsIHRoZSA8aXA+J3MgbmFtZSBpcyBsb29rZWQgdXAgdXNpbmcg dGhpcyBwcm9jZWR1cmU6IHBlcmZvcm0gYQogICBETlMgcmV2ZXJzZS1tYXBwaW5nIGZvciA8aXA+ LCBsb29raW5nIHVwIHRoZSBjb3JyZXNwb25kaW5nIFBUUiByZWNvcmQKICAgaW4gImluLWFkZHIu YXJwYS4iIGlmIHRoZSBhZGRyZXNzIGlzIGFuIElQdjQgb25lIGFuZCBpbiAiaXA2LmFycGEuIgog ICBpZiBpdCBpcyBhbiBJUHY2IGFkZHJlc3MuICBGb3IgZWFjaCByZWNvcmQgcmV0dXJuZWQsIHZh bGlkYXRlIHRoZQogICBkb21haW4gbmFtZSBieSBsb29raW5nIHVwIGl0cyBJUCBhZGRyZXNzLiAg VG8gcHJldmVudCBEb1MgYXR0YWNrcywKICAgbW9yZSB0aGFuIDEwIFBUUiBuYW1lcyBNVVNUIE5P VCBiZSBsb29rZWQgdXAgZHVyaW5nIHRoZSBldmFsdWF0aW9uIG9mCiAgIGEgInB0ciIgbWVjaGFu aXNtIChzZWUgU2VjdGlvbiAxMCkuICBJZiA8aXA+IGlzIGFtb25nIHRoZSByZXR1cm5lZCBJUAog ICBhZGRyZXNzZXMsIHRoZW4gdGhhdCBkb21haW4gbmFtZSBpcyB2YWxpZGF0ZWQuCgpbTVNLOiBU aGlzIG5lZWRzIHRvIGJlIGRvbmUgYXMgYW4gZW51bWVyYXRlZCBsaXN0IHJhdGhlciB0aGFuIGEg cGFyYWdyYXBoLiAgQWxzbywgdGhlIHR3byBwc2V1ZG9jb2RlIGNodW5rcyBzaG91bGQgYmUgcHJl c2VudGVkIHRvZ2V0aGVyLl0KCiAgIEluIHBzZXVkb2NvZGU6CgogICBzZW5kaW5nLWRvbWFpbl9u YW1lcyA6PSBwdHJfbG9va3VwKHNlbmRpbmctaG9zdF9JUCk7CiAgIGlmIG1vcmUgdGhhbiAxMCBz ZW5kaW5nLWRvbWFpbl9uYW1lcyBhcmUgZm91bmQsIHVzZSBhdCBtb3N0IDEwLgogICBmb3IgZWFj aCBuYW1lIGluIChzZW5kaW5nLWRvbWFpbl9uYW1lcykgewogICAgIElQX2FkZHJlc3NlcyA6PSBh X2xvb2t1cChuYW1lKTsKICAgICBpZiB0aGUgc2VuZGluZy1kb21haW5fSVAgaXMgb25lIG9mIHRo ZSBJUF9hZGRyZXNzZXMgewogICAgICAgdmFsaWRhdGVkLXNlbmRpbmctZG9tYWluX25hbWVzICs9 IG5hbWU7CiAgICAgfQogICB9CgogICBDaGVjayBhbGwgdmFsaWRhdGVkIGRvbWFpbiBuYW1lcyB0 byBzZWUgaWYgdGhleSBlbmQgaW4gdGhlCiAgIDx0YXJnZXQtbmFtZT4gZG9tYWluLiAgSWYgYW55 IGRvLCB0aGlzIG1lY2hhbmlzbSBtYXRjaGVzLiAgSWYgbm8KCltNU0s6IFNvIGlmIHhlYmF5LmNv bSBpcyB2YWxpZGF0ZWQsIGFuZCA8dGFyZ2V0LW5hbWU+IGlzIGViYXkuY29tLCB0aGUgbWVjaGFu aXNtIG1hdGNoZXM/ICBTdXJlbHkgbm90LCBidXQgaXQgaWxsdXN0cmF0ZXMgdGhhdCB0aGUgZGVm aW5pdGlvbiBvZiB0aGlzIGlzIHdlYWsuXQoKICAgdmFsaWRhdGVkIGRvbWFpbiBuYW1lIGNhbiBi ZSBmb3VuZCwgb3IgaWYgbm9uZSBvZiB0aGUgdmFsaWRhdGVkCiAgIGRvbWFpbiBuYW1lcyBlbmQg aW4gdGhlIDx0YXJnZXQtbmFtZT4sIHRoaXMgbWVjaGFuaXNtIGZhaWxzIHRvIG1hdGNoLgogICBJ ZiBhIEROUyBlcnJvciBvY2N1cnMgd2hpbGUgZG9pbmcgdGhlIFBUUiBSUiBsb29rdXAsIHRoZW4g dGhpcwogICBtZWNoYW5pc20gZmFpbHMgdG8gbWF0Y2guICBJZiBhIEROUyBlcnJvciBvY2N1cnMg d2hpbGUgZG9pbmcgYW4gQSBSUgogICBsb29rdXAsIHRoZW4gdGhhdCBkb21haW4gbmFtZSBpcyBz a2lwcGVkIGFuZCB0aGUgc2VhcmNoIGNvbnRpbnVlcy4KCgoKCktpdHRlcm1hbiAgICAgICAgICAg ICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDI0XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BGKSAgICAgICAg ICAgIEp1bHkgMjAxMgoKCiAgIFBzZXVkb2NvZGU6CgogICBmb3IgZWFjaCBuYW1lIGluICh2YWxp ZGF0ZWQtc2VuZGluZy1kb21haW5fbmFtZXMpIHsKICAgICBpZiBuYW1lIGVuZHMgaW4gPGRvbWFp bi1zcGVjPiwgcmV0dXJuIG1hdGNoLgogICAgIGlmIG5hbWUgaXMgPGRvbWFpbi1zcGVjPiwgcmV0 dXJuIG1hdGNoLgogICB9CiAgIHJldHVybiBuby1tYXRjaC4KCiAgIFRoaXMgbWVjaGFuaXNtIG1h dGNoZXMgaWYgdGhlIDx0YXJnZXQtbmFtZT4gaXMgZWl0aGVyIGFuIGFuY2VzdG9yIG9mCiAgIGEg dmFsaWRhdGVkIGRvbWFpbiBuYW1lIG9yIGlmIHRoZSA8dGFyZ2V0LW5hbWU+IGFuZCBhIHZhbGlk YXRlZAogICBkb21haW4gbmFtZSBhcmUgdGhlIHNhbWUuICBGb3IgZXhhbXBsZTogIm1haWwuZXhh bXBsZS5jb20iIGlzIHdpdGhpbgogICB0aGUgZG9tYWluICJleGFtcGxlLmNvbSIsIGJ1dCAibWFp bC5iYWQtZXhhbXBsZS5jb20iIGlzIG5vdC4KCiAgIE5vdGU6IFRoaXMgbWVjaGFuaXNtIGhhcyBi ZWVuIGRlcHJlY2F0ZWQgYmVjYXVzZSBpdCBpcyBzbG93LCBpdCBpcwogICBub3QgYXMgcmVsaWFi bGUgYXMgb3RoZXIgbWVjaGFuaXNtcyBpbiBjYXNlcyBvZiBETlMgZXJyb3JzLCBhbmQgaXQKICAg cGxhY2VzIGEgbGFyZ2UgYnVyZGVuIG9uIHRoZSBhcnBhIG5hbWUgc2VydmVycy4gIElmIHVzZWQs IHByb3BlciBQVFIKCltNU0s6IHMvYXJwYS8iLmFycGEiL10KCiAgIHJlY29yZHMgbXVzdCBiZSBp biBwbGFjZSBmb3IgdGhlIGRvbWFpbidzIGhvc3RzIGFuZCB0aGUgInB0ciIKICAgbWVjaGFuaXNt IHNob3VsZCBiZSBvbmUgb2YgdGhlIGxhc3QgbWVjaGFuaXNtcyBjaGVja2VkLiAgQWZ0ZXIgbWFu eQogICB5YWVycyBvZiBTUEYgZGVwbG95bWVudCBleHBlcmllbmNlIGl0IGhhcyBiZWVuIGNvbmNs dWRlZCBpdCBpcwoKW01TSzogcy95YWVycy95ZWFycy9dCgogICB1bm5lY2Vzc2FyeSBhbmQgbW9y ZSByZWxpYWJsZSBhbHRlcm5hdGl2ZXMgdXNlZCBpbnN0ZWFkLgoKNS42LiAgImlwNCIgYW5kICJp cDYiCgogICBUaGVzZSBtZWNoYW5pc21zIHRlc3Qgd2hldGhlciA8aXA+IGlzIGNvbnRhaW5lZCB3 aXRoaW4gYSBnaXZlbiBJUAogICBuZXR3b3JrLgoKICAgSVA0ICAgICAgICAgICAgICA9ICJpcDQi ICAgICAgIjoiIGlwNC1uZXR3b3JrICAgWyBpcDQtY2lkci1sZW5ndGggXQogICBJUDYgICAgICAg ICAgICAgID0gImlwNiIgICAgICAiOiIgaXA2LW5ldHdvcmsgICBbIGlwNi1jaWRyLWxlbmd0aCBd CgogICBpcDQtY2lkci1sZW5ndGggID0gIi8iIDEqRElHSVQKICAgaXA2LWNpZHItbGVuZ3RoICA9 ICIvIiAxKkRJR0lUCiAgIGR1YWwtY2lkci1sZW5ndGggPSBbIGlwNC1jaWRyLWxlbmd0aCBdIFsg Ii8iIGlwNi1jaWRyLWxlbmd0aCBdCgpbTVNLOiBDYW4ndCB0aGlzIGJlIHNpbXBsaWZpZWQgdG8g anVzdCBhICJjaWRyLWxlbmd0aCIsIGFuZCB0aGUgYWJvdmUgdGhyZWUgZHJvcHBlZD8gIFJlYWxs eSB0aGUgb25seSBkaWZmZXJlbmNlIGlzIHRoYXQgaXA0LWNpZHItbGVuZ3RoIGNhbid0IGJlIG1v cmUgdGhhbiAzMiBhbmQgaXA2LWNpZHItbGVuZ3RoIGNhbid0IGJlIG1vcmUgdGhhbiAxMjguICBT byBlaXRoZXIgc2F5IHRoYXQgaW4gYW4gQUJORiBjb21tZW50IGZvciBlYWNoIChhbmQgeW91IGNv dWxkIG1ha2UgdGhlIGZvcm1lciBiZSAxKjJESUdJVCBhbmQgdGhlIGxhdHRlciAxKjNESUdJVCks IG9yIHNpbXBsaWZ5Ll0KCiAgIGlwNC1uZXR3b3JrICAgICAgPSBxbnVtICIuIiBxbnVtICIuIiBx bnVtICIuIiBxbnVtCiAgIHFudW0gICAgICAgICAgICAgPSBESUdJVCAgICAgICAgICAgICAgICAg OyAwLTkKICAgICAgICAgICAgICAgICAgICAgIC8gJXgzMS0zOSBESUdJVCAgICAgICA7IDEwLTk5 CiAgICAgICAgICAgICAgICAgICAgICAvICIxIiAyRElHSVQgICAgICAgICAgOyAxMDAtMTk5CiAg ICAgICAgICAgICAgICAgICAgICAvICIyIiAleDMwLTM0IERJR0lUICAgOyAyMDAtMjQ5CiAgICAg ICAgICAgICAgICAgICAgICAvICIyNSIgJXgzMC0zNSAgICAgICAgOyAyNTAtMjU1CiAgICAgICAg ICAgIDsgYXMgcGVyIGNvbnZlbnRpb25hbCBkb3R0ZWQgcXVhZCBub3RhdGlvbi4gIGUuZy4sIDE5 Mi4wLjIuMAoKW01TSzogSXMgdGhlcmUgcmVhbGx5IG5vdCBhIHJlZmVyZW5jZSBmb3IgdGhpcyBz eW50YXg/XQoKICAgaXA2LW5ldHdvcmsgICAgICA9IDxhcyBwZXIgW1JGQyA0MjkxXSwgc2VjdGlv biAyLjI+CiAgICAgICAgICAgIDsgZS5nLiwgMjAwMTpEQjg6OkNEMzAKCiAgIFRoZSA8aXA+IGlz IGNvbXBhcmVkIHRvIHRoZSBnaXZlbiBuZXR3b3JrLiAgSWYgQ0lEUi1sZW5ndGggaGlnaC1vcmRl cgogICBiaXRzIG1hdGNoLCB0aGUgbWVjaGFuaXNtIG1hdGNoZXMuCgogICBJZiBpcDQtY2lkci1s ZW5ndGggaXMgb21pdHRlZCwgaXQgaXMgdGFrZW4gdG8gYmUgIi8zMiIuICBJZgogICBpcDYtY2lk ci1sZW5ndGggaXMgb21pdHRlZCwgaXQgaXMgdGFrZW4gdG8gYmUgIi8xMjgiLiAgSXQgaXMgbm90 CgoKCktpdHRlcm1hbiAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAg ICAgICAgICAgIFtQYWdlIDI1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5 IEZyYW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1bHkgMjAxMgoKCiAgIHBlcm1pdHRlZCB0byBv bWl0IHBhcnRzIG9mIHRoZSBJUCBhZGRyZXNzIGluc3RlYWQgb2YgdXNpbmcgQ0lEUgogICBub3Rh dGlvbnMuICBUaGF0IGlzLCB1c2UgMTkyLjAuMi4wLzI0IGluc3RlYWQgb2YgMTkyLjAuMi4KCltN U0s6IEkgY2FuJ3QgcmVtZW1iZXIgaWYgSSBzYWlkIHRoaXMgYWxyZWFkeSwgYnV0IHRoZXJlJ3Mg YW4gUkZDIHRoYXQgZGVmaW5lcyBDSURSIHdoaWNoIHNob3VsZCBiZSByZWZlcmVuY2VkIHNvbWV3 aGVyZSBoZXJlLl0KCjUuNy4gICJleGlzdHMiCgogICBUaGlzIG1lY2hhbmlzbSBpcyB1c2VkIHRv IGNvbnN0cnVjdCBhbiBhcmJpdHJhcnkgZG9tYWluIG5hbWUgdGhhdCBpcwogICB1c2VkIGZvciBh IEROUyBBIHJlY29yZCBxdWVyeS4gIEl0IGFsbG93cyBmb3IgY29tcGxpY2F0ZWQgc2NoZW1lcwog ICBpbnZvbHZpbmcgYXJiaXRyYXJ5IHBhcnRzIG9mIHRoZSBtYWlsIGVudmVsb3BlIHRvIGRldGVy bWluZSB3aGF0IGlzCiAgIHBlcm1pdHRlZC4KCiAgIGV4aXN0cyAgICAgICAgICAgPSAiZXhpc3Rz IiAgICI6IiBkb21haW4tc3BlYwoKICAgVGhlIGRvbWFpbi1zcGVjIGlzIGV4cGFuZGVkIGFzIHBl ciBTZWN0aW9uIDguICBUaGUgcmVzdWx0aW5nIGRvbWFpbgogICBuYW1lIGlzIHVzZWQgZm9yIGEg RE5TIEEgUlIgbG9va3VwLiAgSWYgYW55IEEgcmVjb3JkIGlzIHJldHVybmVkLAogICB0aGlzIG1l Y2hhbmlzbSBtYXRjaGVzLiAgVGhlIGxvb2t1cCB0eXBlIGlzIEEgZXZlbiB3aGVuIHRoZQogICBj b25uZWN0aW9uIHR5cGUgaXMgSVB2Ni4KCltNU0s6IFdoYXQgYWJvdXQgQUFBQT9dCgogICBEb21h aW5zIGNhbiB1c2UgdGhpcyBtZWNoYW5pc20gdG8gc3BlY2lmeSBhcmJpdHJhcmlseSBjb21wbGV4 CiAgIHF1ZXJpZXMuICBGb3IgZXhhbXBsZSwgc3VwcG9zZSBleGFtcGxlLmNvbSBwdWJsaXNoZXMg dGhlIHJlY29yZDoKCiAgICAgIHY9c3BmMSBleGlzdHM6JXtpcn0uJXtsMXIrLX0uX3NwZi4le2R9 IC1hbGwKCiAgIFRoZSA8dGFyZ2V0LW5hbWU+IG1pZ2h0IGV4cGFuZCB0bwogICAiMS4yLjAuMTky LnNvbWV1c2VyLl9zcGYuZXhhbXBsZS5jb20iLiAgVGhpcyBtYWtlcyBmaW5lLWdyYWluZWQKICAg ZGVjaXNpb25zIHBvc3NpYmxlIGF0IHRoZSBsZXZlbCBvZiB0aGUgdXNlciBhbmQgY2xpZW50IElQ IGFkZHJlc3MuCgogICBUaGlzIG1lY2hhbmlzbSBlbmFibGVzIHF1ZXJpZXMgdGhhdCBtaW1pYyB0 aGUgc3R5bGUgb2YgdGVzdHMgdGhhdAogICBleGlzdGluZyBhbnRpLXNwYW0gRE5TIGJsYWNrbGlz dHMgKEROU0JMKSB1c2UuCgpbTVNLOiBSZWZlciB0byB0aGUgRE5TQkwgUkZDIGhlcmUuXQoKCgoK CgoKCgoKCgoKCgoKCgoKCgpLaXR0ZXJtYW4gICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5 IDYsIDIwMTMgICAgICAgICAgICAgICBbUGFnZSAyNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg U2VuZGVyIFBvbGljeSBGcmFtZXdvcmsgKFNQRikgICAgICAgICAgICBKdWx5IDIwMTIKCgo2LiAg TW9kaWZpZXIgRGVmaW5pdGlvbnMKCiAgIE1vZGlmaWVycyBhcmUgbmFtZS92YWx1ZSBwYWlycyB0 aGF0IHByb3ZpZGUgYWRkaXRpb25hbCBpbmZvcm1hdGlvbi4KICAgTW9kaWZpZXJzIGFsd2F5cyBo YXZlIGFuICI9IiBzZXBhcmF0aW5nIHRoZSBuYW1lIGFuZCB0aGUgdmFsdWUuCgogICBUaGUgbW9k aWZpZXJzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCAoInJlZGlyZWN0IiBhbmQgImV4cCIpIE1B WQogICBhcHBlYXIgYW55d2hlcmUgaW4gdGhlIHJlY29yZCwgYnV0IFNIT1VMRCBhcHBlYXIgYXQg dGhlIGVuZCwgYWZ0ZXIKICAgYWxsIG1lY2hhbmlzbXMuICBPcmRlcmluZyBvZiB0aGVzZSB0d28g bW9kaWZpZXJzIGRvZXMgbm90IG1hdHRlci4KICAgVGhlc2UgdHdvIG1vZGlmaWVycyBNVVNUIE5P VCBhcHBlYXIgaW4gYSByZWNvcmQgbW9yZSB0aGFuIG9uY2UgZWFjaC4KICAgSWYgdGhleSBkbywg dGhlbiBjaGVja19ob3N0KCkgZXhpdHMgd2l0aCBhIHJlc3VsdCBvZiAicGVybWVycm9yIi4KCltN U0s6IHMvY2hlY2tfaG9zdCgpL0NoZWNrSG9zdC9dCgogICBVbnJlY29nbml6ZWQgbW9kaWZpZXJz IE1VU1QgYmUgaWdub3JlZCBubyBtYXR0ZXIgd2hlcmUgaW4gYSByZWNvcmQsCiAgIG9yIGhvdyBv ZnRlbi4gIFRoaXMgYWxsb3dzIGltcGxlbWVudGF0aW9ucyBvZiB0aGlzIGRvY3VtZW50IHRvCiAg IGdyYWNlZnVsbHkgaGFuZGxlIHJlY29yZHMgd2l0aCBtb2RpZmllcnMgdGhhdCBhcmUgZGVmaW5l ZCBpbiBvdGhlcgogICBzcGVjaWZpY2F0aW9ucy4KCjYuMS4gIHJlZGlyZWN0OiBSZWRpcmVjdGVk IFF1ZXJ5CgogICBJZiBhbGwgbWVjaGFuaXNtcyBmYWlsIHRvIG1hdGNoLCBhbmQgYSAicmVkaXJl Y3QiIG1vZGlmaWVyIGlzCiAgIHByZXNlbnQsIHRoZW4gcHJvY2Vzc2luZyBwcm9jZWVkcyBhcyBm b2xsb3dzOgoKICAgcmVkaXJlY3QgICAgICAgICA9ICJyZWRpcmVjdCIgIj0iIGRvbWFpbi1zcGVj CgpbTVNLOiBUaGUgQUJORiBzZWVtcyB0byBpbnRlcnJ1cHQgdGhlIGZsb3cgb2YgdGhlIHByb3Nl Ll0KCiAgIFRoZSBkb21haW4tc3BlYyBwb3J0aW9uIG9mIHRoZSByZWRpcmVjdCBzZWN0aW9uIGlz IGV4cGFuZGVkIGFzIHBlcgogICB0aGUgbWFjcm8gcnVsZXMgaW4gU2VjdGlvbiA4LiAgVGhlbiBj aGVja19ob3N0KCkgaXMgZXZhbHVhdGVkIHdpdGgKICAgdGhlIHJlc3VsdGluZyBzdHJpbmcgYXMg dGhlIDxkb21haW4+LiAgVGhlIDxpcD4gYW5kIDxzZW5kZXI+CiAgIGFyZ3VtZW50cyByZW1haW4g dGhlIHNhbWUgYXMgaW4gdGhlIGN1cnJlbnQgZXZhbHVhdGlvbiBvZgogICBjaGVja19ob3N0KCku CgpbTVNLOiBzL2NoZWNrX2hvc3QoKS9DaGVja0hvc3QvLCB4Ml0KCiAgIFRoZSByZXN1bHQgb2Yg dGhpcyBuZXcgZXZhbHVhdGlvbiBvZiBjaGVja19ob3N0KCkgaXMgdGhlbiBjb25zaWRlcmVkCgpb TVNLOiDigKZhbmQgYWdhaW5dCgogICB0aGUgcmVzdWx0IG9mIHRoZSBjdXJyZW50IGV2YWx1YXRp b24gd2l0aCB0aGUgZXhjZXB0aW9uIHRoYXQgaWYgbm8KICAgU1BGIHJlY29yZCBpcyBmb3VuZCwg b3IgaWYgdGhlIHRhcmdldC1uYW1lIGlzIG1hbGZvcm1lZCwgdGhlIHJlc3VsdAogICBpcyBhICJw ZXJtZXJyb3IiIHJhdGhlciB0aGFuICJub25lIi4KCiAgIE5vdGUgdGhhdCB0aGUgbmV3bHktcXVl cmllZCBkb21haW4gY2FuIGl0c2VsZiBzcGVjaWZ5IHJlZGlyZWN0CiAgIHByb2Nlc3NpbmcuCgog ICBUaGlzIGZhY2lsaXR5IGlzIGludGVuZGVkIGZvciB1c2UgYnkgb3JnYW5pemF0aW9ucyB0aGF0 IHdpc2ggdG8gYXBwbHkKICAgdGhlIHNhbWUgcmVjb3JkIHRvIG11bHRpcGxlIGRvbWFpbnMuICBG b3IgZXhhbXBsZToKCiAgICAgbGEuZXhhbXBsZS5jb20uIFRYVCAidj1zcGYxIHJlZGlyZWN0PV9z cGYuZXhhbXBsZS5jb20iCiAgICAgbnkuZXhhbXBsZS5jb20uIFRYVCAidj1zcGYxIHJlZGlyZWN0 PV9zcGYuZXhhbXBsZS5jb20iCiAgICAgc2YuZXhhbXBsZS5jb20uIFRYVCAidj1zcGYxIHJlZGly ZWN0PV9zcGYuZXhhbXBsZS5jb20iCiAgIF9zcGYuZXhhbXBsZS5jb20uIFRYVCAidj1zcGYxIG14 OmV4YW1wbGUuY29tIC1hbGwiCgogICBJbiB0aGlzIGV4YW1wbGUsIG1haWwgZnJvbSBhbnkgb2Yg dGhlIHRocmVlIGRvbWFpbnMgaXMgZGVzY3JpYmVkIGJ5CiAgIHRoZSBzYW1lIHJlY29yZC4gIFRo aXMgY2FuIGJlIGFuIGFkbWluaXN0cmF0aXZlIGFkdmFudGFnZS4KCgoKCktpdHRlcm1hbiAgICAg ICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDI3 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BGKSAg ICAgICAgICAgIEp1bHkgMjAxMgoKCiAgIE5vdGU6IEluIGdlbmVyYWwsIHRoZSBkb21haW4gIkEi IGNhbm5vdCByZWxpYWJseSB1c2UgYSByZWRpcmVjdCB0bwogICBhbm90aGVyIGRvbWFpbiAiQiIg bm90IHVuZGVyIHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlIGNvbnRyb2wuICBTaW5jZQogICB0aGUg PHNlbmRlcj4gc3RheXMgdGhlIHNhbWUsIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0IHRoZSBy ZWNvcmQgYXQKICAgZG9tYWluICJCIiB3aWxsIGNvcnJlY3RseSB3b3JrIGZvciBtYWlsYm94ZXMg aW4gZG9tYWluICJBIiwKICAgZXNwZWNpYWxseSBpZiBkb21haW4gIkIiIHVzZXMgbWVjaGFuaXNt cyBpbnZvbHZpbmcgbG9jYWxwYXJ0cy4gIEFuCgpbTVNLOiBzL2xvY2FscGFydHMvbG9jYWwtcGFy dHMvXQoKICAgImluY2x1ZGUiIGRpcmVjdGl2ZSBpcyBnZW5lcmFsbHkgYmUgbW9yZSBhcHByb3By aWF0ZS4KCiAgIEZvciBjbGFyaXR5LCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGFueSAicmVkaXJl Y3QiIG1vZGlmaWVyIGFwcGVhciBhcwogICB0aGUgdmVyeSBsYXN0IHRlcm0gaW4gYSByZWNvcmQu Cgo2LjIuICBleHA6IEV4cGxhbmF0aW9uCgogICBleHBsYW5hdGlvbiAgICAgID0gImV4cCIgIj0i IGRvbWFpbi1zcGVjCgogICBJZiBjaGVja19ob3N0KCkgcmVzdWx0cyBpbiBhICJmYWlsIiBkdWUg dG8gYSBtZWNoYW5pc20gbWF0Y2ggKHN1Y2ggYXMKCltNU0s6cy9jaGVja19ob3N0KCkvQ2hlY2tI b3N0L10KCiAgICItYWxsIiksIGFuZCB0aGUgImV4cCIgbW9kaWZpZXIgaXMgcHJlc2VudCwgdGhl biB0aGUgZXhwbGFuYXRpb24KICAgc3RyaW5nIHJldHVybmVkIGlzIGNvbXB1dGVkIGFzIGRlc2Ny aWJlZCBiZWxvdy4gIElmIG5vICJleHAiIG1vZGlmaWVyCiAgIGlzIHByZXNlbnQsIHRoZW4gZWl0 aGVyIGEgZGVmYXVsdCBleHBsYW5hdGlvbiBzdHJpbmcgb3IgYW4gZW1wdHkKICAgZXhwbGFuYXRp b24gc3RyaW5nIE1VU1QgYmUgcmV0dXJuZWQuCgogICBUaGUgZG9tYWluLXNwZWMgaXMgbWFjcm8g ZXhwYW5kZWQgKHNlZSBTZWN0aW9uIDgpIGFuZCBiZWNvbWVzIHRoZQogICA8dGFyZ2V0LW5hbWU+ LiAgVGhlIEROUyBUWFQgcmVjb3JkIGZvciB0aGUgPHRhcmdldC1uYW1lPiBpcyBmZXRjaGVkLgoK ICAgSWYgdGhlcmUgYXJlIGFueSBETlMgcHJvY2Vzc2luZyBlcnJvcnMgKGFueSBSQ09ERSBvdGhl ciB0aGFuIDApLCBvcgogICBpZiBubyByZWNvcmRzIGFyZSByZXR1cm5lZCwgb3IgaWYgbW9yZSB0 aGFuIG9uZSByZWNvcmQgaXMgcmV0dXJuZWQsCiAgIG9yIGlmIHRoZXJlIGFyZSBzeW50YXggZXJy b3JzIGluIHRoZSBleHBsYW5hdGlvbiBzdHJpbmcsIHRoZW4gcHJvY2VlZAogICBhcyBpZiBubyBl eHAgbW9kaWZpZXIgd2FzIGdpdmVuLgoKICAgVGhlIGZldGNoZWQgVFhUIHJlY29yZCdzIHN0cmlu Z3MgYXJlIGNvbmNhdGVuYXRlZCB3aXRoIG5vIHNwYWNlcywgYW5kCiAgIHRoZW4gdHJlYXRlZCBh cyBhbiBleHBsYWluLXN0cmluZywgd2hpY2ggaXMgbWFjcm8tZXhwYW5kZWQuICBUaGlzCiAgIGZp bmFsIHJlc3VsdCBpcyB0aGUgZXhwbGFuYXRpb24gc3RyaW5nLiAgSW1wbGVtZW50YXRpb25zIE1B WSBsaW1pdAogICB0aGUgbGVuZ3RoIG9mIHRoZSByZXN1bHRpbmcgZXhwbGFuYXRpb24gc3RyaW5n IHRvIGFsbG93IGZvciBvdGhlcgogICBwcm90b2NvbCBjb25zdHJhaW50cyBhbmQvb3IgcmVhc29u YWJsZSBwcm9jZXNzaW5nIGxpbWl0cy4gIFNpbmNlIHRoZQogICBleHBsYW5hdGlvbiBzdHJpbmcg aXMgaW50ZW5kZWQgZm9yIGFuIFNNVFAgcmVzcG9uc2UgYW5kIFtSRkM1MzIxXQogICBTZWN0aW9u IDIuNCBzYXlzIHRoYXQgcmVzcG9uc2VzIGFyZSBpbiBbVVMtQVNDSUldLCB0aGUgZXhwbGFuYXRp b24KICAgc3RyaW5nIGlzIGFsc28gbGltaXRlZCB0byBVUy1BU0NJSS4KCltNU0s6IFRoZXJlIHNo b3VsZCBiZSBhIE1VU1QgaGVyZS5dCgogICBTb2Z0d2FyZSBldmFsdWF0aW5nIGNoZWNrX2hvc3Qo KSBjYW4gdXNlIHRoaXMgc3RyaW5nIHRvIGNvbW11bmljYXRlCgpbTVNLOiBTb2Z0d2FyZSBhcHBs eWluZyB0aGUgcmVzdWx0cyBvZiBDaGVja0hvc3QgY2FuIHVzZeKApl0KCiAgIGluZm9ybWF0aW9u IGZyb20gdGhlIHB1Ymxpc2hpbmcgZG9tYWluIGluIHRoZSBmb3JtIG9mIGEgc2hvcnQgbWVzc2Fn ZQogICBvciBVUkwuICBTb2Z0d2FyZSBTSE9VTEQgbWFrZSBpdCBjbGVhciB0aGF0IHRoZSBleHBs YW5hdGlvbiBzdHJpbmcKICAgY29tZXMgZnJvbSBhIHRoaXJkIHBhcnR5LiAgRm9yIGV4YW1wbGUs IGl0IGNhbiBwcmVwZW5kIHRoZSBtYWNybwogICBzdHJpbmcgIiV7b30gZXhwbGFpbnM6ICIgdG8g dGhlIGV4cGxhbmF0aW9uLCBzdWNoIGFzIHNob3duIGluCiAgIFNlY3Rpb24gMi41LjQuCgogICBT dXBwb3NlIGV4YW1wbGUuY29tIGhhcyB0aGlzIHJlY29yZDoKCgoKCgoKS2l0dGVybWFuICAgICAg ICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMjhd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpICAg ICAgICAgICAgSnVseSAyMDEyCgoKICAgICAgdj1zcGYxIG14IC1hbGwgZXhwPWV4cGxhaW4uX3Nw Zi4le2R9CgogICBIZXJlIGFyZSBzb21lIGV4YW1wbGVzIG9mIHBvc3NpYmxlIGV4cGxhbmF0aW9u IFRYVCByZWNvcmRzIGF0CiAgIGV4cGxhaW4uX3NwZi5leGFtcGxlLmNvbToKCiAgICAgICJNYWls IGZyb20gZXhhbXBsZS5jb20gc2hvdWxkIG9ubHkgYmUgc2VudCBieSBpdHMgb3duIHNlcnZlcnMu IgogICAgICAgICAtLSAgYSBzaW1wbGUsIGNvbnN0YW50IG1lc3NhZ2UKCiAgICAgICIle2l9IGlz IG5vdCBvbmUgb2YgJXtkfSdzIGRlc2lnbmF0ZWQgbWFpbCBzZXJ2ZXJzLiIKICAgICAgICAgLS0g IGEgbWVzc2FnZSB3aXRoIGEgbGl0dGxlIG1vcmUgaW5mb3JtYXRpb24sIGluY2x1ZGluZyB0aGUg SVAKICAgICAgICAgICAgIGFkZHJlc3MgdGhhdCBmYWlsZWQgdGhlIGNoZWNrCgogICAgICAiU2Vl IGh0dHA6Ly8le2R9L3doeS5odG1sP3M9JXtTfSZpPSV7SX0iCiAgICAgICAgIC0tICBhIGNvbXBs aWNhdGVkIGV4YW1wbGUgdGhhdCBjb25zdHJ1Y3RzIGEgVVJMIHdpdGggdGhlCiAgICAgICAgICAg ICBhcmd1bWVudHMgdG8gY2hlY2tfaG9zdCgpIHNvIHRoYXQgYSB3ZWIgcGFnZSBjYW4gYmUKICAg ICAgICAgICAgIGdlbmVyYXRlZCB3aXRoIGRldGFpbGVkLCBjdXN0b20gaW5zdHJ1Y3Rpb25zCgog ICBOb3RlOiBEdXJpbmcgcmVjdXJzaW9uIGludG8gYW4gImluY2x1ZGUiIG1lY2hhbmlzbSwgYW4g ZXhwPSBtb2RpZmllcgogICBmcm9tIHRoZSA8dGFyZ2V0LW5hbWU+IE1VU1QgTk9UIGJlIHVzZWQu ICBJbiBjb250cmFzdCwgd2hlbiBleGVjdXRpbmcKICAgYSAicmVkaXJlY3QiIG1vZGlmaWVyLCBh biBleHA9IG1vZGlmaWVyIGZyb20gdGhlIG9yaWdpbmFsIGRvbWFpbiBNVVNUCiAgIE5PVCBiZSB1 c2VkLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpLaXR0ZXJtYW4gICAgICAgICAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDYsIDIwMTMgICAgICAgICAgICAgICBbUGFnZSAyOV0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgU2VuZGVyIFBvbGljeSBGcmFtZXdvcmsgKFNQRikgICAgICAgICAg ICBKdWx5IDIwMTIKCgo3LiAgVGhlIFJlY2VpdmVkLVNQRiBIZWFkZXIgRmllbGQKCltNU0s6IFRo aXMgc2hvdWxkIGJlIHVwZGF0ZWQgYXMgYWdyZWVkIChJIHRoaW5rKSB0byBzYXkgaW1wbGVtZW50 YXRpb25zIFNIT1VMRCBnZW5lcmF0ZSBBLVIgYW5kIE1VU1QgTk9UIGdlbmVyYXRlIHRoaXMsIHdo aWxlIHRoZXkgU0hPVUxEIGJlIGFibGUgdG8gcGFyc2UgdGhpcy5dCgogICBJdCBpcyBSRUNPTU1F TkRFRCB0aGF0IFNNVFAgcmVjZWl2ZXJzIHJlY29yZCB0aGUgcmVzdWx0IG9mIFNQRgogICBwcm9j ZXNzaW5nIGluIHRoZSBtZXNzYWdlIGhlYWRlci4gIElmIGFuIFNNVFAgcmVjZWl2ZXIgY2hvb3Nl cyB0byBkbwogICBzbywgaXQgU0hPVUxEIHVzZSB0aGUgIlJlY2VpdmVkLVNQRiIgaGVhZGVyIGZp ZWxkIGRlZmluZWQgaGVyZSBmb3IKICAgZWFjaCBpZGVudGl0eSB0aGF0IHdhcyBjaGVja2VkLiAg VGhpcyBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCBmb3IgdGhlCiAgIHJlY2lwaWVudC4gIChJbmZv cm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNlbmRlciBpcyBkZXNjcmliZWQgaW4KICAgU2VjdGlv biA2LjIsIEV4cGxhbmF0aW9uLikKCiAgIFRoZSBSZWNlaXZlZC1TUEYgaGVhZGVyIGZpZWxkIGlz IGEgdHJhY2UgZmllbGQgKHNlZSBbUkZDNTMyMl0gU2VjdGlvbgogICAzLjYuNykgYW5kIFNIT1VM RCBiZSBwcmVwZW5kZWQgdG8gdGhlIGV4aXN0aW5nIGhlYWRlciwgYWJvdmUgdGhlCiAgIFJlY2Vp dmVkOiBmaWVsZCB0aGF0IGlzIGdlbmVyYXRlZCBieSB0aGUgU01UUCByZWNlaXZlci4gIEl0IE1V U1QKICAgYXBwZWFyIGFib3ZlIGFsbCBvdGhlciBSZWNlaXZlZC1TUEYgZmllbGRzIGluIHRoZSBt ZXNzYWdlLiAgVGhlCiAgIGhlYWRlciBmaWVsZCBoYXMgdGhlIGZvbGxvd2luZyBmb3JtYXQ6Cgog ICBoZWFkZXItZmllbGQgICAgID0gIlJlY2VpdmVkLVNQRjoiIFtDRldTXSByZXN1bHQgRldTIFtj b21tZW50IEZXU10KICAgICAgICAgICAgICAgICAgICAgIFsga2V5LXZhbHVlLWxpc3QgXSBDUkxG CgogICByZXN1bHQgICAgICAgICAgID0gInBhc3MiIC8gImZhaWwiIC8gInNvZnRmYWlsIiAvICJu ZXV0cmFsIiAvCiAgICAgICAgICAgICAgICAgICAgICAibm9uZSIgLyAidGVtcGVycm9yIiAvICJw ZXJtZXJyb3IiCgogICBrZXktdmFsdWUtbGlzdCAgID0ga2V5LXZhbHVlLXBhaXIgKiggIjsiIFtD RldTXSBrZXktdmFsdWUtcGFpciApCiAgICAgICAgICAgICAgICAgICAgICBbIjsiXQoKICAga2V5 LXZhbHVlLXBhaXIgICA9IGtleSBbQ0ZXU10gIj0iICggZG90LWF0b20gLyBxdW90ZWQtc3RyaW5n ICkKCiAgIGtleSAgICAgICAgICAgICAgPSAiY2xpZW50LWlwIiAvICJlbnZlbG9wZS1mcm9tIiAv ICJoZWxvIiAvCiAgICAgICAgICAgICAgICAgICAgICAicHJvYmxlbSIgLyAicmVjZWl2ZXIiIC8g ImlkZW50aXR5IiAvCiAgICAgICAgICAgICAgICAgICAgICAgbWVjaGFuaXNtIC8gbmFtZQoKICAg aWRlbnRpdHkgICAgICAgICA9ICJtYWlsZnJvbSIgICA7IGZvciB0aGUgIk1BSUwgRlJPTSIgaWRl bnRpdHkKICAgICAgICAgICAgICAgICAgICAgIC8gImhlbG8iICAgICA7IGZvciB0aGUgIkhFTE8i IGlkZW50aXR5CiAgICAgICAgICAgICAgICAgICAgICAvIG5hbWUgICAgICAgOyBvdGhlciBpZGVu dGl0aWVzCgpbTVNLOiBTaG91bGQgImlkZW50aXR5IiBiZSBxdW90ZWQgaW4gdGhlICJrZXkiIGxp c3Q/XQoKW01TSzogVGhlcmUgYXJlIHR3byBwYXRocyB0byAia2V5IiBnZW5lcmF0aW5nICJuYW1l Ijogb25lIGRpcmVjdCwgb25lIHRocm91Z2ggImlkZW50aXR5Il0KCiAgIGRvdC1hdG9tICAgICAg ICAgPSA8dW5xdW90ZWQgd29yZCBhcyBwZXIgW1JGQzUzMjJdPgogICBxdW90ZWQtc3RyaW5nICAg ID0gPHF1b3RlZCBzdHJpbmcgYXMgcGVyIFtSRkM1MzIyXT4KICAgY29tbWVudCAgICAgICAgICA9 IDxjb21tZW50IHN0cmluZyBhcyBwZXIgW1JGQzUzMjJdPgogICBDRldTICAgICAgICAgICAgID0g PGNvbW1lbnQgb3IgZm9sZGluZyB3aGl0ZSBzcGFjZSBhcyBwZXIgW1JGQzUzMjJdPgogICBGV1Mg ICAgICAgICAgICAgID0gPGZvbGRpbmcgd2hpdGUgc3BhY2UgYXMgcGVyIFtSRkM1MzIyXT4KICAg Q1JMRiAgICAgICAgICAgICA9IDxzdGFuZGFyZCBlbmQtb2YtbGluZSB0b2tlbiBhcyBwZXIgW1JG QzI1MzJdPgoKICAgVGhlIGhlYWRlciBmaWVsZCBTSE9VTEQgaW5jbHVkZSBhICIoLi4uKSIgc3R5 bGUgY29tbWVudCBhZnRlciB0aGUKICAgcmVzdWx0LCBjb252ZXlpbmcgc3VwcG9ydGluZyBpbmZv cm1hdGlvbiBmb3IgdGhlIHJlc3VsdCwgc3VjaCBhcwogICA8aXA+LCA8c2VuZGVyPiwgYW5kIDxk b21haW4+LgoKICAgVGhlIGZvbGxvd2luZyBrZXktdmFsdWUgcGFpcnMgYXJlIGRlc2lnbmVkIGZv ciBsYXRlciBtYWNoaW5lIHBhcnNpbmcuCiAgIFNQRiBjbGllbnRzIFNIT1VMRCBnaXZlIGVub3Vn aCBpbmZvcm1hdGlvbiBzbyB0aGF0IHRoZSBTUEYgcmVzdWx0cwogICBjYW4gYmUgdmVyaWZpZWQu ICBUaGF0IGlzLCBhdCBsZWFzdCAiY2xpZW50LWlwIiwgImhlbG8iLCBhbmQsIGlmIHRoZQoKCgpL aXR0ZXJtYW4gICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDYsIDIwMTMgICAgICAgICAg ICAgICBbUGFnZSAzMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgU2VuZGVyIFBvbGljeSBGcmFt ZXdvcmsgKFNQRikgICAgICAgICAgICBKdWx5IDIwMTIKCgogICAiTUFJTCBGUk9NIiBpZGVudGl0 eSB3YXMgY2hlY2tlZCwgImVudmVsb3BlLWZyb20iLgoKICAgY2xpZW50LWlwICAgICAgdGhlIElQ IGFkZHJlc3Mgb2YgdGhlIFNNVFAgY2xpZW50CgogICBlbnZlbG9wZS1mcm9tICB0aGUgZW52ZWxv cGUgc2VuZGVyIG1haWxib3gKCltNU0s6IFN1Z2dlc3QgInRoZSBSRkM1MzIxLk1haWxGcm9tIGFk ZHJlc3MiIG9yIHNpbXBseSAidGhlIHJldHVybi1wYXRoIl0KCiAgIGhlbG8gICAgICAgICAgIHRo ZSBob3N0IG5hbWUgZ2l2ZW4gaW4gdGhlIEhFTE8gb3IgRUhMTyBjb21tYW5kCgpbTVNLOiBzL2lu L2FzIHRoZSBwYXJhbWV0ZXIgdG8vXQoKICAgbWVjaGFuaXNtICAgICAgdGhlIG1lY2hhbmlzbSB0 aGF0IG1hdGNoZWQgKGlmIG5vIG1lY2hhbmlzbXMgbWF0Y2hlZCwKICAgICAgICAgICAgICAgICAg c3Vic3RpdHV0ZSB0aGUgd29yZCAiZGVmYXVsdCIpCgogICBwcm9ibGVtICAgICAgICBpZiBhbiBl cnJvciB3YXMgcmV0dXJuZWQsIGRldGFpbHMgYWJvdXQgdGhlIGVycm9yCgogICByZWNlaXZlciAg ICAgICB0aGUgaG9zdCBuYW1lIG9mIHRoZSBTUEYgY2xpZW50CgogICBpZGVudGl0eSAgICAgICB0 aGUgaWRlbnRpdHkgdGhhdCB3YXMgY2hlY2tlZDsgc2VlIHRoZSA8aWRlbnRpdHk+IEFCTkYKICAg ICAgICAgICAgICAgICAgcnVsZQoKICAgT3RoZXIga2V5cyBNQVkgYmUgZGVmaW5lZCBieSBTUEYg Y2xpZW50cy4KCltNU0s6IFNob3VsZCB0aGVzZSBiZSBpbiBhIHJlZ2lzdHJ5P10KCiAgIFNQRiBj bGllbnRzIE1VU1QgbWFrZSBzdXJlIHRoYXQgdGhlIFJlY2VpdmVkLVNQRiBoZWFkZXIgZmllbGQg ZG9lcwogICBub3QgY29udGFpbiBpbnZhbGlkIGNoYXJhY3RlcnMsIGlzIG5vdCBleGNlc3NpdmVs eSBsb25nLCBhbmQgZG9lcyBub3QKICAgY29udGFpbiBtYWxpY2lvdXMgZGF0YSB0aGF0IGhhcyBi ZWVuIHByb3ZpZGVkIGJ5IHRoZSBzZW5kZXIuCgpbTVNLOiBBICJNVVNUIiBmb2xsb3dlZCBieSAi ZXhjZXNzaXZlbHkgbG9uZyIgY3JlYXRlcyBhIG1hbmRhdG9yeSBpbXBsZW1lbnRhdGlvbiBvZiBz b21ldGhpbmcgbXVzaHkuICBJZiB3ZSdyZSByZWZlcnJpbmcgaGVyZSB0byBSRkM1MzJ7MSwyfSBs aW1pdHMsIHdlIHNob3VsZCBlaXRoZXIgcmVmZXJlbmNlIHRoZW0gaGVyZSwgb3Igc2F5IG5vdGhp bmcgc2luY2UgYWxsIG9mIHRoaXMgaGFwcGVucyBpbiB0aGF0IGNvbnRleHQgYW55d2F5Ll0KCiAg IEV4YW1wbGVzIG9mIHZhcmlvdXMgaGVhZGVyIHN0eWxlcyB0aGF0IGNvdWxkIGJlIGdlbmVyYXRl ZCBhcmUgdGhlCiAgIGZvbGxvd2luZzoKCltNU0s6IHMvaGVhZGVyL2hlYWRlciBmaWVsZC9dCgog ICBSZWNlaXZlZC1TUEY6IHBhc3MgKG15Ym94LmV4YW1wbGUub3JnOiBkb21haW4gb2YKICAgIG15 bmFtZUBleGFtcGxlLmNvbSBkZXNpZ25hdGVzIDE5Mi4wLjIuMSBhcyBwZXJtaXR0ZWQgc2VuZGVy KQogICAgICAgcmVjZWl2ZXI9bXlib3guZXhhbXBsZS5vcmc7IGNsaWVudC1pcD0xOTIuMC4yLjE7 CiAgICAgICBlbnZlbG9wZS1mcm9tPSJteW5hbWVAZXhhbXBsZS5jb20iOyBoZWxvPWZvby5leGFt cGxlLmNvbTsKCiAgIFJlY2VpdmVkLVNQRjogZmFpbCAobXlib3guZXhhbXBsZS5vcmc6IGRvbWFp biBvZgogICAgICAgICAgICAgICAgICAgICBteW5hbWVAZXhhbXBsZS5jb20gZG9lcyBub3QgZGVz aWduYXRlCiAgICAgICAgICAgICAgICAgICAgIDE5Mi4wLjIuMSBhcyBwZXJtaXR0ZWQgc2VuZGVy KQogICAgICAgICAgICAgICAgICAgICBpZGVudGl0eT1tYWlsZnJvbTsgY2xpZW50LWlwPTE5Mi4w LjIuMTsKICAgICAgICAgICAgICAgICAgICAgZW52ZWxvcGUtZnJvbT0ibXluYW1lQGV4YW1wbGUu Y29tIjsKCgoKCgoKCgoKCgoKCgpLaXR0ZXJtYW4gICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51 YXJ5IDYsIDIwMTMgICAgICAgICAgICAgICBbUGFnZSAzMV0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgU2VuZGVyIFBvbGljeSBGcmFtZXdvcmsgKFNQRikgICAgICAgICAgICBKdWx5IDIwMTIKCgo4 LiAgTWFjcm9zCgo4LjEuICBNYWNybyBEZWZpbml0aW9ucwoKICAgTWFueSBtZWNoYW5pc21zIGFu ZCBtb2RpZmllcnMgcGVyZm9ybSBtYWNybyBleHBhbnNpb24gb24gdGhlIHRlcm0uCgpbTVNLOiAi T24gdGhlIHRlcm0iPyAgUGVyaGFwcyAib24gYSB0ZXJtIiBvciAib24gYSBwYXJhbWV0ZXIiP10K CiAgIGRvbWFpbi1zcGVjICAgICAgPSBtYWNyby1zdHJpbmcgZG9tYWluLWVuZAogICBkb21haW4t ZW5kICAgICAgID0gKCAiLiIgdG9wbGFiZWwgWyAiLiIgXSApIC8gbWFjcm8tZXhwYW5kCgogICB0 b3BsYWJlbCAgICAgICAgID0gKCAqYWxwaGFudW0gQUxQSEEgKmFscGhhbnVtICkgLwogICAgICAg ICAgICAgICAgICAgICAgKCAxKmFscGhhbnVtICItIiAqKCBhbHBoYW51bSAvICItIiApIGFscGhh bnVtICkKICAgICAgICAgICAgICAgICAgICAgIDsgTERIIHJ1bGUgcGx1cyBhZGRpdGlvbmFsIFRM RCByZXN0cmljdGlvbnMKICAgICAgICAgICAgICAgICAgICAgIDsgKHNlZSBbUkZDMzY5Nl0sIFNl Y3Rpb24gMiBmb3IgYmFja2dyb3VuZCkKICAgYWxwaGFudW0gICAgICAgICA9IEFMUEhBIC8gRElH SVQKCiAgIGV4cGxhaW4tc3RyaW5nICAgPSAqKCBtYWNyby1zdHJpbmcgLyBTUCApCgogICBtYWNy by1zdHJpbmcgICAgID0gKiggbWFjcm8tZXhwYW5kIC8gbWFjcm8tbGl0ZXJhbCApCiAgIG1hY3Jv LWV4cGFuZCAgICAgPSAoICIleyIgbWFjcm8tbGV0dGVyIHRyYW5zZm9ybWVycyAqZGVsaW1pdGVy ICJ9IiApCiAgICAgICAgICAgICAgICAgICAgICAvICIlJSIgLyAiJV8iIC8gIiUtIgoKW01TSzog VGhlICIqZGVsaW1pdGVyIiBhbGxvd3MgdGhpczogJXtzLi0rLC9fPS4rLC4uKy59ICBXaGF0IHdv dWxkIHRoYXQgbWVhbj9dCgogICBtYWNyby1saXRlcmFsICAgID0gJXgyMS0yNCAvICV4MjYtN0UK ICAgICAgICAgICAgICAgICAgICAgIDsgdmlzaWJsZSBjaGFyYWN0ZXJzIGV4Y2VwdCAiJSIKICAg bWFjcm8tbGV0dGVyICAgICA9ICJzIiAvICJsIiAvICJvIiAvICJkIiAvICJpIiAvICJwIiAvICJo IiAvCiAgICAgICAgICAgICAgICAgICAgICAiYyIgLyAiciIgLyAidCIgLyAidiIKICAgdHJhbnNm b3JtZXJzICAgICA9ICpESUdJVCBbICJyIiBdCiAgIGRlbGltaXRlciAgICAgICAgPSAiLiIgLyAi LSIgLyAiKyIgLyAiLCIgLyAiLyIgLyAiXyIgLyAiPSIKCiAgIEEgbGl0ZXJhbCAiJSIgaXMgZXhw cmVzc2VkIGJ5ICIlJSIuCgogICAgICAiJV8iIGV4cGFuZHMgdG8gYSBzaW5nbGUgIiAiIHNwYWNl LgogICAgICAiJS0iIGV4cGFuZHMgdG8gYSBVUkwtZW5jb2RlZCBzcGFjZSwgdml6LiwgIiUyMCIu CgogICBUaGUgZm9sbG93aW5nIG1hY3JvIGxldHRlcnMgYXJlIGV4cGFuZGVkIGluIHRlcm0gYXJn dW1lbnRzOgoKICAgICAgcyA9IDxzZW5kZXI+CiAgICAgIGwgPSBsb2NhbC1wYXJ0IG9mIDxzZW5k ZXI+CiAgICAgIG8gPSBkb21haW4gb2YgPHNlbmRlcj4KICAgICAgZCA9IDxkb21haW4+CiAgICAg IGkgPSA8aXA+CiAgICAgIHAgPSB0aGUgdmFsaWRhdGVkIGRvbWFpbiBuYW1lIG9mIDxpcD4gKGRl cHJlY2F0ZWQpCgpbTVNLOiBUaGlzIG1ha2VzIG1lIHRoaW5rIHdlIG5lZWQgdG8gc2F5IHNvbWV3 aGVyZSB3aGF0IGl0IG1lYW5zIGZvciB0aGlzIHRvIGJlIGRlcHJlY2F0ZWQuICBXaGVuIHZlcmlm aWVycyBzZWUgaXQsIGZvciBleGFtcGxlLCB3aGF0IHNob3VsZCB0aGV5IGRvP10KCiAgICAgIHYg PSB0aGUgc3RyaW5nICJpbi1hZGRyIiBpZiA8aXA+IGlzIGlwdjQsIG9yICJpcDYiIGlmIDxpcD4g aXMgaXB2NgogICAgICBoID0gSEVMTy9FSExPIGRvbWFpbgoKICAgVGhlIGZvbGxvd2luZyBtYWNy byBsZXR0ZXJzIGFyZSBhbGxvd2VkIG9ubHkgaW4gImV4cCIgdGV4dDoKCiAgICAgIGMgPSBTTVRQ IGNsaWVudCBJUCAoZWFzaWx5IHJlYWRhYmxlIGZvcm1hdCkKICAgICAgciA9IGRvbWFpbiBuYW1l IG9mIGhvc3QgcGVyZm9ybWluZyB0aGUgY2hlY2sKICAgICAgdCA9IGN1cnJlbnQgdGltZXN0YW1w CgoKCktpdHRlcm1hbiAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAg ICAgICAgICAgIFtQYWdlIDMyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5 IEZyYW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1bHkgMjAxMgoKCiAgIEEgJyUnIGNoYXJhY3Rl ciBub3QgZm9sbG93ZWQgYnkgYSAneycsICclJywgJy0nLCBvciAnXycgY2hhcmFjdGVyIGlzCiAg IGEgc3ludGF4IGVycm9yLiAgU28KICAgICAgLWV4aXN0czolKGlyKS5zYmwuc3BhbWhhdXMuZXhh bXBsZS5vcmcKICAgaXMgaW5jb3JyZWN0IGFuZCB3aWxsIGNhdXNlIGNoZWNrX2hvc3QoKSB0byBy ZXR1cm4gYSAicGVybWVycm9yIi4KCltNU0s6IHMvY2hlY2tfaG9zdCgpIHRvIHJldHVybiBhL0No ZWNrSG9zdCB0byB5aWVsZC9dCgogICBJbnN0ZWFkLCBzYXkKICAgICAgLWV4aXN0czole2lyfS5z Ymwuc3BhbWhhdXMuZXhhbXBsZS5vcmcKCiAgIE9wdGlvbmFsIHRyYW5zZm9ybWVycyBhcmUgdGhl IGZvbGxvd2luZzoKCiAgICAgICpESUdJVCA9IHplcm8gb3IgbW9yZSBkaWdpdHMKICAgICAgJ3In ICAgID0gcmV2ZXJzZSB2YWx1ZSwgc3BsaXR0aW5nIG9uIGRvdHMgYnkgZGVmYXVsdAoKICAgSWYg dHJhbnNmb3JtZXJzIG9yIGRlbGltaXRlcnMgYXJlIHByb3ZpZGVkLCB0aGUgcmVwbGFjZW1lbnQg dmFsdWUgZm9yCiAgIGEgbWFjcm8gbGV0dGVyIGlzIHNwbGl0IGludG8gcGFydHMuICBBZnRlciBw ZXJmb3JtaW5nIGFueSByZXZlcnNhbAogICBvcGVyYXRpb24gYW5kL29yIHJlbW92YWwgb2YgbGVm dC1oYW5kIHBhcnRzLCB0aGUgcGFydHMgYXJlIHJlam9pbmVkCiAgIHVzaW5nICIuIiBhbmQgbm90 IHRoZSBvcmlnaW5hbCBzcGxpdHRpbmcgY2hhcmFjdGVycy4KCiAgIEJ5IGRlZmF1bHQsIHN0cmlu Z3MgYXJlIHNwbGl0IG9uICIuIiAoZG90cykuICBOb3RlIHRoYXQgbm8gc3BlY2lhbAogICB0cmVh dG1lbnQgaXMgZ2l2ZW4gdG8gbGVhZGluZywgdHJhaWxpbmcsIG9yIGNvbnNlY3V0aXZlIGRlbGlt aXRlcnMsCgpbTVNLOiBJbiBpbnB1dCBzdHJpbmdzLCByaWdodD9dCgogICBhbmQgc28gdGhlIGxp c3Qgb2YgcGFydHMgbWlnaHQgY29udGFpbiBlbXB0eSBzdHJpbmdzLiAgT2xkZXIKICAgaW1wbGVt ZW50YXRpb25zIG9mIFNQRiBwcm9oaWJpdCB0cmFpbGluZyBkb3RzIGluIGRvbWFpbiBuYW1lcywg c28KICAgdHJhaWxpbmcgZG90cyBzaG91bGQgbm90IGJlIHB1Ymxpc2hlZCBieSBkb21haW4gb3du ZXJzLCBhbHRob3VnaCB0aGV5CiAgIG11c3QgYmUgYWNjZXB0ZWQgYnkgaW1wbGVtZW50YXRpb25z IGNvbmZvcm1pbmcgdG8gdGhpcyBkb2N1bWVudC4KCltNU0s6IHMvbXVzdC9NVVNUL10KCiAgIE1h Y3JvcyBNQVkgc3BlY2lmeSBkZWxpbWl0ZXIgY2hhcmFjdGVycyB0aGF0IGFyZSB1c2VkIGluc3Rl YWQgb2YgIi4iLgoKW01TSzogSXNuJ3QgdGhpcyByZWR1bmRhbnQgdG8gdGhlIEFCTkY/XQoKICAg VGhlICdyJyB0cmFuc2Zvcm1lciBpbmRpY2F0ZXMgYSByZXZlcnNhbCBvcGVyYXRpb246IGlmIHRo ZSBjbGllbnQgSVAKICAgYWRkcmVzcyB3ZXJlIDE5Mi4wLjIuMSwgdGhlIG1hY3JvICV7aX0gd291 bGQgZXhwYW5kIHRvICIxOTIuMC4yLjEiCiAgIGFuZCB0aGUgbWFjcm8gJXtpcn0gd291bGQgZXhw YW5kIHRvICIxLjIuMC4xOTIiLgoKICAgVGhlIERJR0lUIHRyYW5zZm9ybWVyIGluZGljYXRlcyB0 aGUgbnVtYmVyIG9mIHJpZ2h0LWhhbmQgcGFydHMgdG8KICAgdXNlLCBhZnRlciBvcHRpb25hbCBy ZXZlcnNhbC4gIElmIGEgRElHSVQgaXMgc3BlY2lmaWVkLCB0aGUgdmFsdWUKICAgTVVTVCBiZSBu b256ZXJvLiAgSWYgbm8gRElHSVRzIGFyZSBzcGVjaWZpZWQsIG9yIGlmIHRoZSB2YWx1ZQogICBz cGVjaWZpZXMgbW9yZSBwYXJ0cyB0aGFuIGFyZSBhdmFpbGFibGUsIGFsbCB0aGUgYXZhaWxhYmxl IHBhcnRzIGFyZQogICB1c2VkLiAgSWYgdGhlIERJR0lUIHdhcyA1LCBhbmQgb25seSAzIHBhcnRz IHdlcmUgYXZhaWxhYmxlLCB0aGUgbWFjcm8KICAgaW50ZXJwcmV0ZXIgd291bGQgcHJldGVuZCB0 aGUgRElHSVQgd2FzIDMuICBJbXBsZW1lbnRhdGlvbnMgTVVTVAogICBzdXBwb3J0IGF0IGxlYXN0 IGEgdmFsdWUgb2YgMTI4LCBhcyB0aGF0IGlzIHRoZSBtYXhpbXVtIG51bWJlciBvZgogICBsYWJl bHMgaW4gYSBkb21haW4gbmFtZS4KCiAgIFRoZSAicyIgbWFjcm8gZXhwYW5kcyB0byB0aGUgPHNl bmRlcj4gYXJndW1lbnQuICBJdCBpcyBhbiBlbWFpbAogICBhZGRyZXNzIHdpdGggYSBsb2NhbHBh cnQsIGFuICJAIiBjaGFyYWN0ZXIsIGFuZCBhIGRvbWFpbi4gIFRoZSAibCIKICAgbWFjcm8gZXhw YW5kcyB0byBqdXN0IHRoZSBsb2NhbHBhcnQuICBUaGUgIm8iIG1hY3JvIGV4cGFuZHMgdG8ganVz dAogICB0aGUgZG9tYWluIHBhcnQuICBOb3RlIHRoYXQgdGhlc2UgdmFsdWVzIHJlbWFpbiB0aGUg c2FtZSBkdXJpbmcKICAgcmVjdXJzaXZlIGFuZCBjaGFpbmVkIGV2YWx1YXRpb25zIGR1ZSB0byAi aW5jbHVkZSIgYW5kL29yICJyZWRpcmVjdCIuCiAgIE5vdGUgYWxzbyB0aGF0IGlmIHRoZSBvcmln aW5hbCA8c2VuZGVyPiBoYWQgbm8gbG9jYWxwYXJ0LCB0aGUKICAgbG9jYWxwYXJ0IHdhcyBzZXQg dG8gInBvc3RtYXN0ZXIiIGluIGluaXRpYWwgcHJvY2Vzc2luZyAoc2VlCiAgIFNlY3Rpb24gNC4z KS4KCltNU0s6IHMvbG9jYWxwYXJ0L2xvY2FsLXBhcnQvLCB4NF0KCiAgIEZvciBJUHY0IGFkZHJl c3NlcywgYm90aCB0aGUgImkiIGFuZCAiYyIgbWFjcm9zIGV4cGFuZCB0byB0aGUKCgoKS2l0dGVy bWFuICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAg W1BhZ2UgMzNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3Jr IChTUEYpICAgICAgICAgICAgSnVseSAyMDEyCgoKICAgc3RhbmRhcmQgZG90dGVkLXF1YWQgZm9y bWF0LgoKICAgRm9yIElQdjYgYWRkcmVzc2VzLCB0aGUgImkiIG1hY3JvIGV4cGFuZHMgdG8gYSBk b3QtZm9ybWF0IGFkZHJlc3M7IGl0CiAgIGlzIGludGVuZGVkIGZvciB1c2UgaW4gJXtpcn0uICBU aGUgImMiIG1hY3JvIE1BWSBleHBhbmQgdG8gYW55IG9mIHRoZQogICBoZXhhZGVjaW1hbCBjb2xv bi1mb3JtYXQgYWRkcmVzc2VzIHNwZWNpZmllZCBpbiBbUkZDNDI5MV0sIFNlY3Rpb24KICAgMi4y LiAgSXQgaXMgaW50ZW5kZWQgZm9yIGh1bWFucyB0byByZWFkLgoKICAgVGhlICJwIiBtYWNybyBl eHBhbmRzIHRvIHRoZSB2YWxpZGF0ZWQgZG9tYWluIG5hbWUgb2YgPGlwPi4gIFRoZQogICBwcm9j ZWR1cmUgZm9yIGZpbmRpbmcgdGhlIHZhbGlkYXRlZCBkb21haW4gbmFtZSBpcyBkZWZpbmVkIGlu CiAgIFNlY3Rpb24gNS41LiAgSWYgdGhlIDxkb21haW4+IGlzIHByZXNlbnQgaW4gdGhlIGxpc3Qg b2YgdmFsaWRhdGVkCiAgIGRvbWFpbnMsIGl0IFNIT1VMRCBiZSB1c2VkLiAgT3RoZXJ3aXNlLCBp ZiBhIHN1YmRvbWFpbiBvZiB0aGUKICAgPGRvbWFpbj4gaXMgcHJlc2VudCwgaXQgU0hPVUxEIGJl IHVzZWQuICBPdGhlcndpc2UsIGFueSBuYW1lIGZyb20gdGhlCiAgIGxpc3QgTUFZIGJlIHVzZWQu ICBJZiB0aGVyZSBhcmUgbm8gdmFsaWRhdGVkIGRvbWFpbiBuYW1lcyBvciBpZiBhIEROUwogICBl cnJvciBvY2N1cnMsIHRoZSBzdHJpbmcgInVua25vd24iIGlzIHVzZWQuICBUaGlzIG1hY3JvIGlz IGRlcHJlY2F0ZWQKICAgYW5kIFNIT1VMRCBOT1QgYmUgdXNlZC4KCltNU0s6IFRoZXJlJ3MgcHJv YmFibHkgbm90IGEgYmV0dGVyIGFsZ29yaXRobSwgYnV0IGl0J3MgdW5jb21mb3J0YWJsZSBoYXZp bmcgdGhlICJhbnkgbmFtZSIgcGFydCwgYmVjYXVzZSB0d28gZXZhbHVhdGlvbnMgb2YgdGhlIHNh bWUgbmFtZSBjb3VsZCB5aWVsZCBkaWZmZXJlbnQgZXhwYW5zaW9ucy5dCgogICBUaGUgInIiIG1h Y3JvIGV4cGFuZHMgdG8gdGhlIG5hbWUgb2YgdGhlIHJlY2VpdmluZyBNVEEuICBUaGlzIFNIT1VM RAogICBiZSBhIGZ1bGx5IHF1YWxpZmllZCBkb21haW4gbmFtZSwgYnV0IGlmIG9uZSBkb2VzIG5v dCBleGlzdCAoYXMgd2hlbgogICB0aGUgY2hlY2tpbmcgaXMgZG9uZSBieSBhIE1VQSkgb3IgaWYg cG9saWN5IHJlc3RyaWN0aW9ucyBkaWN0YXRlCiAgIG90aGVyd2lzZSwgdGhlIHdvcmQgInVua25v d24iIFNIT1VMRCBiZSBzdWJzdGl0dXRlZC4gIFRoZSBkb21haW4gbmFtZQogICBjYW4gYmUgZGlm ZmVyZW50IGZyb20gdGhlIG5hbWUgZm91bmQgaW4gdGhlIE1YIHJlY29yZCB0aGF0IHRoZSBjbGll bnQKICAgTVRBIHVzZWQgdG8gbG9jYXRlIHRoZSByZWNlaXZpbmcgTVRBLgoKICAgVGhlICJ0IiBt YWNybyBleHBhbmRzIHRvIHRoZSBkZWNpbWFsIHJlcHJlc2VudGF0aW9uIG9mIHRoZQogICBhcHBy b3hpbWF0ZSBudW1iZXIgb2Ygc2Vjb25kcyBzaW5jZSB0aGUgRXBvY2ggKE1pZG5pZ2h0LCBKYW51 YXJ5IDEsCiAgIDE5NzAsIFVUQykuICBUaGlzIGlzIHRoZSBzYW1lIHZhbHVlIGFzIGlzIHJldHVy bmVkIGJ5IHRoZSBQT1NJWAogICB0aW1lKCkgZnVuY3Rpb24gaW4gbW9zdCBzdGFuZGFyZHMtY29t cGxpYW50IGxpYnJhcmllcy4KCltNU0s6ICBXaGVuPyAgQXQgdGltZSBvZiBldmFsdWF0aW9uPyAg QXQgdGltZSBvZiBtZXNzYWdlIHJlY2VpcHQ/ICBTb21lIG90aGVyIHRpbWU/XQoKICAgV2hlbiB0 aGUgcmVzdWx0IG9mIG1hY3JvIGV4cGFuc2lvbiBpcyB1c2VkIGluIGEgZG9tYWluIG5hbWUgcXVl cnksIGlmCiAgIHRoZSBleHBhbmRlZCBkb21haW4gbmFtZSBleGNlZWRzIDI1MyBjaGFyYWN0ZXJz ICh0aGUgbWF4aW11bSBsZW5ndGgKICAgb2YgYSBkb21haW4gbmFtZSksIHRoZSBsZWZ0IHNpZGUg aXMgdHJ1bmNhdGVkIHRvIGZpdCwgYnkgcmVtb3ZpbmcKICAgc3VjY2Vzc2l2ZSBkb21haW4gbGFi ZWxzIHVudGlsIHRoZSB0b3RhbCBsZW5ndGggZG9lcyBub3QgZXhjZWVkIDI1MwogICBjaGFyYWN0 ZXJzLgoKW01TSzog4oCmYW5kIHRoZWlyIGZvbGxvd2luZyBkb3RzLCByaWdodD9dCgogICBVcHBl cmNhc2VkIG1hY3JvcyBleHBhbmQgZXhhY3RseSBhcyB0aGVpciBsb3dlcmNhc2VkIGVxdWl2YWxl bnRzLCBhbmQKICAgYXJlIHRoZW4gVVJMIGVzY2FwZWQuICBVUkwgZXNjYXBpbmcgbXVzdCBiZSBw ZXJmb3JtZWQgZm9yIGNoYXJhY3RlcnMKICAgbm90IGluIHRoZSAidW5yZXNlcnZlZCIgc2V0LCB3 aGljaCBpcyBkZWZpbmVkIGluIFtSRkMzOTg2XS4KCiAgIE5vdGU6IENhcmUgbXVzdCBiZSB0YWtl biBzbyB0aGF0IG1hY3JvIGV4cGFuc2lvbiBmb3IgbGVnaXRpbWF0ZSBlbWFpbAogICBkb2VzIG5v dCBleGNlZWQgdGhlIDYzLWNoYXJhY3RlciBsaW1pdCBvbiBETlMgbGFiZWxzLiAgVGhlIGxvY2Fs cGFydAogICBvZiBlbWFpbCBhZGRyZXNzZXMsIGluIHBhcnRpY3VsYXIsIGNhbiBoYXZlIG1vcmUg dGhhbiA2MyBjaGFyYWN0ZXJzCiAgIGJldHdlZW4gZG90cy4KCltNU0s6IHMvbG9jYWxwYXJ0L2xv Y2FsLXBhcnQvXQoKICAgTm90ZTogRG9tYWlucyBzaG91bGQgYXZvaWQgdXNpbmcgdGhlICJzIiwg ImwiLCAibyIsIG9yICJoIiBtYWNyb3MgaW4KCltNU0s6IHMvc2hvdWxkL1NIT1VMRC8sIG9yIHMv c2hvdWxkL2FyZSBhZHZpc2VkIHRvL10KCiAgIGNvbmp1bmN0aW9uIHdpdGggYW55IG1lY2hhbmlz bSBkaXJlY3RpdmUuICBBbHRob3VnaCB0aGVzZSBtYWNyb3MgYXJlCiAgIHBvd2VyZnVsIGFuZCBh bGxvdyBwZXItdXNlciByZWNvcmRzIHRvIGJlIHB1Ymxpc2hlZCwgdGhleSBzZXZlcmVseQogICBs aW1pdCB0aGUgYWJpbGl0eSBvZiBpbXBsZW1lbnRhdGlvbnMgdG8gY2FjaGUgcmVzdWx0cyBvZiBj aGVja19ob3N0KCkKCltNU0s6IHMvY2hlY2tfaG9zdCgpL0NoZWNrSG9zdC9dCgogICBhbmQgdGhl eSByZWR1Y2UgdGhlIGVmZmVjdGl2ZW5lc3Mgb2YgRE5TIGNhY2hlcy4KCgoKS2l0dGVybWFuICAg ICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2Ug MzRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYp ICAgICAgICAgICAgSnVseSAyMDEyCgoKICAgSW1wbGVtZW50YXRpb25zIHNob3VsZCBiZSBhd2Fy ZSB0aGF0IGlmIG5vIGRpcmVjdGl2ZSBwcm9jZXNzZWQgZHVyaW5nCiAgIHRoZSBldmFsdWF0aW9u IG9mIGNoZWNrX2hvc3QoKSBjb250YWlucyBhbiAicyIsICJsIiwgIm8iLCBvciAiaCIKCltNU0s6 IHMvY2hlY2tfaG9zdCgpL0NoZWNrSG9zdC9dCgogICBtYWNybywgdGhlbiB0aGUgcmVzdWx0cyBv ZiB0aGUgZXZhbHVhdGlvbiBjYW4gYmUgY2FjaGVkIG9uIHRoZSBiYXNpcwogICBvZiA8ZG9tYWlu PiBhbmQgPGlwPiBhbG9uZSBmb3IgYXMgbG9uZyBhcyB0aGUgc2hvcnRlc3QgVGltZSBUbyBMaXZl CiAgIChUVEwpIG9mIGFsbCB0aGUgRE5TIHJlY29yZHMgaW52b2x2ZWQuCgo4LjIuICBFeHBhbnNp b24gRXhhbXBsZXMKCiAgICAgIFRoZSA8c2VuZGVyPiBpcyBzdHJvbmctYmFkQGVtYWlsLmV4YW1w bGUuY29tLgogICAgICBUaGUgSVB2NCBTTVRQIGNsaWVudCBJUCBpcyAxOTIuMC4yLjMuCiAgICAg IFRoZSBJUHY2IFNNVFAgY2xpZW50IElQIGlzIDIwMDE6REI4OjpDQjAxLgogICAgICBUaGUgUFRS IGRvbWFpbiBuYW1lIG9mIHRoZSBjbGllbnQgSVAgaXMgbXguZXhhbXBsZS5vcmcuCgogICBtYWNy byAgICAgICAgICAgICAgICAgICAgICAgZXhwYW5zaW9uCiAgIC0tLS0tLS0gIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KICAgJXtzfSAgICAgc3Ryb25nLWJhZEBlbWFpbC5leGFtcGxlLmNv bQogICAle299ICAgICAgICAgICAgICAgIGVtYWlsLmV4YW1wbGUuY29tCiAgICV7ZH0gICAgICAg ICAgICAgICAgZW1haWwuZXhhbXBsZS5jb20KICAgJXtkNH0gICAgICAgICAgICAgICBlbWFpbC5l eGFtcGxlLmNvbQogICAle2QzfSAgICAgICAgICAgICAgIGVtYWlsLmV4YW1wbGUuY29tCiAgICV7 ZDJ9ICAgICAgICAgICAgICAgICAgICAgZXhhbXBsZS5jb20KICAgJXtkMX0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGNvbQogICAle2RyfSAgICAgICAgICAgICAgIGNvbS5leGFtcGxlLmVt YWlsCiAgICV7ZDJyfSAgICAgICAgICAgICAgICAgIGV4YW1wbGUuZW1haWwKICAgJXtsfSAgICAg ICAgICAgICAgICAgICAgICAgc3Ryb25nLWJhZAogICAle2wtfSAgICAgICAgICAgICAgICAgICAg ICBzdHJvbmcuYmFkCiAgICV7bHJ9ICAgICAgICAgICAgICAgICAgICAgIHN0cm9uZy1iYWQKICAg JXtsci19ICAgICAgICAgICAgICAgICAgICAgYmFkLnN0cm9uZwogICAle2wxci19ICAgICAgICAg ICAgICAgICAgICAgICAgc3Ryb25nCgogICBtYWNyby1zdHJpbmcgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4cGFuc2lvbgogICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogICAl e2lyfS4le3Z9Ll9zcGYuJXtkMn0gICAgICAgICAgICAgMy4yLjAuMTkyLmluLWFkZHIuX3NwZi5l eGFtcGxlLmNvbQogICAle2xyLX0ubHAuX3NwZi4le2QyfSAgICAgICAgICAgICAgICAgIGJhZC5z dHJvbmcubHAuX3NwZi5leGFtcGxlLmNvbQoKICAgJXtsci19LmxwLiV7aXJ9LiV7dn0uX3NwZi4l e2QyfQogICAgICAgICAgICAgICAgICAgICAgIGJhZC5zdHJvbmcubHAuMy4yLjAuMTkyLmluLWFk ZHIuX3NwZi5leGFtcGxlLmNvbQoKICAgJXtpcn0uJXt2fS4le2wxci19LmxwLl9zcGYuJXtkMn0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgMy4yLjAuMTkyLmluLWFkZHIuc3Ryb25nLmxwLl9z cGYuZXhhbXBsZS5jb20KCiAgICV7ZDJ9LnRydXN0ZWQtZG9tYWlucy5leGFtcGxlLm5ldAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4YW1wbGUuY29tLnRydXN0ZWQtZG9tYWlucy5l eGFtcGxlLm5ldAoKICAgSVB2NjoKICAgJXtpcn0uJXt2fS5fc3BmLiV7ZDJ9ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDEuMC5CLkMuMC4wLjAuMC4KICAgMC4wLjAuMC4wLjAuMC4wLjAu MC4wLjAuMC4wLjAuMC44LkIuRC4wLjEuMC4wLjIuaXA2Ll9zcGYuZXhhbXBsZS5jb20KCgoKCktp dHRlcm1hbiAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAg ICAgIFtQYWdlIDM1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1l d29yayAoU1BGKSAgICAgICAgICAgIEp1bHkgMjAxMgoKCjkuICBJbXBsaWNhdGlvbnMKCiAgIFRo aXMgc2VjdGlvbiBvdXRsaW5lcyB0aGUgbWFqb3IgaW1wbGljYXRpb25zIHRoYXQgYWRvcHRpb24g b2YgdGhpcwogICBkb2N1bWVudCB3aWxsIGhhdmUgb24gdmFyaW91cyBlbnRpdGllcyBpbnZvbHZl ZCBpbiBJbnRlcm5ldCBlbWFpbC4KICAgSXQgaXMgaW50ZW5kZWQgdG8gbWFrZSBjbGVhciB0byB0 aGUgcmVhZGVyIHdoZXJlIHRoaXMgZG9jdW1lbnQKICAga25vd2luZ2x5IGFmZmVjdHMgdGhlIG9w ZXJhdGlvbiBvZiBzdWNoIGVudGl0aWVzLiAgVGhpcyBzZWN0aW9uIGlzCiAgIG5vdCBhICJob3ct dG8iIG1hbnVhbCwgb3IgYSAiYmVzdCBwcmFjdGljZXMiIGRvY3VtZW50LCBhbmQgaXQgaXMgbm90 CiAgIGEgY29tcHJlaGVuc2l2ZSBsaXN0IG9mIHdoYXQgc3VjaCBlbnRpdGllcyBzaG91bGQgZG8g aW4gbGlnaHQgb2YgdGhpcwogICBkb2N1bWVudC4KCiAgIFRoaXMgc2VjdGlvbiBpcyBub24tbm9y bWF0aXZlLiAgW1JGQzU1OThdIGRlc2NyaWJlcyB0aGUgSW50ZXJuZXQKICAgZW1haWwgYXJjaGl0 ZWN0dXJlLiAgVGhpcyBzZWN0aW9uIGlzIG9yZ2FuaXplZCBiYXNlZCBvbiB0aGUgZGlmZmVyZW50 CiAgIHNlZ21lbnRzIG9mIHRoZSBhcmNoaXRlY3R1cmUuCgo5LjEuICBTZW5kaW5nIERvbWFpbnMK CiAgIE9yaWdpbmF0aW5nIEFETURzIChBRG1pbmlzdHJhdGl2ZSBNYW5hZ2VtZW50IERvbWFpbnMg LSBbUkZDNTU5OF0KICAgU2VjdGlvbiAyLjIuMSBhbmQgU2VjdGlvbiAyLjMpIHRoYXQgd2lzaCB0 byBiZSBjb21wbGlhbnQgd2l0aCB0aGlzCiAgIHNwZWNpZmljYXRpb24gd2lsbCBuZWVkIHRvIGRl dGVybWluZSB0aGUgbGlzdCBvZiByZWxheXMgKFtSRkM1NTk4XQogICBTZWN0aW9uIDIuMi4yKSB0 aGF0IHRoZXkgYWxsb3cgdG8gdXNlIHRoZWlyIGRvbWFpbiBuYW1lIGluIHRoZSAiSEVMTyIKICAg YW5kICJNQUlMIEZST00iIGlkZW50aXRpZXMgd2hlbiByZWxheWluZyB0byBvdGhlciBBRE1Ecy4g IEl0IGlzCiAgIHJlY29nbml6ZWQgdGhhdCBmb3JtaW5nIHN1Y2ggYSBsaXN0IGlzIG5vdCBqdXN0 IGEgc2ltcGxlIHRlY2huaWNhbAogICBleGVyY2lzZSwgYnV0IGludm9sdmVzIHBvbGljeSBkZWNp c2lvbnMgd2l0aCBib3RoIHRlY2huaWNhbCBhbmQKICAgYWRtaW5pc3RyYXRpdmUgY29uc2lkZXJh dGlvbnMuCgo5LjEuMS4gIEROUyBSZXNvdXJjZSBDb25zaWRlcmF0aW9ucwoKICAgTWluaW1pemlu ZyB0aGUgRE5TIHJlc291cmNlcyByZXF1aXJlZCBmb3IgU1BGIGxvb2t1cHMgY2FuIGJlIGRvbmUg YnkKICAgY2hvb3NpbmcgZGlyZWN0aXZlcyB0aGF0IHJlcXVpcmUgbGVzcyBETlMgaW5mb3JtYXRp b24gYW5kIHBsYWNpbmcKICAgbG93ZXItY29zdCBtZWNoYW5pc21zIGVhcmxpZXIgaW4gdGhlIFNQ RiByZWNvcmQuCgpbTVNLOiBzL2FuZCBwbGFjaW5nLywgYW5kIGJ5IHBsYWNpbmcvXQoKICAgRm9y IGV4YW1wbGUsIGNvbnNpZGVyIGEgZG9tYWluIHNldCB1cCBhcyBmb2xsb3dzOgoKICAgZXhhbXBs ZS5jb20uICAgICAgSU4gTVggICAxMCBteC5leGFtcGxlLmNvbS4KICAgbXguZXhhbXBsZS5jb20u ICAgSU4gQSAgICAxOTIuMC4yLjEKICAgYS5leGFtcGxlLmNvbS4gICAgSU4gVFhUICAidj1zcGYx IG14OmV4YW1wbGUuY29tIC1hbGwiCiAgIGIuZXhhbXBsZS5jb20uICAgIElOIFRYVCAgInY9c3Bm MSBhOm14LmV4YW1wbGUuY29tIC1hbGwiCiAgIGMuZXhhbXBsZS5jb20uICAgIElOIFRYVCAgInY9 c3BmMSBpcDQ6MTkyLjAuMi4xIC1hbGwiCgogICBFdmFsdWF0aW5nIGNoZWNrX2hvc3QoKSBmb3Ig dGhlIGRvbWFpbiAiYS5leGFtcGxlLmNvbSIgcmVxdWlyZXMgdGhlCgpbTVNLOiBzL2NoZWNrX2hv c3QoKS9DaGVja0hvc3QvLCBvciBiZXR0ZXIgIkNvbmR1Y3RpbmcgYSBDaGVja0hvc3QgZXZhbHVh dGlvbiJdCgogICBNWCByZWNvcmRzIGZvciAiZXhhbXBsZS5jb20iLCBhbmQgdGhlbiB0aGUgQSBy ZWNvcmRzIGZvciB0aGUgbGlzdGVkCiAgIGhvc3RzLiAgRXZhbHVhdGluZyBmb3IgImIuZXhhbXBs ZS5jb20iIHJlcXVpcmVzIG9ubHkgdGhlIEEgcmVjb3Jkcy4KICAgRXZhbHVhdGluZyBmb3IgImMu ZXhhbXBsZS5jb20iIHJlcXVpcmVzIG5vbmUuCgogICBTZWN0aW9uIDQuNi40IHNwZWNpZmllcyB0 aGUgbGltaXRzIHJlY2VpdmVycyBoYXZlIHRvIHVzZS4gIEl0IGlzCiAgIGVzc2VudGlhbCB0byBw dWJsaXNoIHJlY29yZHMgdGhhdCBkbyBub3QgZXhjZWVkIHRoZXNlIHJlcXVpcmVtZW50cy4KICAg QXMgYW4gZXhhbXBsZSwgaWYgeW91IGhhdmUgbW9yZSB0aGFuIDEwIE1YIHJlY29yZHMsIGRvIG5v dCB1c2UgdGhlCiAgICdNWCIgbWVjaGFuaXNtIHRvIGRlc2NyaWJlIHRoZW0gaW4geW91ciBTUEYg cmVjb3JkLgoKW01TSzogRGlmZmVyZW50IHF1b3RlIHN0eWxlIGFyb3VuZCAiTVgiLiAgUGljayBv bmUuXQoKCgpLaXR0ZXJtYW4gICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDYsIDIwMTMg ICAgICAgICAgICAgICBbUGFnZSAzNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgU2VuZGVyIFBv bGljeSBGcmFtZXdvcmsgKFNQRikgICAgICAgICAgICBKdWx5IDIwMTIKCgo5LjEuMi4gIEFkbWlu aXN0cmF0b3IncyBDb25zaWRlcmF0aW9ucwoKICAgVGhlcmUgbWlnaHQgYmUgYWRtaW5pc3RyYXRp dmUgY29uc2lkZXJhdGlvbnM6IHVzaW5nICJhIiBvdmVyICJpcDQiIG9yCiAgICJpcDYiIGFsbG93 cyBob3N0cyB0byBiZSByZW51bWJlcmVkIGVhc2lseS4gIFVzaW5nICJteCIgb3ZlciAiYSIKICAg YWxsb3dzIHRoZSBzZXQgb2YgbWFpbCBob3N0cyB0byBiZSBjaGFuZ2VkIGVhc2lseS4gIFVubGVz cyBzdWNoCiAgIGNoYW5nZXMgYXJlIGNvbW1vbiwgaXQgaXMgYmV0dGVyIHRvIHVzZSB0aGUgbGVz cyByZXNvdXJjZSBpbnRlbnNpdmUKICAgbWVjaGFuaXNtcyBsaWtlICJpcDQiIGFuZCAiaXA2Ii4K CiAgIFZhbGlkYXRpbmcgY29ycmVjdCBkZXBsb3ltZW50IGlzIGRpZmZpY3VsdC4gIFtSRkM2NjUy XSBkZXNjcmliZXMgb25lCiAgIG1lY2hhbmlzbSBmb3Igc29saWNpdGluZyBmZWVkYmFjayBvbiBT UEYgZmFpbHVyZXMuICBBbm90aGVyIGFwcHJvYWNoCiAgIHRoYXQgY2FuIGJlIGhlbHBmdWwgdG8g cHVibGlzaCByZWNvcmRzIHRoYXQgaW5jbHVkZSBhICJ0cmFja2luZwogICBleGlzdHM6IiBtZWNo YW5pc20uICBCeSBsb29raW5nIGF0IHRoZSBuYW1lIHNlcnZlciBsb2dzLCBhIHJvdWdoIGxpc3QK ICAgY2FuIHRoZW4gYmUgZ2VuZXJhdGVkLiAgRm9yIGV4YW1wbGU6CgogICAgICB2PXNwZjEgZXhp c3RzOl9oLiV7aH0uX2wuJXtsfS5fby4le299Ll9pLiV7aX0uX3NwZi4le2R9ID9hbGwKCiAgIFJl Z2FyZGxlc3Mgb2YgdGhlIG1ldGhvZCB1c2VkLCB1bmRlcnN0YW5kaW5nIHRoZSBBRE1EJ3Mgb3V0 Ym91bmQgbWFpbAogICBhcmNoaXRlY3R1cmUgaXMgZXNzZW50aWFsIHRvIGVmZmVjdGl2ZSBkZXBs b3ltZW50LgoKOS4yLiAgTWVkaWF0b3JzCgogICBCcm9hZGx5IHNwZWFraW5nLCB0aGVyZSBhcmUg dHdvIHR5cGVzIG9mIG1lZGlhdGluZyBBRE1EcyB0aGF0IGNhbgogICBhZmZlY3QgU1BGIGRlcGxv eW1lbnQgb2Ygb3RoZXIgQURNRHM6IG1haWxpbmcgbGlzdHMgKHNlZSBbUkZDNTU5OF0KICAgU2Vj dGlvbiA1LjMpIGFuZCBSZVNlbmRlcnMgKFtSRkM1NTk4XSBTZWN0aW9uIDUuMikuCgo5LjIuMS4g IE1haWxpbmcgTGlzdHMKCiAgIE1haWxpbmcgbGlzdHMgbXVzdCBiZSBhd2FyZSBvZiBob3cgdGhl eSByZS1pbmplY3QgbWFpbCB0aGF0IGlzIHNlbnQKICAgdG8gdGhlIGxpc3QuICBNYWlsaW5nIGxp c3RzIE1VU1QgY29tcGx5IHdpdGggdGhlIHJlcXVpcmVtZW50cyBpbgogICBbUkZDNTMyMV0sIFNl Y3Rpb24gMy4xMCwgYW5kIFtSRkMxMTIzXSwgU2VjdGlvbiA1LjMuNiwgdGhhdCBzYXkgdGhhdAog ICB0aGUgcmV2ZXJzZS1wYXRoIE1VU1QgYmUgY2hhbmdlZCB0byBiZSB0aGUgbWFpbGJveCBvZiBh IHBlcnNvbiBvcgogICBvdGhlciBlbnRpdHkgd2hvIGFkbWluaXN0ZXJzIHRoZSBsaXN0LiAgV2hl cmVhcyB0aGUgcmVhc29ucyBmb3IKICAgY2hhbmdpbmcgdGhlIHJldmVyc2UtcGF0aCBhcmUgbWFu eSBhbmQgbG9uZy1zdGFuZGluZywgU1BGIGFkZHMKICAgZW5mb3JjZW1lbnQgdG8gdGhpcyByZXF1 aXJlbWVudC4KCiAgIEluIHByYWN0aWNlLCBhbG1vc3QgYWxsIG1haWxpbmcgbGlzdCBzb2Z0d2Fy ZSBpbiB1c2UgYWxyZWFkeSBjb21wbGllcwogICB3aXRoIHRoaXMgcmVxdWlyZW1lbnQuICBNYWls aW5nIGxpc3RzIHRoYXQgZG8gbm90IGNvbXBseSBtaWdodAogICBlbmNvdW50ZXIgcHJvYmxlbXMg ZGVwZW5kaW5nIG9uIGhvdyBhY2Nlc3MgdG8gdGhlIGxpc3QgaXMgcmVzdHJpY3RlZC4KICAgU3Vj aCBsaXN0cyB0aGF0IGFyZSBlbnRpcmVseSBpbnRlcm5hbCB0byBhIGRvbWFpbiAob25seSBwZW9w bGUgaW4gdGhlCiAgIGRvbWFpbiBjYW4gc2VuZCB0byBvciByZWNlaXZlIGZyb20gdGhlIGxpc3Qp IGFyZSBub3QgYWZmZWN0ZWQuCgo5LjIuMi4gIEZvcndhcmRpbmcgU2VydmljZXMgYW5kIEFsaWFz ZXMKCiAgIEZvcndhcmRpbmcgc2VydmljZXMgdGFrZSBtYWlsIHRoYXQgaXMgcmVjZWl2ZWQgYXQg YSBtYWlsYm94IGFuZAogICBkaXJlY3QgaXQgdG8gc29tZSBleHRlcm5hbCBtYWlsYm94LiAgQXQg dGhlIHRpbWUgb2YgdGhpcyB3cml0aW5nLCB0aGUKICAgbmVhci11bml2ZXJzYWwgcHJhY3RpY2Ug b2Ygc3VjaCBzZXJ2aWNlcyBpcyB0byB1c2UgdGhlIG9yaWdpbmFsICJNQUlMCiAgIEZST00iIG9m IGEgbWVzc2FnZSB3aGVuIHJlLWluamVjdGluZyBpdCBmb3IgZGVsaXZlcnkgdG8gdGhlIGV4dGVy bmFsCiAgIG1haWxib3guICBbUkZDMTEyM10gYW5kIFtSRkM1MzIxXSBkZXNjcmliZSB0aGlzIGFj dGlvbiBhcyBhbiAiYWxpYXMiCgoKCktpdHRlcm1hbiAgICAgICAgICAgICAgICBFeHBpcmVzIEph bnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDM3XQoMCkludGVybmV0LURyYWZ0ICAg ICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1bHkgMjAxMgoK CiAgIHJhdGhlciB0aGFuIGEgIm1haWwgbGlzdCIuICBUaGlzIG1lYW5zIHRoYXQgdGhlIGV4dGVy bmFsIG1haWxib3gncwogICBNVEEgc2VlcyBhbGwgc3VjaCBtYWlsIGluIGEgY29ubmVjdGlvbiBm cm9tIGEgaG9zdCBvZiB0aGUgZm9yd2FyZGluZwogICBzZXJ2aWNlLCBhbmQgc28gdGhlICJNQUlM IEZST00iIGlkZW50aXR5IHdpbGwgbm90LCBpbiBnZW5lcmFsLCBwYXNzCiAgIGF1dGhvcml6YXRp b24uCgogICBUaGVyZSBhcmUgdGhyZWUgcGxhY2VzIHRoYXQgdGVjaG5pcXVlcyBjYW4gYmUgdXNl ZCB0byBhbWVsaW9yYXRlIHRoaXMKICAgcHJvYmxlbS4KCiAgIDEuICBUaGUgYmVnaW5uaW5nLCB3 aGVuIGVtYWlsIGlzIGZpcnN0IHNlbnQgKE9yaWdpbmF0aW5nIEFETURzKS4KCiAgICAgICAxLiAg Ik5ldXRyYWwiIHJlc3VsdHMgY291bGQgYmUgZ2l2ZW4gZm9yIElQIGFkZHJlc3NlcyB0aGF0IG1p Z2h0CiAgICAgICAgICAgYmUgZm9yd2FyZGVycywgaW5zdGVhZCBvZiAiZmFpbCIgcmVzdWx0cy4g IEZvciBleGFtcGxlOgoKICAgICAgICAgICAgICAidj1zcGYxIG14IC1leGlzdHM6JXtpcn0uc2Js LnNwYW1oYXVzLmV4YW1wbGUub3JnID9hbGwiCgogICAgICAgICAgIFRoaXMgd291bGQgY2F1c2Ug YSBsb29rdXAgb24gYW4gYW50aS1zcGFtIEROUyBibGFja2xpc3QKICAgICAgICAgICAoRE5TQkwp IGFuZCBjYXVzZSBhIHJlc3VsdCBvZiAiZmFpbCIgb25seSBmb3IgZW1haWwgY29taW5nCiAgICAg ICAgICAgZnJvbSBsaXN0ZWQgc291cmNlcy4gIEFsbCBvdGhlciBlbWFpbCwgaW5jbHVkaW5nIGVt YWlsIHNlbnQKICAgICAgICAgICB0aHJvdWdoIGZvcndhcmRlcnMsIHdvdWxkIHJlY2VpdmUgYSAi bmV1dHJhbCIgcmVzdWx0LiAgQnkKICAgICAgICAgICBjaGVja2luZyB0aGUgRE5TQkwgYWZ0ZXIg dGhlIGtub3duIGdvb2Qgc291cmNlcywgcHJvYmxlbXMKICAgICAgICAgICB3aXRoIGluY29ycmVj dCBsaXN0aW5nIG9uIHRoZSBETlNCTCBhcmUgZ3JlYXRseSByZWR1Y2VkLgoKICAgICAgIDIuICBU aGUgIk1BSUwgRlJPTSIgaWRlbnRpdHkgY291bGQgaGF2ZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9u IGluCiAgICAgICAgICAgdGhlIGxvY2FscGFydCB0aGF0IGNyeXB0b2dyYXBoaWNhbGx5IGlkZW50 aWZpZXMgdGhlIG1haWwgYXMKCltNU0s6IHMvbG9jYWxwYXJ0L2xvY2FsLXBhcnQvZ10KCiAgICAg ICAgICAgY29taW5nIGZyb20gYW4gYXV0aG9yaXplZCBzb3VyY2UuICBJbiB0aGlzIGNhc2UsIHN1 Y2ggYW4gU1BGCiAgICAgICAgICAgcmVjb3JkIGNvdWxkIGJlIHVzZWQ6CgogICAgICAgICAgICAg ICJ2PXNwZjEgbXggZXhpc3RzOiV7bH0uX3NwZl92ZXJpZnkuJXtkfSAtYWxsIgoKICAgICAgICAg ICBUaGVuLCBhIHNwZWNpYWxpemVkIEROUyBzZXJ2ZXIgY2FuIGJlIHNldCB1cCB0byBzZXJ2ZSB0 aGUKICAgICAgICAgICBfc3BmX3ZlcmlmeSBzdWJkb21haW4gdGhhdCB2YWxpZGF0ZXMgdGhlIGxv Y2FscGFydC4gIEFsdGhvdWdoCiAgICAgICAgICAgdGhpcyByZXF1aXJlcyBhbiBleHRyYSBETlMg bG9va3VwLCB0aGlzIGhhcHBlbnMgb25seSB3aGVuIHRoZQogICAgICAgICAgIGVtYWlsIHdvdWxk IG90aGVyd2lzZSBiZSByZWplY3RlZCBhcyBub3QgY29taW5nIGZyb20gYSBrbm93bgogICAgICAg ICAgIGdvb2Qgc291cmNlLgogICAgICAgICAgIE5vdGUgdGhhdCBkdWUgdG8gdGhlIDYzLWNoYXJh Y3RlciBsaW1pdCBmb3IgZG9tYWluIGxhYmVscywKICAgICAgICAgICB0aGlzIGFwcHJvYWNoIG9u bHkgd29ya3MgcmVsaWFibHkgaWYgdGhlIGxvY2FscGFydCBzaWduYXR1cmUKICAgICAgICAgICBz Y2hlbWUgaXMgZ3VhcmFudGVlZCBlaXRoZXIgdG8gb25seSBwcm9kdWNlIGxvY2FscGFydHMgd2l0 aCBhCiAgICAgICAgICAgbWF4aW11bSBvZiA2MyBjaGFyYWN0ZXJzIG9yIHRvIGdyYWNlZnVsbHkg aGFuZGxlIHRydW5jYXRlZAogICAgICAgICAgIGxvY2FscGFydHMuCgpbTVNLOiBzL2xvY2FscGFy dC9sb2NhbC1wYXJ0LywgeDRdCgpbTVNLOiBzL3RvIG9ubHkgcHJvZHVjZS90byBwcm9kdWNlIG9u bHkvXQoKICAgICAgIDMuICBTaW1pbGFybHksIGEgc3BlY2lhbGl6ZWQgRE5TIHNlcnZlciBjb3Vs ZCBiZSBzZXQgdXAgdGhhdCB3aWxsCiAgICAgICAgICAgcmF0ZS1saW1pdCB0aGUgZW1haWwgY29t aW5nIGZyb20gdW5leHBlY3RlZCBJUCBhZGRyZXNzZXMuCgogICAgICAgICAgICAgICJ2PXNwZjEg bXggZXhpc3RzOiV7aXJ9Ll9zcGZfcmF0ZS4le2R9IC1hbGwiCgogICAgICAgNC4gIFNQRiBhbGxv d3MgdGhlIGNyZWF0aW9uIG9mIHBlci11c2VyIHBvbGljaWVzIGZvciBzcGVjaWFsCiAgICAgICAg ICAgY2FzZXMuICBGb3IgZXhhbXBsZSwgdGhlIGZvbGxvd2luZyBTUEYgcmVjb3JkIGFuZCBhcHBy b3ByaWF0ZQogICAgICAgICAgIHdpbGRjYXJkIEROUyByZWNvcmRzIGNhbiBiZSB1c2VkOgoKCgpL aXR0ZXJtYW4gICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDYsIDIwMTMgICAgICAgICAg ICAgICBbUGFnZSAzOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgU2VuZGVyIFBvbGljeSBGcmFt ZXdvcmsgKFNQRikgICAgICAgICAgICBKdWx5IDIwMTIKCgogICAgICAgICAgICAgICJ2PXNwZjEg bXggcmVkaXJlY3Q9JXtsMXIrfS5fYXRfLiV7b30uX3NwZi4le2R9IgoKW01TSzogQW4gZXhhbXBs ZSBleHBhbnNpb24gaGVyZSB3b3VsZCBiZSB1c2VmdWwuXQoKICAgMi4gIFRoZSBtaWRkbGUsIHdo ZW4gZW1haWwgaXMgZm9yd2FyZGVkIChNZWRpYXRpbmcgQURNRHMpLgoKICAgICAgIDEuICBGb3J3 YXJkaW5nIHNlcnZpY2VzIGNhbiBzb2x2ZSB0aGUgcHJvYmxlbSBieSByZXdyaXRpbmcgdGhlCiAg ICAgICAgICAgIk1BSUwgRlJPTSIgdG8gYmUgaW4gdGhlaXIgb3duIGRvbWFpbi4gIFRoaXMgbWVh bnMgdGhhdCBtYWlsCgpbTVNLOiBzL21lYW5zIHRoYXQvbWVhbnMvXQoKICAgICAgICAgICByZWpl Y3RlZCBmcm9tIHRoZSBleHRlcm5hbCBtYWlsYm94IHdpbGwgaGF2ZSB0byBiZSBmb3J3YXJkZWQK ICAgICAgICAgICBiYWNrIHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIgYnkgdGhlIGZvcndhcmRpbmcg c2VydmljZS4KICAgICAgICAgICBWYXJpb3VzIHNjaGVtZXMgdG8gZG8gdGhpcyBleGlzdCB0aG91 Z2ggdGhleSB2YXJ5IHdpZGVseSBpbgogICAgICAgICAgIGNvbXBsZXhpdHkgYW5kIHJlc291cmNl IHJlcXVpcmVtZW50cyBvbiB0aGUgcGFydCBvZiB0aGUKICAgICAgICAgICBmb3J3YXJkaW5nIHNl cnZpY2UuCgogICAgICAgMi4gIFNldmVyYWwgcG9wdWxhciBNVEFzIGNhbiBiZSBmb3JjZWQgZnJv bSAiYWxpYXMiIHNlbWFudGljcyB0bwogICAgICAgICAgICJtYWlsaW5nIGxpc3QiIHNlbWFudGlj cyBieSBjb25maWd1cmluZyBhbiBhZGRpdGlvbmFsIGFsaWFzCiAgICAgICAgICAgd2l0aCAib3du ZXItIiBwcmVwZW5kZWQgdG8gdGhlIG9yaWdpbmFsIGFsaWFzIG5hbWUgKGUuZy4sIGFuCiAgICAg ICAgICAgYWxpYXMgb2YgImZyaWVuZHM6IGdlb3JnZUBleGFtcGxlLmNvbSwgZnJlZEBleGFtcGxl Lm9yZyIKICAgICAgICAgICB3b3VsZCBuZWVkIGFub3RoZXIgYWxpYXMgb2YgdGhlIGZvcm0gIm93 bmVyLWZyaWVuZHM6CiAgICAgICAgICAgbG9jYWxvd25lciIpLgoKICAgMy4gIFRoZSBlbmQsIHdo ZW4gZW1haWwgaXMgcmVjZWl2ZWQgKFJlY2VpdmluZyBBRE1EcykuCgogICAgICAgMS4gIElmIHRo ZSBvd25lciBvZiB0aGUgZXh0ZXJuYWwgbWFpbGJveCB3aXNoZXMgdG8gdHJ1c3QgdGhlCiAgICAg ICAgICAgZm9yd2FyZGluZyBzZXJ2aWNlLCBoZSBjYW4gZGlyZWN0IHRoZSBleHRlcm5hbCBtYWls Ym94J3MgTVRBCiAgICAgICAgICAgdG8gc2tpcCBTUEYgdGVzdHMgd2hlbiB0aGUgY2xpZW50IGhv c3QgYmVsb25ncyB0byB0aGUKICAgICAgICAgICBmb3J3YXJkaW5nIHNlcnZpY2UuCgogICAgICAg Mi4gIFRlc3RzIGFnYWluc3Qgb3RoZXIgaWRlbnRpdGllcywgc3VjaCBhcyB0aGUgIkhFTE8iIGlk ZW50aXR5LAogICAgICAgICAgIE1BWSBiZSB1c2VkIHRvIG92ZXJyaWRlIGEgZmFpbGVkIHRlc3Qg YWdhaW5zdCB0aGUgIk1BSUwgRlJPTSIKICAgICAgICAgICBpZGVudGl0eS4KCiAgICAgICAzLiAg Rm9yIGxhcmdlciBkb21haW5zLCBpdCBtaWdodCBub3QgYmUgcG9zc2libGUgdG8gaGF2ZSBhCiAg ICAgICAgICAgY29tcGxldGUgb3IgYWNjdXJhdGUgbGlzdCBvZiBmb3J3YXJkaW5nIHNlcnZpY2Vz IHVzZWQgYnkgdGhlCiAgICAgICAgICAgb3duZXJzIG9mIHRoZSBkb21haW4ncyBtYWlsYm94ZXMu ICBJbiBzdWNoIGNhc2VzLCB3aGl0ZWxpc3RzCiAgICAgICAgICAgb2YgZ2VuZXJhbGx5LXJlY29n bml6ZWQgZm9yd2FyZGluZyBzZXJ2aWNlcyBjb3VsZCBiZQogICAgICAgICAgIGVtcGxveWVkLgoK OS4zLiAgTWFpbCBTZXJ2aWNlcwoKICAgTVNQcyAoTWFpbCBTZXJ2aWNlIFByb3ZpZGVycyAtIFtS RkM1NTk4XSBTZWN0aW9uIDIuMykgdGhhdCBvZmZlciBtYWlsCiAgIHNlcnZpY2VzIHRvIHRoaXJk LXBhcnR5IGRvbWFpbnMsIHN1Y2ggYXMgc2VuZGluZyBvZiBidWxrIG1haWwsIG1pZ2h0CiAgIHdh bnQgdG8gYWRqdXN0IHRoZWlyIHNldHVwIGluIGxpZ2h0IG9mIHRoZSBhdXRob3JpemF0aW9uIGNo ZWNrCgpbTVNLOiBzL3NldHVwL2NvbmZpZ3VyYXRpb25zLzsgIk1TUHMiIGlzIHBsdXJhbCwgc28g dGhpcyBoYXMgdG8gYmUgdG9vLCBvdGhlcndpc2Ugd2UncmUgc2F5aW5nIGFsbCBNU1BzIGhhdmUg YSBzaW5nbGUgc2V0dXBdCgogICBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4gIElmIHRoZSAi TUFJTCBGUk9NIiBpZGVudGl0eSB1c2VkIGZvcgogICBzdWNoIGVtYWlsIHVzZXMgdGhlIGRvbWFp biBvZiB0aGUgc2VydmljZSBwcm92aWRlciwgdGhlbiB0aGUgcHJvdmlkZXIKICAgbmVlZHMgb25s eSB0byBlbnN1cmUgdGhhdCBpdHMgc2VuZGluZyBob3N0IGlzIGF1dGhvcml6ZWQgYnkgaXRzIG93 bgogICBTUEYgcmVjb3JkLCBpZiBhbnkuCgpbTVNLOiBJJ20gZ2V0dGluZyB3YXJ5IG9mIHRoZSB1 c2Ugb2YgImRvbWFpbiIgbm93LCBhbmQgaW4gcmV0cm9zcGVjdCBJIHNob3VsZCd2ZSBiZWVuIGxv b2tpbmcgYXQgdGhpcyB0aHJvdWdob3V0IHRoZSBkb2N1bWVudC4gIEROU0RJUiBoYXMgYmVlbiBr bm93biB0byBnZXQgY3Jhbmt5IGFib3V0IHRoZSB1c2Ugb2YgdGhhdCB3b3JkIHdoZW4gdGhlIHNw ZWNpZmljIGNvbnRleHQgaXNuJ3QgY2xlYXIuICBEaWQgeW91IG1lYW4gQURNRCBoZXJlLCBvciBE TlMgZG9tYWluIG5hbWUsIGZvciBleGFtcGxlP10KCiAgIElmIHRoZSAiTUFJTCBGUk9NIiBpZGVu dGl0eSBkb2VzIG5vdCB1c2UgdGhlIG1haWwgc2VydmljZSBwcm92aWRlcidzCiAgIGRvbWFpbiwg dGhlbiBleHRyYSBjYXJlIG11c3QgYmUgdGFrZW4uICBUaGUgU1BGIHJlY29yZCBmb3JtYXQgaGFz CgoKCktpdHRlcm1hbiAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAg ICAgICAgICAgIFtQYWdlIDM5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5 IEZyYW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1bHkgMjAxMgoKCiAgIHNldmVyYWwgb3B0aW9u cyBmb3IgdGhlIHRoaXJkLXBhcnR5IGRvbWFpbiB0byBhdXRob3JpemUgdGhlIHNlcnZpY2UKICAg cHJvdmlkZXIncyBNVEFzIHRvIHNlbmQgbWFpbCBvbiBpdHMgYmVoYWxmLiAgRm9yIG1haWwgc2Vy dmljZQogICBwcm92aWRlcnMsIHN1Y2ggYXMgSVNQcywgdGhhdCBoYXZlIGEgd2lkZSB2YXJpZXR5 IG9mIGN1c3RvbWVycyB1c2luZwogICB0aGUgc2FtZSBNVEEsIHN0ZXBzIHNob3VsZCBiZSB0YWtl biB0byBwcmV2ZW50IGNyb3NzLWN1c3RvbWVyIGZvcmdlcnkKICAgKHNlZSBTZWN0aW9uIDEwLjQp LgoKOS40LiAgTVRBIFJlbGF5cwoKICAgUmVsYXlzIGFyZSBkZXNjcmliZWQgaW4gW1JGQzU1OThd IFNlY3Rpb24gMi4yLjIuICBUaGUgYXV0aG9yaXphdGlvbgogICBjaGVjayBnZW5lcmFsbHkgcHJl Y2x1ZGVzIHRoZSB1c2Ugb2YgYXJiaXRyYXJ5IE1UQSByZWxheXMgYmV0d2VlbgogICBzZW5kZXIg YW5kIHJlY2VpdmVyIG9mIGFuIGVtYWlsIG1lc3NhZ2UuCgogICBXaXRoaW4gYW4gb3JnYW5pemF0 aW9uLCBNVEEgcmVsYXlzIGNhbiBiZSBlZmZlY3RpdmVseSBkZXBsb3llZC4KICAgSG93ZXZlciwg Zm9yIHB1cnBvc2VzIG9mIHRoaXMgZG9jdW1lbnQsIHN1Y2ggcmVsYXlzIGFyZSBlZmZlY3RpdmVs eQogICB0cmFuc3BhcmVudC4gIFRoZSBTUEYgYXV0aG9yaXphdGlvbiBjaGVjayBpcyBhIGNoZWNr IGJldHdlZW4gYm9yZGVyCiAgIE1UQXMgb2YgZGlmZmVyZW50IEFETURzLgoKICAgRm9yIG1haWwg c2VuZGVycywgdGhpcyBtZWFucyB0aGF0IHB1Ymxpc2hlZCBTUEYgcmVjb3JkcyBtdXN0CiAgIGF1 dGhvcml6ZSBhbnkgTVRBcyB0aGF0IGFjdHVhbGx5IHNlbmQgYWNyb3NzIHRoZSBJbnRlcm5ldC4g IFVzdWFsbHksCiAgIHRoZXNlIGFyZSBqdXN0IHRoZSBib3JkZXIgTVRBcyBhcyBpbnRlcm5hbCBN VEFzIHNpbXBseSBmb3J3YXJkIG1haWwKICAgdG8gdGhlc2UgTVRBcyBmb3IgZGVsaXZlcnkuCgog ICBUaGUgcmVjZWl2aW5nIEFETUQgd2lsbCBnZW5lcmFsbHkgd2FudCB0byBwZXJmb3JtIHRoZSBh dXRob3JpemF0aW9uCiAgIGNoZWNrIGF0IHRoZSBib3VuZGFyeSBNVEFzLCBzcGVjaWZpY2FsbHkg aW5jbHVkaW5nIGFsbCBzZWNvbmRhcnkgTVhzLgogICBUaGlzIGFsbG93cyBtYWlsIHRoYXQgZmFp bHMgdG8gYmUgcmVqZWN0ZWQgZHVyaW5nIHRoZSBTTVRQIHNlc3Npb24KICAgcmF0aGVyIHRoYW4g c2VuZGluZyBhIGZhaWx1cmUgcmVwb3J0LiAgSW50ZXJuYWwgTVRBcyB0aGVuIGRvIG5vdAoKW01T SzogImZhaWxzIHRvIGJlIHJlamVjdGVkIiBpcyBhbWJpZ3VvdXMuICBTdWdnZXN0ICJmYWlscyBD aGVja0hvc3QiIGluc3RlYWQuXQoKICAgcGVyZm9ybSB0aGUgYXV0aG9yaXphdGlvbiB0ZXN0LiAg VG8gcGVyZm9ybSB0aGUgYXV0aG9yaXphdGlvbiB0ZXN0CiAgIG90aGVyIHRoYW4gYXQgdGhlIGJv dW5kYXJ5LCB0aGUgaG9zdCB0aGF0IGZpcnN0IHRyYW5zZmVycmVkIHRoZQogICBtZXNzYWdlIHRv IHRoZSBvcmdhbml6YXRpb24gbXVzdCBiZSBkZXRlcm1pbmVkLCB3aGljaCBjYW4gYmUKICAgZGlm ZmljdWx0IHRvIGV4dHJhY3QgZnJvbSB0aGUgbWVzc2FnZSBoZWFkZXIuICBUZXN0aW5nIG90aGVy IHRoYW4gYXQKICAgdGhlIGJvdW5kYXJ5IGlzIGxpa2VseSB0byBwcm9kdWNlIHVucmVsaWFibGUg cmVzdWx0cy4KCltNU0s6IEkgbWlnaHQgYmUgbW9yZSBzcGVjaWZpYyBhbmQgbWVudGlvbiB0aGF0 IHRoZSBkaWZmaWN1bHR5IGFyaXNlcyBmcm9tIHRoZSBmYWN0cyB0aGF0IChhKSBoZWFkZXIgZmll bGRzIGNhbiBiZSBmb3JnZWQgb3IgbWFsZm9ybWVkLCBhbmQgKGIpIHRoZXJlJ3Mgbm8gc3RhbmRh cmQgd2F5IHRvIGVuY29kZSB0aGF0IGluZm9ybWF0aW9uIHN1Y2ggdGhhdCBpdCBjYW4gYmUgcmVs aWFibHkgZXh0cmFjdGVkLl0KCgoKCgoKCgoKCgoKCgoKCgoKS2l0dGVybWFuICAgICAgICAgICAg ICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgNDBdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpICAgICAgICAg ICAgSnVseSAyMDEyCgoKMTAuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKMTAuMS4gIFByb2Nl c3NpbmcgTGltaXRzCgogICBBcyB3aXRoIG1vc3QgYXNwZWN0cyBvZiBlbWFpbCwgdGhlcmUgYXJl IGEgbnVtYmVyIG9mIHdheXMgdGhhdAogICBtYWxpY2lvdXMgcGFydGllcyBjb3VsZCB1c2UgdGhl IHByb3RvY29sIGFzIGFuIGF2ZW51ZSBmb3IgYQogICBEZW5pYWwtb2YtU2VydmljZSAoRG9TKSBh dHRhY2suICBUaGUgcHJvY2Vzc2luZyBsaW1pdHMgb3V0bGluZWQgaW4KICAgU2VjdGlvbiA0LjYu NCBhcmUgZGVzaWduZWQgdG8gcHJldmVudCBhdHRhY2tzIHN1Y2ggYXMgdGhlIGZvbGxvd2luZzoK CiAgIG8gIEEgbWFsaWNpb3VzIHBhcnR5IGNvdWxkIGNyZWF0ZSBhbiBTUEYgcmVjb3JkIHdpdGgg bWFueSByZWZlcmVuY2VzCiAgICAgIHRvIGEgdmljdGltJ3MgZG9tYWluIGFuZCBzZW5kIG1hbnkg ZW1haWxzIHRvIGRpZmZlcmVudCBTUEYKICAgICAgY2xpZW50czsgdGhvc2UgU1BGIGNsaWVudHMg d291bGQgdGhlbiBjcmVhdGUgYSBEb1MgYXR0YWNrLiAgSW4KICAgICAgZWZmZWN0LCB0aGUgU1BG IGNsaWVudHMgYXJlIGJlaW5nIHVzZWQgdG8gYW1wbGlmeSB0aGUgYXR0YWNrZXIncwogICAgICBi YW5kd2lkdGggYnkgdXNpbmcgZmV3ZXIgYnl0ZXMgaW4gdGhlIFNNVFAgc2Vzc2lvbiB0aGFuIGFy ZSB1c2VkCiAgICAgIGJ5IHRoZSBETlMgcXVlcmllcy4gIFVzaW5nIFNQRiBjbGllbnRzIGFsc28g YWxsb3dzIHRoZSBhdHRhY2tlciB0bwogICAgICBoaWRlIHRoZSB0cnVlIHNvdXJjZSBvZiB0aGUg YXR0YWNrLgoKICAgbyAgV2hlcmVhcyBpbXBsZW1lbnRhdGlvbnMgb2YgY2hlY2tfaG9zdCgpIGFy ZSBzdXBwb3NlZCB0byBsaW1pdCB0aGUKCltNU0s6IHMvY2hlY2tfaG9zdCgpL0NoZWNrSG9zdC9d CgogICAgICBudW1iZXIgb2YgRE5TIGxvb2t1cHMsIG1hbGljaW91cyBkb21haW5zIGNvdWxkIHB1 Ymxpc2ggcmVjb3JkcwogICAgICB0aGF0IGV4Y2VlZCB0aGVzZSBsaW1pdHMgaW4gYW4gYXR0ZW1w dCB0byB3YXN0ZSBjb21wdXRhdGlvbiBlZmZvcnQKICAgICAgYXQgdGhlaXIgdGFyZ2V0cyB3aGVu IHRoZXkgc2VuZCB0aGVtIG1haWwuICBNYWxpY2lvdXMgZG9tYWlucwogICAgICBjb3VsZCBhbHNv IGRlc2lnbiBTUEYgcmVjb3JkcyB0aGF0IGNhdXNlIHBhcnRpY3VsYXIKICAgICAgaW1wbGVtZW50 YXRpb25zIHRvIHVzZSBleGNlc3NpdmUgbWVtb3J5IG9yIENQVSB1c2FnZSwgb3IgdG8KICAgICAg dHJpZ2dlciBidWdzLgoKICAgbyAgTWFsaWNpb3VzIHBhcnRpZXMgY291bGQgc2VuZCBhIGxhcmdl IHZvbHVtZSBvZiBtYWlsIHB1cnBvcnRpbmcgdG8KICAgICAgY29tZSBmcm9tIHRoZSBpbnRlbmRl ZCB0YXJnZXQgdG8gYSB3aWRlIHZhcmlldHkgb2YgbGVnaXRpbWF0ZSBtYWlsCiAgICAgIGhvc3Rz LiAgVGhlc2UgbGVnaXRpbWF0ZSBtYWNoaW5lcyB3b3VsZCB0aGVuIHByZXNlbnQgYSBETlMgbG9h ZCBvbgogICAgICB0aGUgdGFyZ2V0IGFzIHRoZXkgZmV0Y2hlZCB0aGUgcmVsZXZhbnQgcmVjb3Jk cy4KCiAgIE9mIHRoZXNlLCB0aGUgY2FzZSBvZiBhIHRoaXJkIHBhcnR5IHJlZmVyZW5jZWQgaW4g dGhlIFNQRiByZWNvcmQgaXMKICAgdGhlIGVhc2llc3QgZm9yIGEgRG9TIGF0dGFjayB0byBlZmZl Y3RpdmVseSBleHBsb2l0LiAgQXMgYSByZXN1bHQsCiAgIGxpbWl0cyB0aGF0IG1pZ2h0IHNlZW0g cmVhc29uYWJsZSBmb3IgYW4gaW5kaXZpZHVhbCBtYWlsIHNlcnZlciBjYW4KICAgc3RpbGwgYWxs b3cgYW4gdW5yZWFzb25hYmxlIGFtb3VudCBvZiBiYW5kd2lkdGggYW1wbGlmaWNhdGlvbi4KICAg VGhlcmVmb3JlLCB0aGUgcHJvY2Vzc2luZyBsaW1pdHMgbmVlZCB0byBiZSBxdWl0ZSBsb3cuCgog ICBNVEFzIG9yIG90aGVyIHByb2Nlc3NvcnMgU0hPVUxEIGltcG9zZSBhIGxpbWl0IG9uIHRoZSBt YXhpbXVtIGFtb3VudAogICBvZiBlbGFwc2VkIHRpbWUgdG8gZXZhbHVhdGUgY2hlY2tfaG9zdCgp LiAgU3VjaCBhIGxpbWl0IFNIT1VMRCBhbGxvdwoKW01TSzogcy9ldmFsdWF0ZSBjaGVja19ob3N0 KCkvZXhlY3V0ZSBDaGVja0hvc3QvXQoKICAgYXQgbGVhc3QgMjAgc2Vjb25kcy4gIElmIHN1Y2gg YSBsaW1pdCBpcyBleGNlZWRlZCwgdGhlIHJlc3VsdCBvZgogICBhdXRob3JpemF0aW9uIFNIT1VM RCBiZSAidGVtcGVycm9yIi4KCltNU0s6IFdoZXJlIGFyZSB3ZSB0aGVzZSBkYXlzIG9uIG5vcm1h dGl2ZSBsYW5ndWFnZSBpbiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucz8gIEkgdGhvdWdodCB3ZSBj dXJyZW50bHkgZGlkbid0IGxpa2UgaXQuXQoKMTAuMi4gIFNQRi1BdXRob3JpemVkIEVtYWlsIE1h eSBDb250YWluIE90aGVyIEZhbHNlIElkZW50aXRpZXMKCiAgIFRoZSAiTUFJTCBGUk9NIiBhbmQg IkhFTE8iIGlkZW50aXR5IGF1dGhvcml6YXRpb25zIG11c3Qgbm90IGJlCiAgIGNvbnN0cnVlZCB0 byBwcm92aWRlIG1vcmUgYXNzdXJhbmNlIHRoYW4gdGhleSBkby4gIEl0IGlzIGVudGlyZWx5CiAg IHBvc3NpYmxlIGZvciBhIG1hbGljaW91cyBzZW5kZXIgdG8gaW5qZWN0IGEgbWVzc2FnZSB1c2lu ZyBoaXMgb3duCiAgIGRvbWFpbiBpbiB0aGUgaWRlbnRpdGllcyB1c2VkIGJ5IFNQRiwgdG8gaGF2 ZSB0aGF0IGRvbWFpbidzIFNQRgogICByZWNvcmQgYXV0aG9yaXplIHRoZSBzZW5kaW5nIGhvc3Qs IGFuZCB5ZXQgdGhlIG1lc3NhZ2UgY2FuIGVhc2lseQoKCgpLaXR0ZXJtYW4gICAgICAgICAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDYsIDIwMTMgICAgICAgICAgICAgICBbUGFnZSA0MV0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgU2VuZGVyIFBvbGljeSBGcmFtZXdvcmsgKFNQRikgICAgICAgICAg ICBKdWx5IDIwMTIKCgogICBsaXN0IG90aGVyIGlkZW50aXRpZXMgaW4gaXRzIGhlYWRlci4gIFVu bGVzcyB0aGUgdXNlciBvciB0aGUgTVVBCiAgIHRha2VzIGNhcmUgdG8gbm90ZSB0aGF0IHRoZSBh dXRob3JpemVkIGlkZW50aXR5IGRvZXMgbm90IG1hdGNoIHRoZQogICBvdGhlciBtb3JlIGNvbW1v bmx5LXByZXNlbnRlZCBpZGVudGl0aWVzIChzdWNoIGFzIHRoZSBGcm9tOiBoZWFkZXIKICAgZmll bGQpLCB0aGUgdXNlciBtaWdodCBiZSBsdWxsZWQgaW50byBhIGZhbHNlIHNlbnNlIG9mIHNlY3Vy aXR5LgoKMTAuMy4gIFNwb29mZWQgRE5TIGFuZCBJUCBEYXRhCgogICBUaGVyZSBhcmUgdHdvIGFz cGVjdHMgb2YgdGhpcyBwcm90b2NvbCB0aGF0IG1hbGljaW91cyBwYXJ0aWVzIGNvdWxkCiAgIGV4 cGxvaXQgdG8gdW5kZXJtaW5lIHRoZSB2YWxpZGl0eSBvZiB0aGUgY2hlY2tfaG9zdCgpIGZ1bmN0 aW9uOgoKICAgbyAgVGhlIGV2YWx1YXRpb24gb2YgY2hlY2tfaG9zdCgpIHJlbGllcyBoZWF2aWx5 IG9uIEROUy4gIEEgbWFsaWNpb3VzCiAgICAgIGF0dGFja2VyIGNvdWxkIGF0dGFjayB0aGUgRE5T IGluZnJhc3RydWN0dXJlIGFuZCBjYXVzZQogICAgICBjaGVja19ob3N0KCkgdG8gc2VlIHNwb29m ZWQgRE5TIGRhdGEsIGFuZCB0aGVuIHJldHVybiBpbmNvcnJlY3QKICAgICAgcmVzdWx0cy4gIFRo aXMgY291bGQgaW5jbHVkZSByZXR1cm5pbmcgInBhc3MiIGZvciBhbiA8aXA+IHZhbHVlCiAgICAg IHdoZXJlIHRoZSBhY3R1YWwgZG9tYWluJ3MgcmVjb3JkIHdvdWxkIGV2YWx1YXRlIHRvICJmYWls Ii4gIFNlZQogICAgICBbUkZDMzgzM10gZm9yIGEgZGVzY3JpcHRpb24gb2YgRE5TIHdlYWtuZXNz ZXMuCgpbTVNLOiBzL2NoZWNrX2hvc3QoKS9DaGVja0hvc3QvLCB4M10KCiAgIG8gIFRoZSBjbGll bnQgSVAgYWRkcmVzcywgPGlwPiwgaXMgYXNzdW1lZCB0byBiZSBjb3JyZWN0LiAgQQogICAgICBt YWxpY2lvdXMgYXR0YWNrZXIgY291bGQgc3Bvb2YgVENQIHNlcXVlbmNlIG51bWJlcnMgdG8gbWFr ZSBtYWlsCiAgICAgIGFwcGVhciB0byBjb21lIGZyb20gYSBwZXJtaXR0ZWQgaG9zdCBmb3IgYSBk b21haW4gdGhhdCB0aGUKICAgICAgYXR0YWNrZXIgaXMgaW1wZXJzb25hdGluZy4KCjEwLjQuICBD cm9zcy1Vc2VyIEZvcmdlcnkKCiAgIEJ5IGRlZmluaXRpb24sIFNQRiBwb2xpY2llcyBqdXN0IG1h cCBkb21haW4gbmFtZXMgdG8gc2V0cyBvZgogICBhdXRob3JpemVkIE1UQXMsIG5vdCB3aG9sZSBl bWFpbCBhZGRyZXNzZXMgdG8gc2V0cyBvZiBhdXRob3JpemVkCiAgIHVzZXJzLiAgQWx0aG91Z2gg dGhlICJsIiBtYWNybyAoU2VjdGlvbiA4KSBwcm92aWRlcyBhIGxpbWl0ZWQgd2F5IHRvCiAgIGRl ZmluZSBpbmRpdmlkdWFsIHNldHMgb2YgYXV0aG9yaXplZCBNVEFzIGZvciBzcGVjaWZpYyBlbWFp bAogICBhZGRyZXNzZXMsIGl0IGlzIGdlbmVyYWxseSBpbXBvc3NpYmxlIHRvIHZlcmlmeSwgdGhy b3VnaCBTUEYsIHRoZSB1c2UKICAgb2Ygc3BlY2lmaWMgZW1haWwgYWRkcmVzc2VzIGJ5IGluZGl2 aWR1YWwgdXNlcnMgb2YgdGhlIHNhbWUgTVRBLgoKICAgSXQgaXMgdXAgdG8gbWFpbCBzZXJ2aWNl cyBhbmQgdGhlaXIgTVRBcyB0byBkaXJlY3RseSBwcmV2ZW50CiAgIGNyb3NzLXVzZXIgZm9yZ2Vy eTogYmFzZWQgb24gU01UUCBBVVRIIChbUkZDNDk1NF0pLCB1c2VycyBzaG91bGQgYmUKICAgcmVz dHJpY3RlZCB0byB1c2luZyBvbmx5IHRob3NlIGVtYWlsIGFkZHJlc3NlcyB0aGF0IGFyZSBhY3R1 YWxseQogICB1bmRlciB0aGVpciBjb250cm9sIChzZWUgW1JGQzY0MDldLCBTZWN0aW9uIDYuMSku ICBBbm90aGVyIG1lYW5zIHRvCiAgIHZlcmlmeSB0aGUgaWRlbnRpdHkgb2YgaW5kaXZpZHVhbCB1 c2VycyBpcyBtZXNzYWdlIGNyeXB0b2dyYXBoeSBzdWNoCiAgIGFzIFBHUCAoW1JGQzQ4ODBdKSBv ciBTL01JTUUgKFtSRkM1NzUxXSkuCgoxMC41LiAgVW50cnVzdGVkIEluZm9ybWF0aW9uIFNvdXJj ZXMKCiAgIEFuIFNQRiBjb21wbGlhbnQgcmVjZWl2ZXIgZ2F0aGVycyBpbmZvcm1hdGlvbiBmcm9t IHRoZSBTTVRQIGNvbW1hbmRzCiAgIGl0IHJlY2VpdmVzIGFuZCBmcm9tIHRoZSBwdWJsaXNoZWQg RE5TIHJlY29yZHMgb2YgdGhlIHNlbmRpbmcgZG9tYWluCiAgIGhvbGRlciwgKGUuZy4sICJIRUxP IiBkb21haW4gbmFtZSwgdGhlICJNQUlMIEZST00iIGFkZHJlc3MgZnJvbSB0aGUKICAgZW52ZWxv cGUsIGFuZCBTUEYgRE5TIHJlY29yZHMgcHVibGlzaGVkIGJ5IHRoZSBkb21haW4gaG9sZGVyKS4K CiAgIFRoaXMgaW5mb3JtYXRpb24sIHBhc3NlZCB0byB0aGUgcmVjZWl2ZXIgaW4gdGhlIFJlY2Vp dmVkLVNQRjogdHJhY2UKICAgZmllbGRzLCBtYXkgYmUgcmV0dXJuZWQgdG8gdGhlIGNsaWVudCBN VEEgYXMgYW4gU01UUCByZWplY3Rpb24KCltNU0s6IG9yIEF1dGhlbnRpY2F0aW9uLVJlc3VsdHMg KGluY2x1ZGUgcmVmZXJlbmNlKSBmaWVsZHNdCgogICBtZXNzYWdlLiAgSWYgc3VjaCBhbiBTTVRQ IHJlamVjdGlvbiBtZXNzYWdlIGlzIGdlbmVyYXRlZCwgdGhlCgoKCktpdHRlcm1hbiAgICAgICAg ICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDQyXQoM CkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BGKSAgICAg ICAgICAgIEp1bHkgMjAxMgoKCiAgIGluZm9ybWF0aW9uIGZyb20gdGhlIHRyYWNlIGZpZWxkcyBt dXN0IGJlIGNoZWNrZWQgZm9yIHN1Y2ggcHJvYmxlbXMKICAgYXMgaW52YWxpZCBjaGFyYWN0ZXJz IGFuZCBleGNlc3NpdmVseSBsb25nIGxpbmVzLgoKW01TSzogcy9tdXN0L01VU1QvLCBvciBzL211 c3QvaXMgdG8vXQoKICAgV2hlbiB0aGUgYXV0aG9yaXphdGlvbiBjaGVjayBmYWlscywgYW4gZXhw bGFuYXRpb24gc3RyaW5nIGNvdWxkIGJlCiAgIGluY2x1ZGVkIGluIHRoZSByZWplY3QgcmVzcG9u c2UuICBCb3RoIHRoZSBzZW5kZXIgYW5kIHRoZSByZWplY3RpbmcKICAgcmVjZWl2ZXIgbmVlZCB0 byBiZSBhd2FyZSB0aGF0IHRoZSBleHBsYW5hdGlvbiB3YXMgZGV0ZXJtaW5lZCBieSB0aGUKICAg cHVibGlzaGVyIG9mIHRoZSBTUEYgcmVjb3JkIGNoZWNrZWQgYW5kLCBpbiBnZW5lcmFsLCBub3Qg dGhlCiAgIHJlY2VpdmVyLiAgVGhlIGV4cGxhbmF0aW9uIGNhbiBjb250YWluIG1hbGljaW91cyBV UkxzLCBvciBpdCBtaWdodCBiZQogICBvZmZlbnNpdmUgb3IgbWlzbGVhZGluZy4KCiAgIEV4cGxh bmF0aW9ucyByZXR1cm5lZCB0byBzZW5kZXIgZG9tYWlucyBkdWUgdG8gZXhwIG1vZGlmaWVycywK CltNU0s6IFF1b3RlICJleHAiXQoKICAgKFNlY3Rpb24gNi4yKSwgd2VyZSBnZW5lcmF0ZWQgYnkg dGhlIHNlbmRlciBwb2xpY3kgcHVibGlzaGVkIGJ5IHRoZQogICBkb21haW4gaG9sZGVycyB0aGVt c2VsdmVzLiAgQXMgbG9uZyBhcyBtZXNzYWdlcyBhcmUgb25seSByZXR1cm5lZAogICB3aXRoIG5v bi1kZWxpdmVyeSBub3RpZmljYXRpb24gdG8gZG9tYWlucyBwdWJsaXNoaW5nIHRoZSBleHBsYW5h dGlvbgogICBzdHJpbmdzIGZyb20gdGhlaXIgb3duIEROUyBTUEYgcmVjb3JkcywgdGhlIG9ubHkg YWZmZWN0ZWQgcGFydGllcyBhcmUKICAgdGhlIG9yaWdpbmFsIHB1Ymxpc2hlcnMgb2YgdGhlIGRv bWFpbidzIFNQRiByZWNvcmRzLgoKW01TSzogUmVmZXJlbmNlIGZvciBORE5zP10KCiAgIEluIHBy YWN0aWNlLCBzdWNoIG5vbi1kZWxpdmVyeSBub3RpZmljYXRpb25zIGNhbiBiZSBtaXNkaXJlY3Rl ZCwgc3VjaAogICBhcyB3aGVuIGFuIE1UQSBhY2NlcHRzIGFuIGVtYWlsIGFuZCBvbmx5IGxhdGVy IGdlbmVyYXRlcyB0aGUKICAgbm90aWZpY2F0aW9uIHRvIGEgZm9yZ2VkIGFkZHJlc3MsIG9yIHdo ZW4gYW4gZW1haWwgZm9yd2FyZGVyIGRvZXMgbm90CiAgIGRpcmVjdCB0aGUgYm91bmNlIGJhY2sg dG8gdGhlIG9yaWdpbmFsIHNlbmRlci4KCjEwLjYuICBQcml2YWN5IEV4cG9zdXJlCgogICBDaGVj a2luZyBTUEYgcmVjb3JkcyBjYXVzZXMgRE5TIHF1ZXJpZXMgdG8gYmUgc2VudCB0byB0aGUgZG9t YWluCiAgIG93bmVyLiAgVGhlc2UgRE5TIHF1ZXJpZXMsIGVzcGVjaWFsbHkgaWYgdGhleSBhcmUg Y2F1c2VkIGJ5IHRoZQogICAiZXhpc3RzIiBtZWNoYW5pc20sIGNhbiBjb250YWluIGluZm9ybWF0 aW9uIGFib3V0IHdobyBpcyBzZW5kaW5nCiAgIGVtYWlsIGFuZCBsaWtlbHkgdG8gd2hpY2ggTVRB IHRoZSBlbWFpbCBpcyBiZWluZyBzZW50LiAgVGhpcyBjYW4KICAgaW50cm9kdWNlIHNvbWUgcHJp dmFjeSBjb25jZXJucywgd2hpY2ggYXJlIG1vcmUgb3IgbGVzcyBvZiBhbiBpc3N1ZQogICBkZXBl bmRpbmcgb24gbG9jYWwgbGF3cyBhbmQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBkb21h aW4gb3duZXIKICAgYW5kIHRoZSBwZXJzb24gc2VuZGluZyB0aGUgZW1haWwuCgoKCgoKCgoKCgoK CgoKCgoKCgoKS2l0dGVybWFuICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEz ICAgICAgICAgICAgICAgW1BhZ2UgNDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQ b2xpY3kgRnJhbWV3b3JrIChTUEYpICAgICAgICAgICAgSnVseSAyMDEyCgoKMTEuICBDb250cmli dXRvcnMgYW5kIEFja25vd2xlZGdlbWVudHMKCiAgIFRoaXMgZG9jdW1lbnQgaXMgbGFyZ2VseSBi YXNlZCBvbiB0aGUgd29yayBvZiBNZW5nIFdlbmcgV29uZywgTWFyawogICBMZW50Y3puZXIsIGFu ZCBXYXluZSBTY2hsaXR0LiAgQWx0aG91Z2gsIGFzIHRoaXMgc2VjdGlvbgogICBhY2tub3dsZWRn ZXMsIG1hbnkgcGVvcGxlIGhhdmUgY29udHJpYnV0ZWQgdG8gdGhpcyBkb2N1bWVudCwgYSB2ZXJ5 CiAgIGxhcmdlIHBvcnRpb24gb2YgdGhlIHdyaXRpbmcgYW5kIGVkaXRpbmcgYXJlIGR1ZSB0byBN ZW5nLCBNYXJrLCBhbmQKICAgV2F5bmUuCgogICBUaGlzIGRlc2lnbiBvd2VzIGEgZGVidCBvZiBw YXJlbnRhZ2UgdG8gW1JNWF0gYnkgSGFkbXV0IERhbmlzY2ggYW5kCiAgIHRvIFtETVBdIGJ5IEdv cmRvbiBGZWN5ay4gIFRoZSBpZGVhIG9mIHVzaW5nIGEgRE5TIHJlY29yZCB0byBjaGVjawogICB0 aGUgbGVnaXRpbWFjeSBvZiBhbiBlbWFpbCBhZGRyZXNzIHRyYWNlcyBpdHMgYW5jZXN0cnkgZnVy dGhlciBiYWNrCiAgIHRocm91Z2ggbWVzc2FnZXMgb24gdGhlIG5hbWVkcm9wcGVycyBtYWlsaW5n IGxpc3QgYnkgUGF1bCBWaXhpZQogICBbVml4aWVdIChiYXNlZCBvbiBzdWdnZXN0aW9uIGJ5IEpp bSBNaWxsZXIpIGFuZCBieSBEYXZpZCBHcmVlbgogICBbR3JlZW5dLgoKICAgUGhpbGlwIEdsYWRz dG9uZSBjb250cmlidXRlZCB0aGUgY29uY2VwdCBvZiBtYWNyb3MgdG8gdGhlCiAgIHNwZWNpZmlj YXRpb24sIG11bHRpcGx5aW5nIHRoZSBleHByZXNzaXZlbmVzcyBvZiB0aGUgbGFuZ3VhZ2UgYW5k CiAgIG1ha2luZyBwZXItdXNlciBhbmQgcGVyLUlQIGxvb2t1cHMgcG9zc2libGUuCgogICBUaGUg YXV0aG9ycyBvZiBib3RoZSB0aGlzIGRvY3VtZW50IGFuZCBbUkZDNDQwOF0gd291bGQgYWxzbyBs aWtlIHRvCgpbTVNLOiBzL2JvdGhlL2JvdGgvXQoKICAgdGhhbmsgdGhlIGxpdGVyYWxseSBodW5k cmVkcyBvZiBpbmRpdmlkdWFscyB3aG8gaGF2ZSBwYXJ0aWNpcGF0ZWQgaW4KICAgdGhlIGRldmVs b3BtZW50IG9mIHRoaXMgZGVzaWduLiAgVGhleSBhcmUgZmFyIHRvbyBudW1lcm91cyB0byBuYW1l LAogICBidXQgdGhleSBpbmNsdWRlIHRoZSBmb2xsb3dpbmc6CgogICAgICBUaGUgcGFydGljaXBh bnRzIGluIHRoZSBTUEZiaXMgd29ya2luZyBncm91cC4KICAgICAgVGhlIGZvbGtzIG9uIHRoZSBz cGYtZGlzY3VzcyBtYWlsaW5nIGxpc3QuCiAgICAgIFRoZSBmb2xrcyBvbiB0aGUgU1BBTS1MIG1h aWxpbmcgbGlzdC4KICAgICAgVGhlIGZvbGtzIG9uIHRoZSBJUlRGIEFTUkcgbWFpbGluZyBsaXN0 LgogICAgICBUaGUgZm9sa3Mgb24gdGhlIElFVEYgTUFSSUQgbWFpbGluZyBsaXN0LgogICAgICBU aGUgZm9sa3Mgb24gI3BlcmwuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCktpdHRlcm1hbiAgICAgICAg ICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDQ0XQoM CkludGVybmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BGKSAgICAg ICAgICAgIEp1bHkgMjAxMgoKCjEyLiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKMTIuMS4gIFRoZSBT UEYgRE5TIFJlY29yZCBUeXBlCgogICBQZXIgW1JGQzQ0MDhdLCB0aGUgSUFOQSBhc3NpZ25lZCB0 aGUgUmVzb3VyY2UgUmVjb3JkIFR5cGUgYW5kIFF0eXBlCiAgIGZyb20gdGhlIEROUyBQYXJhbWV0 ZXJzIFJlZ2lzdHJ5IGZvciB0aGUgU1BGIFJSIHR5cGUgd2l0aCBjb2RlIDk5LgogICBUaGUgZm9y bWF0IG9mIHRoaXMgdHlwZSBpcyBpZGVudGljYWwgdG8gdGhlIFRYVCBSUiBbUkZDMTAzNV0uICBU aGUKICAgY2hhcmFjdGVyIGNvbnRlbnQgb2YgdGhlIHJlY29yZCBpcyBlbmNvZGVkIGFzIFtVUy1B U0NJSV0uICBVc2Ugb2YKICAgdGhpcyByZWNvcmQgdHlwZSBpcyBvYnNvbGV0ZSBmb3IgU1BGIFZl cnNpb24gMS4KCiAgIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFkZCAodG8gYmUgY2hhbmdlZCB0byAi aGFzIGFkZGVkIiB1cG9uCiAgIHB1YmxpY2F0aW9uKSBhbiBhbm5vdGF0aW9uIHRvIHRoZSBTUEYg UlJUWVBFIHNheWluZyAiKE9CU09MRVRFIC0gdXNlCiAgIFRYVCkiIGluIHRoZSBETlMgUGFyYW1l dGVycyByZWdpc3RyeS4KCltNU0s6IFRoZSBub3RlICJ0byBiZSBjaGFuZ2VkIiBzaG91bGQgYmUg bW92ZWQgdG8gYSBzZW50ZW5jZSBhdCB0aGUgZW5kLCBhbmQgZW5jbG9zZWQgaW46IAlbTk9URSBU TyBSRkMgRURJVE9SOiDigKYgXQpdCgoxMi4yLiAgVGhlIFJlY2VpdmVkLVNQRiBNYWlsIEhlYWRl ciBGaWVsZAoKICAgUGVyIFtSRkMzODY0XSwgdGhlICJSZWNlaXZlZC1TUEY6IiBoZWFkZXIgZmll bGQgaXMgYWRkZWQgdG8gdGhlIElBTkEKICAgUGVybWFuZW50IE1lc3NhZ2UgSGVhZGVyIEZpZWxk IFJlZ2lzdHJ5LiAgVGhlIGZvbGxvd2luZyBpcyB0aGUKICAgcmVnaXN0cmF0aW9uIHRlbXBsYXRl OgoKICAgICAgSGVhZGVyIGZpZWxkIG5hbWU6IFJlY2VpdmVkLVNQRgogICAgICBBcHBsaWNhYmxl IHByb3RvY29sOiBtYWlsIChbUkZDNTMyMl0pCiAgICAgIFN0YXR1czogU3RhbmRhcmRzIFRyYWNr CiAgICAgIEF1dGhvci9DaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICBTcGVjaWZpY2F0aW9u IGRvY3VtZW50KHMpOiBbUkZDNDQwOF0sIFJGQyBYWFhYCgpbTVNLOiBTaG91bGQgYmUganVzdCAi W3RoaXMgZG9jdW1lbnRdIiwgYXMgNDQwOCB3aWxsIGJlIG9ic29sZXRlIHdoZW4gdGhpcyBvbmUg Z29lcyBvdXQuXQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpLaXR0ZXJtYW4gICAgICAgICAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDYsIDIwMTMgICAgICAgICAgICAgICBbUGFnZSA0NV0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgU2VuZGVyIFBvbGljeSBGcmFtZXdvcmsgKFNQRikgICAgICAgICAg ICBKdWx5IDIwMTIKCgoxMy4gIFJlZmVyZW5jZXMKCjEzLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNl cwoKICAgW1JGQzEwMzVdICBNb2NrYXBldHJpcywgUC4sICJEb21haW4gbmFtZXMgLSBpbXBsZW1l bnRhdGlvbiBhbmQKICAgICAgICAgICAgICBzcGVjaWZpY2F0aW9uIiwgU1REIDEzLCBSRkMgMTAz NSwgTm92ZW1iZXIgMTk4Ny4KCiAgIFtSRkMxMTIzXSAgQnJhZGVuLCBSLiwgIlJlcXVpcmVtZW50 cyBmb3IgSW50ZXJuZXQgSG9zdHMgLSBBcHBsaWNhdGlvbgogICAgICAgICAgICAgIGFuZCBTdXBw b3J0IiwgU1REIDMsIFJGQyAxMTIzLCBPY3RvYmVyIDE5ODkuCgogICBbUkZDMjExOV0gIEJyYWRu ZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAg ICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgog ICBbUkZDMzQ2M10gIFZhdWRyZXVpbCwgRy4sICJFbmhhbmNlZCBNYWlsIFN5c3RlbSBTdGF0dXMg Q29kZXMiLAogICAgICAgICAgICAgIFJGQyAzNDYzLCBKYW51YXJ5IDIwMDMuCgogICBbUkZDMzg2 NF0gIEtseW5lLCBHLiwgTm90dGluZ2hhbSwgTS4sIGFuZCBKLiBNb2d1bCwgIlJlZ2lzdHJhdGlv bgogICAgICAgICAgICAgIFByb2NlZHVyZXMgZm9yIE1lc3NhZ2UgSGVhZGVyIEZpZWxkcyIsIEJD UCA5MCwgUkZDIDM4NjQsCiAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDQuCgogICBbUkZDMzk4 Nl0gIEJlcm5lcnMtTGVlLCBULiwgRmllbGRpbmcsIFIuLCBhbmQgTC4gTWFzaW50ZXIsICJVbmlm b3JtCiAgICAgICAgICAgICAgUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKTogR2VuZXJpYyBTeW50 YXgiLCBTVEQgNjYsCiAgICAgICAgICAgICAgUkZDIDM5ODYsIEphbnVhcnkgMjAwNS4KCiAgIFtS RkM0MjkxXSAgSGluZGVuLCBSLiBhbmQgUy4gRGVlcmluZywgIklQIFZlcnNpb24gNiBBZGRyZXNz aW5nCiAgICAgICAgICAgICAgQXJjaGl0ZWN0dXJlIiwgUkZDIDQyOTEsIEZlYnJ1YXJ5IDIwMDYu CgogICBbUkZDNTIzNF0gIENyb2NrZXIsIEQuIGFuZCBQLiBPdmVyZWxsLCAiQXVnbWVudGVkIEJO RiBmb3IgU3ludGF4CiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBTVEQgNjgs IFJGQyA1MjM0LCBKYW51YXJ5IDIwMDguCgogICBbUkZDNTMyMV0gIEtsZW5zaW4sIEouLCAiU2lt cGxlIE1haWwgVHJhbnNmZXIgUHJvdG9jb2wiLCBSRkMgNTMyMSwKICAgICAgICAgICAgICBPY3Rv YmVyIDIwMDguCgogICBbUkZDNTMyMl0gIFJlc25pY2ssIFAuLCBFZC4sICJJbnRlcm5ldCBNZXNz YWdlIEZvcm1hdCIsIFJGQyA1MzIyLAogICAgICAgICAgICAgIE9jdG9iZXIgMjAwOC4KCiAgIFtV Uy1BU0NJSV0KICAgICAgICAgICAgICBBbWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMgSW5zdGl0 dXRlIChmb3JtZXJseSBVbml0ZWQKICAgICAgICAgICAgICBTdGF0ZXMgb2YgQW1lcmljYSBTdGFu ZGFyZHMgSW5zdGl0dXRlKSwgIlVTQSBDb2RlIGZvcgogICAgICAgICAgICAgIEluZm9ybWF0aW9u IEludGVyY2hhbmdlLCBYMy40IiwgMTk2OC4KCiAgICAgICAgICAgICAgQU5TSSBYMy40LTE5Njgg aGFzIGJlZW4gcmVwbGFjZWQgYnkgbmV3ZXIgdmVyc2lvbnMgd2l0aAogICAgICAgICAgICAgIHNs aWdodCBtb2RpZmljYXRpb25zLCBidXQgdGhlIDE5NjggdmVyc2lvbiByZW1haW5zCiAgICAgICAg ICAgICAgZGVmaW5pdGl2ZSBmb3IgdGhlIEludGVybmV0LgoKCgoKCgoKS2l0dGVybWFuICAgICAg ICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgNDZd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpICAg ICAgICAgICAgSnVseSAyMDEyCgoKMTMuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtE TVBdICAgICAgRmVjeWssIEcuLCAiRGVzaWduYXRlZCBNYWlsZXJzIFByb3RvY29sIi4KCiAgICAg ICAgICAgICAgV29yayBJbiBQcm9ncmVzcwoKICAgW0dyZWVuXSAgICBHcmVlbiwgRC4sICJEb21h aW4tQXV0aG9yaXplZCBTTVRQIE1haWwiLCAyMDAyLgoKICAgW1JGQzEwMzRdICBNb2NrYXBldHJp cywgUC4sICJEb21haW4gbmFtZXMgLSBjb25jZXB0cyBhbmQgZmFjaWxpdGllcyIsCiAgICAgICAg ICAgICAgU1REIDEzLCBSRkMgMTAzNCwgTm92ZW1iZXIgMTk4Ny4KCiAgIFtSRkMxOTgzXSAgTWFs a2luLCBHLiwgIkludGVybmV0IFVzZXJzJyBHbG9zc2FyeSIsIFJGQyAxOTgzLAogICAgICAgICAg ICAgIEF1Z3VzdCAxOTk2LgoKICAgW1JGQzIzMDhdICBBbmRyZXdzLCBNLiwgIk5lZ2F0aXZlIENh Y2hpbmcgb2YgRE5TIFF1ZXJpZXMgKEROUwogICAgICAgICAgICAgIE5DQUNIRSkiLCBSRkMgMjMw OCwgTWFyY2ggMTk5OC4KCiAgIFtSRkMzNjk2XSAgS2xlbnNpbiwgSi4sICJBcHBsaWNhdGlvbiBU ZWNobmlxdWVzIGZvciBDaGVja2luZyBhbmQKICAgICAgICAgICAgICBUcmFuc2Zvcm1hdGlvbiBv ZiBOYW1lcyIsIFJGQyAzNjk2LCBGZWJydWFyeSAyMDA0LgoKICAgW1JGQzM4MzNdICBBdGtpbnMs IEQuIGFuZCBSLiBBdXN0ZWluLCAiVGhyZWF0IEFuYWx5c2lzIG9mIHRoZSBEb21haW4KICAgICAg ICAgICAgICBOYW1lIFN5c3RlbSAoRE5TKSIsIFJGQyAzODMzLCBBdWd1c3QgMjAwNC4KCiAgIFtS RkM0NDA4XSAgV29uZywgTS4gYW5kIFcuIFNjaGxpdHQsICJTZW5kZXIgUG9saWN5IEZyYW1ld29y ayAoU1BGKQogICAgICAgICAgICAgIGZvciBBdXRob3JpemluZyBVc2Ugb2YgRG9tYWlucyBpbiBF LU1haWwsIFZlcnNpb24gMSIsCiAgICAgICAgICAgICAgUkZDIDQ0MDgsIEFwcmlsIDIwMDYuCgog ICBbUkZDNDg4MF0gIENhbGxhcywgSi4sIERvbm5lcmhhY2tlLCBMLiwgRmlubmV5LCBILiwgU2hh dywgRC4sIGFuZCBSLgogICAgICAgICAgICAgIFRoYXllciwgIk9wZW5QR1AgTWVzc2FnZSBGb3Jt YXQiLCBSRkMgNDg4MCwgTm92ZW1iZXIgMjAwNy4KCiAgIFtSRkM0OTU0XSAgU2llbWJvcnNraSwg Ui4gYW5kIEEuIE1lbG5pa292LCAiU01UUCBTZXJ2aWNlIEV4dGVuc2lvbgogICAgICAgICAgICAg IGZvciBBdXRoZW50aWNhdGlvbiIsIFJGQyA0OTU0LCBKdWx5IDIwMDcuCgogICBbUkZDNTU5OF0g IENyb2NrZXIsIEQuLCAiSW50ZXJuZXQgTWFpbCBBcmNoaXRlY3R1cmUiLCBSRkMgNTU5OCwKICAg ICAgICAgICAgICBKdWx5IDIwMDkuCgogICBbUkZDNTc1MV0gIFJhbXNkZWxsLCBCLiBhbmQgUy4g VHVybmVyLCAiU2VjdXJlL011bHRpcHVycG9zZSBJbnRlcm5ldAogICAgICAgICAgICAgIE1haWwg RXh0ZW5zaW9ucyAoUy9NSU1FKSBWZXJzaW9uIDMuMiBNZXNzYWdlCiAgICAgICAgICAgICAgU3Bl Y2lmaWNhdGlvbiIsIFJGQyA1NzUxLCBKYW51YXJ5IDIwMTAuCgogICBbUkZDNjQwOV0gIEdlbGxl bnMsIFIuIGFuZCBKLiBLbGVuc2luLCAiTWVzc2FnZSBTdWJtaXNzaW9uIGZvciBNYWlsIiwKICAg ICAgICAgICAgICBTVEQgNzIsIFJGQyA2NDA5LCBOb3ZlbWJlciAyMDExLgoKICAgW1JGQzY2NDdd ICBLdWNoZXJhd3ksIE0uIGFuZCBELiBDcm9ja2VyLCAiRW1haWwgR3JleWxpc3Rpbmc6IEFuCiAg ICAgICAgICAgICAgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnQgZm9yIFNNVFAiLCBSRkMgNjY0Nywg SnVuZSAyMDEyLgoKICAgW1JGQzY2NTJdICBLaXR0ZXJtYW4sIFMuLCAiU2VuZGVyIFBvbGljeSBG cmFtZXdvcmsgKFNQRikKICAgICAgICAgICAgICBBdXRoZW50aWNhdGlvbiBGYWlsdXJlIFJlcG9y dGluZyBVc2luZyB0aGUgQWJ1c2UgUmVwb3J0aW5nCgoKCktpdHRlcm1hbiAgICAgICAgICAgICAg ICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDQ3XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BGKSAgICAgICAgICAg IEp1bHkgMjAxMgoKCiAgICAgICAgICAgICAgRm9ybWF0IiwgUkZDIDY2NTIsIEp1bmUgMjAxMi4K CiAgIFtSTVhdICAgICAgRGFuaXNjaCwgSC4sICJUaGUgUk1YIEROUyBSUiBUeXBlIGZvciBsaWdo dCB3ZWlnaHQgc2VuZGVyCiAgICAgICAgICAgICAgYXV0aGVudGljYXRpb24iLgoKICAgICAgICAg ICAgICBXb3JrIEluIFByb2dyZXNzCgogICBbVml4aWVdICAgIFZpeGllLCBQLiwgIlJlcHVkaWF0 aW5nIE1BSUwgRlJPTSIsIDIwMDIuCgogICBbZHJhZnQtaWV0Zi1zcGZiaXMtZXhwZXJpbWVudF0K ICAgICAgICAgICAgICBLdWNoZXJhd3ksIE0uLCAiUmVzb2x1dGlvbiBvZiBUaGUgU1BGIGFuZCBT ZW5kZXIgSUQKICAgICAgICAgICAgICBFeHBlcmltZW50cyIsIGRyYWZ0LWlldGYtc3BmYmlzLWV4 cGVyaW1lbnQgKHdvcmsgaW4KICAgICAgICAgICAgICBwcm9ncmVzcyksIDIwMTIuCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKS2l0dGVybWFuICAgICAgICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgNDhdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpICAgICAgICAgICAgSnVs eSAyMDEyCgoKQXBwZW5kaXggQS4gIENvbGxlY3RlZCBBQk5GCgogICBUaGlzIHNlY3Rpb24gaXMg bm9ybWF0aXZlIGFuZCBhbnkgZGlzY3JlcGFuY2llcyB3aXRoIHRoZSBBQk5GCiAgIGZyYWdtZW50 cyBpbiB0aGUgcHJlY2VkaW5nIHRleHQgYXJlIHRvIGJlIHJlc29sdmVkIGluIGZhdm9yIG9mIHRo aXMKICAgZ3JhbW1hci4KCltNU0s6IE1hZGUgbXkgQUJORiBjb21tZW50cyBpbiBhIHByZXZpb3Vz IHNlY3Rpb24uXQoKICAgU2VlIFtSRkM1MjM0XSBmb3IgQUJORiBub3RhdGlvbi4gIFBsZWFzZSBu b3RlIHRoYXQgYXMgcGVyIHRoaXMgQUJORgogICBkZWZpbml0aW9uLCBsaXRlcmFsIHRleHQgc3Ry aW5ncyAodGhvc2UgaW4gcXVvdGVzKSBhcmUgY2FzZS0KICAgaW5zZW5zaXRpdmUuICBIZW5jZSwg Im14IiBtYXRjaGVzICJteCIsICJNWCIsICJtWCIsIGFuZCAiTXgiLgoKICAgcmVjb3JkICAgICAg ICAgICA9IHZlcnNpb24gdGVybXMgKlNQCiAgIHZlcnNpb24gICAgICAgICAgPSAidj1zcGYxIgoK ICAgdGVybXMgICAgICAgICAgICA9ICooIDEqU1AgKCBkaXJlY3RpdmUgLyBtb2RpZmllciApICkK CiAgIGRpcmVjdGl2ZSAgICAgICAgPSBbIHF1YWxpZmllciBdIG1lY2hhbmlzbQogICBxdWFsaWZp ZXIgICAgICAgID0gIisiIC8gIi0iIC8gIj8iIC8gIn4iCiAgIG1lY2hhbmlzbSAgICAgICAgPSAo IGFsbCAvIGluY2x1ZGUKICAgICAgICAgICAgICAgICAgICAgIC8gQSAvIE1YIC8gUFRSIC8gSVA0 IC8gSVA2IC8gZXhpc3RzICkKCiAgIGFsbCAgICAgICAgICAgICAgPSAiYWxsIgogICBpbmNsdWRl ICAgICAgICAgID0gImluY2x1ZGUiICAiOiIgZG9tYWluLXNwZWMKICAgQSAgICAgICAgICAgICAg ICA9ICJhIiAgICAgIFsgIjoiIGRvbWFpbi1zcGVjIF0gWyBkdWFsLWNpZHItbGVuZ3RoIF0KICAg TVggICAgICAgICAgICAgICA9ICJteCIgICAgIFsgIjoiIGRvbWFpbi1zcGVjIF0gWyBkdWFsLWNp ZHItbGVuZ3RoIF0KICAgUFRSICAgICAgICAgICAgICA9ICJwdHIiICAgIFsgIjoiIGRvbWFpbi1z cGVjIF0KICAgSVA0ICAgICAgICAgICAgICA9ICJpcDQiICAgICAgIjoiIGlwNC1uZXR3b3JrICAg WyBpcDQtY2lkci1sZW5ndGggXQogICBJUDYgICAgICAgICAgICAgID0gImlwNiIgICAgICAiOiIg aXA2LW5ldHdvcmsgICBbIGlwNi1jaWRyLWxlbmd0aCBdCiAgIGV4aXN0cyAgICAgICAgICAgPSAi ZXhpc3RzIiAgICI6IiBkb21haW4tc3BlYwoKICAgbW9kaWZpZXIgICAgICAgICA9IHJlZGlyZWN0 IC8gZXhwbGFuYXRpb24gLyB1bmtub3duLW1vZGlmaWVyCiAgIHJlZGlyZWN0ICAgICAgICAgPSAi cmVkaXJlY3QiICI9IiBkb21haW4tc3BlYwogICBleHBsYW5hdGlvbiAgICAgID0gImV4cCIgIj0i IGRvbWFpbi1zcGVjCiAgIHVua25vd24tbW9kaWZpZXIgPSBuYW1lICI9IiBtYWNyby1zdHJpbmcK ICAgICAgICAgICAgICAgICAgICAgIDsgd2hlcmUgbmFtZSBpcyBub3QgYW55IGtub3duIG1vZGlm aWVyCgogICBpcDQtY2lkci1sZW5ndGggID0gIi8iIDEqRElHSVQKICAgaXA2LWNpZHItbGVuZ3Ro ICA9ICIvIiAxKkRJR0lUCiAgIGR1YWwtY2lkci1sZW5ndGggPSBbIGlwNC1jaWRyLWxlbmd0aCBd IFsgIi8iIGlwNi1jaWRyLWxlbmd0aCBdCgogICBpcDQtbmV0d29yayAgICAgID0gcW51bSAiLiIg cW51bSAiLiIgcW51bSAiLiIgcW51bQogICBxbnVtICAgICAgICAgICAgID0gRElHSVQgICAgICAg ICAgICAgICAgIDsgMC05CiAgICAgICAgICAgICAgICAgICAgICAvICV4MzEtMzkgRElHSVQgICAg ICAgOyAxMC05OQogICAgICAgICAgICAgICAgICAgICAgLyAiMSIgMkRJR0lUICAgICAgICAgIDsg MTAwLTE5OQogICAgICAgICAgICAgICAgICAgICAgLyAiMiIgJXgzMC0zNCBESUdJVCAgIDsgMjAw LTI0OQogICAgICAgICAgICAgICAgICAgICAgLyAiMjUiICV4MzAtMzUgICAgICAgIDsgMjUwLTI1 NQogICAgICAgICAgICA7IGNvbnZlbnRpb25hbCBkb3R0ZWQgcXVhZCBub3RhdGlvbi4gIGUuZy4s IDE5Mi4wLjIuMAogICBpcDYtbmV0d29yayAgICAgID0gPGFzIHBlciBbUkZDIDQyOTFdLCBzZWN0 aW9uIDIuMj4KICAgICAgICAgICAgOyBlLmcuLCAyMDAxOkRCODo6Q0QzMAoKCgpLaXR0ZXJtYW4g ICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDYsIDIwMTMgICAgICAgICAgICAgICBbUGFn ZSA0OV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgU2VuZGVyIFBvbGljeSBGcmFtZXdvcmsgKFNQ RikgICAgICAgICAgICBKdWx5IDIwMTIKCgogICBkb21haW4tc3BlYyAgICAgID0gbWFjcm8tc3Ry aW5nIGRvbWFpbi1lbmQKICAgZG9tYWluLWVuZCAgICAgICA9ICggIi4iIHRvcGxhYmVsIFsgIi4i IF0gKSAvIG1hY3JvLWV4cGFuZAoKICAgdG9wbGFiZWwgICAgICAgICA9ICggKmFscGhhbnVtIEFM UEhBICphbHBoYW51bSApIC8KICAgICAgICAgICAgICAgICAgICAgICggMSphbHBoYW51bSAiLSIg KiggYWxwaGFudW0gLyAiLSIgKSBhbHBoYW51bSApCiAgICAgICAgICAgICAgICAgICAgICA7IExE SCBydWxlIHBsdXMgYWRkaXRpb25hbCBUTEQgcmVzdHJpY3Rpb25zCiAgICAgICAgICAgICAgICAg ICAgICA7IChzZWUgW1JGQzM2OTZdLCBTZWN0aW9uIDIgZm9yIGJhY2tncm91bmQpCiAgIGFscGhh bnVtICAgICAgICAgPSBBTFBIQSAvIERJR0lUCgogICBleHBsYWluLXN0cmluZyAgID0gKiggbWFj cm8tc3RyaW5nIC8gU1AgKQoKICAgbWFjcm8tc3RyaW5nICAgICA9ICooIG1hY3JvLWV4cGFuZCAv IG1hY3JvLWxpdGVyYWwgKQogICBtYWNyby1leHBhbmQgICAgID0gKCAiJXsiIG1hY3JvLWxldHRl ciB0cmFuc2Zvcm1lcnMgKmRlbGltaXRlciAifSIgKQogICAgICAgICAgICAgICAgICAgICAgLyAi JSUiIC8gIiVfIiAvICIlLSIKICAgbWFjcm8tbGl0ZXJhbCAgICA9ICV4MjEtMjQgLyAleDI2LTdF CiAgICAgICAgICAgICAgICAgICAgICA7IHZpc2libGUgY2hhcmFjdGVycyBleGNlcHQgIiUiCiAg IG1hY3JvLWxldHRlciAgICAgPSAicyIgLyAibCIgLyAibyIgLyAiZCIgLyAiaSIgLyAicCIgLyAi aCIgLwogICAgICAgICAgICAgICAgICAgICAgImMiIC8gInIiIC8gInQiIC8gInYiCiAgIHRyYW5z Zm9ybWVycyAgICAgPSAqRElHSVQgWyAiciIgXQogICBkZWxpbWl0ZXIgICAgICAgID0gIi4iIC8g Ii0iIC8gIisiIC8gIiwiIC8gIi8iIC8gIl8iIC8gIj0iCgogICBuYW1lICAgICAgICAgICAgID0g QUxQSEEgKiggQUxQSEEgLyBESUdJVCAvICItIiAvICJfIiAvICIuIiApCgogICBoZWFkZXItZmll bGQgICAgID0gIlJlY2VpdmVkLVNQRjoiIFtDRldTXSByZXN1bHQgRldTIFtjb21tZW50IEZXU10K ICAgICAgICAgICAgICAgICAgICAgIFsga2V5LXZhbHVlLWxpc3QgXSBDUkxGCgogICByZXN1bHQg ICAgICAgICAgID0gInBhc3MiIC8gImZhaWwiIC8gInNvZnRmYWlsIiAvICJuZXV0cmFsIiAvCiAg ICAgICAgICAgICAgICAgICAgICAibm9uZSIgLyAidGVtcGVycm9yIiAvICJwZXJtZXJyb3IiCgog ICBrZXktdmFsdWUtbGlzdCAgID0ga2V5LXZhbHVlLXBhaXIgKiggIjsiIFtDRldTXSBrZXktdmFs dWUtcGFpciApCiAgICAgICAgICAgICAgICAgICAgICBbIjsiXQoKICAga2V5LXZhbHVlLXBhaXIg ICA9IGtleSBbQ0ZXU10gIj0iICggZG90LWF0b20gLyBxdW90ZWQtc3RyaW5nICkKCiAgIGtleSAg ICAgICAgICAgICAgPSAiY2xpZW50LWlwIiAvICJlbnZlbG9wZS1mcm9tIiAvICJoZWxvIiAvCiAg ICAgICAgICAgICAgICAgICAgICAicHJvYmxlbSIgLyAicmVjZWl2ZXIiIC8gaWRlbnRpdHkgLwog ICAgICAgICAgICAgICAgICAgICAgIG1lY2hhbmlzbSAvIG5hbWUKCiAgIGlkZW50aXR5ICAgICAg ICAgPSAibWFpbGZyb20iICAgOyBmb3IgdGhlICJNQUlMIEZST00iIGlkZW50aXR5CiAgICAgICAg ICAgICAgICAgICAgICAvICJoZWxvIiAgICAgOyBmb3IgdGhlICJIRUxPIiBpZGVudGl0eQogICAg ICAgICAgICAgICAgICAgICAgLyBuYW1lICAgICAgIDsgb3RoZXIgaWRlbnRpdGllcwoKICAgQUxQ SEEgICAgICAgICAgICA9IDxBLVogLyBhLXogYXMgcGVyIFtSRkM1MjM0XT4KICAgRElHSVQgICAg ICAgICAgICA9IDwwLTkgYXMgcGVyIFtSRkM1MjM0XT4KICAgU1AgICAgICAgICAgICAgICA9IDxz cGFjZSBjaGFyYWN0ZXIgYXMgcGVyIFtSRkM1MjM0XT4KICAgZG90LWF0b20gICAgICAgICA9IDx1 bnF1b3RlZCB3b3JkIGFzIHBlciBbUkZDNTMyMl0+CiAgIHF1b3RlZC1zdHJpbmcgICAgPSA8cXVv dGVkIHN0cmluZyBhcyBwZXIgW1JGQzUzMjJdPgogICBjb21tZW50ICAgICAgICAgID0gPGNvbW1l bnQgc3RyaW5nIGFzIHBlciBbUkZDNTMyMl0+CgoKCktpdHRlcm1hbiAgICAgICAgICAgICAgICBF eHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDUwXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1 bHkgMjAxMgoKCiAgIENGV1MgICAgICAgICAgICAgPSA8Y29tbWVudCBvciBmb2xkaW5nIHdoaXRl IHNwYWNlIGFzIHBlciBbUkZDNTMyMl0+CiAgIEZXUyAgICAgICAgICAgICAgPSA8Zm9sZGluZyB3 aGl0ZSBzcGFjZSBhcyBwZXIgW1JGQzUzMjJdPgogICBDUkxGICAgICAgICAgICAgID0gPHN0YW5k YXJkIGVuZC1vZi1saW5lIHRva2VuIGFzIHBlciBbUkZDNTMyMl0+CgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCktpdHRlcm1hbiAgICAgICAgICAgICAgICBF eHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDUxXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICBTZW5kZXIgUG9saWN5IEZyYW1ld29yayAoU1BGKSAgICAgICAgICAgIEp1 bHkgMjAxMgoKCkFwcGVuZGl4IEIuICBFeHRlbmRlZCBFeGFtcGxlcwoKICAgVGhlc2UgZXhhbXBs ZXMgYXJlIGJhc2VkIG9uIHRoZSBmb2xsb3dpbmcgRE5TIHNldHVwOgoKICAgOyBBIGRvbWFpbiB3 aXRoIHR3byBtYWlsIHNlcnZlcnMsIHR3byBob3N0cwogICA7IGFuZCB0d28gc2VydmVycyBhdCB0 aGUgZG9tYWluIG5hbWUKICAgJE9SSUdJTiBleGFtcGxlLmNvbS4KICAgQCAgICAgICAgICAgTVgg IDEwIG1haWwtYQogICAgICAgICAgICAgICBNWCAgMjAgbWFpbC1iCiAgICAgICAgICAgICAgIEEg ICAxOTIuMC4yLjEwCiAgICAgICAgICAgICAgIEEgICAxOTIuMC4yLjExCiAgIGFteSAgICAgICAg IEEgICAxOTIuMC4yLjY1CiAgIGJvYiAgICAgICAgIEEgICAxOTIuMC4yLjY2CiAgIG1haWwtYSAg ICAgIEEgICAxOTIuMC4yLjEyOQogICBtYWlsLWIgICAgICBBICAgMTkyLjAuMi4xMzAKICAgd3d3 ICAgICAgICAgQ05BTUUgZXhhbXBsZS5jb20uCgogICA7IEEgcmVsYXRlZCBkb21haW4KICAgJE9S SUdJTiBleGFtcGxlLm9yZy4KICAgQCAgICAgICAgICAgTVggIDEwIG1haWwtYwogICBtYWlsLWMg ICAgICBBICAgMTkyLjAuMi4xNDAKCiAgIDsgVGhlIHJldmVyc2UgSVAgZm9yIHRob3NlIGFkZHJl c3NlcwogICAkT1JJR0lOIDIuMC4xOTIuaW4tYWRkci5hcnBhLgogICAxMCAgICAgICAgICBQVFIg ZXhhbXBsZS5jb20uCiAgIDExICAgICAgICAgIFBUUiBleGFtcGxlLmNvbS4KICAgNjUgICAgICAg ICAgUFRSIGFteS5leGFtcGxlLmNvbS4KICAgNjYgICAgICAgICAgUFRSIGJvYi5leGFtcGxlLmNv bS4KICAgMTI5ICAgICAgICAgUFRSIG1haWwtYS5leGFtcGxlLmNvbS4KICAgMTMwICAgICAgICAg UFRSIG1haWwtYi5leGFtcGxlLmNvbS4KICAgMTQwICAgICAgICAgUFRSIG1haWwtYy5leGFtcGxl Lm9yZy4KCiAgIDsgQSByb2d1ZSByZXZlcnNlIElQIGRvbWFpbiB0aGF0IGNsYWltcyB0byBiZQog ICA7IHNvbWV0aGluZyBpdCdzIG5vdAogICAkT1JJR0lOIDAuMC4xMC5pbi1hZGRyLmFycGEuCiAg IDQgICAgICAgICAgIFBUUiBib2IuZXhhbXBsZS5jb20uCgpCLjEuICBTaW1wbGUgRXhhbXBsZXMK CiAgIFRoZXNlIGV4YW1wbGVzIHNob3cgdmFyaW91cyBwb3NzaWJsZSBwdWJsaXNoZWQgcmVjb3Jk cyBmb3IKICAgZXhhbXBsZS5jb20gYW5kIHdoaWNoIHZhbHVlcyBpZiA8aXA+IHdvdWxkIGNhdXNl IGNoZWNrX2hvc3QoKSB0bwogICByZXR1cm4gInBhc3MiLiAgTm90ZSB0aGF0IDxkb21haW4+IGlz ICJleGFtcGxlLmNvbSIuCgogICB2PXNwZjEgK2FsbAoKCgoKCgoKS2l0dGVybWFuICAgICAgICAg ICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgNTJdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpICAgICAg ICAgICAgSnVseSAyMDEyCgoKICAgICAgLS0gIGFueSA8aXA+IHBhc3NlcwoKICAgdj1zcGYxIGEg LWFsbAogICAgICAtLSAgaG9zdHMgMTkyLjAuMi4xMCBhbmQgMTkyLjAuMi4xMSBwYXNzCgogICB2 PXNwZjEgYTpleGFtcGxlLm9yZyAtYWxsCiAgICAgIC0tICBubyBzZW5kaW5nIGhvc3RzIHBhc3Mg c2luY2UgZXhhbXBsZS5vcmcgaGFzIG5vIEEgcmVjb3JkcwoKICAgdj1zcGYxIG14IC1hbGwKICAg ICAgLS0gIHNlbmRpbmcgaG9zdHMgMTkyLjAuMi4xMjkgYW5kIDE5Mi4wLjIuMTMwIHBhc3MKCiAg IHY9c3BmMSBteDpleGFtcGxlLm9yZyAtYWxsCiAgICAgIC0tICBzZW5kaW5nIGhvc3QgMTkyLjAu Mi4xNDAgcGFzc2VzCgogICB2PXNwZjEgbXggbXg6ZXhhbXBsZS5vcmcgLWFsbAogICAgICAtLSAg c2VuZGluZyBob3N0cyAxOTIuMC4yLjEyOSwgMTkyLjAuMi4xMzAsIGFuZCAxOTIuMC4yLjE0MCBw YXNzCgogICB2PXNwZjEgbXgvMzAgbXg6ZXhhbXBsZS5vcmcvMzAgLWFsbAogICAgICAtLSAgYW55 IHNlbmRpbmcgaG9zdCBpbiAxOTIuMC4yLjEyOC8zMCBvciAxOTIuMC4yLjE0MC8zMCBwYXNzZXMK CiAgIHY9c3BmMSBwdHIgLWFsbAogICAgICAtLSAgc2VuZGluZyBob3N0IDE5Mi4wLjIuNjUgcGFz c2VzIChyZXZlcnNlIEROUyBpcyB2YWxpZCBhbmQgaXMgaW4KICAgICAgICAgIGV4YW1wbGUuY29t KQogICAgICAtLSAgc2VuZGluZyBob3N0IDE5Mi4wLjIuMTQwIGZhaWxzIChyZXZlcnNlIEROUyBp cyB2YWxpZCwgYnV0IG5vdAogICAgICAgICAgaW4gZXhhbXBsZS5jb20pCiAgICAgIC0tICBzZW5k aW5nIGhvc3QgMTAuMC4wLjQgZmFpbHMgKHJldmVyc2UgSVAgaXMgbm90IHZhbGlkKQoKICAgdj1z cGYxIGlwNDoxOTIuMC4yLjEyOC8yOCAtYWxsCiAgICAgIC0tICBzZW5kaW5nIGhvc3QgMTkyLjAu Mi42NSBmYWlscwogICAgICAtLSAgc2VuZGluZyBob3N0IDE5Mi4wLjIuMTI5IHBhc3NlcwoKQi4y LiAgTXVsdGlwbGUgRG9tYWluIEV4YW1wbGUKCiAgIFRoZXNlIGV4YW1wbGVzIHNob3cgdGhlIGVm ZmVjdCBvZiByZWxhdGVkIHJlY29yZHM6CgogICAgICBleGFtcGxlLm9yZzogInY9c3BmMSBpbmNs dWRlOmV4YW1wbGUuY29tIGluY2x1ZGU6ZXhhbXBsZS5uZXQgLWFsbCIKCiAgIFRoaXMgcmVjb3Jk IHdvdWxkIGJlIHVzZWQgaWYgbWFpbCBmcm9tIGV4YW1wbGUub3JnIGFjdHVhbGx5IGNhbWUKICAg dGhyb3VnaCBzZXJ2ZXJzIGF0IGV4YW1wbGUuY29tIGFuZCBleGFtcGxlLm5ldC4gIEV4YW1wbGUu b3JnJ3MKICAgZGVzaWduYXRlZCBzZXJ2ZXJzIGFyZSB0aGUgdW5pb24gb2YgZXhhbXBsZS5jb20n cyBhbmQgZXhhbXBsZS5uZXQncwogICBkZXNpZ25hdGVkIHNlcnZlcnMuCgogICAgICBsYS5leGFt cGxlLm9yZzogInY9c3BmMSByZWRpcmVjdD1leGFtcGxlLm9yZyIKICAgICAgbnkuZXhhbXBsZS5v cmc6ICJ2PXNwZjEgcmVkaXJlY3Q9ZXhhbXBsZS5vcmciCiAgICAgIHNmLmV4YW1wbGUub3JnOiAi dj1zcGYxIHJlZGlyZWN0PWV4YW1wbGUub3JnIgoKICAgVGhlc2UgcmVjb3JkcyBhbGxvdyBhIHNl dCBvZiBkb21haW5zIHRoYXQgYWxsIHVzZSB0aGUgc2FtZSBtYWlsCiAgIHN5c3RlbSB0byBtYWtl IHVzZSBvZiB0aGF0IG1haWwgc3lzdGVtJ3MgcmVjb3JkLiAgSW4gdGhpcyB3YXksIG9ubHkKCgoK S2l0dGVybWFuICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAg ICAgICAgW1BhZ2UgNTNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJh bWV3b3JrIChTUEYpICAgICAgICAgICAgSnVseSAyMDEyCgoKICAgdGhlIG1haWwgc3lzdGVtJ3Mg cmVjb3JkIG5lZWRzIHRvIGJlIHVwZGF0ZWQgd2hlbiB0aGUgbWFpbCBzZXR1cAogICBjaGFuZ2Vz LiAgVGhlc2UgZG9tYWlucycgcmVjb3JkcyBuZXZlciBoYXZlIHRvIGNoYW5nZS4KCkIuMy4gIERO U0JMIFN0eWxlIEV4YW1wbGUKCiAgIEltYWdpbmUgdGhhdCwgaW4gYWRkaXRpb24gdG8gdGhlIGRv bWFpbiByZWNvcmRzIGxpc3RlZCBhYm92ZSwgdGhlcmUKICAgYXJlIHRoZXNlOgoKICAgJE9SSUdJ TiBfc3BmLmV4YW1wbGUuY29tLgogICBtYXJ5Lm1vYmlsZS11c2VycyAgICAgICAgICAgICAgICAg ICBBIDEyNy4wLjAuMgogICBmcmVkLm1vYmlsZS11c2VycyAgICAgICAgICAgICAgICAgICBBIDEy Ny4wLjAuMgogICAxNS4xNS4xNjguMTkyLmpvZWwucmVtb3RlLXVzZXJzICAgICBBIDEyNy4wLjAu MgogICAxNi4xNS4xNjguMTkyLmpvZWwucmVtb3RlLXVzZXJzICAgICBBIDEyNy4wLjAuMgoKICAg VGhlIGZvbGxvd2luZyByZWNvcmRzIGRlc2NyaWJlIHVzZXJzIGF0IGV4YW1wbGUuY29tIHdobyBt YWlsIGZyb20KICAgYXJiaXRyYXJ5IHNlcnZlcnMsIG9yIHdobyBtYWlsIGZyb20gcGVyc29uYWwg c2VydmVycy4KCiAgIGV4YW1wbGUuY29tOgoKICAgdj1zcGYxIG14CiAgICAgICAgICBpbmNsdWRl Om1vYmlsZS11c2Vycy5fc3BmLiV7ZH0KICAgICAgICAgIGluY2x1ZGU6cmVtb3RlLXVzZXJzLl9z cGYuJXtkfQogICAgICAgICAgLWFsbAoKICAgbW9iaWxlLXVzZXJzLl9zcGYuZXhhbXBsZS5jb206 CgogICB2PXNwZjEgZXhpc3RzOiV7bDFyK30uJXtkfQoKICAgcmVtb3RlLXVzZXJzLl9zcGYuZXhh bXBsZS5jb206CgogICB2PXNwZjEgZXhpc3RzOiV7aXJ9LiV7bDFyK30uJXtkfQoKQi40LiAgTXVs dGlwbGUgUmVxdWlyZW1lbnRzIEV4YW1wbGUKCiAgIFNheSB0aGF0IHlvdXIgc2VuZGVyIHBvbGlj eSByZXF1aXJlcyBib3RoIHRoYXQgdGhlIElQIGFkZHJlc3MgaXMKICAgd2l0aGluIGEgY2VydGFp biByYW5nZSBhbmQgdGhhdCB0aGUgcmV2ZXJzZSBETlMgZm9yIHRoZSBJUCBtYXRjaGVzLgogICBU aGlzIGNhbiBiZSBkb25lIHNldmVyYWwgd2F5cywgaW5jbHVkaW5nIHRoZSBmb2xsb3dpbmc6Cgog ICBleGFtcGxlLmNvbS4gICAgICAgICAgIFNQRiAgKCAidj1zcGYxICIKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIi1pbmNsdWRlOmlwNC5fc3BmLiV7ZH0gIgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAiLWluY2x1ZGU6cHRyLl9zcGYuJXtkfSAiCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICIrYWxsIiApCiAgIGlwNC5fc3BmLmV4YW1wbGUuY29tLiAg U1BGICAidj1zcGYxIC1pcDQ6MTkyLjAuMi4wLzI0ICthbGwiCiAgIHB0ci5fc3BmLmV4YW1wbGUu Y29tLiAgU1BGICAidj1zcGYxIC1wdHIgK2FsbCIKCiAgIFRoaXMgZXhhbXBsZSBzaG93cyBob3cg dGhlICItaW5jbHVkZSIgbWVjaGFuaXNtIGNhbiBiZSB1c2VmdWwsIGhvdyBhbgogICBTUEYgcmVj b3JkIHRoYXQgZW5kcyBpbiAiK2FsbCIgY2FuIGJlIHZlcnkgcmVzdHJpY3RpdmUsIGFuZCB0aGUg dXNlCiAgIG9mIERlIE1vcmdhbidzIExhdy4KCgoKS2l0dGVybWFuICAgICAgICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgNTRdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpICAgICAgICAgICAgSnVs eSAyMDEyCgoKQXBwZW5kaXggQy4gIENoYW5nZSBIaXN0b3J5CgogICBDaGFuZ2VzIHNpbmNlIFJG QyA0NDA4ICh0byBiZSByZW1vdmVkIHByaW9yIHRvIHB1YmxpY2F0aW9uKQoKICAgICAgTW92ZWQg dG8gc3RhbmRhcmRzIHRyYWNrCgogICAgICBBdXRob3JzIHVwZGF0ZWQKCiAgICAgIElFU0cgTm90 ZSByZWdhcmRpbmcgZXhwZXJpbWVudGFsIHVzZSByZXBsYWNlZCB3aXRoIGRpc2N1c3Npb24gb2YK ICAgICAgcmVzdWx0cwoKICAgICAgUHJvY2VzcyBlcnJhdGE6CgogICAgICBBZGQgJXYgbWFjcm8g dG8gQUJORiBncmFtbWFyCgogICAgICBSZXBsYWNlICJ1cmljIiBieSAidW5yZXNlcnZlZCIKCiAg ICAgIFJlY29tbWVuZCBhbiBTTVRQIHJlcGx5IGNvZGUgZm9yIG9wdGlvbmFsIHBlcm1lcnJvciBy ZWplY3Rpb25zCgogICAgICBDb3JyZWN0IHN5bnRheCBpbiBSZWNlaXZlZC1TUEYgZXhhbXBsZXMK CiAgICAgIEZpeCB1bmtub3duLW1vZGlmaWVyIGNsYXVzZSBpcyB0b28gZ3JlZWR5IGluIEFCTkYK CiAgICAgIENvcnJlY3QgdXNlIG9mIGVtcHR5IGRvbWFpbi1zcGVjIG9uIGV4cCBtb2RpZmllcgoK ICAgICAgRml4IG1pbm9yIHR5cG8gZXJyYXRhCgogICAgICBDb252ZXJ0IHRvIHNwZmJpcyB3b3Jr aW5nIGdyb3VwIGRyYWZ0LAogICAgICBkcmFmdC1pZXRmLXNwZmJpcy00NDA4YmlzLTAwCgogICAg ICBBZGRyZXNzZWQgVGlja2V0ICMxLCBSRkMgNDQwOCBTZWN0aW9uIDIuNS42IC0gVGVtcG9yYXJ5 IGVycm9ycyBieQogICAgICBnaXZpbmcgdGhlIG9wdGlvbiB0byB0dXJuIHJlcGVhdGVkIFNFUlZG QUlMIGludG8gcGVybWVycm9yIGFuZAogICAgICBhZGRpbmcgUkZDIDIzMDggcmVmZXJlbmNlLgoK ICAgICAgQ2xhcmlmaWVkIHRleHQgYWJvdXQgSVB2NCBtYXBwZWQgYWRkcmVzc2VzIHRvIHJlc29s dmUgdGVzdCBzdWl0ZQogICAgICBhbWJpZ3VpdHkKCiAgICAgIENsYXJpZmllZCBhbWJpZ3VpdHkg YWJvdXQgcmVzdWx0IHdoZW4gbW9yZSB0aGFuIDEwICJteCIgb3IgInB0ciIKICAgICAgcmVjb3Jk cyBhcmUgcmV0dXJuZWQgZm9yIGxvb2t1cCB0byBzcGVjaWZ5IHBlcm1lcnJvci4gIFRoaXMKICAg ICAgcmVzb2x2ZXMgb25lIG9mIHRoZSB0ZXN0IHN1aXRlIGFtYmlndWl0aWVzCgogICAgICBNYWRl IGFsbCByZWZlcmVuY2VzIHRvIHJlc3VsdCBjb2RlcyBsb3dlciBjYXNlIHBlciBpc3N1ZSAjNwoK ICAgICAgQWRqdXN0ZWQgc2VjdGlvbiAyLjIgUmVxdWlyZW1lbnQgdG8gY2hlY2sgbWFpbCBmcm9t IHBlciBpc3N1ZSAjMTUKCiAgICAgIEFkZGVkIG1pc3NpbmcgInYiIGVsZW1lbnQgaW4gbWFjcm8t bGV0dGVyIGluIHRoZSBjb2xsZWN0ZWQgQUJORgogICAgICBwZXIgaXNzdWUgIzE2IC0gc2VjdGlv biA4LjEgd2FzIGFscmVhZHkgZml4ZWQgaW4gdGhlIHByZS1XRyBkcmFmdAoKCgoKS2l0dGVybWFu ICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgW1Bh Z2UgNTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChT UEYpICAgICAgICAgICAgSnVseSAyMDEyCgoKICAgICAgTWFya2VkIHB0ciBhbmQgInAiIG1hY3Jv IGRlcHJlY2F0ZWQvU0hPVUxEIE5PVCB1c2UgcGVyIGlzc3VlICMyNwoKICAgICAgRXhwdW5nZWQg bG93ZXIgY2FzZSBtYXkgZnJvbSB0aGUgZHJhZnQgcGVyIGlzc3VlICM4CgogICAgICBFeHB1bmdl ZCAieC0iIG5hbWUgYXMgYW4gb2Jzb2xldGUgY29uY2VwdAoKICAgICAgVXBkYXRlZCBvYnNsZXRl IHJlZmVyZW5jZXM6IFJGQzI4MjEgdG8gUkZDNTMyMSwgUkZDMjgyMiB0bwogICAgICBSRkM1MzIy LCBhbmQgUkZDNDIzNCB0byBSRkM1MjM0CgogICAgICBSZWZlciB0byBSRkM2NjQ3IHRvIGRlc2Ny aWJlIGdyZXlsaXN0aW5nIGluc3RlYWQgb2YgdHJ5aW5nIHRvCiAgICAgIGRlc2NyaWJlIGl0IGRp cmVjdGx5LgoKICAgICAgVXBkYXRlZCBpbmZvcm1hdGl2ZSByZWZlcmVuY2VzIHRvIHRoZSBjdXJy ZW50IHZlcnNpb25zLgoKICAgICAgQWRkZWQgZGVmaW5pdGlvbiBmb3IgZGVwcmVjYXRlZCBzaW5j ZSB0aGVyZSBhcmUgcXVlc3Rpb25zLgoKICAgICAgU3RhcnQgdG8gcmV3b3JrIHNlY3Rpb24gOSB3 aXRoIHNvbWUgUkZDNTU5OCB0ZXJtcy4KCiAgICAgIEFkZGVkIG1lbnRpb24gb2YgUkZDIDY1NTIg ZmVlZGJhY2sgcmVwb3J0cyBpbiBzZWN0aW9uIDkuCgogICAgICBBZGRlZCBkcmFmdC1pZXRmLXNw ZmJpcy1leHBlcmltZW50IGFzIGFuIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlLgoKICAgICAgRHJv cCBUeXBlIFNQRi4KCiAgICAgIFRyeSBhbmQgY2xhcmlmeSBpbmZvcm1hdGlvbmFsIG5hdHVyZSBv ZiBSRkMzNjk2CgogICAgICBGaXggQUJORiBuaXRzIGFuZCBhZGQgbWlzc2luZyBkZWZpbml0aW9u cyBwZXIgQmlsbCdzIEFCTkYgY2hlY2tlci4KCiAgICAgIE1ha2UgRE5TIGxvb2t1cCB0aW1lIGxp bWl0IFNIT1VMRCBpbnN0ZWFkIG9mIE1BWS4KCiAgICAgIFJlb3JnYW5pemUgYW5kIGNsYXJpZnkg cHJvY2Vzc2luZyBsaW1pdHMuICBNb3ZlIGhhcmQgbGltaXRzIHRvIG5ldwogICAgICBzZWN0aW9u IDQuNi40LCBFdmFsdWF0aW9uIExpbWl0cy4gIE1vdmUgYWR2aWNlIHRvIG5vbi1ub3JtYXRpdmUK ICAgICAgc2VjdGlvbiA5LgoKICAgICAgUmVtb3ZlZCBwYXJhZ3JhcGggaW4gc2VjdGlvbiAxMC4x IGFib3V0IGxpbWl0aW5nIHRvdGFsIGRhdGEKICAgICAgdm9sdW1lcyBhcyBpdCBpcyB1bnVzZWQg KGFuZCByZW1vdmFibGUgcGVyIHRoZSBjaGFydGVyKSBhbmQgc2VydmVzCiAgICAgIG5vIHB1cnBv c2UgKGl0IGlzbid0IHNvbWV0aGluZyB0aGF0IGFjdHVhbGx5IGNhbiBiZSBpbXBsZW1lbnRlZCBp bgogICAgICBhbnkgcmVhc29uYWJsZSB3YXkpLgoKCgoKCgoKCgoKCgoKS2l0dGVybWFuICAgICAg ICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgNTZd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpICAg ICAgICAgICAgSnVseSAyMDEyCgoKQXV0aG9yJ3MgQWRkcmVzcwoKICAgU2NvdHQgS2l0dGVybWFu CiAgIEFnYXJpCiAgIDM2MTEgU2NoZWVsIERyCiAgIEVsbGljb3R0IENpdHksIE1EICAyMTA0Mgog ICBVbml0ZWQgU3RhdGVzIG9mIEFtZXJpY2EKCiAgIEVtYWlsOiBzY290dEBraXR0ZXJtYW4uY29t CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCktpdHRlcm1hbiAgICAg ICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDU3 XQoMCg== --f46d040838d3bc507a04c4b1c040-- From hsantos@isdg.net Fri Jul 13 03:58:36 2012 Return-Path: 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 DC0E821F8694 for ; Fri, 13 Jul 2012 03:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.018 X-Spam-Level: X-Spam-Status: No, score=-102.018 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 xtmEaHKIKYGb for ; Fri, 13 Jul 2012 03:58:36 -0700 (PDT) Received: from secure.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E78BE21F8681 for ; Fri, 13 Jul 2012 03:58:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3869; t=1342177146; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=w1czmwhr+6Vp1fyt/gKGtzIz4hY=; b=H/XK+HezGF8OVeLrWZQh tRz4r6NJNScNcxODxvQR2mYCi7PVqBh7lUuN7r/MZQSJGgi6zlD6jtL4jhEBBrdC aBadurBr/HRyOD71v2vjThaQhIz0O9EQlrGaMCRms6qXrztAQypIgXmlAQpXge/F ccPUg7FRohFHZqVpd4SpBeY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 13 Jul 2012 06:59:06 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2493950879.12589.2772; Fri, 13 Jul 2012 06:59:05 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3869; t=1342177027; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+cK5rmN XM19gEBGgVNI439ycU0RQElzWbzLqOEa54Pk=; b=pn1GusMUdh9Q7Q+XOiwUDnU AMLLrZHtryhv9wohI4hGQvaauWQ34LEYCY1F3LBSNDe9rTZRRjBuvbQ3y43sroON Oge5JGe0YNM9tx0iUR5u7hjruKSsv5Uqf9GQtA1Lt+mAV27k/hJk9lUe2nGiLG3e k9BN3fJxrAMErfz5jLQo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 13 Jul 2012 06:57:07 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3092791988.9.6272; Fri, 13 Jul 2012 06:57:05 -0400 Message-ID: <4FFFFFA1.3090201@isdg.net> Date: Fri, 13 Jul 2012 06:59:45 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120712022051.60587.qmail@joyce.lan> <2786082.683g7oVmD0@scott-latitude-e6320> <7553255.LjjZa8jCz8@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 10:58:37 -0000 The premise that an documented feature in a specification is unused is now a basis for removal, opens the highly subjective door to popularity contests and "Who's Who Using What" reasonings. Case in point, the statement "its an unused feature, pure and simple" is not a fact. If this premise is used across the board, I sincerely doubt we would have extremely wide support for (or it would be very hard to support) protocols when a "less popular" feature is always open for be subjectively removed and pulled from under your feet. Fortunately, it hasn't and doesn't work that way. I would prefer to discuss the proposal of removing a (SPF) feature on the basis there is a technical and/or security problem. Odds are good, it is probably inherently less used anyway on that basis and IMO, worthy of discussion. IMO, the issues with EAI appear to be complex, therefore unsettled and a moving target. -- HLS Murray S. Kucherawy wrote: > On Thu, Jul 12, 2012 at 10:45 PM, Scott Kitterman wrote: > >> We gain nothing from dropping it and we break a small number of existing >> records. >> > > I don't agree that we gain nothing from dropping it. We gain simplicity. > Perhaps the value of simplicity in a Proposed Standard is being > underestimated. > > >> It seems a bit odd that if we learned that as a lesson of the experiment, >> we >> didn't think important enough to mention in draft-ietf-spfbis-experiment. >> > > Why would use of SPF macros be germane to a document whose function is to > compare adoption rates of SPF versus Sender ID, and not their specific > components? > > As it happens, the data collection we did for that effort includes > something that's interesting to this one. I don't think that's odd at all. > > Because there's no compelling reason to remove it. > > > But there is. > > >> Did any of these precedents involve working groups where the charter said >> only >> unused features could be removed? If not, I don't think they are relevant. >> > > Yes, all of them, since it's normal IETF procedure when upgrading the > status of something on the standards track. You might want to review > RFC6410 Section 2.2, which covers advancement from Proposed Standard to > Internet Standard (Draft Standard has been eliminated since DKIM was > updated), as it includes as one of the criteria: > > (3) There are no unused features in the specification that greatly > increase implementation complexity. > > Macros are both relatively unused and increase complexity. I'm trudging > through Section 8 in my review now. > > The only "outs" here to me are the facts that (a) we're moving from > Experimental to Proposed Standard, which RFC6410 doesn't cover (although I > believe it's still useful to apply these criteria as good practice), and > (b) the definition of "unused" in this context is fuzzy. > > I believe we have a stronger Proposed Standard by removing this or anything > else that yields no operational or community benefit. Section 8 is not a > trivial piece of work for an implementer to follow and get right. No, it's > not impossible, but I don't agree that it's at all straightforward either. > > >> Changes to the SPF specification will be limited to the correction >> of errors, removal of unused features, addition of any enhancements >> that have already gained widespread support, and addition of >> clarifying language. >> >> I don't think any of those apply here. >> >> > I don't agree. The statistics speak clearly to me that macros are an > unused feature, and "removal of unused features" appears in the very > charter text you cited. > > I've said my piece here. Others will have to weigh in. However, I ask > that the co-chairs open this as a new tracker item as a separate issue from > #14. > > -MSK > From ajs@anvilwalrusden.com Fri Jul 13 07:16:46 2012 Return-Path: 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 7AFE521F8763 for ; Fri, 13 Jul 2012 07:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 rsoNbBhhiaVW for ; Fri, 13 Jul 2012 07:16:46 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id EA66421F86A7 for ; Fri, 13 Jul 2012 07:16:45 -0700 (PDT) Received: from mail.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3863F8A031 for ; Fri, 13 Jul 2012 14:17:21 +0000 (UTC) Date: Fri, 13 Jul 2012 10:17:19 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120713141719.GE93613@mail.yitter.info> References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFEE64C.6000308@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 14:16:46 -0000 Chair hat on. On Thu, Jul 12, 2012 at 07:59:24AM -0700, Dave Crocker wrote: > A feature that adds significantly complexity in design, development > and operation (debugging) but has gained so little use is a feature > worth dropping. As you know, I was quite uncomfortable with the decision about the SPF type not because I think TYPE 99 is real useful, but because our charter says that we are to drop _unused_ features. Dave, at the time you argued for an interpretation of "unused" that was really "not used very much", where the value of "very much" had to be evaluated by the WG. We avoided having to make a decision about that, however, because we concluded that there was a significant ambiguity in the published RFC and that therefore we would be required to make a change. This case is not like that: there's no requirement to use these macros at all in order to get the protocol working, and even though the protocol is complicated by them we have positive evidence that some people are using them, which presumably means that they can't achieve their desired goal through some other (equivalent) functionality already available in RFC 4408. Therefore, I cannot see how we are in any way chartered to ditch this feature, unless we opt for Dave's somewhat strained interpretation of "unused". Now, with my hat off, why can't the document simply note that there are significant issues entailed by local part macros, that they won't work at all with internationalized addresses, and leave it at that for now? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Fri Jul 13 07:30:01 2012 Return-Path: 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 26E5621F87C7 for ; Fri, 13 Jul 2012 07:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] 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 fL1+GKDn9YJA for ; Fri, 13 Jul 2012 07:29:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5E021F86A7 for ; Fri, 13 Jul 2012 07:29:59 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 608CA20E40A6; Fri, 13 Jul 2012 10:30:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342189832; bh=GgnXzN+B3ED7pp3foLo+1jAApYKY7xG1dtXo0aED/aI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aiUg+l7HZL+ue6YidaAPvl2qsmLNfOOarEshroCWYZhchnD99LG8XJ4+Ynj8EpnDZ ojTpuq85GGZrf24vSUxQEGfhbznhTGIR9FqRAEz7eaQ+wvu/Xmn/IoaerR4irsRi/W /0H+POnTG0Eyq+R7kZqr+Yx//v1Q33+YTKshnmu4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4570620E4064; Fri, 13 Jul 2012 10:30:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Jul 2012 10:30:31 -0400 Message-ID: <1829264.emYc08YJ9f@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120713141719.GE93613@mail.yitter.info> References: <20120712022051.60587.qmail@joyce.lan> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 14:30:02 -0000 On Friday, July 13, 2012 10:17:19 AM Andrew Sullivan wrote: > Now, with my hat off, why can't the document simply note that there > are significant issues entailed by local part macros, that they won't > work at all with internationalized addresses, and leave it at that for > now? It can and should do exactly that. Scott K From WebMaster@Commerco.Net Fri Jul 13 07:55:54 2012 Return-Path: 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 82B7821F87B9 for ; Fri, 13 Jul 2012 07:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 oc4f0pe5i1H0 for ; Fri, 13 Jul 2012 07:55:53 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9C46E21F87B0 for ; Fri, 13 Jul 2012 07:55:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=MnwUAxxa9jwo/CS1K2WJJQpxS540ZpIq7P+7L+H9pAepA/dt4xn8fvOGFSpq6R8+aX17Cobqd/FuqVK+xHPWjDVbfjDHkDHEDjru/V4pGpS3SQ1Hwrx+Ni8ijrkNhxyZS6ja2ZWLbTpEy8D7Vy+TJEUtWC8/gq66U+I0Mb28zW0= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]); Fri, 13 Jul 2012 14:56:27 +0000 Message-ID: <50003714.6010105@Commerco.Net> Date: Fri, 13 Jul 2012 08:56:20 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org, Andrew Sullivan References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> In-Reply-To: <20120713141719.GE93613@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 14:55:54 -0000 On 7/13/2012 8:17 AM, Andrew Sullivan wrote: > Chair hat on. > > On Thu, Jul 12, 2012 at 07:59:24AM -0700, Dave Crocker wrote: >> A feature that adds significantly complexity in design, development >> and operation (debugging) but has gained so little use is a feature >> worth dropping. > > As you know, I was quite uncomfortable with the decision about the SPF > type not because I think TYPE 99 is real useful, but because our > charter says that we are to drop _unused_ features. Dave, at the time > you argued for an interpretation of "unused" that was really "not used > very much", where the value of "very much" had to be evaluated by the > WG. We avoided having to make a decision about that, however, because > we concluded that there was a significant ambiguity in the published > RFC and that therefore we would be required to make a change. > > This case is not like that: there's no requirement to use these macros > at all in order to get the protocol working, and even though the > protocol is complicated by them we have positive evidence that some > people are using them, which presumably means that they can't achieve > their desired goal through some other (equivalent) functionality > already available in RFC 4408. Therefore, I cannot see how we are in > any way chartered to ditch this feature, unless we opt for Dave's > somewhat strained interpretation of "unused". > > Now, with my hat off, why can't the document simply note that there > are significant issues entailed by local part macros, that they won't > work at all with internationalized addresses, and leave it at that for > now? > > Best, > > A > +1. Although I do appreciate the benefits Murray points out in reducing complexity of a specification, there is certainly no requirement to implement the marcros in SPF. A note mentioning the downsides of doing so with this optional facility within the SPF spec should suffice and seems a good compromise. As to this issue vs the DNS SPF type 99 issue, while I also shared the concern in dropping the use of SPF type 99 in the current spec, it was done so because of its potential for "breaking things". Stretching the charter in that case to ensure a better working specification was almost certainly worth it. Best, Alan M. From spf2@kitterman.com Fri Jul 13 08:13:43 2012 Return-Path: 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 5798F21F86E2 for ; Fri, 13 Jul 2012 08:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] 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 6u85RU-NRG2e for ; Fri, 13 Jul 2012 08:13:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF0921F86D7 for ; Fri, 13 Jul 2012 08:13:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A019320E40A6; Fri, 13 Jul 2012 11:14:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342192458; bh=VfiLLyzjdizxzp+FbehjkEh1HNpi7dsFB+69gXEH2gA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dTjNASyCyVA+pR06o0fyc5fb/pLU8Sa05MFkShdfdoXAhmVfo3H45Leg0e4Mnx1Ss 3y2Kagq7pP/fMYBjdMglIcHbyLw+Bs9LbL51HHPQI8vBzFdMBZiNEap2Q30ygeItSw pS5D2OIsYJUjNfr0Zdvs+UcwcvlqpTVmkgtNCQmA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8268320E4064; Fri, 13 Jul 2012 11:14:18 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Jul 2012 11:14:17 -0400 Message-ID: <1526222.13biqUg3CC@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50003714.6010105@Commerco.Net> References: <20120712022051.60587.qmail@joyce.lan> <20120713141719.GE93613@mail.yitter.info> <50003714.6010105@Commerco.Net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 15:13:43 -0000 On Friday, July 13, 2012 08:56:20 AM Commerco WebMaster wrote: ... > +1. Although I do appreciate the benefits Murray points out in reducing > complexity of a specification, there is certainly no requirement to > implement the marcros in SPF. A note mentioning the downsides of doing > so with this optional facility within the SPF spec should suffice and > seems a good compromise. ... Just to make sure we're all on the same page about this ... By, "no requirement to implement the macros in SPF", I gather you mean "no requirement to use macros in an SPF record". Support for macros as part of receiver processing of SPF is not optional. Scott K From dhc@dcrocker.net Fri Jul 13 08:18:00 2012 Return-Path: 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 2A5A621F878B for ; Fri, 13 Jul 2012 08:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 nsf2MyEs3kyL for ; Fri, 13 Jul 2012 08:17:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B03421F8780 for ; Fri, 13 Jul 2012 08:17:59 -0700 (PDT) Received: from [192.168.1.9] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6DFIZh9009579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Jul 2012 08:18:35 -0700 Message-ID: <50003C42.7020208@dcrocker.net> Date: Fri, 13 Jul 2012 08:18:26 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <20120712022051.60587.qmail@joyce.lan> <7553255.LjjZa8jCz8@scott-latitude-e6320> <25336858.gnRrL7ieMU@scott-latitude-e6320> In-Reply-To: <25336858.gnRrL7ieMU@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 13 Jul 2012 08:18:35 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 15:18:00 -0000 On 7/12/2012 11:53 PM, Scott Kitterman wrote: > On Thursday, July 12, 2012 11:32:48 PM Murray S. Kucherawy wrote: >> (3) There are no unused features in the specification that greatly >> increase implementation complexity. > > Requiring unused features to be removed is not at all the same thing as > requiring used features be kept (which is what the SPFbis charter says). > Additionally, while I agree that macros increase complexity, I wouldn't agree > with the idea that they greatly increase complexity. 1. "Unused" is a statistical label. It does not mean that there are literally no implementations or deployments. It means that it has not gained serious use. Anything that's been available this long and has reached such a tiny percentage of deployment is unused. (Murray's comparison to Sender-ID statistics brings this home nicely, IMO.) 2. A recursion construct is inherently complex. It invites both software and configuration bugs and they are naturally more difficult to debug, especially across the Internet with different administrations and where the parties are not actively debugging at the same time. The more simple a specification, the easier it is for a wider range of readers to understand it and the easier it is for a wider range of implementers and operators to follow it correctly. The cost of any feature is exponentially higher than we tend to think, because it affects so many implementations and installations. On Internet scale, that's a very, very large number. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From WebMaster@Commerco.Net Fri Jul 13 08:35:45 2012 Return-Path: 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 87BB221F87B6 for ; Fri, 13 Jul 2012 08:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 67hDqCu4JYak for ; Fri, 13 Jul 2012 08:35:44 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9B25821F87BF for ; Fri, 13 Jul 2012 08:35:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=V1sG4tv0XZedof+micFBS1uTijvGF/oipvT0LLukD+6thXaVh9UY1fhN87tWyAjGS5i9PUt84A5OiOpA0kVv63bDzkLfXTSNt+6UzxFx04RoihFbB0NC+vGEPxV7K91OHCxO4yhbQuzV4Oxkt6bkOGQmmCT3162dM126XyXZQYU= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]); Fri, 13 Jul 2012 15:36:18 +0000 Message-ID: <5000406B.9070804@Commerco.Net> Date: Fri, 13 Jul 2012 09:36:11 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org, Scott Kitterman References: <20120712022051.60587.qmail@joyce.lan> <20120713141719.GE93613@mail.yitter.info> <50003714.6010105@Commerco.Net> <1526222.13biqUg3CC@scott-latitude-e6320> In-Reply-To: <1526222.13biqUg3CC@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 15:35:45 -0000 On 7/13/2012 9:14 AM, Scott Kitterman wrote: > On Friday, July 13, 2012 08:56:20 AM Commerco WebMaster wrote: > ... >> +1. Although I do appreciate the benefits Murray points out in reducing >> complexity of a specification, there is certainly no requirement to >> implement the marcros in SPF. A note mentioning the downsides of doing >> so with this optional facility within the SPF spec should suffice and >> seems a good compromise. > ... > > Just to make sure we're all on the same page about this ... > > By, "no requirement to implement the macros in SPF", I gather you mean "no > requirement to use macros in an SPF record". Support for macros as part of > receiver processing of SPF is not optional. > > Scott K Sorry about that. Just me being publisher centric. Yes, you interpreted my intent correctly. Alan M. From johnl@iecc.com Fri Jul 13 08:51:27 2012 Return-Path: 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 87E7B21F87D8 for ; Fri, 13 Jul 2012 08:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.121 X-Spam-Level: X-Spam-Status: No, score=-111.121 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 tGCeCbuPkcFt for ; Fri, 13 Jul 2012 08:51:26 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 82C6011E8098 for ; Fri, 13 Jul 2012 08:51:25 -0700 (PDT) Received: (qmail 67200 invoked from network); 13 Jul 2012 15:52:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Jul 2012 15:52:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50004420.xn--btvx9d.k1207; i=johnl@user.iecc.com; bh=GUfRHerHHGQIKl2GwvQufC1fA+GqQmCpKMQX7XNP2W8=; b=SdHsbxGUUTYnbohfxvtFXyT7dwdTsAMYkxNziYiOlbm0Y6Qhpe1L8OpV0tSvR8dySIINxDIWN5w/78ldWTMKwfLOsgomgl9GcPNBRcRzF9rGviLuaMmvqi96zYaw9L0dwmPord51+MIyGImWULfatCL9vY/My0SVJ5VdRpQGLHY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50004420.xn--btvx9d.k1207; olt=johnl@user.iecc.com; bh=GUfRHerHHGQIKl2GwvQufC1fA+GqQmCpKMQX7XNP2W8=; b=bZPBEyo/ofaTsCWdSH9mjxMclLH6RQ2DWhKdIYtkFGvGa7+AxqlI54Sro/KEPJa6omXaI8QET0QFt4E4VpW/ixolBVcutRO59YbfrPMl8CW86N552d/PM8sB8THVDtIKzlRm0XNLPC6+bn3Hzm1n+CR1D0G7ws8wZQzNL4I4vcE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Jul 2012 15:51:38 -0000 Message-ID: <20120713155138.39234.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1829264.emYc08YJ9f@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 15:51:27 -0000 >> Now, with my hat off, why can't the document simply note that there >> are significant issues entailed by local part macros, that they won't >> work at all with internationalized addresses, and leave it at that for >> now? I'm more worried about the broken by design aspect of macros, particularly localpart macros, since they let bad guys inject arbitrary text strings into the expanded text. In the example of generating an explanatory URL in an exp: record, a suitably forged bounce address can inject ? & and other interesting characters into the URL. Or it can inject arbitrary invalid characters into domain names to be looked up, which DNS client libraries may defend against and may not. (How many people have checked to see what happens if you feed ^D or ^Z or characters with the high bit set to your local version of gethostbyname?) I realize there are upper case versions that do percent expansion, but if we leave macros in, we can't force people to use them. Given how few people have found them useful, I'd rather just deprecate them. R's, John PS: In case it's not obvious, this is not the same issue as Doug's alleged DNS storms. From ajs@anvilwalrusden.com Fri Jul 13 08:52:42 2012 Return-Path: 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 BE00C21F87D8 for ; Fri, 13 Jul 2012 08:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 fi-0Jf99dSkQ for ; Fri, 13 Jul 2012 08:52:42 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A7F5711E8098 for ; Fri, 13 Jul 2012 08:52:41 -0700 (PDT) Received: from mail.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 9FE448A031 for ; Fri, 13 Jul 2012 15:53:17 +0000 (UTC) Date: Fri, 13 Jul 2012 11:53:16 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120713155316.GN93613@mail.yitter.info> References: <20120712022051.60587.qmail@joyce.lan> <7553255.LjjZa8jCz8@scott-latitude-e6320> <25336858.gnRrL7ieMU@scott-latitude-e6320> <50003C42.7020208@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50003C42.7020208@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 15:52:42 -0000 Hat on. On Fri, Jul 13, 2012 at 08:18:26AM -0700, Dave Crocker wrote: > > 1. "Unused" is a statistical label. It does not mean that > there are literally no implementations or deployments. It means > that it has not gained serious use. Anything that's been available > this long and has reached such a tiny percentage of deployment is > unused. Just to be clear: you mean that as a proposed interpretation, not a statement of fact, right? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From vesely@tana.it Fri Jul 13 08:54:24 2012 Return-Path: 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 0F9D521F87E1 for ; Fri, 13 Jul 2012 08:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.612 X-Spam-Level: X-Spam-Status: No, score=-4.612 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 kvgSBcNpXdaN for ; Fri, 13 Jul 2012 08:54:22 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE0521F87DF for ; Fri, 13 Jul 2012 08:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342194897; bh=8CF8EfqAPgNNHxz84t2MTGM1tieX4cqAo9yQvYoVYtU=; l=3794; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=e5XhzXGWxtGIwOc/G3c7c7TPZCE/iaglntWV0bn4/SceeQU6LHn4I0636HvMDqSfL s+8OSjtGP17Bt52G0QkXnfrHp+hHmg2HIPbArlxVTvI0j2ip8ke2MKQdEvH6LRJAF9 3ca5ECJIEG24jNVq8AvZ0IOCBMH4t5T4bZ7B+VyQ= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 13 Jul 2012 17:54:57 +0200 id 00000000005DC035.00000000500044D1.000076C3 Message-ID: <500044D1.8090501@tana.it> Date: Fri, 13 Jul 2012 17:54:57 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 15:54:24 -0000 On Fri 13/Jul/2012 10:20:28 +0200 Murray S. Kucherawy wrote: > Attached is a top-down review of the RFC4408bis document. Apologies > that it took so long, but it's a big document. That's great of you, thanks. > Comments welcome. I comment only some of Murray's suggestions, for the time being. @ 445 > It is RECOMMENDED that SPF clients not only check the "MAIL FROM" > identity, but also separately check the "HELO" identity by applying > the check_host() function (Section 4) to the "HELO" identity as the > . > > [MSK: We need to explain why this is RECOMMENDED. We might later, > but I haven't gotten that far yet and I might forget to come back > and delete this. :-)] Good point. I don't see how we can explain that "why" without also telling how the result can affect the server's behavior. See the text at line 653 of Murray's review, quoted below. @ 480 > If domain owners choose to publish SPF records, it is RECOMMENDED > that they end in "-all", or redirect to other records that do, so > that a definitive determination of authorization can be made. > > [MSK: RECOMMENDED in RFC2119 terms is effectively a SHOULD. I > don't think we should do this, as that's strictly a local policy > matter and not one of interoperability.] Although local policy is intertwined with interoperability in various ways, I agree 2119-language is not adequate to express policy issues. For example, publishers ShOuLd NoT use +all. How do we convey such stuff? @ 599 > Generating non-delivery notifications to forged identities that have > failed the authorization check is generally abusive and against the > explicit wishes of the identity owner. > > [MSK: I think we should say more here. For example, how exactly is > it abusive? The recipient has done exactly what it was asked to > do, yet it's abusing someone? Rather than saying it's abusive, I > suggest we say it introduces backscatter, and then define that > term.] E.g.: Backscatter: An unwitting abuse of domain names caused by using unverified addresses as targets for NDNs. @ 653 > [MSK: We should probably give a sentence somewhere above this about > what's meant by "mark the mail". Maybe even a small section about > possible "fail" actions that underscores the fact that rejection > vs. marking is a choice and neither is specifically required would > be a good idea.] A new Section 2? It had better be a "non normative" section, since we want to avoid 2119-language for this topic. Some parts of Section 9 might go there as well. @ 711 > [MSK: Do we really need to spell out SMTP reply codes and enhanced > status codes? Isn't it enough to say those codes are defined in > RFC5321 and RFC3463, and leave it at that?] +1, those constructs are indirect ways to insinuate behavioral suggestions. They should be stated in a more direct manner, perhaps in the new Section 2 aired above. @ 761 > Loosely, the record partitions all hosts > into permitted and not-permitted sets (though some hosts might fall > into neither category). > > [MSK: That sounds confusing. How is that possible?] I attempted a better wording, but my English doesn't support me. That quoted sentence was transformed into the less loose but too lengthy: For each identity, an SPF evaluation starting at the relevant domain name associates an authorization result to each possible sender, based on the authentication token provided by lower level protocols, the IP address. http://www.ietf.org/mail-archive/web/spfbis/current/msg01775.html Can someone compose something that's precise and readable at the same time? @ 777 > Domain owners wishing to be SPF compliant must publish SPF records > > [MSK: s/must/MUST/] I'd suggest MAY. From vesely@tana.it Fri Jul 13 09:17:35 2012 Return-Path: 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 3E0F721F86F7 for ; Fri, 13 Jul 2012 09:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.615 X-Spam-Level: X-Spam-Status: No, score=-4.615 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 H3d5hBWtU4pc for ; Fri, 13 Jul 2012 09:17:34 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 453F921F86EB for ; Fri, 13 Jul 2012 09:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342196289; bh=iKQKpRI2TuqZxMOHWA6528knAREStCXoa320Ed6Ymtg=; l=618; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=CKHdiaR5GSuNgpvSH8JcHSeHHVzMvNeB2LoQUh/wTResbFpyz11t4LnWH9V4F1H+K SJ4CM/HI925PhEMI+8rupP35fxdkCUt07NgBtQeKwHuKXJIdC8taqenZvOO7yjng2i /lMS50PF4LLxG+n8BKRhcbYkFI5/yWmiWmuLiIH0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 13 Jul 2012 18:18:09 +0200 id 00000000005DC035.0000000050004A41.00007BFF Message-ID: <50004A41.2050802@tana.it> Date: Fri, 13 Jul 2012 18:18:09 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> In-Reply-To: <20120713141719.GE93613@mail.yitter.info> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 16:17:35 -0000 On Fri 13/Jul/2012 16:17:19 +0200 Andrew Sullivan wrote: > This case is not like that: there's no requirement to use these macros > at all in order to get the protocol working, and even though the > protocol is complicated by them we have positive evidence that some > people are using them, which presumably means that they can't achieve > their desired goal through some other (equivalent) functionality > already available in RFC 4408. +1, type 99 has an obvious and painless replacement, while replacing an already deployed authorization scheme that uses local-parts can be plainly unfeasible. jm2c From hsantos@isdg.net Fri Jul 13 09:41:46 2012 Return-Path: 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 EF26921F87C8 for ; Fri, 13 Jul 2012 09:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 Nul0ceygLccd for ; Fri, 13 Jul 2012 09:41:46 -0700 (PDT) Received: from dkim.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C976A21F8674 for ; Fri, 13 Jul 2012 09:41:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1571; t=1342197732; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=h64OWt4v9f7J9Rzz6u1zyiW3Urw=; b=DKq8Xlu2tHroUjV3AZxN mmoF1Jr/xSq3N4DlThn0Kz080BOoAVDs66KgYv8LtCgGXV4e46mTn4GEe8tJ06+q ucCKdjruF05Jl5xT/5GkWDFrSq8FFjr87GN6UtZ/YERmKCvn8toF6VviLl3mkS4i zSLvMBg58oyGklpTwUWT65Q= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 13 Jul 2012 12:42:12 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2514536162.12589.2668; Fri, 13 Jul 2012 12:42:11 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1571; t=1342197610; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gn9v4MS S+fKBjjr4W+txnPGBMQIp77jKtBcp7M2Jl9I=; b=qsKLcnnwcFtpJNHzqPJtXnl 5UY5RawcVIJZQCAyrAUidktLTIxOOfkp4aVrMwCj9isolhw1/iLJLERpS506oNQs mOQw32qpGXvyFTlOYFw4Bml33AeAlM1fgajYxEjuegMuHstzMq/YW3/KjSiD2gZi 5y1MIU5YOl0uP6upo+Xk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 13 Jul 2012 12:40:10 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3113375770.9.5104; Fri, 13 Jul 2012 12:40:09 -0400 Message-ID: <50004FE7.10202@isdg.net> Date: Fri, 13 Jul 2012 12:42:15 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120712022051.60587.qmail@joyce.lan> <7553255.LjjZa8jCz8@scott-latitude-e6320> <25336858.gnRrL7ieMU@scott-latitude-e6320> <50003C42.7020208@dcrocker.net> In-Reply-To: <50003C42.7020208@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 16:41:47 -0000 Dave Crocker wrote: > > On 7/12/2012 11:53 PM, Scott Kitterman wrote: >> On Thursday, July 12, 2012 11:32:48 PM Murray S. Kucherawy wrote: >>> (3) There are no unused features in the specification that greatly >>> increase implementation complexity. >> >> Requiring unused features to be removed is not at all the same thing as >> requiring used features be kept (which is what the SPFbis charter says). >> Additionally, while I agree that macros increase complexity, I >> wouldn't agree >> with the idea that they greatly increase complexity. > > > 1. "Unused" is a statistical label. It does not mean that there > are literally no implementations or deployments. It means that it has > not gained serious use. So now we need to define "serious." Rhetorically, is it related to vendor size, influence, IETF or trade group meetings, attendance, not just # of vendors but which ones, industry size, etc? I am sure we get that point. I hope. I don't think SPF macro language falls in that category of considerations. Personally see it is rarely used (according to a quick dns cache read), it is nonetheless in play. I also have not seen DNS Storms in the 9+ years for product deployment among thousands of operators. I believe the limits may be part of the security blanket. (I thought this issue was dropped because in fact, we do have limits?) Finally, isn't this two different issues? macro expansion versus EAI text conversion methods? I presume one is about overhead and the other complexity/correctiveness/capability. -- HLS From hsantos@isdg.net Fri Jul 13 10:25:24 2012 Return-Path: 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 9DFA911E8087 for ; Fri, 13 Jul 2012 10:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 c9MxAdGGj0pK for ; Fri, 13 Jul 2012 10:25:23 -0700 (PDT) Received: from dkim.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 40BB611E8086 for ; Fri, 13 Jul 2012 10:25:22 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1462; t=1342200347; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=kjQQw3jm+pe82gPPsdRJX2h+PKk=; b=p+esSAJXSlWhGnA8HqTw 7fKEMf93awHngCitTtwTFpuxFiEPZmEEbW1VN6Q3m8eEdlj6WiZtvC2TbeugY8Z3 EyTDi6jMKCk3sCGywpX6d/TkgV8aeFhAA3kMwwl+lVswtnd8rLFKvuu/jPs6oNU9 ZicPv9VsuWxEfl1HYErdPxg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 13 Jul 2012 13:25:47 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2517151316.12589.5868; Fri, 13 Jul 2012 13:25:46 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1462; t=1342200226; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=kRmwUnG mGTPcUDplv7sXPiPrB6f28Ou8bS59K8LNMYs=; b=bZ0kiyytjguFjmcB4yHEqAO P1qNSiR0HFJavFERW+5JPQDV9XHaE26sa+5dJnoGHBZ9bJjyoZ9HeZzcVrQgITrr 0InEW1Vhq/pSlVAPG8jfX2bMaFV3keEox5f6l+cRBVZ29jBaWXzlL6hS1xQ5pEr4 4U6xI9PBLMpQyov42QPQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 13 Jul 2012 13:23:46 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3115991504.9.5868; Fri, 13 Jul 2012 13:23:45 -0400 Message-ID: <50005A1F.8060606@isdg.net> Date: Fri, 13 Jul 2012 13:25:51 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: SPFBIS WG References: <20120712022051.60587.qmail@joyce.lan> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <1829264.emYc08YJ9f@scott-latitude-e6320> In-Reply-To: <1829264.emYc08YJ9f@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 17:25:25 -0000 Scott Kitterman wrote: > On Friday, July 13, 2012 10:17:19 AM Andrew Sullivan wrote: >> Now, with my hat off, why can't the document simply note that there >> are significant issues entailed by local part macros, that they won't >> work at all with internationalized addresses, and leave it at that for >> now? > > It can and should do exactly that. IMV, since this continues to be a moving target with associations across many applications levels, there is an increase need to understand this in general. So I think it is better to described it as best as we know it now. Personally, one that often comes into logic play is when conversion is expected or passthru. i.e. should the conversion be dynamic or once when the input stream is received? I do think that no matter what, even when the receiver does all it suppose to do correctly, if the result is a calculation failure then we should consider what the SPF result should be. NONE? SOFTFAIL? To me, NONE is ok, but too much or on-going promotion to NONE which there is intent to use SPF does give receivers the natural server abuse protection right to take action against this unnecessary overhead. The same issue applies to the TEMPFAIL/SERVFAIL issue and what should be returned. Receivers have an inherent right to control abuse and redundancy (never ending) errors, therefore a temporary error "SHOULD" be allowed to be promoted to an permanent error. -- HLS From dhc@dcrocker.net Fri Jul 13 11:53:43 2012 Return-Path: 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 9DD1311E80B5 for ; Fri, 13 Jul 2012 11:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 r78PEMWAhIpY for ; Fri, 13 Jul 2012 11:53:42 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EE0E911E80C6 for ; Fri, 13 Jul 2012 11:53:41 -0700 (PDT) Received: from [172.19.85.176] (64.125.189.90.t00817-23.above.net [64.125.189.90] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6DIrkBC013409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Jul 2012 11:53:47 -0700 Message-ID: <50006EB2.7040601@dcrocker.net> Date: Fri, 13 Jul 2012 11:53:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> In-Reply-To: <20120713141719.GE93613@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 13 Jul 2012 11:53:47 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 18:53:43 -0000 On 7/13/2012 7:17 AM, Andrew Sullivan wrote: > Dave, at the time > you argued for an interpretation of "unused" that was really "not used > very much", where the value of "very much" had to be evaluated by the Good to know that I am sometimes consistent, since I am still putting forward that view... > This case is not like that: there's no requirement to use these macros > at all in order to get the protocol working, and even though the > protocol is complicated by them we have positive evidence that some > people are using them, which presumably means that they can't achieve > their desired goal through some other (equivalent) functionality > already available in RFC 4408. Therefore, I cannot see how we are in > any way chartered to ditch this feature, unless we opt for Dave's > somewhat strained interpretation of "unused". Besides re-raising the question of whether 'unused' requires the mathematical perfection on 'none' versus 'extremely few', you have introduced another aspect of 'used' that is often debated. That is, the distinction between "in the code" vs. "over the wire". They are very different kinds of usage, of course. My view is that putting something in the specification essentially requires implementation in code and that that's expensive. Yes, many scenarios of non-use operationally can formally justify not implementing in code, but I believe it is more typical to have it in the code but be unexercised. Stated differently: If it's in the spec, there will be many implementations. That's expensive. If we have solid evidence that it will be (essentially) unused operationally, we have caused the industry to waste significant software development effort AND deployed software that is not well-tested by the crucible of actual use. > Now, with my hat off, why can't the document simply note that there > are significant issues entailed by local part macros, that they won't > work at all with internationalized addresses, and leave it at that for > now? cost and bugs. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john@jlc.net Fri Jul 13 13:02:41 2012 Return-Path: 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 5D4DC11E80F0 for ; Fri, 13 Jul 2012 13:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.384 X-Spam-Level: X-Spam-Status: No, score=-105.384 tagged_above=-999 required=5 tests=[AWL=1.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Tp3a884pHrvb for ; Fri, 13 Jul 2012 13:02:40 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 904E911E80EA for ; Fri, 13 Jul 2012 13:02:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 85B1533C24; Fri, 13 Jul 2012 16:03:17 -0400 (EDT) Date: Fri, 13 Jul 2012 16:03:17 -0400 From: John Leslie To: dcrocker@bbiw.net Message-ID: <20120713200317.GA55459@verdi> References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50006EB2.7040601@dcrocker.net> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 20:02:41 -0000 Dave Crocker wrote: > > My view is that putting something in the specification essentially > requires implementation in code and that that's expensive. Yes, many > scenarios of non-use operationally can formally justify not implementing > in code, but I believe it is more typical to have it in the code but be > unexercised. May I remind everyone that "coded but not tested" is a sure-fire recipe for disaster? > Stated differently: If it's in the spec, there will be many > implementations. That's expensive. If we have solid evidence that it > will be (essentially) unused operationally, we have caused the industry > to waste significant software development effort AND deployed software > that is not well-tested by the crucible of actual use. I understand that folks who have already implemented SPF look at every "change" as yet another opportunity for disaster; but there _will_ be others implementing from scratch... > Andrew Sullivan wrote: > >> Now, with my hat off, why can't the document simply note that there >> are significant issues entailed by local part macros, that they won't >> work at all with internationalized addresses, and leave it at that for >> now? > > cost and bugs. I don't think "simply note" will cover it. We have to deal with changes in the environment since RFC4408: specifically - IPv6, and - internationalized email addresses. It is not instantly obvious how to deal with these in SPF macro expansion. We _could_ work it out -- or we could deprecate them. "Deprecate" feels right to me. Please understand, "deprecate" means " " senders SHOULD NOT publish SPF records that make use of the feature " in question. Its use is NOT RECOMMENDED and it might be removed entirely " in future updates to the protocol. Such features do, however, remain " part of the SPF protocol and receiving systems MUST support them unless " this specification says otherwise. So, anything we mark "deprecated" we don't have to handle well: we can say essentially "Use at your own risk." I think I agree with Dave here. (But no doubt Dave will find a way to prove me wrong. ;^) -- John Leslie From superuser@gmail.com Fri Jul 13 13:35:44 2012 Return-Path: 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 893EA11E80E4 for ; Fri, 13 Jul 2012 13:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 4gsaGNqrHsEA for ; Fri, 13 Jul 2012 13:35:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80C2111E80C7 for ; Fri, 13 Jul 2012 13:35:43 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5586991lbb.31 for ; Fri, 13 Jul 2012 13:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fE4fWdtGLUKQ1XlTXvO/nwOZD0vtmWUj6jay4KDVhLk=; b=N/JM6kN5oj+IdxGE59comtbMTsev0OqfLYDrpShPUir6UZbDlaroQ19vHZMNxu6hxH I2D6bVQppENYojzcdMfkWexTKU2JXavEoRYSZNklHtvVzgTJvxv34tVQlJ/vjLALjQ47 ++M96iZFCfz/BPPl7T0TdU8pfR/4SP5i7Y5hNW+lunHYz9LIq1YagavLd3u++onLQ1eL 7GpLLOkAA47mpuM3sM25kaYOEDTzun3S+/kPV1jqxIdYamoHe4bOfoJinv1plf4UKydJ lmwN4PZ7k8z7o4Oe/wqn9ewrQ+6Rjcz3/kas3Bo3j/Erxtai6FZgUHPkvrcS3JXjLCHA Uj0A== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr2717549lab.40.1342211779721; Fri, 13 Jul 2012 13:36:19 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Fri, 13 Jul 2012 13:36:19 -0700 (PDT) In-Reply-To: <500044D1.8090501@tana.it> References: <500044D1.8090501@tana.it> Date: Fri, 13 Jul 2012 13:36:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d040838d357f8a804c4bc089d Cc: spfbis@ietf.org Subject: Re: [spfbis] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 20:35:44 -0000 --f46d040838d357f8a804c4bc089d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 13, 2012 at 8:54 AM, Alessandro Vesely wrote: > @ 761 > > Loosely, the record partitions all hosts > > into permitted and not-permitted sets (though some hosts might fall > > into neither category). > > > > [MSK: That sounds confusing. How is that possible?] > > I attempted a better wording, but my English doesn't support me. > Actually, I withdraw the comment. It was late and I read "either" rather than "neither", i.e., a client could somehow be both permitted and not-permitted simultaneously, which is of course absurd. It's fine as "neither". -MSK --f46d040838d357f8a804c4bc089d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jul 13, 2012 at 8:54 AM, Alessandro Vesely <vesely@tana.it> wrote:
@ 761
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Loosely, the r= ecord partitions all hosts
> =A0 =A0into permitted and not-permitted sets (though some hosts might = fall
> =A0 =A0into neither category).
>
> [MSK: That sounds confusing. =A0How is that possible?]

I attempted a better wording, but my English doesn't support me.

Actually, I withdraw the comment.=A0 It was late and I r= ead "either" rather than "neither", i.e., a client coul= d somehow be both permitted and not-permitted simultaneously, which is of c= ourse absurd.=A0 It's fine as "neither".

-MSK
--f46d040838d357f8a804c4bc089d-- From hsantos@isdg.net Fri Jul 13 13:44:59 2012 Return-Path: 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 A67BE21F85C2 for ; Fri, 13 Jul 2012 13:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 1nql-yF4TORo for ; Fri, 13 Jul 2012 13:44:58 -0700 (PDT) Received: from listserv.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0D60B21F85A7 for ; Fri, 13 Jul 2012 13:44:57 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2881; t=1342212327; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=VIY5LtEG/yiGqu3lbbFT4VzmryA=; b=Dq5ODpNs35lzOoaoEIiG bcYQFowjL59Kke4Zp5tMIPbMGz2+G2dz/UMHny03dEheE74kj3DOqRTvaDcZnNS+ VFi5DEVFXv3NfE4xtJCgZaDlJLFhoD5v1UA0zcZ0Oszw4jnOQxE1YddC4MJZOgGK rQ6ykXgS7ULUX7yCyeRu07g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 13 Jul 2012 16:45:27 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2529131507.12589.2440; Fri, 13 Jul 2012 16:45:26 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2881; t=1342212205; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=62H43/m H7t2CVXCfT44ijORjPbUeNxz7TpoHJFhEOso=; b=XrYFe/jUAbp5WTgZFhlYMT3 moqLS8wX8sorfXjRwFG2wf98XRb0jCpQgUY61wPZC+v+1Q+2NvBmBKCHhCpkc7UK ZyYt9cM2znHW6r+A3hNY1bisF4liF9pr3k9pDbAExz4XcblZcZjSDeBQVgPtuIzk 9yg5dpRg9B1ljitB5ns0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 13 Jul 2012 16:43:25 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3127970566.9.2892; Fri, 13 Jul 2012 16:43:24 -0400 Message-ID: <500088FE.60807@isdg.net> Date: Fri, 13 Jul 2012 16:45:50 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: SPFBIS WG References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> In-Reply-To: <50006EB2.7040601@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 20:44:59 -0000 The difference is that original functional macro support was already part of the development expense long ago and it is also a requirement on the receiver side. So with a proposed removal, we are now talking of additional expenses: - Programmers to remove it, - Testers to continue to see if it (removal) didn't break anything else, - Documentators to explain or add/change the operators and references guides, - Teaching support people that new complaints may be reported when the removal fails to support any published advanced SPF records. That all new expenses "serious" implementators need to consider when "change (removal)" is proposed for an original protocol feature. -- HLS Dave Crocker wrote: > > On 7/13/2012 7:17 AM, Andrew Sullivan wrote: >> Dave, at the time >> you argued for an interpretation of "unused" that was really "not used >> very much", where the value of "very much" had to be evaluated by the > > Good to know that I am sometimes consistent, since I am still putting > forward that view... > > >> This case is not like that: there's no requirement to use these macros >> at all in order to get the protocol working, and even though the >> protocol is complicated by them we have positive evidence that some >> people are using them, which presumably means that they can't achieve >> their desired goal through some other (equivalent) functionality >> already available in RFC 4408. Therefore, I cannot see how we are in >> any way chartered to ditch this feature, unless we opt for Dave's >> somewhat strained interpretation of "unused". > > Besides re-raising the question of whether 'unused' requires the > mathematical perfection on 'none' versus 'extremely few', you have > introduced another aspect of 'used' that is often debated. > > That is, the distinction between "in the code" vs. "over the wire". They > are very different kinds of usage, of course. > > My view is that putting something in the specification essentially > requires implementation in code and that that's expensive. Yes, many > scenarios of non-use operationally can formally justify not implementing > in code, but I believe it is more typical to have it in the code but be > unexercised. > > Stated differently: If it's in the spec, there will be many > implementations. That's expensive. If we have solid evidence that it > will be (essentially) unused operationally, we have caused the industry > to waste significant software development effort AND deployed software > that is not well-tested by the crucible of actual use. > > >> Now, with my hat off, why can't the document simply note that there >> are significant issues entailed by local part macros, that they won't >> work at all with internationalized addresses, and leave it at that for >> now? > > cost and bugs. > > d/ > -- HLS From spf2@kitterman.com Fri Jul 13 14:10:03 2012 Return-Path: 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 D667111E8097 for ; Fri, 13 Jul 2012 14:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] 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 r20AtREfHDyw for ; Fri, 13 Jul 2012 14:09:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E4F2511E80C0 for ; Fri, 13 Jul 2012 14:09:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1A3DE20E40A6; Fri, 13 Jul 2012 17:10:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342213833; bh=v6C6Tzoheqlvwt+KL4LeAoJ7Pr43Z8De6R9zMttmvNM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HAm4IccksnEFwFoAPTQ4PVhAbNYXu4UGmyN/I8JPx+B6netm/AFQQPD3azc34GxE/ GDSMdxk+lMO25XwaJUa3u0TCVvR1oHGr4VagVOmU9bN+YX8Qr0Ikc13U1cufueI2cM FUy6fnJVzkt4U7IZkTO+vM8dERy/jWhR+xVHfuiQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id F166F20E4064; Fri, 13 Jul 2012 17:10:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Jul 2012 17:10:31 -0400 Message-ID: <4641363.qHPnb1KDz0@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120713200317.GA55459@verdi> References: <20120712022051.60587.qmail@joyce.lan> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:10:04 -0000 On Friday, July 13, 2012 04:03:17 PM John Leslie wrote: > Dave Crocker wrote: > > My view is that putting something in the specification essentially > > requires implementation in code and that that's expensive. Yes, many > > scenarios of non-use operationally can formally justify not implementing > > in code, but I believe it is more typical to have it in the code but be > > unexercised. > > May I remind everyone that "coded but not tested" is a sure-fire > recipe for disaster? In 2005, before there was an SPF test suite, I was grateful that Philip Gladstone had published SPF records with macros. It was an invaluable source of test cases that helped me fix a bunch of bugs in the pyspf macro processing code, so I know exactly what you mean. Fortunately, the situation is different now. You can go to http://www.openspf.org/Test_Suite and get a copy of a comprehensive test suite that is believed to cover all the RFC 4408 requirements. It includes section number citations of what requirements are being tested and where the SPF community (after a lot of discussion) felt RFC 4408 had some ambiguity about what the correct result was. It's been stable for almost three years. It has been used both to validate correctness in existing implementations and by developers working from scratch to assist them through the process of development. I don't anticipate significant changes based on what's been done so far. The only things that need to be done is to set the ambiguous desired results to the 4408bis correct result (I believe that the current draft resolves all of them). So yes, untested code is bad, but if you aren't doing comprehensive testing, you've got no one to blame but yourself. The community has already done the hard part of figuring out the exact test cases you need to run. > > Stated differently: If it's in the spec, there will be many > > implementations. That's expensive. If we have solid evidence that it > > will be (essentially) unused operationally, we have caused the industry > > to waste significant software development effort AND deployed software > > that is not well-tested by the crucible of actual use. > > I understand that folks who have already implemented SPF look at > every "change" as yet another opportunity for disaster; but there _will_ > be others implementing from scratch... All of the "new" implementations I'm aware of have been done via integration of existing open source libraries that provide the core functionality of the protocol. There are C, Java, Python, Perl, and .Net libraries available that I know of. See http://www.openspf.org/Implementations . Once again, anyone who ignores the existing wealth of code out there to reuse has already taken a gun and aimed it squarely at their feet. People who want to do it the hard way are going to get about the result you would expect no matter what we put in 4408bis. > > Andrew Sullivan wrote: > >> Now, with my hat off, why can't the document simply note that there > >> are significant issues entailed by local part macros, that they won't > >> work at all with internationalized addresses, and leave it at that for > >> now? > > > > cost and bugs. > > I don't think "simply note" will cover it. > > We have to deal with changes in the environment since RFC4408: > specifically > - IPv6, and > - internationalized email addresses. Other than a few places in the spec where we say A instead of A and AAAA, IPv6 is already fully addressed (and I'm unaware of any implementations that didn't assume that anyway). I don't think the coming of IPv6 presents any new issues. As we've discussed, I think the internationalized email addresses are almost as easy. You can only use things in SPF records (including those with macro parts) that can be represented as an A label. Once again, no impact to the protocol. The only effect is a limitation on what internationalized localparts can be represented by the "l" macro. So something you couldn't do before, you still can't do. > It is not instantly obvious how to deal with these in SPF macro > expansion. We _could_ work it out -- or we could deprecate them. > > "Deprecate" feels right to me. Please understand, "deprecate" means > " > " senders SHOULD NOT publish SPF records that make use of the feature > " in question. Its use is NOT RECOMMENDED and it might be removed entirely > " in future updates to the protocol. Such features do, however, remain > " part of the SPF protocol and receiving systems MUST support them unless > " this specification says otherwise. > > So, anything we mark "deprecated" we don't have to handle well: we > can say essentially "Use at your own risk." I think it's perfectly obvious how to deal with this issues and other than a few cases of "you can't do that" I don't think there's any problem at all. The potentially significant operational issue is that some records which use macros can't be cached. RFC 4408 (and our draft) already address this: Note: Domains should avoid using the "s", "l", "o", or "h" macros in conjunction with any mechanism directive. Although these macros are powerful and allow per-user records to be published, they severely limit the ability of implementations to cache results of check_host() and they reduce the effectiveness of DNS caches. I have no objection to beefing that up, but I'm not aware of anyone have actual operational issues as a result of this (unlike PTR, which we've deprecated - I know of cases where those cause real problems). Scott K From superuser@gmail.com Fri Jul 13 14:12:21 2012 Return-Path: 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 E3AB511E80FD for ; Fri, 13 Jul 2012 14:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Zc0JY7r2oF4v for ; Fri, 13 Jul 2012 14:12:21 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E03811E8097 for ; Fri, 13 Jul 2012 14:12:20 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5624977lbb.31 for ; Fri, 13 Jul 2012 14:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H42qjRVc4HBsBWeSHQzmiNRd4LoHfeyB33YgO2LrBj8=; b=seii0QNl1GHxEOq+lgp14Gte8VWlGudeuhgup6/FyZjFiBqXZI0WGS8PDGF3KlVvsK bgjyLKB3Lkaf8N2yIvtjZlP2mdyoVsjsnXeXFq/uwQYup8ru+UDRs2k0HIoFREr1OAhh g7kJZ8MFjt4HoR2KIxcZ4T9u46ElXr0DVAsCb3b6LES1QoS122VMbs9qMVr5K6D0621Y NhMfCqB0Za6X/zOvjVdw1FaMKE+EyEdcJ6LNi/mqR6O7ClOPKtBtwrst0nFR0MLp2/fd /h2o23aA/kfl2LeNafplDTDhMQxbKxhpQCmnwdr7JiUaa5XrFTnjkRkzT0FmxeeT1jZm A03A== MIME-Version: 1.0 Received: by 10.112.83.198 with SMTP id s6mr1512508lby.76.1342213977204; Fri, 13 Jul 2012 14:12:57 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Fri, 13 Jul 2012 14:12:57 -0700 (PDT) In-Reply-To: <20120713200317.GA55459@verdi> References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> Date: Fri, 13 Jul 2012 14:12:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Leslie Content-Type: multipart/alternative; boundary=f46d04016b2352e89104c4bc8b00 Cc: spfbis@ietf.org, dcrocker@bbiw.net, Andrew Sullivan Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:12:22 -0000 --f46d04016b2352e89104c4bc8b00 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 13, 2012 at 1:03 PM, John Leslie wrote: > I understand that folks who have already implemented SPF look at > every "change" as yet another opportunity for disaster; but there _will_ > be others implementing from scratch... > > > This is largely my concern. It's virtually guaranteed* that there will be some industry participant that can't use any of the existing open source or even commercial implementations for whatever local infrastructure reason and has to implement from scratch. We should make their jobs as easy as possible, lest interoperability or even security issues be introduced. -MSK * Please don't ask me to give a precise quantitative definition for this. --f46d04016b2352e89104c4bc8b00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jul 13, 2012 at 1:03 PM, John Leslie <john@jlc.net> wrot= e:
=A0=A0 I understand that folks who have already implemented SPF look at
every "change" as yet another opportunity for disaster; but there= _will_
be others implementing from scratch...



This is largely my co= ncern.=A0 It's virtually guaranteed* that there will be some industry p= articipant that can't use any of the existing open source or even comme= rcial implementations for whatever local infrastructure reason and has to i= mplement from scratch.=A0 We should make their jobs as easy as possible, le= st interoperability or even security issues be introduced.

-MSK

* Please don't ask me to give a precise quantitative de= finition for this.

=A0

--f46d04016b2352e89104c4bc8b00-- From spf2@kitterman.com Fri Jul 13 14:19:57 2012 Return-Path: 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 4E5EB11E80FF for ; Fri, 13 Jul 2012 14:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] 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 zZM7RBcGTvCo for ; Fri, 13 Jul 2012 14:19:56 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1AA11E8097 for ; Fri, 13 Jul 2012 14:19:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 77FBB20E40A6; Fri, 13 Jul 2012 17:20:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342214433; bh=taRpbEAUg2KVMm5hmi9pUgfNo2hhZEh1rqiPTeQGfns=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MULdQq/H12rt69LWcwqSjKQjFLKmmK1msnozy7HGHsw7k+lPeW3zNxLP6PhAQnBhX 6PlNuhFDSM+qSGt2/iArSKjTZwZhg8ipl8KnOGSPZQVJDwiKx6IdrGfRWsm/C2ZglD kN51HYu/eT//5T9BlW+1UJCmYBWK3pZzjm2YTGdk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5E91420E4064; Fri, 13 Jul 2012 17:20:33 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Jul 2012 17:20:32 -0400 Message-ID: <4055854.X8Jd2YyCrS@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <20120712022051.60587.qmail@joyce.lan> <20120713200317.GA55459@verdi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:19:57 -0000 On Friday, July 13, 2012 02:12:57 PM Murray S. Kucherawy wrote: > On Fri, Jul 13, 2012 at 1:03 PM, John Leslie wrote: > > I understand that folks who have already implemented SPF look at > > > > every "change" as yet another opportunity for disaster; but there _will_ > > be others implementing from scratch... > > This is largely my concern. It's virtually guaranteed* that there will be > some industry participant that can't use any of the existing open source or > even commercial implementations for whatever local infrastructure reason > and has to implement from scratch. We should make their jobs as easy as > possible, lest interoperability or even security issues be introduced. > > -MSK > > * Please don't ask me to give a precise quantitative definition for this. For this corner case, I think the detailed test suite we have already proven out mitigates the risk significantly. If there are test cases that are missing, I'll be glad to make sure they are documented and added (spf-discuss is the best place for that discussion I think). We've been through an entire from scratch development cycle with http://james.apache.org/jspf/ - you'll see they even reference the test suite in their release announcements. Unless their local reasons include idiocies like not using tests in development, I don't think there is much risk here nor does removing macros significantly simplify the work of implementing SPF from scratch. Scott K From johnl@iecc.com Fri Jul 13 14:27:05 2012 Return-Path: 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 562B211E8117 for ; Fri, 13 Jul 2012 14:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.127 X-Spam-Level: X-Spam-Status: No, score=-111.127 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 bAJl9E3o8Ehp for ; Fri, 13 Jul 2012 14:27:04 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2256711E8097 for ; Fri, 13 Jul 2012 14:27:04 -0700 (PDT) Received: (qmail 27012 invoked from network); 13 Jul 2012 21:27:40 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Jul 2012 21:27:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=500092cc.xn--hew.k1207; i=johnl@user.iecc.com; bh=ZOPtDaB5H84JcO0Skyh3ivj0jxds2He70O2TXJqlJPQ=; b=vEqsXXIfQS0dN9hy3cEvErE0PFQkT59HA7u1qGC1pKNnV1OwA7wFEEabS09Dz5Lb8dcZ0+YZvKlgY2YbKZlYsR2HsS1ZMhfn9D02i+Grhj/RpGbgNxSxDopauQ8dXvfN+YeofYnYEeKrdH30c9B4mRvNsATqrc2c5mmGY25jYRA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=500092cc.xn--hew.k1207; olt=johnl@user.iecc.com; bh=ZOPtDaB5H84JcO0Skyh3ivj0jxds2He70O2TXJqlJPQ=; b=XHPuV8e0c+v+LUa0dr3wVUIXwMbOiWhW1EASLmX/AlS/CKXA15+76jlwAacUq3ptnV792SCmNxMbZfdlnXQs00jImQL0e9bVynHwofpYxpr5EMiMyb1CI18lglAxarUJk5c8NZ2MAQwj4ZyLDR587wqkdFWewD4GO+7UjqRGTMg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Jul 2012 21:27:18 -0000 Message-ID: <20120713212718.35051.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4641363.qHPnb1KDz0@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:27:05 -0000 >Fortunately, the situation is different now. You can go to >http://www.openspf.org/Test_Suite and get a copy of a comprehensive test suite >that is believed to cover all the RFC 4408 requirements. I took a look. With respect to macros, it has one test called dorky-sentinel with a space in a local part, although it's not obvious to me what the correct answer is supposed to be, one called upper-macro that tests that upper cased macros do percent encoding, and invalid-domain-long-via-macro which checks for a macro expansion that creates an excessively long domain name. There's also a bunch of other tests that check that macros do what they're supposed to with normal input. Other than the one about the space, I don't see any tests for what happens if the text being expanded contains unexpected hostile characters. R's, John From spf2@kitterman.com Fri Jul 13 14:35:53 2012 Return-Path: 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 5984011E8112 for ; Fri, 13 Jul 2012 14:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] 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 N3w7lwjPpz3u for ; Fri, 13 Jul 2012 14:35:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8B011E80AD for ; Fri, 13 Jul 2012 14:35:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5DA2B20E40A6; Fri, 13 Jul 2012 17:36:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342215389; bh=C8m9YgNLKtBVMHClYRLDOPb3sz+D6OZlki/NBJMLMO8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=auZHOTNhn87ohT3L656p9rGcUvEbn9azqNSTfHGNRXrpLccsls3mr4w5oAs1w7r5w ZX7BWi38M7ev8ywZOWCn3yTvBUQueAh3H1tFaWHlAAQeuHQQJJc0RkNW3+fAQjjMnQ FxzUpOYcp4//7qqHZMK6AvTzaHyxDlYD95UCqM9Q= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4456020E4064; Fri, 13 Jul 2012 17:36:29 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Jul 2012 17:36:28 -0400 Message-ID: <3042871.nWlL1OK6Yn@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120713212718.35051.qmail@joyce.lan> References: <20120713212718.35051.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:35:53 -0000 On Friday, July 13, 2012 09:27:18 PM John Levine wrote: > >Fortunately, the situation is different now. You can go to > >http://www.openspf.org/Test_Suite and get a copy of a comprehensive test > >suite that is believed to cover all the RFC 4408 requirements. > > I took a look. With respect to macros, it has one test called > dorky-sentinel with a space in a local part, although it's not obvious > to me what the correct answer is supposed to be, one called > upper-macro that tests that upper cased macros do percent encoding, > and invalid-domain-long-via-macro which checks for a macro expansion > that creates an excessively long domain name. There's also a bunch of > other tests that check that macros do what they're supposed to with > normal input. > > Other than the one about the space, I don't see any tests for what > happens if the text being expanded contains unexpected hostile > characters. Should be easy enough to add. What would you consider hostile? Scott K From spf2@kitterman.com Fri Jul 13 14:43:23 2012 Return-Path: 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 7884721F86A6 for ; Fri, 13 Jul 2012 14:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] 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 Hww82LBvACrT for ; Fri, 13 Jul 2012 14:43:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8573021F8698 for ; Fri, 13 Jul 2012 14:43:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6D50820E40A6; Fri, 13 Jul 2012 17:43:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342215839; bh=u1kCupYmBRHcYGcdKAqt98WLAPn5CJm2sDmjzictl0I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=G1sorjYyqz81EI69QAgpMsAiIl9G2RPdKQheTW7zIRTRBIn4yy5IMWNJa7bpSOKcz T9yZ22wdprC061HR+a+xsmTrwbtVnMXi7q/eCBLnyxNy1T1V3gSGVR+vgjIn1jC80G sF+w5M6GLkm8obFY+X8EBv8lyrGUZTLNxiU9Z23A= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4FCED20E4064; Fri, 13 Jul 2012 17:43:59 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Jul 2012 17:43:58 -0400 Message-ID: <4517119.2HVXk1EHT0@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <3042871.nWlL1OK6Yn@scott-latitude-e6320> References: <20120713212718.35051.qmail@joyce.lan> <3042871.nWlL1OK6Yn@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:43:23 -0000 On Friday, July 13, 2012 05:36:28 PM Scott Kitterman wrote: > On Friday, July 13, 2012 09:27:18 PM John Levine wrote: > > >Fortunately, the situation is different now. You can go to > > >http://www.openspf.org/Test_Suite and get a copy of a comprehensive test > > >suite that is believed to cover all the RFC 4408 requirements. > > > > I took a look. With respect to macros, it has one test called > > dorky-sentinel with a space in a local part, although it's not obvious > > to me what the correct answer is supposed to be, one called > > upper-macro that tests that upper cased macros do percent encoding, > > and invalid-domain-long-via-macro which checks for a macro expansion > > that creates an excessively long domain name. There's also a bunch of > > other tests that check that macros do what they're supposed to with > > normal input. > > > > Other than the one about the space, I don't see any tests for what > > happens if the text being expanded contains unexpected hostile > > characters. > > Should be easy enough to add. What would you consider hostile? I ask, not just because of the test suite, macro question, but if there are potential characters that should be prohibited from SPF records generally due to security considerations, I think we should address it in the draft. Scott K From johnl@iecc.com Fri Jul 13 18:02:45 2012 Return-Path: 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 0DA8C21F8777 for ; Fri, 13 Jul 2012 18:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.132 X-Spam-Level: X-Spam-Status: No, score=-111.132 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 Q0-JMkRYSPUF for ; Fri, 13 Jul 2012 18:02:44 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB6721F8773 for ; Fri, 13 Jul 2012 18:02:43 -0700 (PDT) Received: (qmail 53542 invoked from network); 14 Jul 2012 01:03:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Jul 2012 01:03:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5000c559.xn--btvx9d.k1207; i=johnl@user.iecc.com; bh=pqSVpTlk9Hoq+H/wU4yxgDDPDX7RhtjEqGBqZ7Tysnc=; b=EcVTHwBPX48jZ8xg1j44maVpb1tJsKpnafD2cCvg+YTghC/aC+BbPA5u0G2vWA72Cjoz46kgScobnnfU0MmKHMFSSJOFFHDLJrRa/PrYRq4zHwFXBBiqAdEw5llJOaON0/5+y12UZFtJ5kr10BaVwoTpKsEGj6PT0sIPlJTYrlg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5000c559.xn--btvx9d.k1207; olt=johnl@user.iecc.com; bh=pqSVpTlk9Hoq+H/wU4yxgDDPDX7RhtjEqGBqZ7Tysnc=; b=sflTqdpKYiZ9LNPT3nnDx3uT3bDGToJKiXkD/TXeNYkyWt17RqjS6apA3lLnxiHIYgZCWAKoic1KiWd4woDnnRrV5y68YTHle/NzqNKu9k7sEOjYNdE9MyS7zKZXhcV0D2NFP/CXdjWHk7MxqxlvkQ6zLWV1lJEoz8BEu9rpyG8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Jul 2012 01:02:59 -0000 Message-ID: <20120714010259.94149.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4517119.2HVXk1EHT0@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 01:02:45 -0000 >> Should be easy enough to add. What would you consider hostile? > >I ask, not just because of the test suite, macro question, but if there are >potential characters that should be prohibited from SPF records generally due >to security considerations, I think we should address it in the draft. It's not characters in SPF records, it's characters in SMTP bounce addresses. Try some records with %s and %l, and bounce addresses that contain 0x04, 0x1a, 0xa0 and other characters most DNS software doesn't expect. R's, John From vesely@tana.it Sat Jul 14 05:59:05 2012 Return-Path: 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 7284621F86AF for ; Sat, 14 Jul 2012 05:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.619 X-Spam-Level: X-Spam-Status: No, score=-4.619 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 oePd-jmwq947 for ; Sat, 14 Jul 2012 05:59:04 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD0B21F86A3 for ; Sat, 14 Jul 2012 05:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342270781; bh=6zoBJtsWxgifcSMaXL4iThFSl92+lQOABcXjV7OWw/0=; l=1416; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=fV5BYRCXDwftB996ffQPSOGsOvPWQIuGlw1r0JjmCfD8g4cvWwxJwsdsPqa05y/v3 CplbH7bG7AGMV7XSa+dUCF8yqK8J6s6f6t/SzK0QpZtOKdJQ6gl9gxDJcFcdCOw8I3 j1eEHr8pHmBtvTJL0F6KuwMX+A8e6rbcfYVk4m+0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 14 Jul 2012 14:59:41 +0200 id 00000000005DC039.0000000050016D3D.00000EB9 Message-ID: <50016D3D.5090106@tana.it> Date: Sat, 14 Jul 2012 14:59:41 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120714010259.94149.qmail@joyce.lan> In-Reply-To: <20120714010259.94149.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 12:59:05 -0000 On Sat 14/Jul/2012 03:02:59 +0200 John Levine wrote: >> >> I ask, not just because of the test suite, macro question, but if there are >> potential characters that should be prohibited from SPF records generally due >> to security considerations, I think we should address it in the draft. > > It's not characters in SPF records, it's characters in SMTP bounce addresses. > Try some records with %s and %l, and bounce addresses that contain 0x04, 0x1a, > 0xa0 and other characters most DNS software doesn't expect. Many multibyte characters vulnerabilities were found and fixed during the last decade, so I believe IDN software is robust and reliable enough nowadays. AFAICS, the one thing we have to take care for is servers/implementations that cannot avail themselves of up-to-date libraries. Possibly, they should raise permerror as soon as they see a signed byte, and mention they're not SMTPUTF8 in any reply or mark. IMHO, using UTF-8 for both records and parameters makes for smoother specs, implementations, and deployment. That does not mean U-labels are mandatory. Until the number of non EAI-compliant servers becomes irrelevant, publishers will find it convenient to convert domain names to A-labels. An annoyance that will be forgotten afterwards. PS: Sorry for having overlooked uppercase macros in a previous message of mines. Anyway, malicious exp's are a known issue. From dhc@dcrocker.net Sat Jul 14 08:32:40 2012 Return-Path: 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 B89FB21F8623 for ; Sat, 14 Jul 2012 08:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ettdswdGWy91 for ; Sat, 14 Jul 2012 08:32:40 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 31B9021F8598 for ; Sat, 14 Jul 2012 08:32:40 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6EFXIT0031353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Jul 2012 08:33:18 -0700 Message-ID: <50019135.6070103@dcrocker.net> Date: Sat, 14 Jul 2012 08:33:09 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Levine References: <20120713212718.35051.qmail@joyce.lan> In-Reply-To: <20120713212718.35051.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 14 Jul 2012 08:33:19 -0700 (PDT) Cc: spfbis@ietf.org, spf2@kitterman.com Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 15:32:40 -0000 On 7/13/2012 2:27 PM, John Levine wrote: >> Fortunately, the situation is different now. You can go to >> >http://www.openspf.org/Test_Suite and get a copy of a comprehensive test suite >> >that is believed to cover all the RFC 4408 requirements. > I took a look. With respect to macros, it has one test called > dorky-sentinel with a space in a local part, Bringing this around to the other active thread... Along with various contributions that innovated core technology -- eg, ip and tcp -- and styles of collaboration -- open collaboration -- the Internet's history demonstrated the essential benefit of interoperability testings, specifically in contrast with bench testing against suites. It's not that test suites are useless -- they can be extremely efficient at finding common problems. However, they are insufficient for producing working product. What produces working products is direct interaction with other implementations. When code is deployed that is not used, it does not receive this kind of testing. Ever. The extremely low level of deployment macros have received after this long make clear that such code is unlikely to get that testing. This makes the code a kind of time-bomb, waiting possibly for years, for some unusual situation which /does/ invoke it and demonstrate that it does not work properly. and returning to the Subject thread: this is also why it is advisable to delay adopting brand new component standards into other standards, until there is more field experience. That field experience provides the interoperability testing and development of operational knowledge about the new component. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Sat Jul 14 08:34:13 2012 Return-Path: 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 B8A2821F8687 for ; Sat, 14 Jul 2012 08:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PpstMv5m1Eq7 for ; Sat, 14 Jul 2012 08:34:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB9621F8686 for ; Sat, 14 Jul 2012 08:34:13 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6EFYohL031377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Jul 2012 08:34:50 -0700 Message-ID: <50019191.7080700@dcrocker.net> Date: Sat, 14 Jul 2012 08:34:41 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <20120712022051.60587.qmail@joyce.lan> <7553255.LjjZa8jCz8@scott-latitude-e6320> <25336858.gnRrL7ieMU@scott-latitude-e6320> <50003C42.7020208@dcrocker.net> <20120713155316.GN93613@mail.yitter.info> In-Reply-To: <20120713155316.GN93613@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 14 Jul 2012 08:34:51 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 15:34:13 -0000 On 7/13/2012 8:53 AM, Andrew Sullivan wrote: > On Fri, Jul 13, 2012 at 08:18:26AM -0700, Dave Crocker wrote: >> >> 1. "Unused" is a statistical label. It does not mean that >> there are literally no implementations or deployments. It means >> that it has not gained serious use. Anything that's been available >> this long and has reached such a tiny percentage of deployment is >> unused. > > Just to be clear: you mean that as a proposed interpretation, not a > statement of fact, right? It's the perspective/definition I've been operating with for a couple of decades, at least. Possible 3 or 4. And I didn't create it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Sat Jul 14 10:51:40 2012 Return-Path: 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 923F321F85C4 for ; Sat, 14 Jul 2012 10:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.134 X-Spam-Level: X-Spam-Status: No, score=-111.134 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 nwLJvTCnWA7l for ; Sat, 14 Jul 2012 10:51:40 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9144121F8564 for ; Sat, 14 Jul 2012 10:51:39 -0700 (PDT) Received: (qmail 7503 invoked from network); 14 Jul 2012 17:52:17 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Jul 2012 17:52:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5001b1d1.xn--30v786c.k1207; i=johnl@user.iecc.com; bh=OWjIt/l3g+uekRPaBl00bB9eO6buHcWSIQupzOm71Tg=; b=ESU/r7FgEPa2/mKnO19bMqnu8tx2MxrHLNfHsLwf4I2IDfFcp39d6QkPJII8NWfn/6AgzQpJ397senF4IhhxCSBTxjxR9APqtCbKpinHnWTrRlzOAEtwixrO+MGSTUlacLJDuGq07xYZ8NGhscg39kdShqFOMFIY8WdY44tiVRE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5001b1d1.xn--30v786c.k1207; olt=johnl@user.iecc.com; bh=OWjIt/l3g+uekRPaBl00bB9eO6buHcWSIQupzOm71Tg=; b=g53bCTmXJCx6cwrdwv4Jwwg/ZqdNUMIRCxe5JBqNNToA/S2XipsVfWdv7mKT6fOVL3tUwbk5VVxmss0qDlpbzTMZoCMNtF2F0za4gwLm/vH9B869kDT5ZjdA4MRuM+vOwvXk104UPe81iz8Rcos+CMYnjfOzW7Y5SEZp1Jz7rJo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Jul 2012 17:51:55 -0000 Message-ID: <20120714175155.73102.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <50016D3D.5090106@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 17:51:40 -0000 >Many multibyte characters vulnerabilities ... This issue has nothing whatsoever to do with multibyte characters. R's, John From vesely@tana.it Sat Jul 14 11:27:39 2012 Return-Path: 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 495B821F8629 for ; Sat, 14 Jul 2012 11:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.622 X-Spam-Level: X-Spam-Status: No, score=-4.622 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 T1XrC-Tdr+Dq for ; Sat, 14 Jul 2012 11:27:38 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3C221F861E for ; Sat, 14 Jul 2012 11:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342290496; bh=le6vntrcUknEtjHV6k2XvmxNlOt1GkNtnDC3wTFm+W0=; l=2622; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=eibzzAc3UGFUw0XCEPdxgrF4RxRT2lDFZgm9FHPcdJNL4YZmj+MIc+0EKFc3QCwfo lHryPjmO3b3NGYkLjXNwfIX8O2zl40XoNT9PoytUe+RoDlams2YIkPANBqVoKu3fYS Bpogn+5xlOEL4W2bLWxbVHLX+QJh5TTFnwsIlmho= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 14 Jul 2012 20:28:16 +0200 id 00000000005DC042.000000005001BA40.000054D9 Message-ID: <5001BA40.4080409@tana.it> Date: Sat, 14 Jul 2012 20:28:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] #11: RFC 4408 Section 4 check_host() function, was Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 18:27:39 -0000 On Fri 13/Jul/2012 10:20:28 +0200 Murray S. Kucherawy wrote: @ 589 > [MSK: I have an open ticket in the tracker about check_host(), so > I'll make my first comment about it here though there will be many > more later. The very string "check_host()" looks like a function > definition, and as I said in the tracker item, the IETF prefers to > avoid the business of API definitions. It's possible that I might > be able to search-and-replace it into something more palatable. The term "function" as well as the use of parentheses was borrowed from mathematics and logic. It does not, by itself, imply any API definition. However, the use of parentheses to indicate that it is a function is typical of programming. It can be safely removed, IMHO. @ 972 > [MSK: I'm reading this on the assumption that "check_host()" is > replaced by "CheckHost". Let's see if that works.] Switching to camel-case is not particularly meaningful, as far as telling logical functions from API is concerned. The downside of a name change is that it will never propagate to all SPF-related documents. That way we'll end up with two lexically different terms to indicate exactly the same thing. @ 984 > 4.1. Arguments > > The check_host() function takes these arguments: > > [MSK: "This section describes the procedure for evaluating an SMTP > client's authorization to use a domain name as an identity in the > SMTP session based on SPF policy retrieved from the DNS. The > procedure is referred to as the "CheckHost function". It uses > these inputs:"] If the I-D specifies each and every step, I'd call it the "check_host algorithm". Using the term function seems to stress that some details are left to the implementation, while the logical relationship between input and output is essential. s/4.1. Arguments/4.1. Input/? @ 999 > [MSK: "(The names in angle brackets are symbolic names for these > inputs, and are discussed using these symbols elsewhere in this > document.)"] @ 1006 > Actual implementations of the check_host() function might need > additional arguments. > > [MSK: "Specific implementations of CheckHost may, of course, > consider other parameters as inputs in addition to these."] I'm quite unhappy with either wording. The I-D specifies what input results in what output. I propose: The names in angle brackets are symbolic names for the inputs, and correspond to values discussed using these symbols elsewhere in this document. No resemblance is implied with the names, order, and number of parameters of actual implementations of this function. From sm@elandsys.com Sat Jul 14 11:32:30 2012 Return-Path: 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 7A02D21F863C for ; Sat, 14 Jul 2012 11:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 Kys5tVQ5xe6b for ; Sat, 14 Jul 2012 11:32:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E2C21F861E for ; Sat, 14 Jul 2012 11:32:29 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.134]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6EIWqnJ018501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2012 11:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342290784; bh=cZNIt/LZpfC9cs2ztqIN89UYfXSamkXqZT4FEn6vbv4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JHgMwMAXtCrnZOs5e/eqMciIAMmxym6G/as/Phyee0ve97AOv2MbJm0nV2MGMJJht f3BYEH4nNShQMdJhwXVC0F9LJmVgcB2jnGcqjdlgVP0h3E5pek1SRqu9yMZW41k5bG yAgX/2AkG6jN1rN1YFng9q//RV/MzXLsD/s3IgH8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342290784; i=@elandsys.com; bh=cZNIt/LZpfC9cs2ztqIN89UYfXSamkXqZT4FEn6vbv4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ksi2vZAyMPhxVggzdYqkWCSAHYRWNVblT6+zL8qEPjqI3XAjM6EaaN0kS/9L20cED H23SHwePGBnKvUOOusEQIvkqS6//gAvk837X/FFQhI5WPeGab5aLZbxWh9LOeGiiEg cbK8T/nw/DBJv8TZwE5I7TwSIj6Crh429cDZBP/I= Message-Id: <6.2.5.6.2.20120714104731.09d989c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Jul 2012 11:29:49 -0700 To: dcrocker@bbiw.net From: S Moonesamy In-Reply-To: <50019135.6070103@dcrocker.net> References: <20120713212718.35051.qmail@joyce.lan> <50019135.6070103@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 18:32:30 -0000 Hi Dave, At 08:33 14-07-2012, Dave Crocker wrote: >It's not that test suites are useless -- they can be extremely >efficient at finding common problems. However, they are >insufficient for producing working product. What produces working >products is direct interaction with other implementations. Yes. >This makes the code a kind of time-bomb, waiting possibly for >years, for some unusual situation which /does/ invoke it and >demonstrate that it does not work properly. That was one of the arguments which was taken into consideration to encourage discussion about some of the issues. Even if all the code paths are exercised that unusual situation can still happen. It helps in the decision-making if it can be demonstrated that X does not work properly. Having input from several WG participants is also helpful. That's why WG participants are asked to weigh in on an issue. Regards, S. Moonesamy From dotis@mail-abuse.org Sat Jul 14 21:56:02 2012 Return-Path: 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 CBF2B21F8552 for ; Sat, 14 Jul 2012 21:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 mJ+K7yXyd0O3 for ; Sat, 14 Jul 2012 21:55:58 -0700 (PDT) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2DD21F8554 for ; Sat, 14 Jul 2012 21:55:58 -0700 (PDT) Received: from US-DOUGO-MAC.local (unknown [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 90C81174054B for ; Sun, 15 Jul 2012 04:56:38 +0000 (UTC) Message-ID: <50024D85.5030104@mail-abuse.org> Date: Sat, 14 Jul 2012 21:56:37 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120713212718.35051.qmail@joyce.lan> <3042871.nWlL1OK6Yn@scott-latitude-e6320> In-Reply-To: <3042871.nWlL1OK6Yn@scott-latitude-e6320> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 04:56:03 -0000 On 7/13/12 2:36 PM, Scott Kitterman wrote: > On Friday, July 13, 2012 09:27:18 PM John Levine wrote: >>> Fortunately, the situation is different now. You can go to >>> http://www.openspf.org/Test_Suite and get a copy of a >>> comprehensive test suite that is believed to cover all the RFC >>> 4408 requirements. >> >> I took a look. With respect to macros, it has one test called >> dorky-sentinel with a space in a local part, although it's not >> obvious to me what the correct answer is supposed to be, one >> called upper-macro that tests that upper cased macros do percent >> encoding, and invalid-domain-long-via-macro which checks for a >> macro expansion that creates an excessively long domain name. >> There's also a bunch of other tests that check that macros do what >> they're supposed to with normal input. >> >> Other than the one about the space, I don't see any tests for what >> happens if the text being expanded contains unexpected hostile >> characters. > > Should be easy enough to add. What would you consider hostile? Dear Scott, Since SMTPUTF8 permits UTF-8 mail-parameters that may affect either the local-part or the domain of email-addresses, it seems unlikely adequate test coverage will be found based on older specifications that expected mail parameters were limited to US-ASCII. This is no longer an SMTP constraint based upon the standards track RFC6530 extending both RFC5321 and RFC5322. Use of SPF records to filter local-part values independent of the domain is an expensive operation for receivers that may negatively impact their DNS cache or other third-parties whenever a component of the local-part constructs domains that may not appear in the email-address or anywhere in the email. A static local-part minimizes the impact of macro expansions, especially since no limit is imposed on the number of no-domain errors that might be generated. A simple macro expansion of a local-part label can direct an unlimited number of DNS queries against any third-party domain derived from a single cached SPF record. Simple deprecation of the local-part macro expansion guards against a potential form of reflected and amplified abuse where a pass result is possible subsequent to as many as 100 random sub-domain queries against any uninvolved third-party that may not be evident anywhere in the email. Page 9: Was: Implementations must take care to correctly extract the from the data given with the SMTP MAIL FROM command as many MTAs will still accept such things as source routes (see [RFC5321], Appendix C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). These archaic features have been maliciously used to bypass security systems. Change to: The EHLO/HELO parameter must use A-Label encoding. However that may not be true for the mail parameter. Implementations must take care to correctly extract the from the data given with the SMTP MAIL command as many MTAs will still accept such things as source routes (see [RFC5321], Appendix C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). These archaic features have been maliciously used to bypass security systems. There should be some combination of routines available to ensure UTF-8 parameters do not use illegal code-points. One method might use UTF-8(a) -> A-Label(a) conversion strategies that may not include assurances against illegal code-points. Confirmation that A-Label(a) -> UTF-8(b) provides the same string as UTF-8(a) should offer assurances against illegal code points without any additional routines. Elimination of illegal code-points is required to guard against visually deceptive strings. The domain portion of a UTF-8 encoded email address should be converted to an A-Label form using a method that ensures against illegal code-points, only the A-Label version of the domain should be passed to the SPF library. Otherwise, results will be undefined. Dealing with the local-part of a UTF-8 encoded email-address is problematic. One solution could replace the local-part with the value "postmaster" defined in Section 2.2 and 4.3. If there is a library in use that has not deprecated the operation of the '%l' macro, a simple string replacement still offers predictable results. Ideally, any record that includes '%l' macro should return the result "none". Page 10: Was: A result of "none" means that no records were published by the domain or that no checkable sender domain could be determined from the given identity. The checking software cannot ascertain whether or not the client host is authorized. Change to: A result of "none" means that no records were published by the domain or that no checkable sender domain could be determined from the given identity. The checking software cannot ascertain whether or not the client host is authorized. Use of a deprecated local-part macro should return the result of "none" or alternatively checked against the identity where local-part is replaced by the string "postmaster". Page 27: Was: Note: In general, the domain "A" cannot reliably use a redirect to another domain "B" not under the same administrative control. Since the stays the same, there is no guarantee that the record at domain "B" will correctly work for mailboxes in domain "A", especially if domain "B" uses mechanisms involving localparts. An "include" directive is generally be more appropriate. Change to: Note: In general, the domain "A" cannot reliably use a redirect to another domain "B" not under the same administrative control. Since the stays the same, there is no guarantee that the record at domain "B" will correctly work for mailboxes in domain "A". An "include" directive is generally more appropriate. Page 31: Was: l = local-part of Change to: Deprecated l = local-part of Page 32: Was: The "l" macro expands to just the localpart. Change to: The "l" macro is deprecated and may not expand to components of the local-part. Page 37: Was: 2. The "MAIL FROM" identity could have additional information in the localpart that cryptographically identifies the mail as coming from an authorized source. In this case, such an SPF record could be used: "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" Then, a specialized DNS server can be set up to serve the _spf_verify subdomain that validates the localpart. Although this requires an extra DNS lookup, this happens only when the email would otherwise be rejected as not coming from a known good source. Note that due to the 63-character limit for domain labels, this approach only works reliably if the localpart signature scheme is guaranteed either to only produce localparts with a maximum of 63 characters or to gracefully handle truncated localparts. Change to: Use of DNS resource records to individually validate an entire population of a domain's users is detrimental to the operation of DNS, and inappropriately burdens receiving domains. Domain-wide verifications should be used instead, such as DKIM for example. Regards, Douglas Otis From spf2@kitterman.com Sun Jul 15 22:06:25 2012 Return-Path: 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 9287621F858E for ; Sun, 15 Jul 2012 22:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[AWL=0.703, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_22=0.6] 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 RKo-o8MxNZQe for ; Sun, 15 Jul 2012 22:06:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D358F21F8579 for ; Sun, 15 Jul 2012 22:06:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3990320E40BD; Mon, 16 Jul 2012 01:07:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342415224; bh=Op1KxPLmxXJ4KyUP/9VM6N9JZu7LvJy2jp4MfPWcfZ8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QrtyRtM+UX2jHJJt0olhP04i6Rwg5HQUGM/LzKYTE28i3Wr05IKWWrR7FhAo5CpXm mng9PXRu65KGmv9ZwXKzx9aKZp+6KIXqmrsjBSDruvsvprknx/TWnqAlKehCGUStyj +2iU/aTDD0J/2kMA1VHPePWAXq2Q4RqBoqVO+jxs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1A1B620E40B9; Mon, 16 Jul 2012 01:07:03 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 16 Jul 2012 01:07:03 -0400 Message-ID: <13841705.Ry8OH4Cp8v@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 05:06:25 -0000 On Friday, July 13, 2012 01:20:28 AM Murray S. Kucherawy wrote: > Attached is a top-down review of the RFC4408bis document. Apologies = that > it took so long, but it's a big document. >=20 > The majority of the things I've tagged in there are editorial in natu= re. > Some refer to things that are open in the tracker as well, including = my > suggestion for making "check_host()" not look so much like an API > definition. Note that it's only a suggestion; I'm happy to discuss o= ther > ways to resolve that issue. >=20 > tl;dr version: It's well on its way to being ready, but we need to sp= end > some more time polishing it as well as resolving the open issues. No= ne of > it creates a need for face time in Vancouver. >=20 > Comments welcome. I'm only commenting on the things that I think need discussion. > 1. Introduction >=20 > The current email infrastructure has the property that any host > injecting mail into the mail system can identify itself as any dom= ain > name it wants. Hosts can do this at a variety of levels: in > particular, the session, the envelope, and the mail headers. >=20 > [MSK: Does "the session" refer to HELO/EHLO, rDNS, or something else?= ] Good question. I don't actually recall. I went back and looked and th= at=20 paragraph first appears in the draft done for MARID. The pre-MARID dra= fts=20 don't have anything like it at all and it wasn't touched after. My gue= ss=20 would be the SMTP session and the identity in question is HELO/EHLO. This paragraph seems to beg for editorial improvements, so I'd welcome = text if=20 someone is up to it. > Although this feature is desirable in some circumstances, it is a > major obstacle to reducing Unsolicited Bulk email (UBE, aka spam).= > Furthermore, many domain name holders are understandably concerned= > about the ease with which other entities can make use of their dom= ain > names, often with malicious intent. >=20 > [MSK: Would ADMD from RFC5598 be helpful in place of "domain name hol= ders" > above or "domain owners" below?]>=20 > This document defines a protocol by which domain owners can author= ize > hosts to use their domain name in the "MAIL FROM" or "HELO" identi= ty. Sort of. I think it would have to be something like "ADMD owning the d= omain",=20 since there are plenty of non-domain owning ADMDs. I'm not sure how mu= ch that=20 helps. > It is RECOMMENDED that SPF clients not only check the "MAIL FROM" > identity, but also separately check the "HELO" identity by applyin= g > the check_host() function (Section 4) to the "HELO" identity as th= e > . >=20 > [MSK: We need to explain why this is RECOMMENDED. We might later, bu= t I > haven't gotten that far yet and I might forget to come back and delet= e > this. :-)] It doesn't. It's RECOMMENDED as a general practice both in the sense o= f=20 "being a useful thing to do" and for overall consistency of results. I= don't=20 know that the latter is enough of an interoperability point to keep the= 2119=20 language. The SPF design, up to the point where local policy starts, = is=20 meant to be pretty deterministic and get consistent results. > If domain owners choose to publish SPF records, it is RECOMMENDED > that they end in "-all", or redirect to other records that do, so > that a definitive determination of authorization can be made. >=20 > [MSK: RECOMMENDED in RFC2119 terms is effectively a SHOULD. I don't = think > we should do this, as that's strictly a local policy matter and not o= ne of > interoperability.] Agreed. This needs to be reworded into something along the lines of "I= f the=20 domain owning ADMDs purpose in publishing the SPF record includes allow= ing=20 other parties to make a definitive determination of which hosts are not= =20 authorized by the ADMD to send mail from the domain, then they MUST pub= lish a=20 record that ends in "-all" or redirect to other records that do." Maybe that belongs in section with a non-2119 word for MUST. > When changing SPF records, care must be taken to ensure that there= is > a transition period so that the old policy remains valid until all= > legitimate email has been checked. >=20 > [MSK: There's no way to ever know this. Who's to say that a message = hasn't > sat queued for a month and finally goes through, or something erroneo= usly > begins relaying and thus re-evaluating a ton of old mail? We saw tha= t all > the time at Cloudmark, where someone would report an entire chunk of > his/her inbox as "spam" all at once. Re-evaluations like that could = have > undesirable effects. Thus, I think that last bit isn't actionable. = DKIM > talked about overlapping selectors as a transition policy, but I'm no= t sure > it applies here. Don't know what to suggest either.] Microsoft's original Caller ID for Email specification suggested 30 day= s, but=20 they also envisioned checking in MUAs, which SPF never has (people do i= t, but=20 it often doesn't end well). The intent of this was to warn people that= there=20 needed to be a transition, but we didn't try to define the time require= ment=20 because, as you say, there's no way to know. This should probably move= to=20 section 9. > 2.5. Interpreting the Result >=20 > This section describes how software that performs the authorizatio= n > should interpret the results of the check_host() function. The > authorization check SHOULD be performed during the processing of t= he > SMTP transaction that sends the mail. This allows errors to be > returned directly to the sending MTA by way of SMTP replies. >=20 > [MSK: I have an open ticket in the tracker about check_host(), so I'l= l make > my first comment about it here though there will be many more later. = The > very string "check_host()" looks like a function definition, and as I= said > in the tracker item, the IETF prefers to avoid the business of API > definitions. It's possible that I might be able to search-and-replac= e it > into something more palatable. This is just a placeholder comment to= note > that I still think it's an issue and I'm figuring out how to suggest = we > deal with it.]>=20 It looks like later you started replacing check_host() with CheckHost. = If=20 it's just a string replacement like that, I don't object. I don't like= the=20 idea of creating diff for things like this, but as long as there's supp= ort in=20 the group for it, no problem. > Performing the authorization after the SMTP transaction has finish= ed > can cause problems, such as the following: (1) It might be difficu= lt > to accurately extract the required information from potentially > deceptive headers; (2) legitimate email might fail because the > sender's policy had since changed. >=20 > [MSK: How is (1) above specific to post-transaction processing? Seem= s to me > it's a problem at the end of DATA as well.]>=20 > Generating non-delivery notifications to forged identities that ha= ve > failed the authorization check is generally abusive and against th= e > explicit wishes of the identity owner. I guess this is a bit implementation dependent. In Postfix, the MTA I'= m most=20 familiar with, all of the information from the SMTP session is still av= ailable=20 to me through it's policy interface. Meng Wong was also a Postfix user= , IIRC,=20 so this wording may be too implementation specific and need to be gener= alized. =20 I'd appreciate help on text. > [MSK: I think we should say more here. For example, how exactly is i= t > abusive? The recipient has done exactly what it was asked to do, yet= it's > abusing someone? Rather than saying it's abusive, I suggest we say i= t > introduces backscatter, and then define that term.] Makes sense. If someone can suggest a definition or a reference for a=20= definition (even better), I would appreciate it. > 2.5.1. None >=20 > A result of "none" means that no records were published by the dom= ain > or that no checkable sender domain could be determined from the gi= ven > identity. The checking software cannot ascertain whether or not t= he > client host is authorized. >=20 > [MSK: s/means that/means/, s/or that/or/] >=20 > [MSK: What constitutes "checkable"?] It means a domain could not be extracted to be used in check_host()=20 (CheckHost). The two possible conditions are "couldn't figure out what= domain=20 to query for a TXT record" and "queried for a record, got no DNS errror= , and=20 did not get an SPF record back (could have gotten other TXT records." = It=20 would be good if someone could suggest a clearer way to put this. > 2.5.4. Fail >=20 > A "fail" result is an explicit statement that the client is not > authorized to use the domain in the given identity. The checking > software can choose to mark the mail based on this or to reject th= e > mail outright. >=20 > [MSK: We should probably give a sentence somewhere above this about w= hat's > meant by "mark the mail". Maybe even a small section about possible = "fail" > actions that underscores the fact that rejection vs. marking is a cho= ice > and neither is specifically required would be a good idea.]>=20 I think change the second sentence to something like "Disposition of SP= F fail=20 messages is a matter of local policy. See [new part of section 9] for=20= considerations on developing local policy." Then we'd add what you're=20= suggesting to section 9. That makes it very clear that the mark/reject= =20 decision is up to the receiver and not a normative part of the protocol= . > example, the recipient's Mail User Agent (MUA) could highlight the= > "softfail" status, or the receiving MTA could give the sender a > message using greylisting, [RFC6647], with a note the first time t= he > message is received, but accept it on a later attempt based on > receiver policy. >=20 > [MSK: Are there any implementations that do this?] Yes. Tumgreyspf can do this. It's a blended SPF/Grey listing applicat= ion. > 2.5.6. TempError >=20 > A "temperror" result means that the SPF client encountered a > transient error while performing the check. Checking software can= > choose to accept or temporarily reject the message. If the messag= e > is rejected during the SMTP transaction for this reason, the softw= are > SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 > enhanced status code. >=20 > [MSK: Do we really need to spell out SMTP reply codes and enhanced st= atus > codes? Isn't it enough to say those codes are defined in RFC5321 and= > RFC3463, and leave it at that?] I think we should. There was an erratum about one of them being missin= g and=20 it would be odd to resolve that erratum by removing them all. Addition= ally,=20 I'm not sure it's 100% obvious. When we were reviewing that erratum, w= e=20 discovered RFC 4408 got one of them wrong. I think there is an=20 interoperability point here about consistency that it's worth not remov= ing=20 text for. > 2.5.7. PermError >=20 > A "permerror" result means that the domain's published records cou= ld > not be correctly interpreted. This signals an error condition tha= t > requires manual intervention to be resolved, as opposed to the > temperror result. If the message is rejected during the SMTP > transaction for this reason, the software SHOULD use an SMTP reply= > code of 550 and, if supported, the 5.5.2 enhanced status code. Be= > aware that if the domain owner uses macros (Section 8), it is > possible that this result is due to the checked identities having = an > unexpected format. >=20 > [MSK: s/means that/means/] >=20 > [MSK: Same point as above about reply codes, etc.] >=20 > [MSK: If not covered elsewhere, we need to indicate which of these is= an > appropriate return when a DNS error occurs. It may be the case that = we > leave this as an implementation detail, but I'd prefer we say that.] >=20 Is this not already addressed under temperror? > 3. SPF Records >=20 > An SPF record is a DNS Resource Record (RR) that declares which ho= sts >=20 > [MSK: This needs to be adjusted, because there's an SPF RRTYPE, but a= lso a > TXT RRTYPE, and as of this draft we prefer only the latter. Suggest = adding > "TXT (type 16)" after "DNS" here.]>=20 Agreed. > are, and are not, authorized to use a domain name for the "HELO" a= nd > "MAIL FROM" identities. Loosely, the record partitions all hosts > into permitted and not-permitted sets (though some hosts might fal= l > into neither category). >=20 > [MSK: That sounds confusing. How is that possible?] Pass =3D permitted and Fail =3D not permitted. The none, neutral, soft= fail,=20 permerror, and temperror results are variants of "I don't know". I don= 't know=20 are the ones that are in neither category. I'd appreciate someone prov= iding=20 recommended text to make this clearer. > [MSK: As I found in the experiment survey, there are some domains tha= t have > as many as 37 records at the domain level. We might want to include = any > other permanent references we can find that establish other TXT recor= ds > published at the domain level that might interfere with these guideli= nes.] If someone want to look into gathering a list, I don't object, but I'm = not=20 sure of the value. Many/most uses are not standardized, so whatever we= do=20 will be guaranteed to be substantially incomplete. I'm not sure what b= enefit a=20 partial list would do. > 4. The check_host() Function >=20 > [MSK: I'm reading this on the assumption that "check_host()" is repla= ced by > "CheckHost". Let's see if that works.] FWIW, I see what you're going after here and I think it 'works', but I = don't=20 think we should change it. It's a distinction without a difference and= the=20 existence of references to both check_host() and CheckHost is documenta= tion=20 would be confusing. I'm not worried about references withing 4408bis, = but in=20 other documents. > 4.3. Initial Processing >=20 > If the is malformed (label longer than 63 characters, zer= o- > length label not at the end, etc.) or is not a fully qualified dom= ain > name, or if the DNS lookup returns "domain does not exist" (RCODE = 3), > check_host() immediately returns the result "none". >=20 > [MSK: I suggest be defined in terms of whatever a legal doma= in name > is in [RFC5321], as amended by EAI, and further require that it be > fully-qualified. In terms of I18N, we should just do what DKIM did t= o > handle this case.] What did "DKIM do"? =20 > When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, > there MUST be a limit of no more than 10 MX or PTR RRs looked up a= nd > checked. If more than 10 "mx" or "ptr" records are returned for t= his > further lookup, a permerror MUST be returned. This limit is per > mechanism or macro in the record and in addition to the lookup lim= its > above. >=20 > [MSK: So this is where the concern about 110 queries comes from. The= > minutes from the Paris meeting say we would ask the DNS Directorate f= or > guidance here as to whether we should be concerned about it. I don't= think > that's happened yet. Someone should put that question together and s= end it > over to them ASAP.] I believe that the actual number of concern is 111 which you achieve by= =20 including the original record lookup. > Note that records SHOULD always use either a "redirect" modifier o= r > an "all" mechanism to explicitly terminate processing. >=20 > [MSK: So there's a default, but people SHOULD NOT rely on it? That s= eems > awkward.] SPF records are read by humans in addition to computers and they are of= ten=20 confused about this feature of the protocol. There is an implicit resu= lt,=20 but, as the "Zen of Python" says, "Explicit is better than implicit." = The=20 default result is fine for the silicon based computers that read SPF re= cords,=20 but the carbon based ones do better if one specifies it. =20 > For several mechanisms, the is optional. If it is n= ot > provided, the is used as the . >=20 > [MSK: How are and different? Do we need them = both?] Domain-spec is a defined ABNF term. Domain isn't. It's one of the inp= ut=20 arguments to check_host()/CheckHost defined in section 4.1. In the cas= e of an=20 SPF record like: example.com In TXT "v=3Dspf1 a:mail.example.com -all" the domain is example.com, an input value applicable to the entire eval= uation=20 (see redirect=3D for a limited exception to this) while domain-spec is = a=20 property associated with a particular mechanism or modifer. I think they are distinct enough that we ought not try and combine them= . > If no CIDR-length is given in the directive, then and the IP > address are compared for equality. (Here, CIDR is Classless Inter= - > Domain Routing.) >=20 > [MSK: Provide a reference to the definition of CIDR, and make sure > "CIDR-length" is defined there or use the term that document uses.]>=20= > If a CIDR-length is specified, then only the specified number of > high-order bits of and the IP address are compared for equali= ty. If someone knows/would look up the reference, I'd appreciate it. > [MSK: Do we need to mention network byte order? Probably not, just a= sking.] No that I know of. > =20 > Mechanisms after "all" will never be tested. Any "redirect" modif= ier > (Section 6.1) has no effect when there is an "all" mechanism. >=20 > [MSK: Unless it appears before "all", right?] I'm not sure how well it's defined, but the spec at least hints in more= than=20 one place (and this is one of them) that modifiers are processed after=20= mechanisms. I believe that's the original intent and we ought to clari= fy=20 things to explicitly say so. So, answer to your question, I don't think thats right, but I think it= 's not=20 at all clear. > In hindsight, the name "include" was poorly chosen. Only the > evaluated result of the referenced SPF record is used, rather than= > acting as if the referenced SPF record was literally included in t= he > first. For example, evaluating a "-all" directive in the referenc= ed > record does not terminate the overall processing and does not > necessarily result in an overall "fail". (Better names for this > mechanism would have been "if-pass", "on-pass", etc.) >=20 > [MSK: Interesting. Should we make a new name for it, synonymous with= > "include", to facilitate introduction of a new name in a future versi= on?] I don't see how we can do that without running into transition problems= . You=20 can't publish both the new/old name as the new name would cause an erro= r on=20 existing implementations, so it couldn't be deployed as part of SPF v 1= . =20 This is one of the changes (like combining a/ip4/ip6) that would be goo= d to=20 consider in a future update that is free to worry less about backward=20= compatibliilty. > The "include" mechanism is intended for crossing administrative > boundaries. Although it is possible to use includes to consolidat= e > multiple domains that share the same set of designated hosts, doma= ins > are encouraged to use redirects where possible, and to minimize th= e > number of includes within a single administrative domain. For > example, if example.com and example.org were managed by the same > entity, and if the permitted set of hosts for both domains was > "mx:example.com", it would be possible for example.org to specify > "include:example.com", but it would be preferable to specify > "redirect=3Dexample.com" or even "mx:example.com". >=20 > [MSK: I get that it's preferable, but I don't see why. What differen= ce does > it make?] It's a question of how the records expand and what results you get. example.com IN TXT "v=3Dspf1 include: another.example.net ?all" example.com IN A 192.0.2.1 another.example.net IN TXT "v=3Dspf1 a -all" another.example.net IN A 192.0.2.200 This will match for mail from 192.0.2.200 since the domain used in the=20= evaluation of another.example.net's SPF record is another.example.net. = The=20 result for mail from any other IP address is Neutral because include wi= th just=20 match/notmatch and the original SPF record's "all" mechanism is what co= ntrols=20 the result if nothing matches. With include you are specifying you want another domain's authorized ho= sts to=20 be authorized for your domain, but you still want to control the sender= policy=20 from this one (what result to give for things that don't match). Similarly, consider: example.com IN TXT "v=3Dspf1 redirect=3Danother.example.net" example.com IN A 192.0.2.1 another.example.net IN TXT "v=3Dspf1 a -all" another.example.net IN A 192.0.2.200 In this case, mail from 192.0.2.1 matches the record since the check_ho= st=20 expansion is done using the orignal domain name, not the domain-spec of= the=20 redirect modifier. The result is fail is the mail doesn't match. Redirect is much more like a common code element to be shared among rec= ords in=20 a single ADMD. You could control both authorized hosts and policy for = an=20 arbitrary number of domains from a single record. >=20 > 5.5. "ptr" (deprecated) >=20 > [MSK: Wouldn't it be easier to drop this section?] It's in use. We can't drop it, only discourage it harder. =20 > sending-domain_names :=3D ptr_lookup(sending-host_IP); > if more than 10 sending-domain_names are found, use at most 10. > for each name in (sending-domain_names) { > =20 > IP_addresses :=3D a_lookup(name); > if the sending-domain_IP is one of the IP_addresses { > =20 > validated-sending-domain_names +=3D name; > =20 > } > =20 > } > =20 > Check all validated domain names to see if they end in the > domain. If any do, this mechanism matches. If no >=20 > [MSK: So if xebay.com is validated, and is ebay.com, th= e > mechanism matches? Surely not, but it illustrates that the definitio= n of > this is weak.]>=20 That's meant to be limited to subdomain matches. We should improve the= =20 language. > 5.6. "ip4" and "ip6" >=20 > These mechanisms test whether is contained within a given IP > network. > =20 > IP4 =3D "ip4" ":" ip4-network [ ip4-cidr-lengt= h ] > IP6 =3D "ip6" ":" ip6-network [ ip6-cidr-lengt= h ] > =20 > ip4-cidr-length =3D "/" 1*DIGIT > ip6-cidr-length =3D "/" 1*DIGIT > dual-cidr-length =3D [ ip4-cidr-length ] [ "/" ip6-cidr-length ] >=20 > [MSK: Can't this be simplified to just a "cidr-length", and the above= three > dropped? Really the only difference is that ip4-cidr-length can't be= more > than 32 and ip6-cidr-length can't be more than 128. So either say th= at in > an ABNF comment for each (and you could make the former be 1*2DIGIT a= nd the > latter 1*3DIGIT), or simplify.]>=20 Would that still allow one to use a:example.com/30/64? That's legit no= w for=20 dual homed IPv4/6 hosts. > ip4-network =3D qnum "." qnum "." qnum "." qnum > qnum =3D DIGIT ; 0-9 > =20 > / %x31-39 DIGIT ; 10-99 > / "1" 2DIGIT ; 100-199 > / "2" %x30-34 DIGIT ; 200-249 > / "25" %x30-35 ; 250-255 > =20 > ; as per conventional dotted quad notation. e.g., 192.0.= 2.0 >=20 > [MSK: Is there really not a reference for this syntax?] There probably is, but we didn't find it in 2005. If someone can dig i= t up,=20 I'll add it. =20 > The domain-spec is expanded as per Section 8. The resulting domai= n > name is used for a DNS A RR lookup. If any A record is returned, > this mechanism matches. The lookup type is A even when the > connection type is IPv6. >=20 > [MSK: What about AAAA?] This is one of the few places where it says A and it should say A/AAAA.= I=20 think fixing it is an obvious bug fix. > 7. The Received-SPF Header Field >=20 > [MSK: This should be updated as agreed (I think) to say implementatio= ns > SHOULD generate A-R and MUST NOT generate this, while they SHOULD be = able > to parse this.]>=20 We argued about this. I agree that Section 7 should cover both Receive= d SPF=20 and Authentication Results. I think it should also described how to cr= eate an=20 Authentication Results header that has all the information found in a R= eceived=20 SPF header. =20 I don't believe that there is an Internet interoperability point in pre= ferring=20 one over the other. These are generated and consumed within an ADMD an= d so=20 within that ADMD, they should use whichever works for them. On that ba= sis, I=20 think it's reasonable to encourage adoption of Authentication Results b= y=20 software developers so that ADMD administrators can choose. > It is RECOMMENDED that SMTP receivers record the result of SPF > processing in the message header. If an SMTP receiver chooses to = do > so, it SHOULD use the "Received-SPF" header field defined here for= > each identity that was checked. This information is intended for = the > recipient. (Information intended for the sender is described in > Section 6.2, Explanation.) > =20 > The Received-SPF header field is a trace field (see [RFC5322] Sect= ion > 3.6.7) and SHOULD be prepended to the existing header, above the > Received: field that is generated by the SMTP receiver. It MUST > appear above all other Received-SPF fields in the message. The > header field has the following format: > =20 > header-field =3D "Received-SPF:" [CFWS] result FWS [comment FW= S] > =20 > [ key-value-list ] CRLF > =20 > result =3D "pass" / "fail" / "softfail" / "neutral" / > =20 > "none" / "temperror" / "permerror" > =20 > key-value-list =3D key-value-pair *( ";" [CFWS] key-value-pair )= > =20 > [";"] > =20 > key-value-pair =3D key [CFWS] "=3D" ( dot-atom / quoted-string )= > =20 > key =3D "client-ip" / "envelope-from" / "helo" / > =20 > "problem" / "receiver" / "identity" / > =20 > mechanism / name > =20 > identity =3D "mailfrom" ; for the "MAIL FROM" identity > =20 > / "helo" ; for the "HELO" identity > / name ; other identities >=20 > [MSK: Should "identity" be quoted in the "key" list?] >=20 > [MSK: There are two paths to "key" generating "name": one direct, one= > through "identity"]>=20 Is this a problem? > "MAIL FROM" identity was checked, "envelope-from". > =20 > client-ip the IP address of the SMTP client > =20 > envelope-from the envelope sender mailbox >=20 > [MSK: Suggest "the RFC5321.MailFrom address" or simply "the return-pa= th"] There's a section at the beginning where we cover all the different nam= es for=20 mail from. We ought to use this terminology from there on. =20 > macro-expand =3D ( "%{" macro-letter transformers *delimiter "= }" ) > =20 > / "%%" / "%_" / "%-" >=20 > [MSK: The "*delimiter" allows this: %{s.-+,/_=3D.+,..+.} What would = that > mean?]>=20 Good question. It's almost 1AM, so I'm not even going to try and figur= e that=20 one out right now. What does it mean? > p =3D the validated domain name of (deprecated) >=20 > [MSK: This makes me think we need to say somewhere what it means for = this to > be deprecated. When verifiers see it, for example, what should they = do?]>=20 Deprecated is defined early in the draft. > By default, strings are split on "." (dots). Note that no special= > treatment is given to leading, trailing, or consecutive delimiters= , >=20 > [MSK: In input strings, right?] Yes. >=20 > Macros MAY specify delimiter characters that are used instead of "= .". >=20 > [MSK: Isn't this redundant to the ABNF?] Yes, but so is a lot of the text. > The 'r' transformer indicates a reversal operation: if the client = IP > address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1"= > and the macro %{ir} would expand to "1.2.0.192". > =20 > The DIGIT transformer indicates the number of right-hand parts to > use, after optional reversal. If a DIGIT is specified, the value > MUST be nonzero. If no DIGITs are specified, or if the value > specifies more parts than are available, all the available parts a= re > used. If the DIGIT was 5, and only 3 parts were available, the ma= cro > interpreter would pretend the DIGIT was 3. Implementations MUST > support at least a value of 128, as that is the maximum number of > labels in a domain name. > =20 > The "s" macro expands to the argument. It is an email > address with a localpart, an "@" character, and a domain. The "l"= > macro expands to just the localpart. The "o" macro expands to jus= t > the domain part. Note that these values remain the same during > recursive and chained evaluations due to "include" and/or "redirec= t". > Note also that if the original had no localpart, the > localpart was set to "postmaster" in initial processing (see > Section 4.3). >=20 > [MSK: s/localpart/local-part/, x4] >=20 > For IPv4 addresses, both the "i" and "c" macros expand to the >=20 > Kitterman Expires January 6, 2013 [Page = 33] > =0C > Internet-Draft Sender Policy Framework (SPF) July 2= 012 >=20 > standard dotted-quad format. > =20 > For IPv6 addresses, the "i" macro expands to a dot-format address;= it > is intended for use in %{ir}. The "c" macro MAY expand to any of = the > hexadecimal colon-format addresses specified in [RFC4291], Section= > 2.2. It is intended for humans to read. > =20 > The "p" macro expands to the validated domain name of . The > procedure for finding the validated domain name is defined in > Section 5.5. If the is present in the list of validated > domains, it SHOULD be used. Otherwise, if a subdomain of the > is present, it SHOULD be used. Otherwise, any name from = the > list MAY be used. If there are no validated domain names or if a = DNS > error occurs, the string "unknown" is used. This macro is depreca= ted > and SHOULD NOT be used. >=20 > [MSK: There's probably not a better algorithm, but it's uncomfortable= having > the "any name" part, because two evaluations of the same name could y= ield > different expansions.]>=20 Multiple PTR names and how that can get confused are part of why this w= as=20 considered unreliable and why I think deprecation is a good idea. > The "t" macro expands to the decimal representation of the > approximate number of seconds since the Epoch (Midnight, January 1= , > 1970, UTC). This is the same value as is returned by the POSIX > time() function in most standards-compliant libraries. >=20 > [MSK: When? At time of evaluation? At time of message receipt? So= me > other time?]>=20 At evaluation. It has to be. > When the result of macro expansion is used in a domain name query,= if > the expanded domain name exceeds 253 characters (the maximum lengt= h > of a domain name), the left side is truncated to fit, by removing > successive domain labels until the total length does not exceed 25= 3 > characters. >=20 > [MSK: =E2=80=A6and their following dots, right?] Yes. > 9.3. Mail Services >=20 > MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer m= ail > services to third-party domains, such as sending of bulk mail, mig= ht > want to adjust their setup in light of the authorization check > [MSK: I'm getting wary of the use of "domain" now, and in retrospect = I > should've been looking at this throughout the document. DNSDIR has b= een > known to get cranky about the use of that word when the specific cont= ext > isn't clear. Did you mean ADMD here, or DNS domain name, for example= ?]>=20 I can make this one clearer. If there are others, let's address them. >=20 > at least 20 seconds. If such a limit is exceeded, the result of > authorization SHOULD be "temperror". >=20 > [MSK: Where are we these days on normative language in Security > Considerations? I thought we currently didn't like it.] So did I, but I got pushback when I tried to move it up into section 4.= I=20 think it does fit rather better there. > (Section 6.2), were generated by the sender policy published by th= e > domain holders themselves. As long as messages are only returned > with non-delivery notification to domains publishing the explanati= on > strings from their own DNS SPF records, the only affected parties = are > the original publishers of the domain's SPF records. >=20 > [MSK: Reference for NDNs?] If someone could provide this, it would be appreciated. Thanks for the detailed review. I've just left in the things that I'd = like=20 help with or that I think need some further discussion. Scott K From superuser@gmail.com Sun Jul 15 23:31:19 2012 Return-Path: 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 B156A11E807F for ; Sun, 15 Jul 2012 23:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.563 X-Spam-Level: X-Spam-Status: No, score=-4.563 tagged_above=-999 required=5 tests=[AWL=1.035, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 WbNNy6fjSAvX for ; Sun, 15 Jul 2012 23:31:15 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2E011E8079 for ; Sun, 15 Jul 2012 23:31:14 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so7586015lbb.31 for ; Sun, 15 Jul 2012 23:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eYcdGfQg7qgbHf6qy0GfLT4kpHzIDB5E85nK+sNnXlk=; b=kWjaw92D/tKck1/mH07aTF7pcAbAx4YQWECcdYNIEbvrb8zNBP9Hu2uvSgHVtz74rl wyVoUBug1y56nPYJYtsP63ktYb0gZ5mxMld87GxmfHl8YOoP3GKgU1STnMpFt4eBpwwY Q4OKcpy0LXRM1gdIY66WhLe46z9u8V6blO7aTawVzvtbNArLIZgEzYOVFh4Eb7H7TV7w bQpzZNpBlR0BguNEEyXDYOoGkBHPP6y8W7yfHHf7DVLdf/B3/Vu/FLt1THzH4YGdXLuj kuj3L4Tgu864Bb12/sEAGeK8lIfY3GoSJ8pz6lnllMaO2w2EAKa4achSuSkTz4kf6REh 5PFg== MIME-Version: 1.0 Received: by 10.152.112.138 with SMTP id iq10mr10323065lab.13.1342420317243; Sun, 15 Jul 2012 23:31:57 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sun, 15 Jul 2012 23:31:57 -0700 (PDT) In-Reply-To: <13841705.Ry8OH4Cp8v@scott-latitude-e6320> References: <13841705.Ry8OH4Cp8v@scott-latitude-e6320> Date: Sun, 15 Jul 2012 23:31:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0408da07260a8704c4ec968f Cc: spfbis@ietf.org Subject: Re: [spfbis] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 06:31:19 -0000 --f46d0408da07260a8704c4ec968f Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 15, 2012 at 10:07 PM, Scott Kitterman wrote: > > 1. Introduction > > > > The current email infrastructure has the property that any host > > injecting mail into the mail system can identify itself as any domain > > name it wants. Hosts can do this at a variety of levels: in > > particular, the session, the envelope, and the mail headers. > > > > [MSK: Does "the session" refer to HELO/EHLO, rDNS, or something else?] > > Good question. I don't actually recall. I went back and looked and that > paragraph first appears in the draft done for MARID. The pre-MARID drafts > don't have anything like it at all and it wasn't touched after. My guess > would be the SMTP session and the identity in question is HELO/EHLO. > > This paragraph seems to beg for editorial improvements, so I'd welcome > text if > someone is up to it. > The current email infrastructure has the property that any host injecting mail into the system can use any DNS domain name it wants in each of the various identifiers specified by [RFC5321] and [RFC5322], plus the "reverse pointer" which is the purported hostname of the SMTP client as far as the DNS is concerned [RFC1035]. > > > Although this feature is desirable in some circumstances, it is a > > major obstacle to reducing Unsolicited Bulk email (UBE, aka spam). > > Furthermore, many domain name holders are understandably concerned > > about the ease with which other entities can make use of their domain > > names, often with malicious intent. > > > > [MSK: Would ADMD from RFC5598 be helpful in place of "domain name > holders" > > above or "domain owners" below?]> > > This document defines a protocol by which domain owners can authorize > > hosts to use their domain name in the "MAIL FROM" or "HELO" identity. > > Sort of. I think it would have to be something like "ADMD owning the > domain", > since there are plenty of non-domain owning ADMDs. I'm not sure how much > that > helps. > The opposite is true though: Every domain is owned by an ADMD. Your suggestion seems okay to me. > It is RECOMMENDED that SPF clients not only check the "MAIL FROM" > identity, but also separately check the "HELO" identity by applying > the check_host() function (Section 4) to the "HELO" identity as the > . > > [MSK: We need to explain why this is RECOMMENDED. We might later, but I > haven't gotten that far yet and I might forget to come back and delete > this. :-)] It doesn't. It's RECOMMENDED as a general practice both in the sense of > "being a useful thing to do" and for overall consistency of results. I > don't > know that the latter is enough of an interoperability point to keep the > 2119 > language. The SPF design, up to the point where local policy starts, is > meant to be pretty deterministic and get consistent results. > I think saying exactly that is probably sufficient. > > > If domain owners choose to publish SPF records, it is RECOMMENDED > > that they end in "-all", or redirect to other records that do, so > > that a definitive determination of authorization can be made. > > > > [MSK: RECOMMENDED in RFC2119 terms is effectively a SHOULD. I don't > think > > we should do this, as that's strictly a local policy matter and not one > of > > interoperability.] > > Agreed. This needs to be reworded into something along the lines of "If > the > domain owning ADMDs purpose in publishing the SPF record includes allowing > other parties to make a definitive determination of which hosts are not > authorized by the ADMD to send mail from the domain, then they MUST > publish a > record that ends in "-all" or redirect to other records that do." > That's probably fine, especially if there's a "however" type reference to a section that discusses caveats in use of SPF, such as its known failure modes (forwarders, for example). > When changing SPF records, care must be taken to ensure that there is > > a transition period so that the old policy remains valid until all > > legitimate email has been checked. > > > > [MSK: There's no way to ever know this. Who's to say that a message > hasn't > > sat queued for a month and finally goes through, or something erroneously > > begins relaying and thus re-evaluating a ton of old mail? We saw that > all > > the time at Cloudmark, where someone would report an entire chunk of > > his/her inbox as "spam" all at once. Re-evaluations like that could have > > undesirable effects. Thus, I think that last bit isn't actionable. DKIM > > talked about overlapping selectors as a transition policy, but I'm not > sure > > it applies here. Don't know what to suggest either.] > > Microsoft's original Caller ID for Email specification suggested 30 days, > but > they also envisioned checking in MUAs, which SPF never has (people do it, > but > it often doesn't end well). The intent of this was to warn people that > there > needed to be a transition, but we didn't try to define the time requirement > because, as you say, there's no way to know. This should probably move to > section 9. > Sure, let's try that. > > > 2.5. Interpreting the Result > > > > This section describes how software that performs the authorization > > should interpret the results of the check_host() function. The > > authorization check SHOULD be performed during the processing of the > > SMTP transaction that sends the mail. This allows errors to be > > returned directly to the sending MTA by way of SMTP replies. > > > > [MSK: I have an open ticket in the tracker about check_host(), so I'll > make > > my first comment about it here though there will be many more later. The > > very string "check_host()" looks like a function definition, and as I > said > > in the tracker item, the IETF prefers to avoid the business of API > > definitions. It's possible that I might be able to search-and-replace it > > into something more palatable. This is just a placeholder comment to > note > > that I still think it's an issue and I'm figuring out how to suggest we > > deal with it.]> > > It looks like later you started replacing check_host() with CheckHost. If > it's just a string replacement like that, I don't object. I don't like the > idea of creating diff for things like this, but as long as there's support > in > the group for it, no problem. > The chatter in Paris suggested simply adding a paragraph before the definition of check_host() that says emphatically that this is not an API definition, but rather the mechanism is used to illustrate the algorithm; a compliant SPF implementation MUST do something semantically equivalent to what we describe for check_host(). Pete said this was probably acceptable. It's probably less work than all the s// I did here as well. We should probably try that approach, in retrospect. > > > Performing the authorization after the SMTP transaction has finished > > can cause problems, such as the following: (1) It might be difficult > > to accurately extract the required information from potentially > > deceptive headers; (2) legitimate email might fail because the > > sender's policy had since changed. > > > > [MSK: How is (1) above specific to post-transaction processing? Seems > to me > > it's a problem at the end of DATA as well.]> > > Generating non-delivery notifications to forged identities that have > > failed the authorization check is generally abusive and against the > > explicit wishes of the identity owner. > > I guess this is a bit implementation dependent. In Postfix, the MTA I'm > most > familiar with, all of the information from the SMTP session is still > available > to me through it's policy interface. Meng Wong was also a Postfix user, > IIRC, > so this wording may be too implementation specific and need to be > generalized. > I'd appreciate help on text. > Just change "after the SMTP transaction has finished" to "other than using the return-path and client address at the time of the MAIL command during the SMTP session", and I'd be happy. > > > [MSK: I think we should say more here. For example, how exactly is it > > abusive? The recipient has done exactly what it was asked to do, yet > it's > > abusing someone? Rather than saying it's abusive, I suggest we say it > > introduces backscatter, and then define that term.] > > Makes sense. If someone can suggest a definition or a reference for a > definition (even better), I would appreciate it. > RFC3834 comes closest, I think. Section 2, especially. > > > 2.5.1. None > > > > A result of "none" means that no records were published by the domain > > or that no checkable sender domain could be determined from the given > > identity. The checking software cannot ascertain whether or not the > > client host is authorized. > > > > [MSK: s/means that/means/, s/or that/or/] > > > > [MSK: What constitutes "checkable"?] > > It means a domain could not be extracted to be used in check_host() > (CheckHost). The two possible conditions are "couldn't figure out what > domain > to query for a TXT record" and "queried for a record, got no DNS errror, > and > did not get an SPF record back (could have gotten other TXT records." It > would be good if someone could suggest a clearer way to put this. > A result of "none" means either (a) no syntactically valid DNS domain name was extracted from the SMTP session that could be used as the one to be authorized, or (b) no TXT records were retrieved from the DNS that appeared to be intended for use by SPF verifiers. > > > 2.5.4. Fail > > > > A "fail" result is an explicit statement that the client is not > > authorized to use the domain in the given identity. The checking > > software can choose to mark the mail based on this or to reject the > > mail outright. > > > > [MSK: We should probably give a sentence somewhere above this about > what's > > meant by "mark the mail". Maybe even a small section about possible > "fail" > > actions that underscores the fact that rejection vs. marking is a choice > > and neither is specifically required would be a good idea.]> > > I think change the second sentence to something like "Disposition of SPF > fail > messages is a matter of local policy. See [new part of section 9] for > considerations on developing local policy." Then we'd add what you're > suggesting to section 9. That makes it very clear that the mark/reject > decision is up to the receiver and not a normative part of the protocol. > That sounds much better. I'll wait to see what you develop there. > > > > example, the recipient's Mail User Agent (MUA) could highlight the > > "softfail" status, or the receiving MTA could give the sender a > > message using greylisting, [RFC6647], with a note the first time the > > message is received, but accept it on a later attempt based on > > receiver policy. > > > > [MSK: Are there any implementations that do this?] > > Yes. Tumgreyspf can do this. It's a blended SPF/Grey listing application. > Hmm. It sounds complicated. Although it's possible and legal, does it add anything here to call it out as an example? I'm pushing for simplicity here. > > > 2.5.6. TempError > > > > A "temperror" result means that the SPF client encountered a > > transient error while performing the check. Checking software can > > choose to accept or temporarily reject the message. If the message > > is rejected during the SMTP transaction for this reason, the software > > SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 > > enhanced status code. > > > > [MSK: Do we really need to spell out SMTP reply codes and enhanced status > > codes? Isn't it enough to say those codes are defined in RFC5321 and > > RFC3463, and leave it at that?] > > I think we should. There was an erratum about one of them being missing > and > it would be odd to resolve that erratum by removing them all. > Additionally, > I'm not sure it's 100% obvious. When we were reviewing that erratum, we > discovered RFC 4408 got one of them wrong. I think there is an > interoperability point here about consistency that it's worth not removing > text for. > What do others think? I always prefer to refer to other protocols (or specific parts of them) rather than copying details from them. > > > are, and are not, authorized to use a domain name for the "HELO" and > > "MAIL FROM" identities. Loosely, the record partitions all hosts > > into permitted and not-permitted sets (though some hosts might fall > > into neither category). > > > > [MSK: That sounds confusing. How is that possible?] > > Pass = permitted and Fail = not permitted. The none, neutral, softfail, > permerror, and temperror results are variants of "I don't know". I don't > know > are the ones that are in neither category. I'd appreciate someone > providing > recommended text to make this clearer. > You don't need to. I originally read "neither" as "either". It's fine the way it is. > > > [MSK: As I found in the experiment survey, there are some domains that > have > > as many as 37 records at the domain level. We might want to include any > > other permanent references we can find that establish other TXT records > > published at the domain level that might interfere with these > guidelines.] > > If someone want to look into gathering a list, I don't object, but I'm not > sure of the value. Many/most uses are not standardized, so whatever we do > will be guaranteed to be substantially incomplete. I'm not sure what > benefit a > partial list would do. > The point of this would be to encourage implementers to harden their code against receiving TXT records that have nothing to do with SPF. As an opposite example of sorts, ADSP, DKIM, VBR, and various other protocols have all had to be hardened against the notion of asking for one of their own TXT records and getting back an SPF record because of the use of DNS wildcards since SPF pre-dates them. DMARC will have to do this too. We could reference those as examples of other protocols that use DNS TXT records, and due to wildcarding, an SPF implementation needs to anticipate getting data it doesn't expect. In practice this is far less likely than the opposite, but who knows what the future will yield. > > > 4. The check_host() Function > > > > [MSK: I'm reading this on the assumption that "check_host()" is replaced > by > > "CheckHost". Let's see if that works.] > > FWIW, I see what you're going after here and I think it 'works', but I > don't > think we should change it. It's a distinction without a difference and the > existence of references to both check_host() and CheckHost is documentation > would be confusing. I'm not worried about references withing 4408bis, but > in > other documents. > I commented on this above already. This was just one example of dealing with the concern. There might be something much simpler we can do. > > > 4.3. Initial Processing > > > > If the is malformed (label longer than 63 characters, zero- > > length label not at the end, etc.) or is not a fully qualified domain > > name, or if the DNS lookup returns "domain does not exist" (RCODE 3), > > check_host() immediately returns the result "none". > > > > [MSK: I suggest be defined in terms of whatever a legal domain > name > > is in [RFC5321], as amended by EAI, and further require that it be > > fully-qualified. In terms of I18N, we should just do what DKIM did to > > handle this case.] > > What did "DKIM do"? > I'm referring to Section 3.5 of RFC6376, the definition of "d=". > > Note that records SHOULD always use either a "redirect" modifier or > > an "all" mechanism to explicitly terminate processing. > > > > [MSK: So there's a default, but people SHOULD NOT rely on it? That seems > > awkward.] > > SPF records are read by humans in addition to computers and they are often > confused about this feature of the protocol. There is an implicit result, > but, as the "Zen of Python" says, "Explicit is better than implicit." The > default result is fine for the silicon based computers that read SPF > records, > but the carbon based ones do better if one specifies it. > We should say at the end "Although the latter is the default (specifically "?all"), it aids debugging efforts if it is explicitly included." (At least, I think it's "?all", but whatever it is should go there.) > > For several mechanisms, the is optional. If it is not > > provided, the is used as the . > > > > [MSK: How are and different? Do we need them > both?] > > Domain-spec is a defined ABNF term. Domain isn't. It's one of the input > arguments to check_host()/CheckHost defined in section 4.1. In the case > of an > SPF record like: > > example.com In TXT "v=spf1 a:mail.example.com -all" > > the domain is example.com, an input value applicable to the entire > evaluation > (see redirect= for a limited exception to this) while domain-spec is a > property associated with a particular mechanism or modifer. > > I think they are distinct enough that we ought not try and combine them. > OK, then I think the right thing would be to say that they are syntactically identical, but used in different parts of the evaluation process. In ABNF, something like this would do: domain = domain-spec = domain ; syntactically identical to "domain", but used differently in the evaluation Dave, do you have any other insight here? > > > If no CIDR-length is given in the directive, then and the IP > > address are compared for equality. (Here, CIDR is Classless Inter- > > Domain Routing.) > > > > [MSK: Provide a reference to the definition of CIDR, and make sure > > "CIDR-length" is defined there or use the term that document uses.]> > > If a CIDR-length is specified, then only the specified number of > > high-order bits of and the IP address are compared for equality. > > If someone knows/would look up the reference, I'd appreciate it. > RFC4632 is the current reference, but alas it contains no ABNF. > > Mechanisms after "all" will never be tested. Any "redirect" modifier > > (Section 6.1) has no effect when there is an "all" mechanism. > > > > [MSK: Unless it appears before "all", right?] > > I'm not sure how well it's defined, but the spec at least hints in more > than > one place (and this is one of them) that modifiers are processed after > mechanisms. I believe that's the original intent and we ought to clarify > things to explicitly say so. > I think that needs to be stated explicitly someplace, maybe an "overall flow of the evaluation process" paragraph or something before it gets too detailed. > > In hindsight, the name "include" was poorly chosen. Only the > > evaluated result of the referenced SPF record is used, rather than > > acting as if the referenced SPF record was literally included in the > > first. For example, evaluating a "-all" directive in the referenced > > record does not terminate the overall processing and does not > > necessarily result in an overall "fail". (Better names for this > > mechanism would have been "if-pass", "on-pass", etc.) > > > > [MSK: Interesting. Should we make a new name for it, synonymous with > > "include", to facilitate introduction of a new name in a future version?] > > I don't see how we can do that without running into transition problems. > You > can't publish both the new/old name as the new name would cause an error on > existing implementations, so it couldn't be deployed as part of SPF v 1. > This is one of the changes (like combining a/ip4/ip6) that would be good to > consider in a future update that is free to worry less about backward > compatibliilty. > I hadn't thought of a/ip4/ip6. This makes me think a short appendix about "notes for future revisions to SPF" or such might be a good idea. > > > The "include" mechanism is intended for crossing administrative > > boundaries. Although it is possible to use includes to consolidate > > multiple domains that share the same set of designated hosts, domains > > are encouraged to use redirects where possible, and to minimize the > > number of includes within a single administrative domain. For > > example, if example.com and example.org were managed by the same > > entity, and if the permitted set of hosts for both domains was > > "mx:example.com", it would be possible for example.org to specify > > "include:example.com", but it would be preferable to specify > > "redirect=example.com" or even "mx:example.com". > > > > [MSK: I get that it's preferable, but I don't see why. What difference > does > > it make?] > > It's a question of how the records expand and what results you get. > > example.com IN TXT "v=spf1 include: another.example.net ?all" > example.com IN A 192.0.2.1 > another.example.net IN TXT "v=spf1 a -all" > another.example.net IN A 192.0.2.200 > > This will match for mail from 192.0.2.200 since the domain used in the > evaluation of another.example.net's SPF record is another.example.net. > The > result for mail from any other IP address is Neutral because include with > just > match/notmatch and the original SPF record's "all" mechanism is what > controls > the result if nothing matches. > > With include you are specifying you want another domain's authorized hosts > to > be authorized for your domain, but you still want to control the sender > policy > from this one (what result to give for things that don't match). > > Similarly, consider: > > example.com IN TXT "v=spf1 redirect=another.example.net" > example.com IN A 192.0.2.1 > another.example.net IN TXT "v=spf1 a -all" > another.example.net IN A 192.0.2.200 > > In this case, mail from 192.0.2.1 matches the record since the check_host > expansion is done using the orignal domain name, not the domain-spec of the > redirect modifier. The result is fail is the mail doesn't match. > > Redirect is much more like a common code element to be shared among > records in > a single ADMD. You could control both authorized hosts and policy for an > arbitrary number of domains from a single record. > Your example is a lot more illustrative than the paragraph I cited. Perhaps a briefer summary of the difference would be helpful. The concept that speaks to me as a coder is something like "redirect never returns". For example, in C, if you do this: status = foo(); return status; You have the choice to use the return value from foo() as it does, or to insert code before the "return" to do your own thing and eventually return your own result (which "include" does), while: return foo(); This executes foo() and its return value is the return value of the caller with no opportunity to do something different (which "redirect" does). > > > > 5.5. "ptr" (deprecated) > > > > [MSK: Wouldn't it be easier to drop this section?] > > It's in use. We can't drop it, only discourage it harder. > I would remove it to an appendix or something if we don't intend for it to be part of the live protocol. But this is another example of the question, which I think is still being discussed, about whether it's appropriate to remove or at least deprecate things. The same survey that started the other argument finds 93 domains using "ptr" out of over 150,000 reporting. If it's okay do deprecate ptr, then it's okay to deprecate macros. And if it's deprecated and moving from Experimental to Proposed Standard, I think this is a serious consideration. > > Check all validated domain names to see if they end in the > > domain. If any do, this mechanism matches. If no > > > > [MSK: So if xebay.com is validated, and is ebay.com, the > > mechanism matches? Surely not, but it illustrates that the definition of > > this is weak.]> > > That's meant to be limited to subdomain matches. We should improve the > language. > Something about a "right-to-left label-for-label subset match" might do. > > > 5.6. "ip4" and "ip6" > > > > These mechanisms test whether is contained within a given IP > > network. > > > > IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] > > IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] > > > > ip4-cidr-length = "/" 1*DIGIT > > ip6-cidr-length = "/" 1*DIGIT > > dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] > > > > [MSK: Can't this be simplified to just a "cidr-length", and the above > three > > dropped? Really the only difference is that ip4-cidr-length can't be > more > > than 32 and ip6-cidr-length can't be more than 128. So either say that > in > > an ABNF comment for each (and you could make the former be 1*2DIGIT and > the > > latter 1*3DIGIT), or simplify.]> > > Would that still allow one to use a:example.com/30/64? That's legit now > for > dual homed IPv4/6 hosts. > My survey found zero dual-cidr-lengths in use. > > > ip4-network = qnum "." qnum "." qnum "." qnum > > qnum = DIGIT ; 0-9 > > > > / %x31-39 DIGIT ; 10-99 > > / "1" 2DIGIT ; 100-199 > > / "2" %x30-34 DIGIT ; 200-249 > > / "25" %x30-35 ; 250-255 > > > > ; as per conventional dotted quad notation. e.g., 192.0.2.0 > > > > [MSK: Is there really not a reference for this syntax?] > > There probably is, but we didn't find it in 2005. If someone can dig it > up, > I'll add it. > I actually can't find one either. Pete or Dave, perhaps? > > 7. The Received-SPF Header Field > > > > [MSK: This should be updated as agreed (I think) to say implementations > > SHOULD generate A-R and MUST NOT generate this, while they SHOULD be able > > to parse this.]> > > We argued about this. I agree that Section 7 should cover both Received > SPF > and Authentication Results. I think it should also described how to > create an > Authentication Results header that has all the information found in a > Received > SPF header. > > I don't believe that there is an Internet interoperability point in > preferring > one over the other. These are generated and consumed within an ADMD and so > within that ADMD, they should use whichever works for them. On that > basis, I > think it's reasonable to encourage adoption of Authentication Results by > software developers so that ADMD administrators can choose. > Sounds good to me. > > > > > key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) > > > > key = "client-ip" / "envelope-from" / "helo" / > > > > "problem" / "receiver" / "identity" / > > > > mechanism / name > > > > identity = "mailfrom" ; for the "MAIL FROM" identity > > > > / "helo" ; for the "HELO" identity > > / name ; other identities > > > > [MSK: Should "identity" be quoted in the "key" list?] > > > > [MSK: There are two paths to "key" generating "name": one direct, one > > through "identity"]> > > Is this a problem? > I thought it was considered an ambiguous grammar in that case, and thus "improper". You should run this through a BNF checker too just to see if any bugs are found. There's one on tools.ietf.org someplace. > > > "MAIL FROM" identity was checked, "envelope-from". > > > > client-ip the IP address of the SMTP client > > > > envelope-from the envelope sender mailbox > > > > [MSK: Suggest "the RFC5321.MailFrom address" or simply "the return-path"] > > There's a section at the beginning where we cover all the different names > for > mail from. We ought to use this terminology from there on. > Yeah, using one throughout would be ideal. > > > > macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) > > > > / "%%" / "%_" / "%-" > > > > [MSK: The "*delimiter" allows this: %{s.-+,/_=.+,..+.} What would that > > mean?]> > > Good question. It's almost 1AM, so I'm not even going to try and figure > that > one out right now. What does it mean? > My point is that the grammar allows it, and I'm not certain we want that. What's the point of allowing lots of delimiters? How would one apply more than one? > > > p = the validated domain name of (deprecated) > > > > [MSK: This makes me think we need to say somewhere what it means for > this to > > be deprecated. When verifiers see it, for example, what should they > do?]> > > Deprecated is defined early in the draft. > So it does; withdrawn. > > > By default, strings are split on "." (dots). Note that no special > > treatment is given to leading, trailing, or consecutive delimiters, > > > > [MSK: In input strings, right?] > > Yes. > So if the "delimiter" part of the ABNF is "+.", what does a parser do? Break on +, then within those break on .? Break on either (like strtok() does)? > > > > > Macros MAY specify delimiter characters that are used instead of ".". > > > > [MSK: Isn't this redundant to the ABNF?] > > Yes, but so is a lot of the text. > I guess I'd like to keep that to a minimum. > > > The "p" macro expands to the validated domain name of . The > > procedure for finding the validated domain name is defined in > > Section 5.5. If the is present in the list of validated > > domains, it SHOULD be used. Otherwise, if a subdomain of the > > is present, it SHOULD be used. Otherwise, any name from the > > list MAY be used. If there are no validated domain names or if a DNS > > error occurs, the string "unknown" is used. This macro is deprecated > > and SHOULD NOT be used. > > > > [MSK: There's probably not a better algorithm, but it's uncomfortable > having > > the "any name" part, because two evaluations of the same name could yield > > different expansions.]> > > Multiple PTR names and how that can get confused are part of why this was > considered unreliable and why I think deprecation is a good idea. > Let's add a sentence in there to this effect then. > > > The "t" macro expands to the decimal representation of the > > approximate number of seconds since the Epoch (Midnight, January 1, > > 1970, UTC). This is the same value as is returned by the POSIX > > time() function in most standards-compliant libraries. > > > > [MSK: When? At time of evaluation? At time of message receipt? Some > > other time?]> > > At evaluation. It has to be. > Let's add that clause. > > 9.3. Mail Services > > > > MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail > > services to third-party domains, such as sending of bulk mail, might > > want to adjust their setup in light of the authorization check > > > [MSK: I'm getting wary of the use of "domain" now, and in retrospect I > > should've been looking at this throughout the document. DNSDIR has been > > known to get cranky about the use of that word when the specific context > > isn't clear. Did you mean ADMD here, or DNS domain name, for example?]> > > I can make this one clearer. If there are others, let's address them. > That was the first one that got my attention. When you post -04 I'll do a quick pass looking for that word and see if I can spot any that need massaging. > > > > > at least 20 seconds. If such a limit is exceeded, the result of > > authorization SHOULD be "temperror". > > > > [MSK: Where are we these days on normative language in Security > > Considerations? I thought we currently didn't like it.] > > So did I, but I got pushback when I tried to move it up into section 4. I > think it does fit rather better there. > Pete or Barry? > > > (Section 6.2), were generated by the sender policy published by the > > domain holders themselves. As long as messages are only returned > > with non-delivery notification to domains publishing the explanation > > strings from their own DNS SPF records, the only affected parties are > > the original publishers of the domain's SPF records. > > > > [MSK: Reference for NDNs?] > > If someone could provide this, it would be appreciated. > RFC3464, I believe. -MSK --f46d0408da07260a8704c4ec968f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Jul 15, 2012 at 10:07 PM, Scott Kitterman <spf2@kitterman.com= > wrote:
> 1. =A0Introduction
>
> =A0 =A0The current email infrastructure has the property that any host=
> =A0 =A0injecting mail into the mail system can identify itself as any = domain
> =A0 =A0name it wants. =A0Hosts can do this at a variety of levels: in<= br> > =A0 =A0particular, the session, the envelope, and the mail headers. >
> [MSK: Does "the session" refer to HELO/EHLO, rDNS, or someth= ing else?]

Good question. =A0I don't actually recall. =A0I went back and looked an= d that
paragraph first appears in the draft done for MARID. =A0The pre-MARID draft= s
don't have anything like it at all and it wasn't touched after. =A0= My guess
would be the SMTP session and the identity in question is HELO/EHLO.

This paragraph seems to beg for editorial improvements, so I'd welcome = text if
someone is up to it.

The current email infrastruct= ure has the property that any host injecting mail into the system can use a= ny DNS domain name it wants in each of the various identifiers specified by= [RFC5321] and [RFC5322], plus the "reverse pointer" which is the= purported hostname of the SMTP client as far as the DNS is concerned [RFC1= 035].
=A0

> =A0 =A0Although this feature is desirable in some circumstances, it is= a
> =A0 =A0major obstacle to reducing Unsolicited Bulk email (UBE, aka spa= m).
> =A0 =A0Furthermore, many domain name holders are understandably concer= ned
> =A0 =A0about the ease with which other entities can make use of their = domain
> =A0 =A0names, often with malicious intent.
>
> [MSK: Would ADMD from RFC5598 be helpful in place of "domain name= holders"
> above or "domain owners" below?]>
> =A0 =A0This document defines a protocol by which domain owners can aut= horize
> =A0 =A0hosts to use their domain name in the "MAIL FROM" or = "HELO" identity.

Sort of. =A0I think it would have to be something like "ADMD owning th= e domain",
since there are plenty of non-domain owning ADMDs. =A0I'm not sure how = much that
helps.

The opposite is true though: E= very domain is owned by an ADMD.=A0 Your suggestion seems okay to me.
> =A0 =A0It is RECOMMENDED that SPF clients not only check the "MAI= L FROM"
> =A0 =A0identity, but also separately check the "HELO" identi= ty by applying
> =A0 =A0the check_host() function (Section 4) to the "HELO" i= dentity as the
> =A0 =A0<sender>.
>
> [MSK: We need to explain why this is RECOMMENDED. =A0We might later, b= ut I
> haven't gotten that far yet and I might forget to come back and de= lete
> this. =A0:-)]

It doesn't. =A0= It's RECOMMENDED as a general practice both in the sense of
"being a useful thing to do" and for overall consistency of resul= ts. =A0I don't
know that the latter is enough of an interoperability point to keep the 211= 9
language. =A0The SPF design, =A0up to the point where local policy starts, = is
meant to be pretty deterministic and get consistent results.

I think saying exactly that is probably sufficient.
=A0

> =A0 =A0If domain owners choose to publish SPF records, it is RECOMMEND= ED
> =A0 =A0that they end in "-all", or redirect to other records= that do, so
> =A0 =A0that a definitive determination of authorization can be made. >
> [MSK: RECOMMENDED in RFC2119 terms is effectively a SHOULD. =A0I don&#= 39;t think
> we should do this, as that's strictly a local policy matter and no= t one of
> interoperability.]

Agreed. =A0This needs to be reworded into something along the lines o= f "If the
domain owning ADMDs purpose in publishing the SPF record includes allowing<= br> other parties to make a definitive determination of which hosts are not
authorized by the ADMD to send mail from the domain, then they MUST publish= a
record that ends in "-all" or redirect to other records that do.&= quot;

That's probably fine, especially if ther= e's a "however" type reference to a section that discusses ca= veats in use of SPF, such as its known failure modes (forwarders, for examp= le).
=A0

> =A0 =A0When changing SPF records, care must be taken to ensure that th= ere is
> =A0 =A0a transition period so that the old policy remains valid until = all
> =A0 =A0legitimate email has been checked.
>
> [MSK: There's no way to ever know this. =A0Who's to say that a= message hasn't
> sat queued for a month and finally goes through, or something erroneou= sly
> begins relaying and thus re-evaluating a ton of old mail? =A0We saw th= at all
> the time at Cloudmark, where someone would report an entire chunk of > his/her inbox as "spam" all at once. =A0Re-evaluations like = that could have
> undesirable effects. =A0Thus, I think that last bit isn't actionab= le. =A0DKIM
> talked about overlapping selectors as a transition policy, but I'm= not sure
> it applies here. =A0Don't know what to suggest either.]

Microsoft's original Caller ID for Email specification suggested 30 day= s, but
they also envisioned checking in MUAs, which SPF never has (people do it, b= ut
it often doesn't end well). =A0The intent of this was to warn people th= at there
needed to be a transition, but we didn't try to define the time require= ment
because, as you say, there's no way to know. =A0This should probably mo= ve to
section 9.

Sure, let's try that.
=A0

> 2.5. =A0Interpreting the Result
>
> =A0 =A0This section describes how software that performs the authoriza= tion
> =A0 =A0should interpret the results of the check_host() function. =A0T= he
> =A0 =A0authorization check SHOULD be performed during the processing o= f the
> =A0 =A0SMTP transaction that sends the mail. =A0This allows errors to = be
> =A0 =A0returned directly to the sending MTA by way of SMTP replies. >
> [MSK: I have an open ticket in the tracker about check_host(), so I= 9;ll make
> my first comment about it here though there will be many more later. = =A0The
> very string "check_host()" looks like a function definition,= and as I said
> in the tracker item, the IETF prefers to avoid the business of API
> definitions. =A0It's possible that I might be able to search-and-r= eplace it
> into something more palatable. =A0This is just a placeholder comment t= o note
> that I still think it's an issue and I'm figuring out how to s= uggest we
> deal with it.]>

It looks like later you started replacing check_host() with CheckHost. =A0I= f
it's just a string replacement like that, I don't object. =A0I don&= #39;t like the
idea of creating diff for things like this, but as long as there's supp= ort in
the group for it, no problem.

The chatter in Paris= suggested simply adding a paragraph before the definition of check_host() = that says emphatically that this is not an API definition, but rather the m= echanism is used to illustrate the algorithm; a compliant SPF implementatio= n MUST do something semantically equivalent to what we describe for check_h= ost().=A0 Pete said this was probably acceptable.=A0 It's probably less= work than all the s// I did here as well.=A0 We should probably try that a= pproach, in retrospect.
=A0

> =A0 =A0Performing the authorization after the SMTP transaction has fin= ished
> =A0 =A0can cause problems, such as the following: (1) It might be diff= icult
> =A0 =A0to accurately extract the required information from potentially=
> =A0 =A0deceptive headers; (2) legitimate email might fail because the<= br> > =A0 =A0sender's policy had since changed.
>
> [MSK: How is (1) above specific to post-transaction processing? =A0See= ms to me
> it's a problem at the end of DATA as well.]>
> =A0 =A0Generating non-delivery notifications to forg= ed identities that have
> =A0 =A0failed the authorization check is generally abusive and against= the
> =A0 =A0explicit wishes of the identity owner.

I guess this is a bit implementation dependent. =A0In Postfix, the MT= A I'm most
familiar with, all of the information from the SMTP session is still availa= ble
to me through it's policy interface. =A0Meng Wong was also a Postfix us= er, IIRC,
so this wording may be too implementation specific and need to be generaliz= ed.
I'd appreciate help on text.

Just change "= ;after the SMTP transaction has finished" to "other than using th= e return-path and client address at the time of the MAIL command during the= SMTP session", and I'd be happy.
=A0

> [MSK: I think we should say more here. =A0For example, how exactly is = it
> abusive? =A0The recipient has done exactly what it was asked to do, ye= t it's
> abusing someone? =A0Rather than saying it's abusive, I suggest we = say it
> introduces backscatter, and then define that term.]

Makes sense. =A0If someone can suggest a definition or a reference fo= r a
definition (even better), I would appreciate it.

R= FC3834 comes closest, I think.=A0 Section 2, especially.

=A0

> 2.5.1. =A0None
>
> =A0 =A0A result of "none" means that no records were publish= ed by the domain
> =A0 =A0or that no checkable sender domain could be determined from the= given
> =A0 =A0identity. =A0The checking software cannot ascertain whether or = not the
> =A0 =A0client host is authorized.
>
> [MSK: s/means that/means/, s/or that/or/]
>
> [MSK: What constitutes "checkable"?]

It means a domain could not be extracted to be used in check_host()
(CheckHost). =A0The two possible conditions are "couldn't figure o= ut what domain
to query for a TXT record" and "queried for a record, got no DNS = errror, and
did not get an SPF record back (could have gotten other TXT records." = =A0It
would be good if someone could suggest a clearer way to put this.

A result of "none" means either (a) no syntactica= lly valid DNS domain name was extracted from the SMTP session that could be= used as the one to be authorized, or (b) no TXT records were retrieved fro= m the DNS that appeared to be intended for use by SPF verifiers.



> 2.5.4. =A0Fail
>
> =A0 =A0A "fail" result is an explicit statement that the cli= ent is not
> =A0 =A0authorized to use the domain in the given identity. =A0The chec= king
> =A0 =A0software can choose to mark the mail based on this or to reject= the
> =A0 =A0mail outright.
>
> [MSK: We should probably give a sentence somewhere above this about wh= at's
> meant by "mark the mail". =A0Maybe even a small section abou= t possible "fail"
> actions that underscores the fact that rejection vs. marking is a choi= ce
> and neither is specifically required would be a good idea.]>

I think change the second sentence to something like "Dispositio= n of SPF fail
messages is a matter of local policy. =A0See [new part of section 9] for considerations on developing local policy." Then we'd add what you= 're
suggesting to section 9. =A0That makes it very clear that the mark/reject decision is up to the receiver and not a normative part of the protocol.

That sounds much better.=A0 I'll wait to see wha= t you develop there.
=A0


> =A0 =A0example, the recipient's Mail User Agent (MUA) could highli= ght the
> =A0 =A0"softfail" status, or the receiving MTA could give th= e sender a
> =A0 =A0message using greylisting, [RFC6647], with a note the first tim= e the
> =A0 =A0message is received, but accept it on a later attempt based on<= br> > =A0 =A0receiver policy.
>
> [MSK: Are there any implementations that do this?]

Yes. =A0Tumgreyspf can do this. =A0It's a blended SPF/Grey listing appl= ication.

Hmm.=A0 It sounds complicated.=A0 Althoug= h it's possible and legal, does it add anything here to call it out as = an example?=A0 I'm pushing for simplicity here.
=A0

> 2.5.6. =A0TempError
>
> =A0 =A0A "temperror" result means that the SPF client encoun= tered a
> =A0 =A0transient error while performing the check. =A0Checking softwar= e can
> =A0 =A0choose to accept or temporarily reject the message. =A0If the m= essage
> =A0 =A0is rejected during the SMTP transaction for this reason, the so= ftware
> =A0 =A0SHOULD use an SMTP reply code of 451 and, if supported, the 4.4= .3
> =A0 =A0enhanced status code.
>
> [MSK: Do we really need to spell out SMTP reply codes and enhanced sta= tus
> codes? =A0Isn't it enough to say those codes are defined in RFC532= 1 and
> RFC3463, and leave it at that?]

I think we should. =A0There was an erratum about one of them being mi= ssing and
it would be odd to resolve that erratum by removing them all. =A0Additional= ly,
I'm not sure it's 100% obvious. =A0When we were reviewing that erra= tum, we
discovered RFC 4408 got one of them wrong. =A0I think there is an
interoperability point here about consistency that it's worth not remov= ing
text for.

What do others think?=A0 I always prefer= to refer to other protocols (or specific parts of them) rather than copyin= g details from them.
=A0

> =A0 =A0are, and are not, authorized to use a domain name for the "= ;HELO" and
> =A0 =A0"MAIL FROM" identities. =A0Loosely, the record partit= ions all hosts
> =A0 =A0into permitted and not-permitted sets (though= some hosts might fall
> =A0 =A0into neither category).
>
> [MSK: That sounds confusing. =A0How is that possible?]

Pass =3D permitted and Fail =3D not permitted. =A0The none, neutral, = softfail,
permerror, and temperror results are variants of "I don't know&quo= t;. =A0I don't know
are the ones that are in neither category. =A0I'd appreciate someone pr= oviding
recommended text to make this clearer.

You don'= ;t need to.=A0 I originally read "neither" as "either".= =A0 It's fine the way it is.
=A0

> [MSK: As I found in the experiment survey, there are some domains that= have
> as many as 37 records at the domain level. =A0We might want to include= any
> other permanent references we can find that establish other TXT record= s
> published at the domain level that might interfere with these guidelin= es.]

If someone want to look into gathering a list, I don't object, but I= 9;m not
sure of the value. =A0Many/most uses are not standardized, so whatever we d= o
will be guaranteed to be substantially incomplete. =A0I'm not sure what= benefit a
partial list would do.

The point of this would be = to encourage implementers to harden their code against receiving TXT record= s that have nothing to do with SPF.=A0 As an opposite example of sorts, ADS= P, DKIM, VBR, and various other protocols have all had to be hardened again= st the notion of asking for one of their own TXT records and getting back a= n SPF record because of the use of DNS wildcards since SPF pre-dates them.= =A0 DMARC will have to do this too.

We could reference those as examples of other protocols that use DNS TX= T records, and due to wildcarding, an SPF implementation needs to anticipat= e getting data it doesn't expect.=A0 In practice this is far less likel= y than the opposite, but who knows what the future will yield.
=A0

> 4. =A0The check_host() Function
>
> [MSK: I'm reading this on the assumption that "check_host()&q= uot; is replaced by
> "CheckHost". =A0Let's see if that works.]

FWIW, I see what you're going after here and I think it 'works'= , but I don't
think we should change it. =A0It's a distinction without a difference a= nd the
existence of references to both check_host() and CheckHost is documentation=
would be confusing. =A0I'm not worried about references withing 4408bis= , but in
other documents.

I commented on this above already= .=A0 This was just one example of dealing with the concern.=A0 There might = be something much simpler we can do.
=A0

> 4.3. =A0Initial Processing
>
> =A0 =A0If the <domain> is malformed (label longer than 63 charac= ters, zero-
> =A0 =A0length label not at the end, etc.) or is not a fully qualified = domain
> =A0 =A0name, or if the DNS lookup returns "domain does not exist&= quot; (RCODE 3),
> =A0 =A0check_host() immediately returns the result "none". >
> [MSK: I suggest <domain> be defined in terms of whatever a legal= domain name
> is in [RFC5321], as amended by EAI, and further require that it be
> fully-qualified. =A0In terms of I18N, we should just do what DKIM did = to
> handle this case.]

What did "DKIM do"?

I'm referring to= Section 3.5 of RFC6376, the definition of "d=3D".
=A0
> =A0 =A0Note that records SHOULD always use either a "redirect&quo= t; modifier or
> =A0 =A0an "all" mechanism to explicitly terminate processing= .
>
> [MSK: So there's a default, but people SHOULD NOT rely on it? =A0T= hat seems
> awkward.]

SPF records are read by humans in addition to computers and they are often<= br> confused about this feature of the protocol. =A0There is an implicit result= ,
but, as the "Zen of Python" says, "Explicit is better than i= mplicit." =A0The
default result is fine for the silicon based computers that read SPF record= s,
but the carbon based ones do better if one specifies it.

We should say at the end "Although the latter is the default (s= pecifically "?all"), it aids debugging efforts if it is explicitl= y included."
=A0
(At least, I think it's "?all", but whatever it is sho= uld go there.)


> =A0 =A0For several mechanisms, the <domain-spec> is optional. = =A0If it is not
> =A0 =A0provided, the <domain> is used as the <target-name>= .
>
> [MSK: How are <domain-spec> and <domain> different? =A0Do = we need them both?]

Domain-spec is a defined ABNF term. =A0Domain isn't. =A0It's one of= the input
arguments to check_host()/CheckHost defined in section 4.1. =A0In the case = of an
SPF record like:

example.com In TXT &qu= ot;v=3Dspf1 a:mail.ex= ample.com -all"

the domain is example.com<= /a>, an input value applicable to the entire evaluation
(see redirect=3D for a limited exception to this) while domain-spec is a property associated with a particular mechanism or modifer.

I think they are distinct enough that we ought not try and combine them.

> =A0 =A0If no CIDR-length is given in the directive, then <ip> an= d the IP
> =A0 =A0address are compared for equality. =A0(Here, CIDR is Classless = Inter-
> =A0 =A0Domain Routing.)
>
> [MSK: Provide a reference to the definition of CIDR, and make sure
> "CIDR-length" is defined there or use the term that document= uses.]>
> =A0 =A0If a CIDR-length is specified, then only the specified number o= f
> =A0 =A0high-order bits of <ip> and the IP address are compared f= or equality.

If someone knows/would look up the reference, I'd appreciate it.

RFC4632 is the current reference, but alas it contains n= o ABNF.
=A0
> =A0 =A0Mechanisms after "all" will never be tested. =A0Any &= quot;redirect" modifier
> =A0 =A0(Section 6.1) has no effect when there is an "all" me= chanism.
>
> [MSK: Unless it appears before "all", right?]

I'm not sure how well it's defined, but the spec at least hints in = more than
one place (and this is one of them) that modifiers are processed after
mechanisms. =A0I believe that's the original intent and we ought to cla= rify
things to explicitly say so.

I think that needs to= be stated explicitly someplace, maybe an "overall flow of the evaluat= ion process" paragraph or something before it gets too detailed.
=A0
> =A0 =A0In hindsight, the name "include" was poorly chosen. = =A0Only the
> =A0 =A0evaluated result of the referenced SPF record is used, rather t= han
> =A0 =A0acting as if the referenced SPF record was literally included i= n the
> =A0 =A0first. =A0For example, evaluating a "-all" directive = in the referenced
> =A0 =A0record does not terminate the overall processing and does not > =A0 =A0necessarily result in an overall "fail". =A0(Better n= ames for this
> =A0 =A0mechanism would have been "if-pass", "on-pass&qu= ot;, etc.)
>
> [MSK: Interesting. =A0Should we make a new name for it, synonymous wit= h
> "include", to facilitate introduction of a new name in a fut= ure version?]

I don't see how we can do that without running into transition problems= . =A0You
can't publish both the new/old name as the new name would cause an erro= r on
existing implementations, so it couldn't be deployed as part of SPF v 1= .
This is one of the changes (like combining a/ip4/ip6) that would be good to=
consider in a future update that is free to worry less about backward
compatibliilty.

I hadn't thought of a/ip4/ip6.= =A0 This makes me think a short appendix about "notes for future revis= ions to SPF" or such might be a good idea.
=A0

> =A0 =A0The "include" mechanism is intended for crossing admi= nistrative
> =A0 =A0boundaries. =A0Although it is possible to use includes to conso= lidate
> =A0 =A0multiple domains that share the same set of designated hosts, d= omains
> =A0 =A0are encouraged to use redirects where possible, and to minimize= the
> =A0 =A0number of includes within a single administrative domain. =A0Fo= r
> =A0 =A0example, if ex= ample.com and example.= org were managed by the same
> =A0 =A0entity, and if the permitted set of hosts for both domains was<= br> > =A0 =A0"mx:examp= le.com", it would be possible for example.org to specify
> =A0 =A0"include:= example.com", but it would be preferable to specify
> =A0 =A0"redirect=3Dexample.com" or even "mx:example.com".
>
> [MSK: I get that it's preferable, but I don't see why. =A0What= difference does
> it make?]

It's a question of how the records expand and what results you get.

example.com IN TXT &qu= ot;v=3Dspf1 include: another.example.net ?all"
example.com IN A 192.0= .2.1
another.example.ne= t IN TXT "v=3Dspf1 a -all"
another.example.ne= t IN A 192.0.2.200

This will match for mail from 192.0.2.200 since the domain used in the
evaluation of anot= her.example.net's SPF record is another.example.net. =A0The
result for mail from any other IP address is Neutral because include with j= ust
match/notmatch and the original SPF record's "all" mechanism = is what controls
the result if nothing matches.

With include you are specifying you want another domain's authorized ho= sts to
be authorized for your domain, but you still want to control the sender pol= icy
from this one (what result to give for things that don't match).

Similarly, consider:

example.com IN TXT &qu= ot;v=3Dspf1 redirect=3Danother.example.net"
example.com IN A 192.0= .2.1
another.example.ne= t IN TXT "v=3Dspf1 a -all"
another.example.ne= t IN A 192.0.2.200

In this case, mail from 192.0.2.1 matches the record since the check_host expansion is done using the orignal domain name, not the domain-spec of the=
redirect modifier. =A0The result is fail is the mail doesn't match.

Redirect is much more like a common code element to be shared among records= in
a single ADMD. =A0You could control both authorized hosts and policy for an=
arbitrary number of domains from a single record.

= Your example is a lot more illustrative than the paragraph I cited.=A0 Perh= aps a briefer summary of the difference would be helpful.=A0 The concept th= at speaks to me as a coder is something like "redirect never returns&q= uot;.=A0 For example, in C, if you do this:

status =3D foo();
return status;

You have the choice to use t= he return value from foo() as it does, or to insert code before the "r= eturn" to do your own thing and eventually return your own result (whi= ch "include" does), while:

return foo();

This executes foo() and its return value is the re= turn value of the caller with no opportunity to do something different (whi= ch "redirect" does).


>
> 5.5. =A0"ptr" (deprecated)
>
> [MSK: Wouldn't it be easier to drop this section?]

It's in use. =A0We can't drop it, only discourage it harder.

I would remove it to an appendix or something if we don&= #39;t intend for it to be part of the live protocol.

But this is ano= ther example of the question, which I think is still being discussed, about= whether it's appropriate to remove or at least deprecate things.=A0 Th= e same survey that started the other argument finds 93 domains using "= ptr" out of over 150,000 reporting.=A0 If it's okay do deprecate p= tr, then it's okay to deprecate macros.=A0 And if it's deprecated a= nd moving from Experimental to Proposed Standard, I think this is a serious= consideration.
=A0
> =A0 =A0Check all validated domain names to see if they end in the
> =A0 =A0<target-name> domain. =A0If any do, this mechanism matche= s. =A0If no
>
> [MSK: So if xebay.com is validated, and <target-name> is ebay.com, the
> mechanism matches? =A0Surely not, but it illustrates that the definiti= on of
> this is weak.]>

That's meant to be limited to subdomain matches. =A0We should improve t= he
language.

Something about a "right-to-left la= bel-for-label subset match" might do.
=A0

> 5.6. =A0"ip4" and "ip6"
>
> =A0 =A0These mechanisms test whether <ip> is contained within a = given IP
> =A0 =A0network.
>
> =A0 =A0IP4 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D "ip4" =A0 =A0 =A0&= quot;:" ip4-network =A0 [ ip4-cidr-length ]
> =A0 =A0IP6 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D "ip6" =A0 =A0 =A0&= quot;:" ip6-network =A0 [ ip6-cidr-length ]
>
> =A0 =A0ip4-cidr-length =A0=3D "/" 1*DIGIT
> =A0 =A0ip6-cidr-length =A0=3D "/" 1*DIGIT
> =A0 =A0dual-cidr-length =3D [ ip4-cidr-length ] [ "/" ip6-ci= dr-length ]
>
> [MSK: Can't this be simplified to just a "cidr-length", = and the above three
> dropped? =A0Really the only difference is that ip4-cidr-length can'= ;t be more
> than 32 and ip6-cidr-length can't be more than 128. =A0So either s= ay that in
> an ABNF comment for each (and you could make the former be 1*2DIGIT an= d the
> latter 1*3DIGIT), or simplify.]>

Would that still allow one to use a:example.com/30/64? =A0That's legit now for
dual homed IPv4/6 hosts.

My survey found zero dual= -cidr-lengths in use.
=A0

> =A0 =A0ip4-network =A0 =A0 =A0=3D qnum "." qnum "."= ; qnum "." qnum
> =A0 =A0qnum =A0 =A0 =A0 =A0 =A0 =A0 =3D DIGIT =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 ; 0-9
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / %x31-39 DIGIT =A0 =A0 = =A0 ; 10-99
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "1" 2DIGIT =A0= =A0 =A0 =A0 =A0; 100-199
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "2" %x30-34 DI= GIT =A0 ; 200-249
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "25" %x30-35 = =A0 =A0 =A0 =A0; 250-255
>
> =A0 =A0 =A0 =A0 =A0 =A0 ; as per conventional dotted quad notation. = =A0e.g., 192.0.2.0
>
> [MSK: Is there really not a reference for this syntax?]

There probably is, but we didn't find it in 2005. =A0If someone can dig= it up,
I'll add it.

I actually can't find one eit= her.=A0 Pete or Dave, perhaps?
=A0
> 7. =A0The Received-SPF Header Field
>
> [MSK: This should be updated as agreed (I think) to say implementation= s
> SHOULD generate A-R and MUST NOT generate this, while they SHOULD be a= ble
> to parse this.]>

We argued about this. =A0I agree that Section 7 should cover both Received = SPF
and Authentication Results. =A0I think it should also described how to crea= te an
Authentication Results header that has all the information found in a Recei= ved
SPF header.

I don't believe that there is an Internet interoperability point in pre= ferring
one over the other. =A0These are generated and consumed within an ADMD and = so
within that ADMD, they should use whichever works for them. =A0On that basi= s, I
think it's reasonable to encourage adoption of Authentication Results b= y
software developers so that ADMD administrators can choose.

Sounds good to me.
=A0

>
> =A0 =A0key-value-pair =A0 =3D key [CFWS] "=3D" ( dot-atom / = quoted-string )
>
> =A0 =A0key =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D "client-ip" / &quo= t;envelope-from" / "helo" /
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "problem" / &quo= t;receiver" / "identity" /
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mechanism / name
>
> =A0 =A0identity =A0 =A0 =A0 =A0 =3D "mailfrom" =A0 ; for the= "MAIL FROM" identity
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "helo" =A0 =A0= ; for the "HELO" identity
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / name =A0 =A0 =A0 ; other= identities
>
> [MSK: Should "identity" be quoted in the "key" lis= t?]
>
> [MSK: There are two paths to "key" generating "name&quo= t;: one direct, one
> through "identity"]>

Is this a problem?

I thought it was considered an = ambiguous grammar in that case, and thus "improper".

You s= hould run this through a BNF checker too just to see if any bugs are found.= =A0 There's one on tools.ietf.org= someplace.
=A0

> =A0 =A0"MAIL FROM" identity was checked, "envelope-from= ".
>
> =A0 =A0client-ip =A0 =A0 =A0the IP address of the SMTP client
>
> =A0 =A0envelope-from =A0the envelope sender mailbox
>
> [MSK: Suggest "the RFC5321.MailFrom address" or simply "= ;the return-path"]

There's a section at the beginning where we cover all the different nam= es for
mail from. =A0We ought to use this terminology from there on.

Yeah, using one throughout would be ideal.
=A0


> =A0 =A0macro-expand =A0 =A0 =3D ( "%{" macro-letter transfor= mers *delimiter "}" )
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "%%" / "%= _" / "%-"
>
> [MSK: The "*delimiter" allows this: %{s.-+,/_=3D.+,..+.} =A0= What would that
> mean?]>

Good question. =A0It's almost 1AM, so I'm not even going to try and= figure that
one out right now. =A0What does it mean?

My point = is that the grammar allows it, and I'm not certain we want that.=A0 Wha= t's the point of allowing lots of delimiters?=A0 How would one apply mo= re than one?
=A0

> =A0 =A0 =A0 p =3D the validated domain name of <ip> (deprecated)=
>
> [MSK: This makes me think we need to say somewhere what it means for t= his to
> be deprecated. =A0When verifiers see it, for example, what should they= do?]>

Deprecated is defined early in the draft.

So it do= es; withdrawn.



> =A0 =A0By default, strings are split on "." (dots). =A0Note = that no special
> =A0 =A0treatment is given to leading, trailing, or consecutive delimit= ers,
>
> [MSK: In input strings, right?]

Yes.

So if the "delimiter" part of the A= BNF is "+.", what does a parser do?=A0 Break on +, then within th= ose break on .?=A0 Break on either (like strtok() does)?
=A0

>
> =A0 =A0Macros MAY specify delimiter characters that are used instead o= f ".".
>
> [MSK: Isn't this redundant to the ABNF?]

Yes, but so is a lot of the text.

I guess I'd = like to keep that to a minimum.
=A0

> =A0 =A0The "p" macro expands to the validated domain name of= <ip>. =A0The
> =A0 =A0procedure for finding the validated domain name is defined in > =A0 =A0Section 5.5. =A0If the <domain> is present in the list of= validated
> =A0 =A0domains, it SHOULD be used. =A0Otherwise, if a subdomain of the=
> =A0 =A0<domain> is present, it SHOULD be used. =A0Otherwise, any= name from the
> =A0 =A0list MAY be used. =A0If there are no validated domain names or = if a DNS
> =A0 =A0error occurs, the string "unknown" is used. =A0This m= acro is deprecated
> =A0 =A0and SHOULD NOT be used.
>
> [MSK: There's probably not a better algorithm, but it's uncomf= ortable having
> the "any name" part, because two evaluations of the same nam= e could yield
> different expansions.]>

Multiple PTR names and how that can get confused are part of why this was considered unreliable and why I think deprecation is a good idea.

Let's add a sentence in there to this effect then.
= =A0

> =A0 =A0The "t" macro expands to the decimal representation o= f the
> =A0 =A0approximate number of seconds since the Epoch (Midnight, Januar= y 1,
> =A0 =A01970, UTC). =A0This is the same value as is returned by the POS= IX
> =A0 =A0time() function in most standards-compliant libraries.
>
> [MSK: =A0When? =A0At time of evaluation? =A0At time of message receipt= ? =A0Some
> other time?]>

At evaluation. =A0It has to be.

Let's add that= clause.
=A0
> 9.3. =A0Mail Services
>
> =A0 =A0MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offe= r mail
> =A0 =A0services to third-party domains, such as sending of bulk mail, = might
> =A0 =A0want to adjust their setup in light of the authorization check<= br>
> [MSK: I'm getting wary of the use of "domain" now, and i= n retrospect I
> should've been looking at this throughout the document. =A0DNSDIR = has been
> known to get cranky about the use of that word when the specific conte= xt
> isn't clear. =A0Did you mean ADMD here, or DNS domain name, for ex= ample?]>

I can make this one clearer. =A0If there are others, let's address them= .

That was the first one that got my attention.=A0= When you post -04 I'll do a quick pass looking for that word and see i= f I can spot any that need massaging.
=A0

>
> =A0 =A0at least 20 seconds. =A0If such a limit is exceeded, the result= of
> =A0 =A0authorization SHOULD be "temperror".
>
> [MSK: Where are we these days on normative language in Security
> Considerations? =A0I thought we currently didn't like it.]

So did I, but I got pushback when I tried to move it up into section 4. =A0= I
think it does fit rather better there.

Pete or Bar= ry?
=A0

> =A0 =A0(Section 6.2), were generated by the sender policy published by= the
> =A0 =A0domain holders themselves. =A0As long as messages are only retu= rned
> =A0 =A0with non-delivery notification to domains publishing the explan= ation
> =A0 =A0strings from their own DNS SPF records, the only affected parti= es are
> =A0 =A0the original publishers of the domain's SPF records.
>
> [MSK: Reference for NDNs?]

If someone could provide this, it would be appreciated.

=A0RFC3464, I believe.

-MSK
--f46d0408da07260a8704c4ec968f-- From vesely@tana.it Mon Jul 16 02:30:48 2012 Return-Path: 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 87C2521F86CA for ; Mon, 16 Jul 2012 02:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.625 X-Spam-Level: X-Spam-Status: No, score=-4.625 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 o5wC8W8wgGay for ; Mon, 16 Jul 2012 02:30:47 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9B33A21F8533 for ; Mon, 16 Jul 2012 02:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342431090; bh=0NrJFV98inIdI6xKzw59wJk23Al4UuuEfCBxySkZFU8=; l=1500; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=T+RaXrLMUbFKU3DE0C3X6rUNwCHLHemIbBAzDG5lP7/nAD5KoEsfk9GgI/mOB5zMF Bh/NWskO/7j8do0yjV5GtlI4izQVywSsEASXuWjBqyebjJ1wfC3G8PF3V4zYI32a4h 8k0sFnwol6LJYkmQAGJ40nV/mI2MNyUh3DzGlV0Y= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 16 Jul 2012 11:31:30 +0200 id 00000000005DC048.000000005003DF72.00004D09 Message-ID: <5003DF71.2000803@tana.it> Date: Mon, 16 Jul 2012 11:31:29 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <13841705.Ry8OH4Cp8v@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 09:30:48 -0000 On Mon 16/Jul/2012 08:31:57 +0200 Murray S. Kucherawy wrote: > On Sun, Jul 15, 2012 at 10:07 PM, Scott Kitterman wrote: > >>> Performing the authorization after the SMTP transaction has finished >>> can cause problems, such as the following: (1) It might be difficult >>> to accurately extract the required information from potentially >>> deceptive headers; (2) legitimate email might fail because the >>> sender's policy had since changed. >>> >>> [MSK: How is (1) above specific to post-transaction processing? Seems to me >>> it's a problem at the end of DATA as well.] >>> Generating non-delivery notifications to forged identities that have >>> failed the authorization check is generally abusive and against the >>> explicit wishes of the identity owner. >> >> I guess this is a bit implementation dependent. In Postfix, the MTA I'm most >> familiar with, all of the information from the SMTP session is still available >> to me through it's policy interface. Meng Wong was also a Postfix user, IIRC, >> so this wording may be too implementation specific and need to be generalized. >> I'd appreciate help on text. > > Just change "after the SMTP transaction has finished" to "other than > using the return-path and client address at the time of the MAIL > command during the SMTP session", and I'd be happy. +1, except that "transaction" seems to be a better term than "session". A client can issue multiple MAIL commands in the same session. From ajs@anvilwalrusden.com Mon Jul 16 03:57:20 2012 Return-Path: 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 A506421F8797 for ; Mon, 16 Jul 2012 03:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 LAoiVfP5HOdv for ; Mon, 16 Jul 2012 03:57:20 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3F43D21F8795 for ; Mon, 16 Jul 2012 03:57:20 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id BEDF98A031 for ; Mon, 16 Jul 2012 10:58:03 +0000 (UTC) Date: Mon, 16 Jul 2012 06:58:06 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120716105805.GB96149@mail.yitter.info> References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120713200317.GA55459@verdi> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 10:57:20 -0000 Hat on. On Fri, Jul 13, 2012 at 04:03:17PM -0400, John Leslie wrote: > "Deprecate" feels right to me. Please understand, "deprecate" means > " > " senders SHOULD NOT publish SPF records that make use of the feature > " in question. Its use is NOT RECOMMENDED and it might be removed entirely > " in future updates to the protocol. Such features do, however, remain > " part of the SPF protocol and receiving systems MUST support them unless > " this specification says otherwise. We have positive evidence, in the form of published records with local-part macros in them, that people are using this feature or at least think they are. Given that is the case, it seems to me that we have a process issue here. I'd like those who support deprecation or removal of the feature to explain how their proposed action is consistent with the charter we have. Dave Crocker has already offered his view, which is (to oversimplify) that "unused" has a meaning slightly different from its plain English meaning, and that local-part macros can therefore be removed. What about the case for deprecation? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Mon Jul 16 06:33:41 2012 Return-Path: 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 A683621F8823 for ; Mon, 16 Jul 2012 06:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599] 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 tVdtzszASNFk for ; Mon, 16 Jul 2012 06:33:40 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2AC21F8822 for ; Mon, 16 Jul 2012 06:33:40 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2CDB920E40BD; Mon, 16 Jul 2012 09:34:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342445664; bh=nTimGPrMrWgAnYlJd4lblYEMxJbgGHn1C00w2faLOpU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZUpgt9w+aBMtJ2o9wgtBfEJK8QuBV2m3KZjZc9h5pywL+McoAF5uj8RwNyBXQkDmu 2aFCHUu8NExX8XqPi11pgpMNHCtKHGi9NQtr06e1o5mu2kH8zNwLv801fVUjNLvSfo R0p9/Cr3y1HXabDmECbYl8sVdrfVQPJGfMHbDhms= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0E2D420E409C; Mon, 16 Jul 2012 09:34:23 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 16 Jul 2012 09:34:22 -0400 Message-ID: <3012340.J63oamIix1@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120716105805.GB96149@mail.yitter.info> References: <20120712022051.60587.qmail@joyce.lan> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 13:33:41 -0000 On Monday, July 16, 2012 06:58:06 AM Andrew Sullivan wrote: > Hat on. > > On Fri, Jul 13, 2012 at 04:03:17PM -0400, John Leslie wrote: > > "Deprecate" feels right to me. Please understand, "deprecate" means > > > > " > > " senders SHOULD NOT publish SPF records that make use of the feature > > " in question. Its use is NOT RECOMMENDED and it might be removed entirely > > " in future updates to the protocol. Such features do, however, remain > > " part of the SPF protocol and receiving systems MUST support them unless > > " this specification says otherwise. > > We have positive evidence, in the form of published records with > local-part macros in them, that people are using this feature or at > least think they are. > > Given that is the case, it seems to me that we have a process issue > here. I'd like those who support deprecation or removal of the > feature to explain how their proposed action is consistent with the > charter we have. Dave Crocker has already offered his view, which is > (to oversimplify) that "unused" has a meaning slightly different from > its plain English meaning, and that local-part macros can therefore be > removed. What about the case for deprecation? I think I started the idea of deprecation with PTR, so I'll explain my thinking and how I think it's consistent with the charter. PTR is unnecessary. If we'd known better in 2005, I think we'd have dropped it. There are, as far as I'm aware, always better ways to construct an SPF record that don't use PTR. It's slow and unreliable for a variety of reasons I won't repeat here. Consistent with the charter, we cannot, however much I would like to, remove it now. It is in broad use and no matter who's definition of in use one selects, it's in use. To me 'deprecated' means that for now it's still an official part of the protocol, but you should migrate away from it because it might be removed in the future. It's a way to stay compatible with existing records and the charter, but provide a path to eventual removal (no idea if that would ever actually happen without bumping the SPF version number and no need to decide now). Given all that, I think making something deprecated is consistent with the charter. So far, in my opinion, we've identified some slight theoretical disadvantages for macros in general, slightly more for the ones that can't be cached, and yet again slightly more for the local-part macro. I don't see a good case for deprecating these, but I think it's within the working group's purview to make that decision. Scott K From spf2@kitterman.com Mon Jul 16 06:41:41 2012 Return-Path: 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 1B32D21F8855 for ; Mon, 16 Jul 2012 06:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599] 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 KW3RXIEcIjR3 for ; Mon, 16 Jul 2012 06:41:39 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A96EB21F8852 for ; Mon, 16 Jul 2012 06:41:39 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 240FB20E40BD; Mon, 16 Jul 2012 09:42:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342446144; bh=kG5YqXMpc1wkozV2+ikDnwJoPnVjqwHuDriYz7Qh+NA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QxkVQM5SeHggxVNvWM7xcasNhkHZHLYM6tjeRVHrA6p5E8RJ98vlKxyeYxTv7zhK9 0uum4AlyQky/RKa3Zkn1Vdnq5mYk0AEhJBY+M+p5IdsBg2y9nb7kRbybaxR1mgjvkC +8tk1lHuLaXJnbXyQVzogk+xkF2mTKNjlEW3WVSo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 061F520E409C; Mon, 16 Jul 2012 09:42:23 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 16 Jul 2012 09:42:23 -0400 Message-ID: <1531354.CvHIYLHnSo@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50024D85.5030104@mail-abuse.org> References: <20120713212718.35051.qmail@joyce.lan> <3042871.nWlL1OK6Yn@scott-latitude-e6320> <50024D85.5030104@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 13:41:41 -0000 On Saturday, July 14, 2012 09:56:37 PM Douglas Otis wrote: > On 7/13/12 2:36 PM, Scott Kitterman wrote: > > On Friday, July 13, 2012 09:27:18 PM John Levine wrote: > >>> Fortunately, the situation is different now. You can go to > >>> http://www.openspf.org/Test_Suite and get a copy of a > >>> comprehensive test suite that is believed to cover all the RFC > >>> 4408 requirements. > >> > >> I took a look. With respect to macros, it has one test called > >> dorky-sentinel with a space in a local part, although it's not > >> obvious to me what the correct answer is supposed to be, one > >> called upper-macro that tests that upper cased macros do percent > >> encoding, and invalid-domain-long-via-macro which checks for a > >> macro expansion that creates an excessively long domain name. > >> There's also a bunch of other tests that check that macros do what > >> they're supposed to with normal input. > >> > >> Other than the one about the space, I don't see any tests for what > >> happens if the text being expanded contains unexpected hostile > >> characters. > > > > Should be easy enough to add. What would you consider hostile? > > Dear Scott, > > Since SMTPUTF8 permits UTF-8 mail-parameters that may affect either the > local-part or the domain of email-addresses, it seems unlikely adequate > test coverage will be found based on older specifications that expected > mail parameters were limited to US-ASCII. This is no longer an SMTP > constraint based upon the standards track RFC6530 extending both RFC5321 > and RFC5322. > > Use of SPF records to filter local-part values independent of the domain > is an expensive operation for receivers that may negatively impact their > DNS cache or other third-parties whenever a component of the local-part > constructs domains that may not appear in the email-address or anywhere > in the email. A static local-part minimizes the impact of macro > expansions, especially since no limit is imposed on the number of > no-domain errors that might be generated. > > A simple macro expansion of a local-part label can direct an unlimited > number of DNS queries against any third-party domain derived from a > single cached SPF record. Simple deprecation of the local-part macro > expansion guards against a potential form of reflected and amplified > abuse where a pass result is possible subsequent to as many as 100 > random sub-domain queries against any uninvolved third-party that may > not be evident anywhere in the email. > > Page 9: > > Was: > > Implementations must take care to correctly extract the from > the data given with the SMTP MAIL FROM command as many MTAs will > still accept such things as source routes (see [RFC5321], Appendix > C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). > These archaic features have been maliciously used to bypass security > systems. > > > Change to: > > The EHLO/HELO parameter must use A-Label encoding. However that may > not be true for the mail parameter. Implementations must take care to > correctly extract the from the data given with the SMTP MAIL > command as many MTAs will still accept such things as source routes (see > [RFC5321], Appendix C), the %-hack (see [RFC1123]), and bang paths (see > [RFC1983]). These archaic features have been maliciously used to bypass > security systems. > > There should be some combination of routines available to ensure UTF-8 > parameters do not use illegal code-points. One method might use > UTF-8(a) -> A-Label(a) conversion strategies that may not include > assurances against illegal code-points. Confirmation that A-Label(a) -> > UTF-8(b) provides the same string as UTF-8(a) should offer assurances > against illegal code points without any additional routines. > Elimination of illegal code-points is required to guard against visually > deceptive strings. > > The domain portion of a UTF-8 encoded email address should be converted > to an A-Label form using a method that ensures against illegal > code-points, only the A-Label version of the domain should be passed to > the SPF library. Otherwise, results will be undefined. > > Dealing with the local-part of a UTF-8 encoded email-address is > problematic. One solution could replace the local-part with the value > "postmaster" defined in Section 2.2 and 4.3. If there is a library in > use that has not deprecated the operation of the '%l' macro, a simple > string replacement still offers predictable results. Ideally, any > record that includes '%l' macro should return the result "none". > > Page 10: > > Was: > A result of "none" means that no records were published by the domain > or that no checkable sender domain could be determined from the given > identity. The checking software cannot ascertain whether or not the > client host is authorized. > > Change to: > A result of "none" means that no records were published by the domain > or that no checkable sender domain could be determined from the given > identity. The checking software cannot ascertain whether or not the > client host is authorized. Use of a deprecated local-part macro > should return the result of "none" or alternatively checked > against the identity where local-part is replaced by the string > "postmaster". > > > Page 27: > > Was: > Note: In general, the domain "A" cannot reliably use a redirect to > another domain "B" not under the same administrative control. Since > the stays the same, there is no guarantee that the record at > domain "B" will correctly work for mailboxes in domain "A", > especially if domain "B" uses mechanisms involving localparts. An > "include" directive is generally be more appropriate. > > Change to: > Note: In general, the domain "A" cannot reliably use a redirect to > another domain "B" not under the same administrative control. Since > the stays the same, there is no guarantee that the record at > domain "B" will correctly work for mailboxes in domain "A". An > "include" directive is generally more appropriate. > > Page 31: > > Was: > l = local-part of > > Change to: > Deprecated l = local-part of > > Page 32: > > Was: > The "l" macro expands to just the localpart. > > Change to: > The "l" macro is deprecated and may not expand to components of the > local-part. > > > Page 37: > > Was: > 2. The "MAIL FROM" identity could have additional information in > the localpart that cryptographically identifies the mail as > coming from an authorized source. In this case, such an SPF > record could be used: > > "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" > > Then, a specialized DNS server can be set up to serve the > _spf_verify subdomain that validates the localpart. Although > this requires an extra DNS lookup, this happens only when the > email would otherwise be rejected as not coming from a known > good source. > Note that due to the 63-character limit for domain labels, > this approach only works reliably if the localpart signature > scheme is guaranteed either to only produce localparts with a > maximum of 63 characters or to gracefully handle truncated > localparts. > > > Change to: > > Use of DNS resource records to individually validate an entire > population of a domain's users is detrimental to the operation of DNS, > and inappropriately burdens receiving domains. Domain-wide > verifications should be used instead, such as DKIM for example. You are using deprecated in a way different than the one I've defined in the current draft. My use of deprecated is "works as before, but stop using, it may go away in the future". Yours is "ignore it, but don't raise an error." The former is backwards compatible and consistent with the charter. The latter is not on either point. Last I checked, the chairs had ruled removing macros out of scope, so I'm going to hold your suggestions for text until that discussion plays out. Scott K From john@jlc.net Mon Jul 16 06:55:24 2012 Return-Path: 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 217B821F87E0 for ; Mon, 16 Jul 2012 06:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.426 X-Spam-Level: X-Spam-Status: No, score=-105.426 tagged_above=-999 required=5 tests=[AWL=1.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 yBUZpS3h5CKl for ; Mon, 16 Jul 2012 06:55:23 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AE08E21F8855 for ; Mon, 16 Jul 2012 06:55:22 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 545AA33C2A; Mon, 16 Jul 2012 09:56:07 -0400 (EDT) Date: Mon, 16 Jul 2012 09:56:07 -0400 From: John Leslie To: Andrew Sullivan Message-ID: <20120716135607.GD55459@verdi> References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120716105805.GB96149@mail.yitter.info> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 13:55:24 -0000 Andrew Sullivan wrote: > > Hat on. > > On Fri, Jul 13, 2012 at 04:03:17PM -0400, John Leslie wrote: > >> "Deprecate" feels right to me. Please understand, "deprecate" means >>" >>" senders SHOULD NOT publish SPF records that make use of the feature >>" in question. Its use is NOT RECOMMENDED and it might be removed entirely >>" in future updates to the protocol. Such features do, however, remain >>" part of the SPF protocol and receiving systems MUST support them unless >>" this specification says otherwise. > > We have positive evidence, in the form of published records with > local-part macros in them, that people are using this feature or at > least think they are. > > Given that is the case, it seems to me that we have a process issue > here. I'd like those who support deprecation or removal of the > feature to explain how their proposed action is consistent with the > charter we have. Dave Crocker has already offered his view, which is > (to oversimplify) that "unused" has a meaning slightly different from > its plain English meaning, and that local-part macros can therefore be > removed. What about the case for deprecation? Simply, "deprecate" is not "remove". From the charter: " " Specifically out-of-scope for this working group: " " * Revisiting past technical arguments where consensus was reached in " the MARID working group, except where review is reasonably " warranted based on operational experience. " " * Discussion of the merits of SPF. " " * Discussion of the merits of Sender-ID in preference to SPF. " " * Extensions to the SPF protocols. " " * Removal of existing features that are in current use. " " Discussion of extensions to the SPF protocols or removal of " existing features shall only be discussed after completion of " current charter items in anticipation of rechartering the working " group. The definition of "deprecate" quite clearly states that the feature is not being removed (even if we threaten to do so in the future). We only say "SHOULD not publish," understanding that there may be valid reasons to publish and still claim compliance with this Proposed Standard. Furthermore, in defense of Dave (who certainly doesn't _need_ me defending him!): - "in current use" is not an exact antonym of "unused"; something may be a non-current use and not run afoul of this charter language; - we can never prove the absence of any use whatsoever, so there must be some judgment involved: judging the existence of "current use" (at the time the charter was written) requires more effort than we should reasonably expend. Besides, "deprecate" is not "remove"... -- John Leslie > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From dhc@dcrocker.net Mon Jul 16 06:59:16 2012 Return-Path: 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 D409221F883B for ; Mon, 16 Jul 2012 06:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 jMePa1ULi4Pt for ; Mon, 16 Jul 2012 06:59:16 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 43D2621F8838 for ; Mon, 16 Jul 2012 06:59:16 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6GE00ar001038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Jul 2012 07:00:00 -0700 Message-ID: <50041E53.4070104@dcrocker.net> Date: Mon, 16 Jul 2012 06:59:47 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <20120713212718.35051.qmail@joyce.lan> <3042871.nWlL1OK6Yn@scott-latitude-e6320> <50024D85.5030104@mail-abuse.org> <1531354.CvHIYLHnSo@scott-latitude-e6320> In-Reply-To: <1531354.CvHIYLHnSo@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 16 Jul 2012 07:00:00 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 13:59:17 -0000 On 7/16/2012 6:42 AM, Scott Kitterman wrote: > My use of deprecated is "works as before, but stop using, it > may go away in the future". Yours is "ignore it, but don't raise an error." > > The former is backwards compatible and consistent with the charter. The > latter is not on either point. I believe your intent with 'deprecated' is roughly the same as what was done for RFC 2822 (now RFC 5322) which used the term "obsolete". So it's worth looking at the way it dealt with the matter. (The difference in label isn't interesting to me. Looking at the meaning is.) The text about this in RFC 5322 is: > 3.1. Introduction ... > In some of the definitions, there will be non-terminals whose names > start with "obs-". These "obs-" elements refer to tokens defined in > the obsolete syntax in section 4. In all cases, these productions > are to be ignored for the purposes of generating legal Internet > messages and MUST NOT be used as part of such a message. However, > when interpreting messages, these tokens MUST be honored as part of > the legal syntax. In this sense, section 3 defines a grammar for the > generation of messages, with "obs-" elements that are to be ignored, > while section 4 adds grammar for the interpretation of messages. I read this as meaning: If you are conforming to the latest specification, you must not /generate/ data using these constructs. However you will still receive and correctly process data that was generated using these constructs. I believe the language in RFC 5322 is compatible with the interpretation that Scott has for 'deprecated'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Mon Jul 16 07:29:32 2012 Return-Path: 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 0227011E80E4 for ; Mon, 16 Jul 2012 07:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.603 X-Spam-Level: X-Spam-Status: No, score=-3.603 tagged_above=-999 required=5 tests=[AWL=0.996, BAYES_00=-2.599, GB_I_LETTER=-2] 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 L7q5oIWpdFCS for ; Mon, 16 Jul 2012 07:29:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB3011E80C6 for ; Mon, 16 Jul 2012 07:29:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 84B2520E40BD; Mon, 16 Jul 2012 10:30:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342449012; bh=qftUlJeN6DMSd4RK7dNaum1YhK119vWIXVre4nIgR00=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C1PUdVLDBdIJd1nWEwiwgBCCp3nEfHnhVVP3/wQYYr8GaW4yTJnCkagi2Nz6Vg9El aqT/2NmEuIWQfMsflmohKjji08tpEx6X0bKP1EiJ7UyPY9nwh6p8j/vJwDlNtmAMfV qaYe0bLiZt6JOoDKDFMbYL5qXQxBqCMzcR3SgH1w= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 69A9320E409C; Mon, 16 Jul 2012 10:30:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 16 Jul 2012 10:30:11 -0400 Message-ID: <1991186.y8zxGRhPli@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <13841705.Ry8OH4Cp8v@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:29:32 -0000 On Sunday, July 15, 2012 11:31:57 PM Murray S. Kucherawy wrote: > On Sun, Jul 15, 2012 at 10:07 PM, Scott Kitterman wrote: ... > > > 2.5. Interpreting the Result > > > > > > This section describes how software that performs the authorization > > > should interpret the results of the check_host() function. The > > > authorization check SHOULD be performed during the processing of the > > > SMTP transaction that sends the mail. This allows errors to be > > > returned directly to the sending MTA by way of SMTP replies. > > > > > > [MSK: I have an open ticket in the tracker about check_host(), so I'll > > make > > > my first comment about it here though there will be many more later. > > > The > > > very string "check_host()" looks like a function definition, and as I > > said > > > in the tracker item, the IETF prefers to avoid the business of API > > > definitions. It's possible that I might be able to search-and-replace > > > it > > > into something more palatable. This is just a placeholder comment to > > note > > > that I still think it's an issue and I'm figuring out how to suggest we > > > deal with it.]> > > > > It looks like later you started replacing check_host() with CheckHost. If > > it's just a string replacement like that, I don't object. I don't like > > the > > idea of creating diff for things like this, but as long as there's support > > in > > the group for it, no problem. > > The chatter in Paris suggested simply adding a paragraph before the > definition of check_host() that says emphatically that this is not an API > definition, but rather the mechanism is used to illustrate the algorithm; a > compliant SPF implementation MUST do something semantically equivalent to > what we describe for check_host(). Pete said this was probably > acceptable. It's probably less work than all the s// I did here as well. > We should probably try that approach, in retrospect. OK. I'll take a shot at that in the next revision. Thanks. > > > example, the recipient's Mail User Agent (MUA) could highlight the > > > "softfail" status, or the receiving MTA could give the sender a > > > message using greylisting, [RFC6647], with a note the first time the > > > message is received, but accept it on a later attempt based on > > > receiver policy. > > > > > > [MSK: Are there any implementations that do this?] > > > > Yes. Tumgreyspf can do this. It's a blended SPF/Grey listing > > application. > > Hmm. It sounds complicated. Although it's possible and legal, does it add > anything here to call it out as an example? I'm pushing for simplicity > here. It's an example. Similarly one might use different spam thresholds in post- SMTP content filtering. I'm open for suggestions. This could get a "see section 9 for examples" here and then something new there if people would prefer (seems overkill to me though). OT: Tumgreyspf isn't particularly complex. It is essentially as complex as both SPF and greylisting and due to taking advantage of existing SPF libraries, the amount of SPF related code is pretty small. > > > 2.5.6. TempError > > > > > > A "temperror" result means that the SPF client encountered a > > > transient error while performing the check. Checking software can > > > choose to accept or temporarily reject the message. If the message > > > is rejected during the SMTP transaction for this reason, the software > > > SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 > > > enhanced status code. > > > > > > [MSK: Do we really need to spell out SMTP reply codes and enhanced > > > status > > > codes? Isn't it enough to say those codes are defined in RFC5321 and > > > RFC3463, and leave it at that?] > > > > I think we should. There was an erratum about one of them being missing > > and > > it would be odd to resolve that erratum by removing them all. > > > > Additionally, > > > > I'm not sure it's 100% obvious. When we were reviewing that erratum, we > > discovered RFC 4408 got one of them wrong. I think there is an > > interoperability point here about consistency that it's worth not removing > > text for. > > What do others think? I always prefer to refer to other protocols (or > specific parts of them) rather than copying details from them. This always seemed to me like adding specificity, not mere copying. > > > [MSK: As I found in the experiment survey, there are some domains that > > have > > > as many as 37 records at the domain level. We might want to include any > > > other permanent references we can find that establish other TXT records > > > published at the domain level that might interfere with these > > guidelines.] > > > > If someone want to look into gathering a list, I don't object, but I'm not > > sure of the value. Many/most uses are not standardized, so whatever we do > > will be guaranteed to be substantially incomplete. I'm not sure what > > benefit a > > partial list would do. > > The point of this would be to encourage implementers to harden their code > against receiving TXT records that have nothing to do with SPF. As an > opposite example of sorts, ADSP, DKIM, VBR, and various other protocols > have all had to be hardened against the notion of asking for one of their > own TXT records and getting back an SPF record because of the use of DNS > wildcards since SPF pre-dates them. DMARC will have to do this too. > > We could reference those as examples of other protocols that use DNS TXT > records, and due to wildcarding, an SPF implementation needs to anticipate > getting data it doesn't expect. In practice this is far less likely than > the opposite, but who knows what the future will yield. OK. If it needs to be more explicit, I think that's fine. If someone would provide text, it would be helpful. > > > 4. The check_host() Function > > > > > > [MSK: I'm reading this on the assumption that "check_host()" is replaced > > > > by > > > > > "CheckHost". Let's see if that works.] > > > > FWIW, I see what you're going after here and I think it 'works', but I > > don't > > think we should change it. It's a distinction without a difference and > > the > > existence of references to both check_host() and CheckHost is > > documentation > > would be confusing. I'm not worried about references withing 4408bis, but > > in > > other documents. > > I commented on this above already. This was just one example of dealing > with the concern. There might be something much simpler we can do. > > > > 4.3. Initial Processing > > > > > > If the is malformed (label longer than 63 characters, zero- > > > length label not at the end, etc.) or is not a fully qualified domain > > > name, or if the DNS lookup returns "domain does not exist" (RCODE 3), > > > check_host() immediately returns the result "none". > > > > > > [MSK: I suggest be defined in terms of whatever a legal domain > > > > name > > > > > is in [RFC5321], as amended by EAI, and further require that it be > > > fully-qualified. In terms of I18N, we should just do what DKIM did to > > > handle this case.] > > > > What did "DKIM do"? > > I'm referring to Section 3.5 of RFC6376, the definition of "d=". It says: Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890]. I think that's fine. In a related point, I think we can dispose of the local- part macro/EAI issue similarly. > > > Note that records SHOULD always use either a "redirect" modifier or > > > an "all" mechanism to explicitly terminate processing. > > > > > > [MSK: So there's a default, but people SHOULD NOT rely on it? That > > > seems > > > awkward.] > > > > SPF records are read by humans in addition to computers and they are often > > confused about this feature of the protocol. There is an implicit result, > > but, as the "Zen of Python" says, "Explicit is better than implicit." The > > default result is fine for the silicon based computers that read SPF > > records, > > but the carbon based ones do better if one specifies it. > > We should say at the end "Although the latter is the default (specifically > "?all"), it aids debugging efforts if it is explicitly included." > > (At least, I think it's "?all", but whatever it is should go there.) It is. Agreed. > > > For several mechanisms, the is optional. If it is not > > > provided, the is used as the . > > > > > > [MSK: How are and different? Do we need them > > both?] > > > > Domain-spec is a defined ABNF term. Domain isn't. It's one of the input > > arguments to check_host()/CheckHost defined in section 4.1. In the case > > of an > > SPF record like: > > > > example.com In TXT "v=spf1 a:mail.example.com -all" > > > > the domain is example.com, an input value applicable to the entire > > evaluation > > (see redirect= for a limited exception to this) while domain-spec is a > > property associated with a particular mechanism or modifer. > > > > I think they are distinct enough that we ought not try and combine them. > > OK, then I think the right thing would be to say that they are > syntactically identical, but used in different parts of the evaluation > process. In ABNF, something like this would do: > > domain = > > domain-spec = domain > ; syntactically identical to "domain", but used differently in the > evaluation > > Dave, do you have any other insight here? The current ABNF says: domain-spec = macro-string domain-end So you're proposing changing this to: domain-spec = macro-string domain-end / domain ; syntactically identical to "domain", but ; used differently in the evaluation This doesn't read quite right to me. I think it's actually the other way around: domain-spec = macro-string domain-end / domain domain = domain-spec / "input value" ; either provided as an input for the ; evaluation process or a domain-spec used ; as an input for recursive evaluation As I've said before though ABNF is not my thing, so that might be totally wrong. > > > If no CIDR-length is given in the directive, then and the IP > > > address are compared for equality. (Here, CIDR is Classless Inter- > > > Domain Routing.) > > > > > > [MSK: Provide a reference to the definition of CIDR, and make sure > > > "CIDR-length" is defined there or use the term that document uses.]> > > > > > > If a CIDR-length is specified, then only the specified number of > > > high-order bits of and the IP address are compared for equality. > > > > If someone knows/would look up the reference, I'd appreciate it. > > RFC4632 is the current reference, but alas it contains no ABNF. So we should add the reference, but we need to keep our own ABNF since there isn't one to refer to, correct? > > > In hindsight, the name "include" was poorly chosen. Only the > > > evaluated result of the referenced SPF record is used, rather than > > > acting as if the referenced SPF record was literally included in the > > > first. For example, evaluating a "-all" directive in the referenced > > > record does not terminate the overall processing and does not > > > necessarily result in an overall "fail". (Better names for this > > > mechanism would have been "if-pass", "on-pass", etc.) > > > > > > [MSK: Interesting. Should we make a new name for it, synonymous with > > > "include", to facilitate introduction of a new name in a future > > > version?] > > > > I don't see how we can do that without running into transition problems. > > You > > can't publish both the new/old name as the new name would cause an error > > on > > existing implementations, so it couldn't be deployed as part of SPF v 1. > > This is one of the changes (like combining a/ip4/ip6) that would be good > > to > > consider in a future update that is free to worry less about backward > > compatibliilty. > > I hadn't thought of a/ip4/ip6. This makes me think a short appendix about > "notes for future revisions to SPF" or such might be a good idea. I think it would distract from the purpose of the document and 4408bis is more than long enough already. The particular example I gave you is well known in the SPF community. If we need an IETF document for "stuff we didn't do in SPFbis" (and I'm not sure we do), I'd suggest a post-WG individual submission from the party or parties that have enough energy left to do it. It doesn't need IETF consensus, so it could be informational. > > > The "include" mechanism is intended for crossing administrative > > > boundaries. Although it is possible to use includes to consolidate > > > multiple domains that share the same set of designated hosts, domains > > > are encouraged to use redirects where possible, and to minimize the > > > number of includes within a single administrative domain. For > > > example, if example.com and example.org were managed by the same > > > entity, and if the permitted set of hosts for both domains was > > > "mx:example.com", it would be possible for example.org to specify > > > "include:example.com", but it would be preferable to specify > > > "redirect=example.com" or even "mx:example.com". > > > > > > [MSK: I get that it's preferable, but I don't see why. What difference > > does > > > it make?] > > > > It's a question of how the records expand and what results you get. > > > > example.com IN TXT "v=spf1 include: another.example.net ?all" > > example.com IN A 192.0.2.1 > > another.example.net IN TXT "v=spf1 a -all" > > another.example.net IN A 192.0.2.200 > > > > This will match for mail from 192.0.2.200 since the domain used in the > > evaluation of another.example.net's SPF record is another.example.net. > > > > The > > result for mail from any other IP address is Neutral because include with > > just > > match/notmatch and the original SPF record's "all" mechanism is what > > controls > > the result if nothing matches. > > > > With include you are specifying you want another domain's authorized hosts > > to > > be authorized for your domain, but you still want to control the sender > > policy > > from this one (what result to give for things that don't match). > > > > Similarly, consider: > > > > example.com IN TXT "v=spf1 redirect=another.example.net" > > example.com IN A 192.0.2.1 > > another.example.net IN TXT "v=spf1 a -all" > > another.example.net IN A 192.0.2.200 > > > > In this case, mail from 192.0.2.1 matches the record since the check_host > > expansion is done using the orignal domain name, not the domain-spec of > > the > > redirect modifier. The result is fail is the mail doesn't match. > > > > Redirect is much more like a common code element to be shared among > > records in > > a single ADMD. You could control both authorized hosts and policy for an > > arbitrary number of domains from a single record. > > Your example is a lot more illustrative than the paragraph I cited. > Perhaps a briefer summary of the difference would be helpful. The concept > that speaks to me as a coder is something like "redirect never returns". > For example, in C, if you do this: > > status = foo(); > return status; > > You have the choice to use the return value from foo() as it does, or to > insert code before the "return" to do your own thing and eventually return > your own result (which "include" does), while: > > return foo(); > > This executes foo() and its return value is the return value of the caller > with no opportunity to do something different (which "redirect" does). I think some of this can go in section 9. I'll look at making it more clear. > > > 5.5. "ptr" (deprecated) > > > > > > [MSK: Wouldn't it be easier to drop this section?] > > > > It's in use. We can't drop it, only discourage it harder. > > I would remove it to an appendix or something if we don't intend for it to > be part of the live protocol. > > But this is another example of the question, which I think is still being > discussed, about whether it's appropriate to remove or at least deprecate > things. The same survey that started the other argument finds 93 domains > using "ptr" out of over 150,000 reporting. If it's okay do deprecate ptr, > then it's okay to deprecate macros. And if it's deprecated and moving from > Experimental to Proposed Standard, I think this is a serious consideration. In my view, things that are deprecated are still part of the protocol, for now. Implementers still need to implement them to fully implement the protocol. I think moving deprecated things into their own section would make the document harder to operate and more confusing. The fact that you found so few is the result of a lot of advocacy in the SPF community against it's use. > > > 5.6. "ip4" and "ip6" > > > > > > These mechanisms test whether is contained within a given IP > > > network. > > > > > > IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] > > > IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] > > > > > > ip4-cidr-length = "/" 1*DIGIT > > > ip6-cidr-length = "/" 1*DIGIT > > > dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] > > > > > > [MSK: Can't this be simplified to just a "cidr-length", and the above > > three > > > dropped? Really the only difference is that ip4-cidr-length can't be > > more > > > than 32 and ip6-cidr-length can't be more than 128. So either say that > > in > > > an ABNF comment for each (and you could make the former be 1*2DIGIT and > > the > > > latter 1*3DIGIT), or simplify.]> > > > > Would that still allow one to use a:example.com/30/64? That's legit now > > for > > dual homed IPv4/6 hosts. > > My survey found zero dual-cidr-lengths in use. Zero explicit dual-cidr-lengths that is. For any dual homed host there is an implicit /32/128. My dual homed SPF records use ip4/ip6 mechanisms to reduce DNS lookups, but for people with dual homed systems that prefer the "A" mechanism, I think this will increasing come up. Without IPv6 deployment, dual-cidr-length won't get used. Given the current level of IPv6 deployment, I think it's premature for us to remove IPv6 related features as unused because we just don't know yet what will get used or not. The original SPF design included careful theoretical consideration of IPv6 because we knew it was coming (eventually), but the operational experience with the IPv6 specific parts of the protocol is still limited. > > > ip4-network = qnum "." qnum "." qnum "." qnum > > > qnum = DIGIT ; 0-9 > > > > > > / %x31-39 DIGIT ; 10-99 > > > / "1" 2DIGIT ; 100-199 > > > / "2" %x30-34 DIGIT ; 200-249 > > > / "25" %x30-35 ; 250-255 > > > > > > ; as per conventional dotted quad notation. e.g., 192.0.2.0 > > > > > > [MSK: Is there really not a reference for this syntax?] > > > > There probably is, but we didn't find it in 2005. If someone can dig it > > up, I'll add it. > > I actually can't find one either. Pete or Dave, perhaps? OK. Standing by. > > > key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) > > > > > > key = "client-ip" / "envelope-from" / "helo" / > > > > > > "problem" / "receiver" / "identity" / > > > > > > mechanism / name > > > > > > identity = "mailfrom" ; for the "MAIL FROM" identity > > > > > > / "helo" ; for the "HELO" identity > > > / name ; other identities > > > > > > [MSK: Should "identity" be quoted in the "key" list?] I think it should not. > > > [MSK: There are two paths to "key" generating "name": one direct, one > > > through "identity"]> > > > > Is this a problem? > > I thought it was considered an ambiguous grammar in that case, and thus > "improper". > > You should run this through a BNF checker too just to see if any bugs are > found. There's one on tools.ietf.org someplace. I did already. The previous round of ABNF discussion we had we engendered by just such a trip to Bill's ABNF checker. > > > macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) > > > > > > / "%%" / "%_" / "%-" > > > > > > [MSK: The "*delimiter" allows this: %{s.-+,/_=.+,..+.} What would that > > > mean?]> > > > > Good question. It's almost 1AM, so I'm not even going to try and figure > > that > > one out right now. What does it mean? > > My point is that the grammar allows it, and I'm not certain we want that. > What's the point of allowing lots of delimiters? How would one apply more > than one? One could publish an SPF record that would match multiple sequential delimiters. That would be odd, and not very useful, but I don't think it's a problem. I don't think there's an interoperability benefit to modifying the ABNF to prohibit it. > > > By default, strings are split on "." (dots). Note that no special > > > treatment is given to leading, trailing, or consecutive delimiters, > > > > > > [MSK: In input strings, right?] > > > > Yes. > > So if the "delimiter" part of the ABNF is "+.", what does a parser do? > Break on +, then within those break on .? Break on either (like strtok() > does)? OK. Now I'm not sure about my previous comment. Let's hold this until the overall macro discussion is resolved. > > > Macros MAY specify delimiter characters that are used instead of ".". > > > > > > [MSK: Isn't this redundant to the ABNF?] > > > > Yes, but so is a lot of the text. > > I guess I'd like to keep that to a minimum. I'm going to leave it for now as I think it's useful. Let's revisit after we get done beating up the concept of macros. Thanks again for the additional comments. Once again, I've just left in the things that I think might need further discussion. From spf2@kitterman.com Mon Jul 16 07:50:10 2012 Return-Path: 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 4D05121F86BD for ; Mon, 16 Jul 2012 07:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599] 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 pLQgtFsR4jNI for ; Mon, 16 Jul 2012 07:50:05 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1C45C21F86B4 for ; Mon, 16 Jul 2012 07:50:05 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9B28220E40BD; Mon, 16 Jul 2012 10:50:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342450249; bh=rgfY3ZzaNlQgtdYr/7rjyc8w1rcV9eLlnA2FO3hQV/Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hrR7MLyGsaxgPOe2dai37waYXzD4mXA0WbCfDSC516ogw+2mD+5sRxJEpar8o8uip YVBiuf6HFZzGHOoxqgy7vW+D8lbxHaKvmUzJT0GWxBec3Hk4489Z7sTsiHZ3vHST9S bgAQWo5/XmdV1AC/Cccxg9YYBGz4Go5ydW2iHRUM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8176B20E409C; Mon, 16 Jul 2012 10:50:49 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 16 Jul 2012 10:50:48 -0400 Message-ID: <1387770.UQiiEdfq0F@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50041E53.4070104@dcrocker.net> References: <20120713212718.35051.qmail@joyce.lan> <1531354.CvHIYLHnSo@scott-latitude-e6320> <50041E53.4070104@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:50:10 -0000 On Monday, July 16, 2012 06:59:47 AM Dave Crocker wrote: > On 7/16/2012 6:42 AM, Scott Kitterman wrote: > > My use of deprecated is "works as before, but stop using, it > > > > may go away in the future". Yours is "ignore it, but don't raise an > > error." > > > > The former is backwards compatible and consistent with the charter. The > > latter is not on either point. > > I believe your intent with 'deprecated' is roughly the same as what was > done for RFC 2822 (now RFC 5322) which used the term "obsolete". So > it's worth looking at the way it dealt with the matter. (The difference > in label isn't interesting to me. Looking at the meaning is.) > > The text about this in RFC 5322 is: > > 3.1. Introduction > > ... > > > In some of the definitions, there will be non-terminals whose names > > start with "obs-". These "obs-" elements refer to tokens defined in > > the obsolete syntax in section 4. In all cases, these productions > > are to be ignored for the purposes of generating legal Internet > > messages and MUST NOT be used as part of such a message. However, > > when interpreting messages, these tokens MUST be honored as part of > > the legal syntax. In this sense, section 3 defines a grammar for the > > generation of messages, with "obs-" elements that are to be ignored, > > while section 4 adds grammar for the interpretation of messages. > > I read this as meaning: If you are conforming to the latest > specification, you must not /generate/ data using these constructs. > However you will still receive and correctly process data that was > generated using these constructs. > > I believe the language in RFC 5322 is compatible with the interpretation > that Scott has for 'deprecated'. It's very close. I think the difference is that my definition is SHOULD NOT and that one is MUST NOT. So far the only thing that's marked 'deprecated' in -03 is PTR and the related macro. I think SHOULD NOT is the appropriate thing to say. I think MUST NOT is too strong. Like you, I'm not very interested in the label and don't mind changing it if something else is better. I originally picked deprecated because it seemed to me to be a widely used term that programmers would generally understand. It's perhaps more important that DNS administrators understand it, so I'm open to suggestions. Scott K From vesely@tana.it Mon Jul 16 08:21:21 2012 Return-Path: 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 CC00011E8085 for ; Mon, 16 Jul 2012 08:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.628 X-Spam-Level: X-Spam-Status: No, score=-4.628 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 4jBsaNm+Oz9V for ; Mon, 16 Jul 2012 08:21:20 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A57D111E8079 for ; Mon, 16 Jul 2012 08:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342452124; bh=bHFdzitpaKUTnnZJa+AHwonFt7gR3HPT6eqCwTFnglE=; l=1504; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=FUVFpGUHop5QKU/CG6LUAZH3uCl/JXLJoDj3TH9imX5ZTtChwv6lALkbKIcPYASyl xAatzu6egJkOxczhJ8CBuyyPqACYq0LEejlDgtvDYfd/hd/76Zlap+XO0QIjb5vHRd MoGYSh4IPmfyRIx4t9CJuzE4YrvwKsQSp9Ughi6Q= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 16 Jul 2012 17:22:04 +0200 id 00000000005DC039.000000005004319C.000023F7 Message-ID: <5004319B.4040507@tana.it> Date: Mon, 16 Jul 2012 17:22:03 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> <20120716135607.GD55459@verdi> In-Reply-To: <20120716135607.GD55459@verdi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:21:22 -0000 On Mon 16/Jul/2012 15:56:07 +0200 John Leslie wrote: > Andrew Sullivan wrote: >> >> I'd like those who support deprecation or removal of the feature >> to explain how their proposed action is consistent with the >> charter we have. > > Simply, "deprecate" is not "remove". From the charter: > " > " Specifically out-of-scope for this working group: > " [...] > " * Removal of existing features that are in current use. > > The definition of "deprecate" quite clearly states that the feature > is not being removed (even if we threaten to do so in the future). > We only say "SHOULD not publish," understanding that there may be > valid reasons to publish and still claim compliance with this Proposed > Standard. I happened to write both in favor and against removal of local macros: http://www.ietf.org/mail-archive/web/spfbis/current/msg00184.html http://www.ietf.org/mail-archive/web/spfbis/current/msg01821.html Let me please try and clarify my thought. We already have the following text in the draft: Note: Domains should avoid using the "s", "l", "o", or "h" macros in conjunction with any mechanism directive. I'd be fine with s/should/SHOULD/. IMHO, we won't get more than that by adding deprecation. But we might get less: By deprecating all those macros rather than just %{p}, we might dilute deprecation itself, and risk that the next WG will just confirm such status without actually removing the unwanted features. jm2c From spf2@kitterman.com Mon Jul 16 09:14:25 2012 Return-Path: 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 842D921F868A for ; Mon, 16 Jul 2012 09:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 PoJM5-uWy87n for ; Mon, 16 Jul 2012 09:14:24 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AFA4921F8675 for ; Mon, 16 Jul 2012 09:14:23 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6180120E40BD; Mon, 16 Jul 2012 12:15:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342455308; bh=RjZVzglwHlwlWrJNALX1jxwLeCtLfLaStdAGMR0oXFA=; h=From:To:Subject:Date:From; b=L8i4ju2KzSJlHO+ry7BM/OAHxUBzHBtaMtKflk2EsgoYgGNZTZDjKPEoReN0/jzxy DHc2v1gspDMeQDBTk2yaMGp8gMFOFruMwteks8BJlVbKYmYH669QN69Ow/EmfgR1fN ghb2NyICXksaq/vRozmVVdwY0JTjCYLgcGu/5J9c= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 445A220E409C; Mon, 16 Jul 2012 12:15:08 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 16 Jul 2012 12:15:07 -0400 Message-ID: <1442775.KUPRUp6gJF@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1743560.9lfiSHBjIg" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Enhanced discussion of DNS limits/resource considerations X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 16:14:25 -0000 --nextPart1743560.9lfiSHBjIg Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Alessandro Vesely sent me some proposed changes in section 9 to make some DNS limits and costs more clear. I've attached an rfcdiff of the changes I think should be incorporated. Feedback please. Scott K --nextPart1743560.9lfiSHBjIg Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-04.txt.new-from-old.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-spfbis-4408bis-04.txt.new-from-old.diff.html" Diff: draft-ietf-spfbis-4408bis-04.txt.old - draft-ietf-spfbis-4408bis-04.txt.new
 draft-ietf-spfbis-4408bis-04.txt.old   draft-ietf-spfbis-4408bis-04.txt.new 
skipping to change at page 4, line 17 skipping to change at page 4, line 17
6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 27 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 27
6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 28 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 28
7. The Received-SPF Header Field . . . . . . . . . . . . . . . . 30 7. The Received-SPF Header Field . . . . . . . . . . . . . . . . 30
8. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Macro Definitions . . . . . . . . . . . . . . . . . . . . 32 8.1. Macro Definitions . . . . . . . . . . . . . . . . . . . . 32
8.2. Expansion Examples . . . . . . . . . . . . . . . . . . . . 35 8.2. Expansion Examples . . . . . . . . . . . . . . . . . . . . 35
9. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 36 9.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 36
9.1.1. DNS Resource Considerations . . . . . . . . . . . . . 36 9.1.1. DNS Resource Considerations . . . . . . . . . . . . . 36
9.1.2. Administrator's Considerations . . . . . . . . . . . . 37 9.1.2. Administrator's Considerations . . . . . . . . . . . . 37
9.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 37 9.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 38
9.2.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 37 9.2.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 38
9.2.2. Forwarding Services and Aliases . . . . . . . . . . . 37 9.2.2. Forwarding Services and Aliases . . . . . . . . . . . 38
9.3. Mail Services . . . . . . . . . . . . . . . . . . . . . . 39 9.3. Mail Services . . . . . . . . . . . . . . . . . . . . . . 40
9.4. MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 40 9.4. MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42
10.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 41 10.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 42
10.2. SPF-Authorized Email May Contain Other False Identities . 41 10.2. SPF-Authorized Email May Contain Other False Identities . 42
10.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 42 10.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 43
10.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 42 10.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 43
10.5. Untrusted Information Sources . . . . . . . . . . . . . . 42 10.5. Untrusted Information Sources . . . . . . . . . . . . . . 43
10.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 43 10.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 44
11. Contributors and Acknowledgements . . . . . . . . . . . . . . 44 11. Contributors and Acknowledgements . . . . . . . . . . . . . . 45
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
12.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 45 12.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 46
12.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 45 12.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 46
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
13.1. Normative References . . . . . . . . . . . . . . . . . . . 46 13.1. Normative References . . . . . . . . . . . . . . . . . . . 47
13.2. Informative References . . . . . . . . . . . . . . . . . . 47 13.2. Informative References . . . . . . . . . . . . . . . . . . 48
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 49 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 50
Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 52 Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 53
B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 52 B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 53
B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 53 B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 54
B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 54 B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 55
B.4. Multiple Requirements Example . . . . . . . . . . . . . . 54 B.4. Multiple Requirements Example . . . . . . . . . . . . . . 55
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 55 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 56
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
The current email infrastructure has the property that any host The current email infrastructure has the property that any host
injecting mail into the mail system can identify itself as any domain injecting mail into the mail system can identify itself as any domain
name it wants. Hosts can do this at a variety of levels: in name it wants. Hosts can do this at a variety of levels: in
particular, the session, the envelope, and the mail headers. particular, the session, the envelope, and the mail headers.
Although this feature is desirable in some circumstances, it is a Although this feature is desirable in some circumstances, it is a
major obstacle to reducing Unsolicited Bulk email (UBE, aka spam). major obstacle to reducing Unsolicited Bulk email (UBE, aka spam).
Furthermore, many domain name holders are understandably concerned Furthermore, many domain name holders are understandably concerned
skipping to change at page 36, line 36 skipping to change at page 36, line 36
recognized that forming such a list is not just a simple technical recognized that forming such a list is not just a simple technical
exercise, but involves policy decisions with both technical and exercise, but involves policy decisions with both technical and
administrative considerations. administrative considerations.
9.1.1. DNS Resource Considerations 9.1.1. DNS Resource Considerations
Minimizing the DNS resources required for SPF lookups can be done by Minimizing the DNS resources required for SPF lookups can be done by
choosing directives that require less DNS information and placing choosing directives that require less DNS information and placing
lower-cost mechanisms earlier in the SPF record. lower-cost mechanisms earlier in the SPF record.
+----------+--------+-----------------+
| term | cost | limit |
+----------+--------+-----------------+
| ip4/ip6 | 0 | - |
| a | 1 | 10 |
| include | 1 | 10 |
| redirect | 1 | 10 |
| exists | 1 | 10 |
| mx | 1 + N* | 10 and N* <= 10 |
| ptr/%{p} | 1 + N* | 10 and N* <= 10 |
+----------+--------+-----------------+
* N is the number of RRs found during each term evaluation
Section 4.6.4 specifies the limits receivers have to use. It is
essential to publish records that do not exceed these requirements.
It is also required to carefully weight the cost and the
maintainability of licit solutions.
For example, consider a domain set up as follows: For example, consider a domain set up as follows:
example.com. IN MX 10 mx.example.com. example.com. IN MX 10 mx.example.com.
mx.example.com. IN A 192.0.2.1 IN MX 20 mx2.example.com.
a.example.com. IN TXT "v=spf1 mx:example.com -all" mx.example.com. IN A 192.0.2.1
b.example.com. IN TXT "v=spf1 a:mx.example.com -all" mx2.example.com. IN A 192.0.2.129
c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all"
Evaluating check_host() for the domain "a.example.com" requires the Assume the administrative point is to authorize (pass) mx and mx2
MX records for "example.com", and then the A records for the listed while failing every other host. Compare the following solutions:
hosts. Evaluating for "b.example.com" requires only the A records.
Evaluating for "c.example.com" requires none.
Section 4.6.4 specifies the limits receivers have to use. It is Best record:
essential to publish records that do not exceed these requirements. example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"
As an example, if you have more than 10 MX records, do not use the
"mx" mechanism to describe them in your SPF record. Good record:
$ORIGIN example.com.
@ IN TXT "v=spf1 a:authorized_spf.example.com -all"
authorized_spf IN A 192.0.2.1
IN A 192.0.2.129
Expensive record:
example.com. IN TXT "v=spf1 mx:example.com -all"
Wasteful, bad record:
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 mx -all"
9.1.2. Administrator's Considerations 9.1.2. Administrator's Considerations
There might be administrative considerations: using "a" over "ip4" or There might be administrative considerations: using "a" over "ip4" or
"ip6" allows hosts to be renumbered easily. Using "mx" over "a" "ip6" allows hosts to be renumbered easily. Using "mx" over "a"
allows the set of mail hosts to be changed easily. Unless such allows the set of mail hosts to be changed easily. Unless such
changes are common, it is better to use the less resource intensive changes are common, it is better to use the less resource intensive
mechanisms like "ip4" and "ip6". mechanisms like "ip4" and "ip6".
Validating correct deployment is difficult. [RFC6652] describes one Validating correct deployment is difficult. [RFC6652] describes one
 End of changes. 6 change blocks. 
39 lines changed or deleted 64 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart1743560.9lfiSHBjIg-- From sm@elandsys.com Mon Jul 16 09:14:57 2012 Return-Path: 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 071D621F867C for ; Mon, 16 Jul 2012 09:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 bSgxDofNFMsQ for ; Mon, 16 Jul 2012 09:14:52 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C7011E80A5 for ; Mon, 16 Jul 2012 09:14:52 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.167]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6GGFOa3024824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Jul 2012 09:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342455336; bh=8E+XpNi5BIybbcU/ml/Tt1t0AL9qE1VbJ3IJjz3fH8A=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=yhtpqSSdvUpDeLOfh0FlDcBAIZePfmlXiXgj1kfledmoyBu8RW+dRXmq8ZsbofutD YrWL1SiB3+VEVg7PVQx1pun6+HC+pzCMx8Si4vX50TM4QyDYkL9lTk1JwSjoeb6EVc gGJkTOI7ycSwQycyBUg9BqyUH8k+hfNVs65XKDwE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342455336; i=@elandsys.com; bh=8E+XpNi5BIybbcU/ml/Tt1t0AL9qE1VbJ3IJjz3fH8A=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=j+DuhQ0lY8fBqM/ZU2B7kK8Ty6NOHAB5O5M/OX6uNFNZpiJnzKlgbwkmHqbA1lXaK w13jDOl2mGEXiGzy9HmQLtd66IxAiFTZCwnco/ghanWeMVrUkAPJItdyDNBF8VM56i g+fOlQYbVTP+ZQ14qCj9fQ64SboDTbgs4B2L+8nA= Message-Id: <6.2.5.6.2.20120716084506.09900cf8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 16 Jul 2012 08:58:38 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1991186.y8zxGRhPli@scott-latitude-e6320> References: <13841705.Ry8OH4Cp8v@scott-latitude-e6320> <1991186.y8zxGRhPli@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 16:14:57 -0000 At 07:30 16-07-2012, Scott Kitterman wrote: >from the party or parties that have enough energy left to do it. It doesn't >need IETF consensus, so it could be informational. As a guideline, an individual submission with an intended status of Informational usually requires IETF consensus. Regards, -sm From hsantos@isdg.net Mon Jul 16 10:01:33 2012 Return-Path: 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 548C911E8168 for ; Mon, 16 Jul 2012 10:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 MucrSb188QxG for ; Mon, 16 Jul 2012 10:01:30 -0700 (PDT) Received: from groups.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B04A011E8159 for ; Mon, 16 Jul 2012 10:01:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1652; t=1342458127; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=MLHwsqNHbcTiJDmM1/alao92vLs=; b=ottprnyBw9YuCYoIFQ1R LYOnEGGtbbAeXrof1S2FykuSjRHxvj7y2v4Q1qK7hf4WSQeHvffG0yjn7AmvVI6X XKOfDCKqSUt5TX9YBoWXud/Nd5Oqt+h+ioxzancydy4rk2OpeFI0A6Qb5POxZ59k ZR3GxKVQPid3GIoCZMYIIBE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 16 Jul 2012 13:02:07 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2774928835.15339.2120; Mon, 16 Jul 2012 13:02:06 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1652; t=1342458001; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=n5fyrGy uYO2QoefWFPZYFJuwWtWZmBUh/Co0ncH8EMg=; b=b7ds/aEIV0/kabA3a3Kwkns W16HwcnuJJh5Fd0z7YCkKOLfGUOCzCLBjK1BqeNrVWS4tGA1Ta3BdSfkiDVtM8gZ OFvBaeE1oV81YKqMYXM2ZyHrZ55YhajHvS3slFRD7Mpd0NDohHQB6bChpmHxfpuG 0Xgi0Q2rNzdTjj9Ezbm0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 16 Jul 2012 13:00:01 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3373766957.9.7424; Mon, 16 Jul 2012 13:00:00 -0400 Message-ID: <5004490D.5060007@isdg.net> Date: Mon, 16 Jul 2012 13:02:05 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120713212718.35051.qmail@joyce.lan> <1531354.CvHIYLHnSo@scott-latitude-e6320> <50041E53.4070104@dcrocker.net> <1387770.UQiiEdfq0F@scott-latitude-e6320> In-Reply-To: <1387770.UQiiEdfq0F@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 17:01:33 -0000 Scott Kitterman wrote: > > It's very close. I think the difference is that my definition is SHOULD NOT and > that one is MUST NOT. So far the only thing that's marked 'deprecated' in -03 > is PTR and the related macro. I think SHOULD NOT is the appropriate thing to > say. I think MUST NOT is too strong. > PTR is deprecated? Sorry for not being able to provide the time to focus of the WG details of whats been done here, but this command is highly used and it is very useful. It serves a very useful purpose for IPs that have multiple A records and SMTP software that use the first round robin A record for a HELO. There are plenty of SMTP software that do this. I submit this is the case with the much higher volume of smaller sites, businesses and operations that have limited IPs but plenty of subdomains for IPs. -1 to DEPRECATING this feature. Can you remind us (or just me) of the reasoning behind this move? I'm certainly not to deprecate PTR in our implementation. In a quick scan of DNS cache, I see at least 20-25% of the records using PTR macros. If deprecating is the consensus, no doubt, SHOULD NOT is the ONLY option. I prefer that would be more of guideline than any sort of strong 2119 encouragement where it may make a replacement SPF statement more complex, longer and possibly impracticable to be dynamic (a new SPF statement update is needed for every new subdomain added to the single IP). PTR allows the SPF statement to be generic for systems that have multiple A records and the SMTP software is randomly and/or in round robin fashion using the first host address it gets. -- HLS From spf2@kitterman.com Mon Jul 16 10:08:24 2012 Return-Path: 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 15DCE11E8160 for ; Mon, 16 Jul 2012 10:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599] 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 lkATKKi-uji7 for ; Mon, 16 Jul 2012 10:08:23 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3709011E80B6 for ; Mon, 16 Jul 2012 10:08:23 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EF2DE20E40BD; Mon, 16 Jul 2012 13:09:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342458548; bh=wUNw69JHwLOsMNAHLJXREFJ7j1p/0vwsvLnoQjDre18=; h=From:To:Subject:Date:In-Reply-To:References:From; b=E43RQrtZVMREsqnkELjGB0etBha1fhCpCp6SXUNa5m6XCsGao9+g1dF/SZQm1nuQK ftqoXY4dIdqLM0Qk2847BzkEQkNAlkAiJYqEIlGqqMALCmjMwGXCxWhtHy/db/VZ3a P4CyvPlz2pzdDFBk7jCy0/l0JJ6/zpq/mYrzljDM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CFF5520E409C; Mon, 16 Jul 2012 13:09:07 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 16 Jul 2012 13:09:06 -0400 Message-ID: <1945149.ydQRFkRVWP@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5004490D.5060007@isdg.net> References: <20120713212718.35051.qmail@joyce.lan> <1387770.UQiiEdfq0F@scott-latitude-e6320> <5004490D.5060007@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 17:08:24 -0000 On Monday, July 16, 2012 01:02:05 PM Hector Santos wrote: > Scott Kitterman wrote: > > It's very close. I think the difference is that my definition is SHOULD > > NOT and that one is MUST NOT. So far the only thing that's marked > > 'deprecated' in -03 is PTR and the related macro. I think SHOULD NOT is > > the appropriate thing to say. I think MUST NOT is too strong. > > PTR is deprecated? > > Sorry for not being able to provide the time to focus of the WG > details of whats been done here, but this command is highly used and > it is very useful. > > It serves a very useful purpose for IPs that have multiple A records > and SMTP software that use the first round robin A record for a HELO. > There are plenty of SMTP software that do this. I submit this is > the case with the much higher volume of smaller sites, businesses and > operations that have limited IPs but plenty of subdomains for IPs. > > -1 to DEPRECATING this feature. > > Can you remind us (or just me) of the reasoning behind this move? I'm > certainly not to deprecate PTR in our implementation. In a quick scan > of DNS cache, I see at least 20-25% of the records using PTR macros. > > If deprecating is the consensus, no doubt, SHOULD NOT is the ONLY > option. I prefer that would be more of guideline than any sort of > strong 2119 encouragement where it may make a replacement SPF > statement more complex, longer and possibly impracticable to be > dynamic (a new SPF statement update is needed for every new subdomain > added to the single IP). PTR allows the SPF statement to be generic > for systems that have multiple A records and the SMTP software is > randomly and/or in round robin fashion using the first host address it > gets. I have yet to run into a situation that can't be better expressed in other ways. I think both the list archives and the draft are pretty clear about why we did it. Scott K From vesely@tana.it Mon Jul 16 10:23:45 2012 Return-Path: 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 2BEDD11E823F for ; Mon, 16 Jul 2012 10:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.63 X-Spam-Level: X-Spam-Status: No, score=-4.63 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 vKuuV5+9AL7p for ; Mon, 16 Jul 2012 10:23:44 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAA811E823D for ; Mon, 16 Jul 2012 10:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342459468; bh=lL4TkOdUKsR9Y7KhmcmnvgcCJyb3af8Y8I0m41ciC6M=; l=2121; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OiHVbw+iRkWASZAlFPo2xsp4G+Ghs5d2EEGl64lUp92wVUEYf/bJWOQwwV5hqQsau st9cShBNec5zSXetu8PQ3N23h3aLJgvVjin4G1xAniiiHJFTP5hirnkUn1X+G06rAV zxxz87QrsTjWYrmoY59Xh0HbF2bo7VdUiMiY9DE8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 16 Jul 2012 19:24:28 +0200 id 00000000005DC033.0000000050044E4C.0000418D Message-ID: <50044E4C.5080308@tana.it> Date: Mon, 16 Jul 2012 19:24:28 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <13841705.Ry8OH4Cp8v@scott-latitude-e6320> <1991186.y8zxGRhPli@scott-latitude-e6320> In-Reply-To: <1991186.y8zxGRhPli@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] #28: i18n for EAI compatibility, was Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 17:23:45 -0000 On Mon 16/Jul/2012 16:30:11 +0200 Scott Kitterman wrote: > On Sunday, July 15, 2012 11:31:57 PM Murray S. Kucherawy wrote: >> On Sun, Jul 15, 2012 at 10:07 PM, Scott Kitterman wrote: > ... >>>> 4.3. Initial Processing >>>> >>>> If the is malformed (label longer than 63 characters, zero- >>>> length label not at the end, etc.) or is not a fully qualified domain >>>> name, or if the DNS lookup returns "domain does not exist" (RCODE 3), >>>> check_host() immediately returns the result "none". >>>> >>>> [MSK: I suggest be defined in terms of whatever a >>>> legal domain name is in [RFC5321], as amended by EAI, and >>>> further require that it be fully-qualified. In terms of >>>> I18N, we should just do what DKIM did to handle this case.] >>> >>> What did "DKIM do"? >> >> I'm referring to Section 3.5 of RFC6376, the definition of "d=". > > It says: > > Internationalized domain names MUST be encoded as A-labels, as > described in Section 2.3 of [RFC5890]. > > I think that's fine. In a related point, I think we can dispose of the local- > part macro/EAI issue similarly. DKIM had good reasons to do so: RFCs 6530-6533 were not published at the time, and having d= tags as A-labels could avoid considerations about UTF-8 completely. Neither of those are true for 4408bis. MAIL command can legally have UTF-8 addresses. SPF implementations may request that parameters be converted by the caller, and prohibit use of UTF-8 in SPF records. But they need to sanitize the arguments they pass to (and receive from) the DNS software anyway, so they could do IDNA calls as well. Disallowing UTF-8 in local explanations, including local-parts, sounds arbitrarily against current trends. Using UTF-8 for both records and parameters may make for smoother specs, implementations, and deployment --especially in the long term. I don't think it will be any easier to switch to UTF-8 in some future SPF version, possibly the opposite. Is that correct? Could we try and see how it works, or at least state the pros and cons we'd expect? From hsantos@isdg.net Mon Jul 16 10:27:24 2012 Return-Path: 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 3C1E711E8247 for ; Mon, 16 Jul 2012 10:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.007 X-Spam-Level: X-Spam-Status: No, score=-102.007 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 9saPBDfrLYzm for ; Mon, 16 Jul 2012 10:27:23 -0700 (PDT) Received: from groups.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 890A911E8244 for ; Mon, 16 Jul 2012 10:27:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2856; t=1342459678; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=O1D/AoEjrK6LVVGD85BVrRwDvS8=; b=S4Vi00Vj59jEZtxVICJG hXPvMNKOLf7B3aJfk3B8t1muXFbM5a8P8xnjcddM+EgbAokL1yEdPQbxBueaKHHS AjW0fzcIYE3LlGOObJB7sv1n7sTD0E/Bl6dRdecuZoc06PPrecDT77nUFuz0ptJl YSzRm3L8PdiZ7M9Kepa1rck= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 16 Jul 2012 13:27:58 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2776479063.15339.5596; Mon, 16 Jul 2012 13:27:57 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2856; t=1342459553; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5aurdIe pkGPVBa+2nzP1KLuLLvbZ3ALasHUQpUjBF/w=; b=1MCarFfB/fidKGs6+Segb+k KWgdIPxK1Oe3TToheYqQVPpPc3Sloc8KBashQLCAAgbFCJ1cjUEEsWX/kJUrfK+k bokCle9sUi5pGZOvHvK6pd/gHgoSXDjBz99SZHXt4FAWr9D/n7bDOb0eUrJ8IK5d xxn2Y8MbVbmLGwHFszZc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 16 Jul 2012 13:25:53 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3375318285.9.7704; Mon, 16 Jul 2012 13:25:52 -0400 Message-ID: <50044F18.2000005@isdg.net> Date: Mon, 16 Jul 2012 13:27:52 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120713212718.35051.qmail@joyce.lan> <1531354.CvHIYLHnSo@scott-latitude-e6320> <50041E53.4070104@dcrocker.net> <1387770.UQiiEdfq0F@scott-latitude-e6320> <5004490D.5060007@isdg.net> In-Reply-To: <5004490D.5060007@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 17:27:24 -0000 > Can you remind us (or just me) of the reasoning behind this move (PTR Deprecation)? > I'm certainly not to deprecate PTR in our implementation. In a quick scan of > DNS cache, I see at least 20-25% of the records using PTR macros. 16.5% in this quick cache to be more snapshot precise are using PTR in their SPF statement. I suggest we have a higher occurrence of a zero PTR overhead for SPF specifically when increasingly at the SMTP receiver level more and more systems are performing PTR lookups as a SMTP policy. So any reasoning that a PTR lookup generally a higher overhead DNS expense lookup, is a problem for SPF is a weaker reason today by the time the SPF query is made. Assuming the SMTP and SPF software are using the same DNS query/cache, any SPF PTR lookup would be in the cache . We had a major update two years ago to make sure all DNS API related components in our total Internet Hosting framework (telnet/rlogin, nntp, ftp, web, smtp, pop, etc) used a common DNS API/Cache to reduce the redundancy and overhead with the new associated DNS security related protocols. -- HLS Hector Santos wrote: > Scott Kitterman wrote: >> >> It's very close. I think the difference is that my definition is >> SHOULD NOT and that one is MUST NOT. So far the only thing that's >> marked 'deprecated' in -03 is PTR and the related macro. I think >> SHOULD NOT is the appropriate thing to say. I think MUST NOT is too >> strong. > > PTR is deprecated? > > Sorry for not being able to provide the time to focus of the WG details > of whats been done here, but this command is highly used and it is very > useful. > > It serves a very useful purpose for IPs that have multiple A records and > SMTP software that use the first round robin A record for a HELO. There > are plenty of SMTP software that do this. I submit this is the case > with the much higher volume of smaller sites, businesses and operations > that have limited IPs but plenty of subdomains for IPs. > > -1 to DEPRECATING this feature. > > Can you remind us (or just me) of the reasoning behind this move? I'm > certainly not to deprecate PTR in our implementation. In a quick scan of > DNS cache, I see at least 20-25% of the records using PTR macros. > > If deprecating is the consensus, no doubt, SHOULD NOT is the ONLY > option. I prefer that would be more of guideline than any sort of > strong 2119 encouragement where it may make a replacement SPF statement > more complex, longer and possibly impracticable to be dynamic (a new SPF > statement update is needed for every new subdomain added to the single > IP). PTR allows the SPF statement to be generic for systems that have > multiple A records and the SMTP software is randomly and/or in round > robin fashion using the first host address it gets. > -- HLS From hsantos@isdg.net Mon Jul 16 10:38:13 2012 Return-Path: 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 B340E11E823E for ; Mon, 16 Jul 2012 10:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.985 X-Spam-Level: X-Spam-Status: No, score=-101.985 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 wulxzuslCACB for ; Mon, 16 Jul 2012 10:38:13 -0700 (PDT) Received: from groups.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B67DF11E8158 for ; Mon, 16 Jul 2012 10:38:12 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3357; t=1342460328; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=zITDuBj7YFPfJiodZZDFbeVlcXI=; b=PXMDRprmc+AfC+HYCI5G MsSM6R93dixejPU4coACfQXu7hJ0bSLD29h8j3i9ojqzaKn8lmY8HKEapO2tsunJ drwcpmC90pg0m8l6Cek85mT9zGvakXioXnASV8d0uViGSwTwTMysqCzHJSvlAWCa 9R6yjzakP+9QORC4PuRj+3w= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 16 Jul 2012 13:38:48 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2777129088.15339.2772; Mon, 16 Jul 2012 13:38:47 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3357; t=1342460200; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RQgeEzc izMbs5Nt8EAtW8xJq9k3Tmn0ikCIvVQeKF/A=; b=iOOj5BoIjjnLMzUfztvcv4K saQVoBmukLjdFmO1Wo3vE+r8O2rkOHFIZl24jyU5Z3bwlyuoIsPtE7PuydB1HLXU ljaQOs3JCw3ai2JBj1EU/J4394etgQDzBBgeG00S6XG0z4RoK167um6q6+CAKpV5 H30jo180nqm3J9NTv3g0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 16 Jul 2012 13:36:40 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3375965426.9.4020; Mon, 16 Jul 2012 13:36:39 -0400 Message-ID: <5004519F.2060101@isdg.net> Date: Mon, 16 Jul 2012 13:38:39 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120713212718.35051.qmail@joyce.lan> <1387770.UQiiEdfq0F@scott-latitude-e6320> <5004490D.5060007@isdg.net> <1945149.ydQRFkRVWP@scott-latitude-e6320> In-Reply-To: <1945149.ydQRFkRVWP@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 17:38:13 -0000 Scott Kitterman wrote: > On Monday, July 16, 2012 01:02:05 PM Hector Santos wrote: >> Scott Kitterman wrote: >>> It's very close. I think the difference is that my definition is SHOULD >>> NOT and that one is MUST NOT. So far the only thing that's marked >>> 'deprecated' in -03 is PTR and the related macro. I think SHOULD NOT is >>> the appropriate thing to say. I think MUST NOT is too strong. >> PTR is deprecated? >> >> Sorry for not being able to provide the time to focus of the WG >> details of whats been done here, but this command is highly used and >> it is very useful. >> >> It serves a very useful purpose for IPs that have multiple A records >> and SMTP software that use the first round robin A record for a HELO. >> There are plenty of SMTP software that do this. I submit this is >> the case with the much higher volume of smaller sites, businesses and >> operations that have limited IPs but plenty of subdomains for IPs. >> >> -1 to DEPRECATING this feature. >> >> Can you remind us (or just me) of the reasoning behind this move? I'm >> certainly not to deprecate PTR in our implementation. In a quick scan >> of DNS cache, I see at least 20-25% of the records using PTR macros. >> >> If deprecating is the consensus, no doubt, SHOULD NOT is the ONLY >> option. I prefer that would be more of guideline than any sort of >> strong 2119 encouragement where it may make a replacement SPF >> statement more complex, longer and possibly impracticable to be >> dynamic (a new SPF statement update is needed for every new subdomain >> added to the single IP). PTR allows the SPF statement to be generic >> for systems that have multiple A records and the SMTP software is >> randomly and/or in round robin fashion using the first host address it >> gets. > > I have yet to run into a situation that can't be better expressed in other > ways. I think both the list archives and the draft are pretty clear about why > we did it. Really? Note: This mechanism has been deprecated because it is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the arpa name servers. If used, proper PTR records must be in place for the domain's hosts and the "ptr" mechanism should be one of the last mechanisms checked. After many yaers of SPF deployment experience it has been concluded it is unnecessary and more reliable alternatives used instead. This hurt smaller, small business and operations systems who are operating with limited IPs and and relying on virtual domains hosting. In addition, the overhead (and "slowness") is already performed at the SMTP level, and I submit increasingly so, especially with the larger ESP, such as AOL and others that now require a PTR record to be available at the connection level. In other words, by the time any in-sessionS SMTP sub-process does any SPF lookup, the PTR records will already be in the DNS cache - zero overhead. This is not a good reason to deprecate it just like it never was a good reason to get rid of it (PTR in general) long ago in the first place, especially in the past years where queries did have a higher network impact with lower bandwidths. There is more harm done with this change. Besides, I don't recall any voting done for this. -- HLS From spf2@kitterman.com Mon Jul 16 10:39:33 2012 Return-Path: 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 2963B11E825C for ; Mon, 16 Jul 2012 10:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599] 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 TB7BFvOA4r0W for ; Mon, 16 Jul 2012 10:39:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA8411E825A for ; Mon, 16 Jul 2012 10:39:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4D03A20E40BD; Mon, 16 Jul 2012 13:40:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342460417; bh=tPs6b9ZcTbhxHAAWQuKQerz4eKUua/atGw1yq/d9jUE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Fj2zaObMWEuxvfZADpHfQygr1VC+3K6WbUu3V/+N9kyniIwQ3u++zs10tX1a6G2bf 9pvrTBJ+xw6tMuDtS9SpHLKa2lDmdNa3x9gOIykRh9HJ+QRNYDH8T23Mfuq5t0MZPq hYZfdIv9HXJiUNhDwnxUa1FXf8dhotguTh2quLeg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3373520E409C; Mon, 16 Jul 2012 13:40:17 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 16 Jul 2012 13:40:16 -0400 Message-ID: <1994154.sBZf5csRg7@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5004519F.2060101@isdg.net> References: <20120713212718.35051.qmail@joyce.lan> <1945149.ydQRFkRVWP@scott-latitude-e6320> <5004519F.2060101@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 17:39:33 -0000 On Monday, July 16, 2012 01:38:39 PM Hector Santos wrote: ... > Besides, I don't recall any voting done for this. ... Probably because the IETF doesn't vote on things. ;-) Scott K From hsantos@isdg.net Mon Jul 16 10:57:25 2012 Return-Path: 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 E849411E8283 for ; Mon, 16 Jul 2012 10:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 oIOyP9-TQsYw for ; Mon, 16 Jul 2012 10:57:25 -0700 (PDT) Received: from groups.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 035A611E828C for ; Mon, 16 Jul 2012 10:57:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1465; t=1342461483; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=iHathoagn7o8nWqQ06q1TQo69OQ=; b=m/kykyCymVAg93JPcAjd XjXwwj9j34DUnZQV/sq28X+f+HsgV/BMt0hJ3DU7D6GMV+NpCVtQN93Y/H4oKmHP AZr8dVbvH+JdbCYnUKQTsKnGkm9bfQ+EkvNwJF60KUSVebTT2HalfFhTreLzOYLa i1Z9AZCgQN8FWvWcoyiMjhE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 16 Jul 2012 13:58:03 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2778284198.15339.3220; Mon, 16 Jul 2012 13:58:02 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1465; t=1342461356; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ERrtriW p5g9SWFcrVQXRY0a3IKG5bix5oOlrQNiwiic=; b=LU3xGrvHVOVaeuMl8xvMmVB qeA5Ti2GBDYayRrXed34Mk55Vr9ymB0Cip/mtBrd6ubGfOZLeA95+7CULJueoRIo VuDLuwUuou41FdNV2GsG3LM9TGbZpYIQyB3IjnhWIpgvmod/DQTNyWtXLHcs/Ie3 Kar6nYW7IFbxhm8KJxig= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 16 Jul 2012 13:55:56 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3377121520.9.988; Mon, 16 Jul 2012 13:55:55 -0400 Message-ID: <50045623.3080000@isdg.net> Date: Mon, 16 Jul 2012 13:57:55 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120713212718.35051.qmail@joyce.lan> <1945149.ydQRFkRVWP@scott-latitude-e6320> <5004519F.2060101@isdg.net> <1994154.sBZf5csRg7@scott-latitude-e6320> In-Reply-To: <1994154.sBZf5csRg7@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 17:57:26 -0000 Scott Kitterman wrote: > On Monday, July 16, 2012 01:38:39 PM Hector Santos wrote: > ... >> Besides, I don't recall any voting done for this. > ... > > Probably because the IETF doesn't vote on things. ;-) So does this means the change was made with no or limited input and practical concerns of others? This PTR deprecation will made the statements more complex, longer to add every possible A/PTR matching sequence - very impractical. The fact there are already a significant amount of usage will force people into a change mode required to avoid increasing errors where it does not exist today for them. I think what was lost this decision is that many SMTP software use the first host domain found for a HELO/EHLO which is one of the reasons performing HELO validations in general is not reliable - this configuration history has been the case for a long time. But if a SPF PTR policy is made that says the IP much match one of the A records, this a strong policy and very easy, simpler SPF policy to have for many sites that have long been in the less than ideal configuration history mode. Now this change is telling people, they must fix their entire SMTP setups (which shouldn't be expected to happen then and now) and now they are being forced to increase the sizes of their SPF records with all the A sub/domain names, and when any new A record is added to the IP, they must change their SPF records again. -- HLS From spf2@kitterman.com Mon Jul 16 11:21:02 2012 Return-Path: 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 1305111E819D for ; Mon, 16 Jul 2012 11:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=-0.634, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 nbc3olvKcCDh for ; Mon, 16 Jul 2012 11:21:01 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECD111E8270 for ; Mon, 16 Jul 2012 11:21:01 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1279B20E40BD; Mon, 16 Jul 2012 14:21:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342462906; bh=xMsNbHixLL8H0ecTdqX45aeOSVPFZ5oX7H+g37Ctwhc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=G/i65cxWLta7jW+s1O+P+R+ratoKCcIg857dV9j70UjW0QEHO96POIufGb5IPTwUj uJBlNN5qt+SxHyaw6W4RiJV6qbl+EXP6v5Tr48EKgjML1OISDpG3jPPNFPKdvT3msD YUnk4FDkiUXAshKsH8c4CPeZ/oYAwplh3+YfibFc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E6EC220E409C; Mon, 16 Jul 2012 14:21:45 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 16 Jul 2012 14:21:44 -0400 Message-ID: <2972423.NzPrSjoX7i@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50045623.3080000@isdg.net> References: <20120713212718.35051.qmail@joyce.lan> <1994154.sBZf5csRg7@scott-latitude-e6320> <50045623.3080000@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 18:21:02 -0000 On Monday, July 16, 2012 01:57:55 PM Hector Santos wrote: > Scott Kitterman wrote: > > On Monday, July 16, 2012 01:38:39 PM Hector Santos wrote: > > ... > > > >> Besides, I don't recall any voting done for this. > > > > ... > > > > Probably because the IETF doesn't vote on things. ;-) > > So does this means the change was made with no or limited input and > practical concerns of others? No. It means the IETF runs on rough consensus which is not getting 51% of the people in the room to agree with you. It's been discussed and as far as I'm recall, you're the only person to speak against the change. > This PTR deprecation will made the statements more complex, longer to > add every possible A/PTR matching sequence - very impractical. The > fact there are already a significant amount of usage will force people > into a change mode required to avoid increasing errors where it does > not exist today for them. > > I think what was lost this decision is that many SMTP software use the > first host domain found for a HELO/EHLO which is one of the reasons > performing HELO validations in general is not reliable - this > configuration history has been the case for a long time. > > But if a SPF PTR policy is made that says the IP much match one of the > A records, this a strong policy and very easy, simpler SPF policy to > have for many sites that have long been in the less than ideal > configuration history mode. > > Now this change is telling people, they must fix their entire SMTP > setups (which shouldn't be expected to happen then and now) and now > they are being forced to increase the sizes of their SPF records with > all the A sub/domain names, and when any new A record is added to the > IP, they must change their SPF records again. Within the last month, I've helped people fix things that turned out to be nothing to do with SPF, but bad rDNS setups. It's an unreliable feature and not necessary. Note that deprecated doesn't mean MUST NOT use. It means SHOULD NOT. If there is such a thing as a setup that would be hard to transition, then there will be lots of time to do so. PTR as a mechanism is not going anywhere in the short term. Scott K From spf2@kitterman.com Mon Jul 16 11:26:20 2012 Return-Path: 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 83C6121F8720 for ; Mon, 16 Jul 2012 11:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] 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 i1E99nUcl-1o for ; Mon, 16 Jul 2012 11:26:19 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCCE21F86FC for ; Mon, 16 Jul 2012 11:26:19 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 993F820E40BD; Mon, 16 Jul 2012 14:27:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342463224; bh=agrMAMkLvxjWQFWsYeQm9h6tuFKg0/0iIDiXv7xgTs8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eJEBjVakXsVaN7iccnd6Og6bOamP50Spslyb+VEVk45OZ7Z+0Kflhjl5zx+EZ2mSl DG7voEm4LqzGdvCRiN9FwWqtcS6VKyuzJqyvAkiYGPGwbMveOuQC6fAPNlihO3VEn7 NmOU0gUGOZU+731c8gXpNgM4wFdFc3HLvQUJoY7w= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7C3E920E409C; Mon, 16 Jul 2012 14:27:04 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 16 Jul 2012 14:27:03 -0400 Message-ID: <5246369.WNxnjnS4q5@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50044E4C.5080308@tana.it> References: <1991186.y8zxGRhPli@scott-latitude-e6320> <50044E4C.5080308@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #28: i18n for EAI compatibility, was Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 18:26:20 -0000 On Monday, July 16, 2012 07:24:28 PM Alessandro Vesely wrote: > On Mon 16/Jul/2012 16:30:11 +0200 Scott Kitterman wrote: > > On Sunday, July 15, 2012 11:31:57 PM Murray S. Kucherawy wrote: > >> On Sun, Jul 15, 2012 at 10:07 PM, Scott Kitterman wrote: > > ... > > > >>>> 4.3. Initial Processing > >>>> > >>>> If the is malformed (label longer than 63 characters, zero- > >>>> length label not at the end, etc.) or is not a fully qualified > >>>> domain > >>>> name, or if the DNS lookup returns "domain does not exist" (RCODE > >>>> 3), > >>>> check_host() immediately returns the result "none". > >>>> > >>>> [MSK: I suggest be defined in terms of whatever a > >>>> legal domain name is in [RFC5321], as amended by EAI, and > >>>> further require that it be fully-qualified. In terms of > >>>> I18N, we should just do what DKIM did to handle this case.] > >>> > >>> What did "DKIM do"? > >> > >> I'm referring to Section 3.5 of RFC6376, the definition of "d=". > > > > It says: > > Internationalized domain names MUST be encoded as A-labels, as > > described in Section 2.3 of [RFC5890]. > > > > I think that's fine. In a related point, I think we can dispose of the > > local- part macro/EAI issue similarly. > > DKIM had good reasons to do so: RFCs 6530-6533 were not published at > the time, and having d= tags as A-labels could avoid considerations > about UTF-8 completely. Neither of those are true for 4408bis. > > MAIL command can legally have UTF-8 addresses. SPF implementations > may request that parameters be converted by the caller, and prohibit > use of UTF-8 in SPF records. But they need to sanitize the arguments > they pass to (and receive from) the DNS software anyway, so they could > do IDNA calls as well. > > Disallowing UTF-8 in local explanations, including local-parts, sounds > arbitrarily against current trends. Using UTF-8 for both records and > parameters may make for smoother specs, implementations, and > deployment --especially in the long term. > > I don't think it will be any easier to switch to UTF-8 in some future > SPF version, possibly the opposite. Is that correct? > > Could we try and see how it works, or at least state the pros and cons > we'd expect? Current implementations don't deal with UTF-8. To the extent they might, they are buggy. I think that converting to an A-label is the best we can do without breaking backward compatibility, which, as I read the charter we aren't allowed to do for non-essential reasons. Given the level of EAI deployment, I don't think it's such a reason. I think full EAI compatibility needs to go into the stack of things to do in a future, non-backward compatible update. If EAI ever gets enough traction, that may be enough to drive it. I've been giving a little bit of thought to how to start experimentation with non-backwards compatible updates which I'll post about on spf-discuss (it's OT here) once my thoughts are a bit more fully formed. Scott K From superuser@gmail.com Mon Jul 16 13:00:22 2012 Return-Path: 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 9FA9821F88BB for ; Mon, 16 Jul 2012 13:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ag0N9Y-sqZa4 for ; Mon, 16 Jul 2012 13:00:21 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 58F2011E80E1 for ; Mon, 16 Jul 2012 13:00:21 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so8576617lbb.31 for ; Mon, 16 Jul 2012 13:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ERh5KH3SPwYAND83AXYXw9YJ4BBu2mRjklpEhT3qrOk=; b=kMajxGeyIgXG4pmo4vwqaNwOSBRvko4Drjm8vxTXa7jLpoQ202OyDL1SvK75bD32sp GyGw0YwLmKrn7K9dyXU41wat/inQaNCxXq6avxr5a0AsQWzgXN/w3m3YiTAlSASRdVCD qFSEoeDdJfnFcUL6BWzIJMIdXuC/kUb20y4fAs2uUP41OP0IgwChRtv4raWFgem4y34d aOpimgk6QOzQSb/sd2JOLQGc2iSpWMPh1Kma52cPf6/NlNvlKpaabl6FqnYab7IPCA3n /ex7og8p7bRcrJk6lOyvRXtvEPavdfiaeTjOIG0nUYYfIwwosqFzZL1rcxjQZL6Sla7u x1jw== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr12595852lab.47.1342468865833; Mon, 16 Jul 2012 13:01:05 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 16 Jul 2012 13:01:05 -0700 (PDT) In-Reply-To: <20120716105805.GB96149@mail.yitter.info> References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> Date: Mon, 16 Jul 2012 13:01:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=f46d0435c1d2debb7504c4f7e33e Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:00:22 -0000 --f46d0435c1d2debb7504c4f7e33e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 16, 2012 at 3:58 AM, Andrew Sullivan wrote: > We have positive evidence, in the form of published records with > local-part macros in them, that people are using this feature or at > least think they are. > > Given that is the case, it seems to me that we have a process issue > here. I'd like those who support deprecation or removal of the > feature to explain how their proposed action is consistent with the > charter we have. Dave Crocker has already offered his view, which is > (to oversimplify) that "unused" has a meaning slightly different from > its plain English meaning, and that local-part macros can therefore be > removed. What about the case for deprecation? > I concur with Dave, and the reasoning behind his position. Given the data available, both PTR and macros introduce complexity but, in the six years since SPF was first published as an Experimental RFC, have enjoyed approximately zero adoption (but not zero). They don't add enough utility to justify their added complexity. It's already been decided that PTR is to be deprecated, and our definition of "deprecated" here seems to be approximately what we want. Based on statistics gathered during our previous work, PTR and macros are in the same ballpark in terms of adoption. I believe we are being inconsistent if we don't apply the same logic to both of them. Since we are going out with the first version of SPF on the standards track, I would prefer not to include large chunks of text that have to do with things people aren't really using or things we don't want them to use anymore. This thing should be as lean as possible. Other working groups have gone through this process and used "unused" in a very-low-but-not-zero way. I cited DKIM as an example. I realize we're not bound by the process defined in RFC6410 because SPF is advancing to, but not along, the Standards Track. Rather, we're bound by our charter. I can say that when I crafted our charter, I had in mind the use of "unused" that I got from the previous work, i.e., almost-but-not-zero qualifies as "unused". I suppose it's a matter of conversation as to whether the IESG had the same assumption when they accepted it, since the charter is basically our operating agreement with them. -MSK --f46d0435c1d2debb7504c4f7e33e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 16, 2012 at 3:58 AM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
We have positive evidence, in the form of published records with
local-part macros in them, that people are using this feature or at
least think they are.

Given that is the case, it seems to me that we have a process issue
here. =A0I'd like those who support deprecation or removal of the
feature to explain how their proposed action is consistent with the
charter we have. =A0Dave Crocker has already offered his view, which is
(to oversimplify) that "unused" has a meaning slightly different = from
its plain English meaning, and that local-part macros can therefore be
removed. =A0What about the case for deprecation?

I= concur with Dave, and the reasoning behind his position.=A0 Given the data= available, both PTR and macros introduce complexity but, in the six years = since SPF was first published as an Experimental RFC, have enjoyed approxim= ately zero adoption (but not zero).=A0 They don't add enough utility to= justify their added complexity.

It's already been decided that PTR is to be deprecated, and our def= inition of "deprecated" here seems to be approximately what we wa= nt.=A0 Based on statistics gathered during our previous work, PTR and macro= s are in the same ballpark in terms of adoption.=A0 I believe we are being = inconsistent if we don't apply the same logic to both of them.

Since we are going out with the first version of SPF on the standards t= rack, I would prefer not to include large chunks of text that have to do wi= th things people aren't really using or things we don't want them t= o use anymore.=A0 This thing should be as lean as possible.

Other working groups have gone through this process and used "unus= ed" in a very-low-but-not-zero way.=A0 I cited DKIM as an example.=A0 = I realize we're not bound by the process defined in RFC6410 because SPF= is advancing to, but not along, the Standards Track.=A0 Rather, we're = bound by our charter.=A0 I can say that when I crafted our charter, I had i= n mind the use of "unused" that I got from the previous work, i.e= ., almost-but-not-zero qualifies as "unused".=A0 I suppose it'= ;s a matter of conversation as to whether the IESG had the same assumption = when they accepted it, since the charter is basically our operating agreeme= nt with them.

-MSK
--f46d0435c1d2debb7504c4f7e33e-- From spf2@kitterman.com Mon Jul 16 13:09:59 2012 Return-Path: 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 EB70A21F8832 for ; Mon, 16 Jul 2012 13:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599] 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 5+Fx-9aAUq6W for ; Mon, 16 Jul 2012 13:09:59 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id F3AC321F883C for ; Mon, 16 Jul 2012 13:09:58 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id AE0AED0407F; Mon, 16 Jul 2012 15:10:43 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342469443; bh=7gX2ZwrvZSIOGfGg2l87gparRD8J+3YA6Y1StwYWYHE=; h=References:In-Reply-To:Subject:From:Date:To:From; b=UNVYnb801ZVqTvuf/zcxetVdkWme/VyMHj8ndnnMex8sXiG51akAaCwSmImtoqKN/ W9l7OESHLlmA7XJlNJLLAMJwO4u5bU16SLSCF7vO0wWRL+rR4aw5B4LpqTALvY00vE opSuI96S1ZBjlOvXzwGzuD+ACA5I99wme1pLk/dc= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 369F8D04058; Mon, 16 Jul 2012 15:10:42 -0500 (CDT) References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 16 Jul 2012 16:10:40 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:10:00 -0000 "Murray S. Kucherawy" wrote: >On Mon, Jul 16, 2012 at 3:58 AM, Andrew Sullivan >wrote: > >> We have positive evidence, in the form of published records with >> local-part macros in them, that people are using this feature or at >> least think they are. >> >> Given that is the case, it seems to me that we have a process issue >> here. I'd like those who support deprecation or removal of the >> feature to explain how their proposed action is consistent with the >> charter we have. Dave Crocker has already offered his view, which is >> (to oversimplify) that "unused" has a meaning slightly different from >> its plain English meaning, and that local-part macros can therefore >be >> removed. What about the case for deprecation? >> > >I concur with Dave, and the reasoning behind his position. Given the >data >available, both PTR and macros introduce complexity but, in the six >years >since SPF was first published as an Experimental RFC, have enjoyed >approximately zero adoption (but not zero). They don't add enough >utility >to justify their added complexity. > >It's already been decided that PTR is to be deprecated, and our >definition >of "deprecated" here seems to be approximately what we want. Based on >statistics gathered during our previous work, PTR and macros are in the >same ballpark in terms of adoption. I believe we are being >inconsistent if >we don't apply the same logic to both of them. > >Since we are going out with the first version of SPF on the standards >track, I would prefer not to include large chunks of text that have to >do >with things people aren't really using or things we don't want them to >use >anymore. This thing should be as lean as possible. > >Other working groups have gone through this process and used "unused" >in a >very-low-but-not-zero way. I cited DKIM as an example. I realize >we're >not bound by the process defined in RFC6410 because SPF is advancing >to, >but not along, the Standards Track. Rather, we're bound by our >charter. I >can say that when I crafted our charter, I had in mind the use of >"unused" >that I got from the previous work, i.e., almost-but-not-zero qualifies >as >"unused". I suppose it's a matter of conversation as to whether the >IESG >had the same assumption when they accepted it, since the charter is >basically our operating agreement with them. Except being unused was not part of the rationale for deprecating PTR. The rationale was that it didn't work well, was unreliable, and was unnecessary. Unused didn't figure into it at all. There's no inconsistency here. I think it's within the charter to deprecate (but not remove) anything we conclude is technically a bad idea, used or not. Scott K From dhc@dcrocker.net Mon Jul 16 13:28:38 2012 Return-Path: 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 BF07D11E80A3 for ; Mon, 16 Jul 2012 13:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PLAj4vQQT17h for ; Mon, 16 Jul 2012 13:28:37 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CF90211E8085 for ; Mon, 16 Jul 2012 13:28:37 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6GKTNDF010128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Jul 2012 13:29:23 -0700 Message-ID: <50047996.6090106@dcrocker.net> Date: Mon, 16 Jul 2012 13:29:10 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 16 Jul 2012 13:29:23 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:28:38 -0000 On 7/16/2012 1:10 PM, Scott Kitterman wrote: > Except being unused was not part of the rationale for deprecating PTR. The rationale was that it didn't work well, was unreliable, and was unnecessary. Unused didn't figure into it at all. There's no inconsistency here. > > I think it's within the charter to deprecate (but not remove) anything we conclude is technically a bad idea, used or not. As I recall, we also saw very poor statistics of use for PTR and that that /did/ factor into the group's decision process. In any event, the charter authorizes removal of 'unused' feature, module agreeing on the meaning of unused... The distinction between deprecating versus removing can be pursued separately, IMO. It's important but independent. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Mon Jul 16 13:30:26 2012 Return-Path: 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 BC1AB11E8149 for ; Mon, 16 Jul 2012 13:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 cc-EW6cmbbOX for ; Mon, 16 Jul 2012 13:30:26 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA61B11E80A3 for ; Mon, 16 Jul 2012 13:30:25 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so8609182lbb.31 for ; Mon, 16 Jul 2012 13:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EhJQ70DkXkB/4TdPzNdmsOsKgCRpb1KlZtlZZQOJgpc=; b=qI26kUYhH/epX9i1tfQbD6UC/XnQfs3Qn6Wi5bLAwLASA2tlE+VoPBljv9SiJq5S/r KoGueO45Utccs/al2A2fCN2t1I9lwKjlP/W8SkS4oeeK+kueV97cpM6q0oh4F7NLfOjy k76GPL9pf6LtHeLzEhSdnvn78GfTjvzWQgmjK2U39WVkLgTD6ZC90xOnZKgRELJWdhlp lRvNhmO9y0oB4TROhf2pF9CyMyczrt8hmQcnlipRfF106H5G1qMWq/C6zXNUvvkipnNs 0XA8NorNhh79HZkseb7a31QMF3B5wMlECDLvemCWIb78bwcYEG/9vGeAEEmr6MdGs8+P eMHA== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr12746113lab.40.1342470670688; Mon, 16 Jul 2012 13:31:10 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 16 Jul 2012 13:31:10 -0700 (PDT) In-Reply-To: References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> Date: Mon, 16 Jul 2012 13:31:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d040838d372a37304c4f84f0f Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:30:26 -0000 --f46d040838d372a37304c4f84f0f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 16, 2012 at 1:10 PM, Scott Kitterman wrote: > > Except being unused was not part of the rationale for deprecating PTR. The > rationale was that it didn't work well, was unreliable, and was > unnecessary. Unused didn't figure into it at all. There's no > inconsistency here. > I think something that sees use by less than 0.2% of the user base qualifies as "unnecessary" as well. I don't have any data about the reliability question. -MSK --f46d040838d372a37304c4f84f0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 16, 2012 at 1:10 PM, Scott Kitterman <spf2@kitterman.com&= gt; wrote:

Except being unused was not part of the rationale for deprecati= ng PTR. The rationale was that it didn't work well, was unreliable, and= was unnecessary. =A0Unused didn't figure into it at all. =A0There'= s no inconsistency here.

I think something that sees use by less than 0.2% of = the user base qualifies as "unnecessary" as well.=A0 I don't = have any data about the reliability question.

-MSK


--f46d040838d372a37304c4f84f0f-- From hsantos@isdg.net Mon Jul 16 13:30:40 2012 Return-Path: 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 8371511E8149 for ; Mon, 16 Jul 2012 13:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 kgd7q0SdSj8G for ; Mon, 16 Jul 2012 13:30:39 -0700 (PDT) Received: from secure.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4D02B11E80A3 for ; Mon, 16 Jul 2012 13:30:38 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3702; t=1342470673; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=7wAY1fdU4/w3hE5fTiO6tdV9cmA=; b=aor7AlEMH4vmsYO9a+Dd 1R9hZRY3/X1IFgaBxCW+cdOnq6v1wOwaYZNHz1/FHsKA+x7Lsr/wWRGq5n/HUEkd p1zGBEanOvR2kENYsguCtZKmPyOfqK5+6W3RPRQ8HKashUZK5jdAplrMOYGbgWcL kkq5010gnHV8b4mYRfW51rA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 16 Jul 2012 16:31:13 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2787474529.15339.2692; Mon, 16 Jul 2012 16:31:12 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3702; t=1342470548; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=BHl9VZH G21nLlCAa3mMEdYU0y7L4gKk4HuITL+vGGpc=; b=jYKFCLeRv+wFMs3ioaKgyF4 Yg4Mw6sv5oOjdWQPGBk7V9djId0lfVAZfo/3XZdDfYOF2DjYrpvcoxwonReLyNnS qTHM3S9wGmPcbz89+SlygDVUBw8gM/XpO1UQ4mKRCCRd+2nAvCsbulz4uuBbl7uY Aoo4EL+GhR/1r6qvFkZ0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 16 Jul 2012 16:29:08 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3386314191.9.2672; Mon, 16 Jul 2012 16:29:08 -0400 Message-ID: <50047A0F.5050907@isdg.net> Date: Mon, 16 Jul 2012 16:31:11 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] SPF and EAI X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:30:40 -0000 Murray S. Kucherawy wrote: > On Mon, Jul 16, 2012 at 3:58 AM, Andrew Sullivan wrote: > >> We have positive evidence, in the form of published records with >> local-part macros in them, that people are using this feature or at >> least think they are. >> >> Given that is the case, it seems to me that we have a process issue >> here. I'd like those who support deprecation or removal of the >> feature to explain how their proposed action is consistent with the >> charter we have. Dave Crocker has already offered his view, which is >> (to oversimplify) that "unused" has a meaning slightly different from >> its plain English meaning, and that local-part macros can therefore be >> removed. What about the case for deprecation? >> > > I concur with Dave, and the reasoning behind his position. Given the data > available, both PTR and macros introduce complexity but, in the six years > since SPF was first published as an Experimental RFC, have enjoyed > approximately zero adoption (but not zero). They don't add enough utility > to justify their added complexity. Either we are mixing apples and oranges at this point, does my 16% snapshot usage of incoming SPF statements with PTR command still doesn't mean anything? > It's already been decided that PTR is to be deprecated, and our definition > of "deprecated" here seems to be approximately what we want. I would like to see when when exactly there was a clear group rough consensus, time frame and/or with a link decision to deprecate the PTR. It must of been some off-list discussion because I don't recall such a public decision. What I do recall was a wide agreement that there shouldn't be a security problem because of the limits already written and used in practice thus why there was never a problem before. > Since we are going out with the first version of SPF on the standards > track, I would prefer not to include large chunks of text that have to do > with things people aren't really using or things we don't want them to use > anymore. This thing should be as lean as possible. But PTR is being used and with proper usages, understanding, controlled and and no harm. Where in your deployment information does it show otherwise? > Other working groups have gone through this process and used "unused" in a > very-low-but-not-zero way. I cited DKIM as an example. I realize we're > not bound by the process defined in RFC6410 because SPF is advancing to, > but not along, the Standards Track. Rather, we're bound by our charter. I > can say that when I crafted our charter, I had in mind the use of "unused" > that I got from the previous work, i.e., almost-but-not-zero qualifies as > "unused". I suppose it's a matter of conversation as to whether the IESG > had the same assumption when they accepted it, since the charter is > basically our operating agreement with them. Well, things are know to fall thru the crack and this appears to be one of them. You can't lump such generality like this to pull the rug from deployment feet. This cause time and money and when they don't see a good reason to listen, they won't. Do you honestly believe SPF receivers are going to stop supporting features that COULD OCCUR even thing in your mind believe it is "unused?" Even if you believe its 1% usage, today there is 0% ERROR because of it. Deprecation means at least 1% ERROR rate and a presumption everyone will follow the NEW SPF and thus go down to zero. How long do you expect that to happen? No matter what, the so called "complexity" still need to be coded in order to support any presumed legacy of PTR usage. -- HLS From sm@elandsys.com Mon Jul 16 17:42:59 2012 Return-Path: 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 5E70611E80FB for ; Mon, 16 Jul 2012 17:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 W76UyzU3laaX for ; Mon, 16 Jul 2012 17:42:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 325A511E80E5 for ; Mon, 16 Jul 2012 17:42:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.167]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6H0hQEv021950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2012 17:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342485819; bh=oGLucQgODZRFuHDJVQna6jooE2Rzh2cAGOTFhF+Wbz8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cASMuWn2TvkTQV6Twp0gHXsamdeeqTohtWPaauWUoXZMJjsSaMRu6ioz9+8QCMltU 3S7QcBoXrsoq7aVoL4wKUB4bY4QV7ZOlg/JmwzjVgEetvf0bKv+LaXmmsKf/5absG5 +EnT56PT3ZRdlQRSHZr7G9djzaECC+z/KpH48oL4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342485819; i=@elandsys.com; bh=oGLucQgODZRFuHDJVQna6jooE2Rzh2cAGOTFhF+Wbz8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=r56+IxBvWU7XNzgj5Ad96RLFnt36JPAF7mnxnuR1f47fKncs275O5vTmG7+fpYnia 9z+3BDQlN0Ym4py1LohnFYEi6LTMqXMInYIEf8kvlZjAMFth0UKHiJZOV/1hKOr6A5 l2kT7H/ITBv9xyJLcxuvbSx3EEOKRiq7SPy3Kz+o= Message-Id: <6.2.5.6.2.20120716171913.08c8be40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 16 Jul 2012 17:41:08 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <50047A0F.5050907@isdg.net> References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> <50047A0F.5050907@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: [spfbis] Issue #27 (was: SPF and EAI) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 00:42:59 -0000 At 13:31 16-07-2012, Hector Santos wrote: >I would like to see when when exactly there was a clear group rough >consensus, time frame and/or with a link decision to deprecate the >PTR. It must of been some off-list discussion because I don't >recall such a public decision. On March 7, Arthur Thisell raised an issue about deprecating the "ptr: mechanism and the %{p} macro" (Issue #27). The following is from the minutes for the SPFBIS session at IETF83: Issue #27 is about the PTR mechanism and %{p} macro. There was support on the mailing list for adding "SHOULD NOT" text about this. There was support for "SHOULD NOT" from the Jabber room. The issue was closed pending the new document. I posted a message to the WG mailing list about the minutes ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01482.html ). Regards, S. Moonesamy SPFBIS WG co-chair From johnl@iecc.com Mon Jul 16 22:08:48 2012 Return-Path: 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 859D521F8570 for ; Mon, 16 Jul 2012 22:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.136 X-Spam-Level: X-Spam-Status: No, score=-111.136 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 JVr6PiNjWlxV for ; Mon, 16 Jul 2012 22:08:47 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 19D6921F856D for ; Mon, 16 Jul 2012 22:08:46 -0700 (PDT) Received: (qmail 88209 invoked from network); 17 Jul 2012 05:09:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Jul 2012 05:09:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5004f38c.xn--9vv.k1207; i=johnl@user.iecc.com; bh=B+73Pbyhtk0Vd/r4IxxHoqmjlgl269mnhIjcXPamj/M=; b=C5Ghzxida9lsj9BcDGS+2c/W9itxo9AG8pK6jAn92B3c92D6MyN6cRRZbh8LcKe3wfZA3f1YDelJKTQUk/bza3pBRV0QW0PlbyhiT4G1S+7D6Yi3xvuo4u0QuuTg/GQSTtieAau9/wc0MO1WOUCUg0NFulBvNR+8OqF3OIPXesA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5004f38c.xn--9vv.k1207; olt=johnl@user.iecc.com; bh=B+73Pbyhtk0Vd/r4IxxHoqmjlgl269mnhIjcXPamj/M=; b=NmtZqW1lm5JvBulw6HWIeUQBRuyT6KSSAMVYYA82C50hFKSaTSOEve4Eej07/0NJ/k4qqGuARtu9+yRif7vNlEylwNKUVMScxQDJHMa/ZPRiOI9T1D931YCNFcltXfK8rSwY4xc62OhLrO3c+xh7D8XJ9MGE3OmTM0zVQqkAW3Q= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 17 Jul 2012 05:09:10 -0000 Message-ID: <20120717050910.11760.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20120716105805.GB96149@mail.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ajs@anvilwalrusden.com Subject: Re: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 05:08:48 -0000 >Given that is the case, it seems to me that we have a process issue >here. I'd like those who support deprecation or removal of the >feature to explain how their proposed action is consistent with the >charter we have. As far as I can tell, localpart macros are no more popular than type 99 records. In both cases, we've found some people publishing them, but it's down in the noise. Also, in both cases, the current spec is broken. For localpart macros, the problem is that localparts can contain any character from %d32 (space) through %d126 (tilde), which includes a lot of characters that aren't valid in host names, don't normally occur in DNS names (particularly given the provisioning problems in DNS names that contain characters like spaces and backslashes), and in the exp: context, can be syntactically significant in URLs such as / & ? and %. While there's an option to percent-encode localparts, it's just an option. EAI will make this much worse, but it's broken now without EAI. While this is fixable, given how little used it is, it makes more sense to deprecate it than to waste time trying to harden it. That's particularly true because hardening would probably require treating syntactically interesting characters differently, and that opens a whole can of worms of backward compatibility with largely non-existent current practice. I realize that nobody's reported problems with hostile characters blowing up localpart macros, but I think it's likely that's because so few people use them that the code has never been stressed, not because it's robust. I suppose I can concoct some SPF records with localpart expansions, start firing mail with funky localparts at Scott and other people who use SPF, and see what happens. R's, John From spf2@kitterman.com Tue Jul 17 08:35:27 2012 Return-Path: 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 EAE6421F86B8 for ; Tue, 17 Jul 2012 08:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599] 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 H32ceMwlwxGg for ; Tue, 17 Jul 2012 08:35:25 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 87A8221F86B6 for ; Tue, 17 Jul 2012 08:35:25 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6A53020E40BD; Tue, 17 Jul 2012 11:36:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342539372; bh=MOi5sEaF1gPFgsQIOs9n7cAscKNBxmqkx9TfM3c2JkI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kBxkv3Ny6OG2DL+egEjBapdJUv30ijN/rCkCYDlzuLYgr4xMKOxPsX74Yzo9v9xLI BBxg5wBkx4+8V8I56/1UZCeeJFs1stLUsaoP4vIzG+Ibs6PPdyTu/p8YRpdcHt05NI bIjn1vUdiHWTOBETEopYpomgZXPsBsD3dfKhkKA0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4F97820E409F; Tue, 17 Jul 2012 11:36:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 17 Jul 2012 11:36:11 -0400 Message-ID: <1725764.tjgqxi0i3Z@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120717050910.11760.qmail@joyce.lan> References: <20120717050910.11760.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 15:35:28 -0000 On Tuesday, July 17, 2012 05:09:10 AM John Levine wrote: > >Given that is the case, it seems to me that we have a process issue > >here. I'd like those who support deprecation or removal of the > >feature to explain how their proposed action is consistent with the > >charter we have. > > As far as I can tell, localpart macros are no more popular than type > 99 records. In both cases, we've found some people publishing them, > but it's down in the noise. > > Also, in both cases, the current spec is broken. For localpart > macros, the problem is that localparts can contain any character from > %d32 (space) through %d126 (tilde), which includes a lot of characters > that aren't valid in host names, don't normally occur in DNS names > (particularly given the provisioning problems in DNS names that > contain characters like spaces and backslashes), and in the exp: > context, can be syntactically significant in URLs such as / & ? and %. > While there's an option to percent-encode localparts, it's just an > option. EAI will make this much worse, but it's broken now without > EAI. > > While this is fixable, given how little used it is, it makes more > sense to deprecate it than to waste time trying to harden it. That's > particularly true because hardening would probably require treating > syntactically interesting characters differently, and that opens a > whole can of worms of backward compatibility with largely non-existent > current practice. > > I realize that nobody's reported problems with hostile characters > blowing up localpart macros, but I think it's likely that's because so > few people use them that the code has never been stressed, not because > it's robust. I suppose I can concoct some SPF records with localpart > expansions, start firing mail with funky localparts at Scott and other > people who use SPF, and see what happens. I don't have a strong objection to deprecation. I do object to removal. One factor that is different than PTR and Type 99 though is that we (or at least I) concluded that neither of those features were needed to support any unique functional requirements. You could remove/deprecate them and not affect the ability of ADMDs to publish SPF records that accomplished everything they did with records based on RFC 4408. Removal/deprecation of macros does impact at least one use case that's difficult to replicate and there might be others. I don't have personal knowledge of how or why publishers actually use macros in the wild except for the logging record suggested in RFC 4408 section 9.1: v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all Trying to figure out SPF deployments is hard. The above use of macros is one of the few reliable ways to get feedback on where receivers think your mail is coming from (yes, we have RFC 6652 and perhaps DMARC at some point in the future, but neither of those mechanisms have the deployment to support being a full replacement for this use of macros). Deprecation does not immediately harm ADMDs making use of macros and, if it turns out there's a need in the future, could conceivably be reversed. Before going beyond that point (i.e. removal) we need to understand what unique use cases the small fraction of ADMDs that use macros are using them for to see if we are dropping functionality that leaves valid (if narrow) use cases unaddressed. Scott K From ajs@anvilwalrusden.com Tue Jul 17 09:29:40 2012 Return-Path: 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 B9F9321F8628 for ; Tue, 17 Jul 2012 09:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 96r80S1PcA2R for ; Tue, 17 Jul 2012 09:29:40 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA9E21F84EE for ; Tue, 17 Jul 2012 09:29:40 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 0BC7C8A031 for ; Tue, 17 Jul 2012 16:30:26 +0000 (UTC) Date: Tue, 17 Jul 2012 12:30:25 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120717163025.GT96149@mail.yitter.info> References: <20120717050910.11760.qmail@joyce.lan> <1725764.tjgqxi0i3Z@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1725764.tjgqxi0i3Z@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 16:29:40 -0000 Still hatted. Maybe it's cooking my brain, but . . . On Tue, Jul 17, 2012 at 11:36:11AM -0400, Scott Kitterman wrote: > One factor that is different than PTR and Type 99 though is that we (or at > least I) concluded that neither of those features were needed to support any > unique functional requirements. You could remove/deprecate them and not affect > the ability of ADMDs to publish SPF records that accomplished everything they > did with records based on RFC 4408. > > Removal/deprecation of macros does impact at least one use case that's difficult > to replicate and there might be others. the above the "process issue" I was referring to. The argument is that we can remove local part macros because we have scanty evidence of their use; but as Scott is pointing out, they provide a piece of functionality otherwise unavailable, and we have detected their use (at least, their publication). Moreover, _all_ our evidence about SPF is scanty: we didn't do the kind of widespread investigation that would allow us to make highly defensible strong statements about SPF. That seemed ok to me as the basis for experiment conclusion, given the way our charter constrained us. If we're now going to use that evidence as a reason to remove a capability (one that I personally dislike), then I worry we are exceeding our permitted activities. If people are really going to push this, then I want to have a discussion with my co-chair and our AD about the matter. One might well argue that we _should_ be free to remove this feature, both because it is little used and because it is dangerous. (On the latter, I still am mulling over John Levine's argument.) That isn't the same thing as saying that our charter permits us that freedom. So far, I haven't convinced myself. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc@dcrocker.net Tue Jul 17 09:42:48 2012 Return-Path: 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 8947321F865C for ; Tue, 17 Jul 2012 09:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Ce4AFDfQmNtR for ; Tue, 17 Jul 2012 09:42:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E1CB221F866B for ; Tue, 17 Jul 2012 09:42:46 -0700 (PDT) Received: from [192.168.1.9] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6HGhYTp019318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Jul 2012 09:43:34 -0700 Message-ID: <50059627.7040502@dcrocker.net> Date: Tue, 17 Jul 2012 09:43:19 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <20120717050910.11760.qmail@joyce.lan> <1725764.tjgqxi0i3Z@scott-latitude-e6320> In-Reply-To: <1725764.tjgqxi0i3Z@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 17 Jul 2012 09:43:34 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 16:42:48 -0000 On 7/17/2012 8:36 AM, Scott Kitterman wrote: > I don't have a strong objection to deprecation. I do object to removal. fwiw, I'm fine with deprecating rather than removal. I'd prefer removal, but would consider it progress to mark the feature deprecated. if/when the group does choose deprecated, I think we'll need a separate thread to get consensus on its precise meaning. (I would prefer that we /not/ debate the issue right now.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Tue Jul 17 09:57:33 2012 Return-Path: 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 EEDE721F86C2 for ; Tue, 17 Jul 2012 09:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599] 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 IEE2EgHdRUT5 for ; Tue, 17 Jul 2012 09:57:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 16C2E21F86A2 for ; Tue, 17 Jul 2012 09:57:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9075720E40BD; Tue, 17 Jul 2012 12:58:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342544296; bh=+xNtCSe6uUJ7OSQkQdZtDRp7AKtXycNl63aGK59IJ6A=; h=From:To:Subject:Date:In-Reply-To:References:From; b=X7imhgml400dWWhM9nD0CiLj1ItE9avnUh8yyU/9B2p8eLtgGkWa3xe2mIuX6vqHi 48UBpfvlskqerA6wUvAfF9kQrk3AfIWEq0DqFDm9kvFJswSu0jndlUHwwE9nN04DNL 6O57QI6eRL1yrP3zT4jshsatW64GGMSlyQFcnKtE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 731B320E409F; Tue, 17 Jul 2012 12:58:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 17 Jul 2012 12:58:15 -0400 Message-ID: <2140160.ATBEx5Nbps@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50059627.7040502@dcrocker.net> References: <20120717050910.11760.qmail@joyce.lan> <1725764.tjgqxi0i3Z@scott-latitude-e6320> <50059627.7040502@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Deprecated X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 16:57:34 -0000 On Tuesday, July 17, 2012 09:43:19 AM Dave Crocker wrote: > On 7/17/2012 8:36 AM, Scott Kitterman wrote: > > I don't have a strong objection to deprecation. I do object to removal. > > fwiw, I'm fine with deprecating rather than removal. I'd prefer > removal, but would consider it progress to mark the feature deprecated. > > if/when the group does choose deprecated, I think we'll need a separate > thread to get consensus on its precise meaning. (I would prefer that we > /not/ debate the issue right now.) Unless we know what deprecated means, we can hardly make a decision to do it. I think the definition needs to come first. The current -03 draft (I have a comment from msk to clean this up a bit, but it doesn't affect the meaning) is: 1.3.4. Deprecated There are several [RFC4408] features that are marked "deprecated". In the context of this document, deprecated means that senders SHOULD NOT publish SPF records that make use of the feature in question. Its use is NOT RECOMMENDED and it might be removed entirely in future updates to the protocol. Such features do, however, remain part of the SPF protocol and receiving systems MUST support them unless this specification says otherwise. As I mentioned earlier, this is different than the 5321 definition of obsolete primarily by virtue of being a SHOULD NOT vice a MUST NOT. Since PTR and the "p" macro are already marked deprecated based on previous WG discussion, if this isn't the definition we want, I think now is the time to find out. Scott K From dotzero@gmail.com Tue Jul 17 10:41:33 2012 Return-Path: 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 C5ED821F860D for ; Tue, 17 Jul 2012 10:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 IQomWFtqHt3Q for ; Tue, 17 Jul 2012 10:41:32 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D825021F85EA for ; Tue, 17 Jul 2012 10:41:32 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1183278pbc.31 for ; Tue, 17 Jul 2012 10:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HQnL4D3AD2MWeIQyBLeosa4DEsCHVcZd1gYPbZxgCgE=; b=m57pcJHW399YhzpJWB7/YRH2rPnSbF6lmj8g9fYyjsgE16j0xenA8Rx7AzE8WOqqls 4xLtSIw2d1qyW0na87KuQs87na+MKDbofFnLTr6QJMXz4BhYq31EZr8khyY9Me5/0eDT jIROgtIKdOpPhtrTwwyMsnFuauakoRb7vWp0s3nSHOgsHYVtHxeXPioHRP8/+bqDHl5L J8RnBctzB/rG2F/ZRCNGZ75UzLlAUI+f2Uj8GELHEjQxEM2PzWhj59zaXwgqu4MRzzoG nNwpEewucP1IkwdSEf4ah1TJy7P3kbN9PGroc7PO2qyd7995/PYq7cv9YrgpBu7W0gUs HK+A== MIME-Version: 1.0 Received: by 10.68.231.10 with SMTP id tc10mr435374pbc.107.1342546940874; Tue, 17 Jul 2012 10:42:20 -0700 (PDT) Received: by 10.68.19.170 with HTTP; Tue, 17 Jul 2012 10:42:20 -0700 (PDT) In-Reply-To: <20120717163025.GT96149@mail.yitter.info> References: <20120717050910.11760.qmail@joyce.lan> <1725764.tjgqxi0i3Z@scott-latitude-e6320> <20120717163025.GT96149@mail.yitter.info> Date: Tue, 17 Jul 2012 13:42:20 -0400 Message-ID: From: Dotzero To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 17:41:33 -0000 On Tue, Jul 17, 2012 at 12:30 PM, Andrew Sullivan wrote: > Still hatted. Maybe it's cooking my brain, but . . . > > On Tue, Jul 17, 2012 at 11:36:11AM -0400, Scott Kitterman wrote: >> One factor that is different than PTR and Type 99 though is that we (or at >> least I) concluded that neither of those features were needed to support any >> unique functional requirements. You could remove/deprecate them and not affect >> the ability of ADMDs to publish SPF records that accomplished everything they >> did with records based on RFC 4408. >> >> Removal/deprecation of macros does impact at least one use case that's difficult >> to replicate and there might be others. > > the above the "process issue" I was referring to. The argument is > that we can remove local part macros because we have scanty evidence > of their use; but as Scott is pointing out, they provide a piece of > functionality otherwise unavailable, and we have detected their use > (at least, their publication). > > Moreover, _all_ our evidence about SPF is scanty: we didn't do the > kind of widespread investigation that would allow us to make highly > defensible strong statements about SPF. That seemed ok to me as the > basis for experiment conclusion, given the way our charter constrained > us. If we're now going to use that evidence as a reason to remove a > capability (one that I personally dislike), then I worry we are > exceeding our permitted activities. If people are really going to > push this, then I want to have a discussion with my co-chair and our > AD about the matter. > > One might well argue that we _should_ be free to remove this feature, > both because it is little used and because it is dangerous. (On the > latter, I still am mulling over John Levine's argument.) That isn't > the same thing as saying that our charter permits us that freedom. So > far, I haven't convinced myself. > > Best, > > A > I lean towards deprecation. I would have leaned that way even before John Levines argument but that just strengthens my position. Even if some small protion of the implementation universe feels there is value, I do believe that as we move from Experimental to Standards Track it is important for us to consider how local part macros fir in with the overall goal and whether we expect additional adoption beyond the small core of advocates, many of whom have been SPF activists since day 1 (MARID). I don't take this position lightly and in fact, going into the SPFbis process I was willing to leave well enough alone simply to see things move forward. I'm now convinced that it is appropriate to consider the future of local part macros and whether to deprecate or even remove them from the standard. Mike From sm@elandsys.com Tue Jul 17 11:20:21 2012 Return-Path: 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 D08B021F861F for ; Tue, 17 Jul 2012 11:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 VbTre0EZu1aZ for ; Tue, 17 Jul 2012 11:20:19 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC2C21F861D for ; Tue, 17 Jul 2012 11:20:18 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.85]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6HIKpJ6024192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2012 11:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342549265; bh=4OMvYf8g+INib2ucdiOAyf4FkFwVUwYGbIU0KylPUVo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=LBLpMrNL2cSCDlljT27HZYXrO3hrZ0xeWpBNPL6k6mflriM4RaUiWvsax4OVuwG38 HvKF5pFmP2dhAKxJzLdB2JRkkNln11MZYenkyIUK34RVHvDyqIAqo+DOkTCsrQ03fY r27tmLrMl0HaRWozYLQjNGTb92OFQFfV6N9aOVOM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342549265; i=@elandsys.com; bh=4OMvYf8g+INib2ucdiOAyf4FkFwVUwYGbIU0KylPUVo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=r/pNXjCGLd3KKVObi9mwgj0VyFdiR9X2W+rV9tL99/oVbJHH+qXbXwrP/luBRh0+M 1XIhXmojXiGuuqgw7C8WBTQ5SYgUvhQm7t+cYP5zJpTRI1890Fdc1c0Tj3QY5WeY/L WqlTAr9xW9DoY9GwkOkn1q+2WxwSjETMcgHvMbXo= Message-Id: <6.2.5.6.2.20120717090109.08c3f6e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Jul 2012 10:59:39 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120717050910.11760.qmail@joyce.lan> References: <20120716105805.GB96149@mail.yitter.info> <20120717050910.11760.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 18:20:22 -0000 At 22:09 16-07-2012, John Levine wrote: >As far as I can tell, localpart macros are no more popular than type >99 records. In both cases, we've found some people publishing them, >but it's down in the noise. I'll pick the above as a starting point. The WG Chair asked the following question [1]: "What about the case for deprecation?" In my view the issue of SPF RR Type and TXT RR was about choosing one of the two RRs. The WG Chair previously mentioned that: "The were people on the mailing list in favor of using the TXT RR appeared to be a modest majority and there were people who argued for SPF RR Type on the grounds of DNS hygiene. The Chair explained that it appears as an empirical matter, overwhelmingly, the TXT RR is used but RRTYPE 99 does not qualify under the unused provision of the SPFBIS charter." There was also Issue #14 and the following was mentioned: 'Nobody argued that the working group must deprecate local-part macros. The Chair closed the issue with "won't fix". The Chair will reconsider the issue if there is text to go in the Security considerations section of the document. John Levine pointed out that as there is only one person in favor of the argument, it should be closed.' 'Pete Resnick, as Area Director, explained what he understood from the discussion of Issue #14: the working group sufficiently considered the issue and agreed not to deprecate the feature; it can add clarification in the Security Considerations section.' I'll quote John Leslie [2] out of context: 'Besides, "deprecate" is not "remove"...' I would not use that in an explanation if the working group is asked about the conclusion of the "local-part" issue. Scott Kitterman mentioned that he does not have a strong objection to deprecation [3]. John Levine mentioned that "the current spec is broken" [4]. That argument probably came up in the arguments about Issue #14. There was agreement previously not to deprecate the feature. There is new information available. Even if there isn't any objection against deprecation I would still like to see comments from WG participants about the case for deprecation. If you have not commented yet please do. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg01845.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg01848.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg01871.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg01870.html From hsantos@isdg.net Tue Jul 17 11:41:52 2012 Return-Path: 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 5021D21F86B3 for ; Tue, 17 Jul 2012 11:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.032 X-Spam-Level: X-Spam-Status: No, score=-102.032 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, SARE_SUB_PCT_LETTER=0.784, 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 YmLn4Rc4SJp0 for ; Tue, 17 Jul 2012 11:41:51 -0700 (PDT) Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF8021F8480 for ; Tue, 17 Jul 2012 11:41:51 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3280; t=1342550551; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=i/CeUqWH5JRHiHukyWXrs1p7qY8=; b=vFOr7R8IGQsxnezrGSh9 N4623vPoSeCVHQ8UuLSvqkc7K844gVuRvA+8tYLOz5PW4QO/8BNjJqaIR2nUvdW9 lO4cf23Ukzascq9DG2uho7Ina830jidzI+vxN2smX69rvI28vgQTuLdg1EaV61Ck boBwueN9+RND0h7t+P1K5t4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 17 Jul 2012 14:42:31 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2867350473.16202.4616; Tue, 17 Jul 2012 14:42:29 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3280; t=1342550421; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=C9aUOIM 5g9boDmOiYtQICGKwJgDtgimuWwTtyU3apH4=; b=A5tZkyjDi1olYH/0O4cghR1 aOlc6Nr0P602RXJo+M+T5G5MiK6H2K1WbK0tqF/jtZwEqIvVZ1+MY3jDkQ/TYe4C z8QibDMHvCqCVE/uSvi6cEnCLvV/iHUYOyvr3EcjEDGPjHiT53Ntnpbqvl/MjaeA SQrdh3q+Qawo1SpSj0eM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 17 Jul 2012 14:40:21 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3466187223.9.3684; Tue, 17 Jul 2012 14:40:21 -0400 Message-ID: <5005B227.6070803@isdg.net> Date: Tue, 17 Jul 2012 14:42:47 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> <50047A0F.5050907@isdg.net> <6.2.5.6.2.20120716171913.08c8be40@resistor.net> In-Reply-To: <6.2.5.6.2.20120716171913.08c8be40@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Andrew Sullivan Subject: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 18:41:52 -0000 SM, thanks for your follow up: IMV, there are apples and oranges being mixed up in this SPF WG thread. I am wondering if I should bother to bring that up but I don't think it is very clear what is exactly wanted and seems to be going going over board by lumping it all together - PTR directive and %p macro. My recollection in the IETF83 Jabber session was that it wasn't cut and dry and Andrew wanted to get list input to make the case for/against. I don't recall seeing many inputs here, if only Doug Otis I seem to recall. My position was always that SPF receivers can not practically remove support (for backward compatibility reasons) and specifically for PTR. Macros such as %p I already felt was more unnecessary, has less utility (IMV) and sure, it is hardly used. But PTR itself is very popular and perhaps I was too naive to believe anyone would take it serious to remove a high utility item instantly creating errors for SPF sessions. No matter what, SPF receivers MUST support it. Recommending Publishers not use it is another thing, so perhaps this is more about a BCP. PTR appears to me to be among the highest use directive among the cache I see and we should not be surprise because the WIZARDS out there makes it part of the easy setup defaults. By far, the #1 SPF statement (among my cache) is: v=spf1 a mx ptr ~all Now, it seems we are mixing apples and oranges here with inconsistent reasons for deprecation either PTR or %p or both: - Scott has a Slowness reason written in 03 - I believe Doug cited security reasons, and now - Several has indicated "unused" reasons, and - Some indicated a complexity reason for new developers. So I think there are different angles to how the features is viewed. As I recall, the main reason against deprecation was that it was under control with limits as there was no security issue. Nonetheless, with PTR itself, we will be losing a high utility in functionality and what it offers. Using the PTR directive makes it dynamic for 1 to MANY IP::A records sites to use a simple SPF policy command like above created by a number of wizards. -- HLS S Moonesamy wrote: > At 13:31 16-07-2012, Hector Santos wrote: >> I would like to see when when exactly there was a clear group rough >> consensus, time frame and/or with a link decision to deprecate the >> PTR. It must of been some off-list discussion because I don't recall >> such a public decision. > > On March 7, Arthur Thisell raised an issue about deprecating the "ptr: > mechanism and the %{p} macro" (Issue #27). > > The following is from the minutes for the SPFBIS session at IETF83: > > Issue #27 is about the PTR mechanism and %{p} macro. There was > support on > the mailing list for adding "SHOULD NOT" text about this. There was > support > for "SHOULD NOT" from the Jabber room. The issue was closed pending > the new > document. > > I posted a message to the WG mailing list about the minutes ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01482.html ). > > Regards, > S. Moonesamy > SPFBIS WG co-chair > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From superuser@gmail.com Tue Jul 17 11:47:49 2012 Return-Path: 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 884AA21F867F for ; Tue, 17 Jul 2012 11:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 4EVRzoLxsp4A for ; Tue, 17 Jul 2012 11:47:49 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDED21F867C for ; Tue, 17 Jul 2012 11:47:47 -0700 (PDT) Received: by bkty7 with SMTP id y7so710700bkt.31 for ; Tue, 17 Jul 2012 11:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YEY9cRXKBzpH/g0wNM4yIuvYxQcz35WI3hgigx+5Cnc=; b=aSYoh2bd5gunTxdX6j0bTugIIY0UVlj7y/5mo1iArb6SmbgViO4jk8NAgkHqGONneI zttQdQ7QBkh6TWQftfRpA/3W3+SoqFjStqzuZkwGOh9bwpz7pwk9lJ1Aw4rOX/gW/nIn uapIcfYf5ZjXeR8kbBkEtk71DQPPU22sNJCIL8hRO3kGKxgLYSmdmMom3pJpZfArV+MQ td50IgAN6QeKgFfYC5kp/hOwHhzBggOJEEgwJwqoxGN/5ehO5nAp0CB2akOftOVCNzzA mZ5GFjN8t0pWokyeUzyTHiYBPLmKaps1iKBuB4hq3hLMe7l51l/NSWmGkX4NXCl6ecVs 0zpA== MIME-Version: 1.0 Received: by 10.152.124.180 with SMTP id mj20mr3836812lab.43.1342550915474; Tue, 17 Jul 2012 11:48:35 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Tue, 17 Jul 2012 11:48:35 -0700 (PDT) In-Reply-To: <50059627.7040502@dcrocker.net> References: <20120717050910.11760.qmail@joyce.lan> <1725764.tjgqxi0i3Z@scott-latitude-e6320> <50059627.7040502@dcrocker.net> Date: Tue, 17 Jul 2012 11:48:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: dcrocker@bbiw.net Content-Type: multipart/alternative; boundary=f46d0434bfde68e46404c50afe37 Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 18:47:49 -0000 --f46d0434bfde68e46404c50afe37 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 17, 2012 at 9:43 AM, Dave Crocker wrote: > > fwiw, I'm fine with deprecating rather than removal. I'd prefer removal, > but would consider it progress to mark the feature deprecated. > I'd accept this compromise. +1. -MSK --f46d0434bfde68e46404c50afe37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 17, 2012 at 9:43 AM, Dave Crocker <dhc@dcrocker.net> wrote:

fwiw, I'm fine with deprecating rather than removal. =A0I'd prefer = removal, but would consider it progress to mark the feature deprecated.
=

I'd accept this compromise.=A0 +1.

-MSK
--f46d0434bfde68e46404c50afe37-- From superuser@gmail.com Tue Jul 17 12:10:40 2012 Return-Path: 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 B1B5621F862F for ; Tue, 17 Jul 2012 12:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 l-QOWkj63Bii for ; Tue, 17 Jul 2012 12:10:40 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9676F21F8621 for ; Tue, 17 Jul 2012 12:10:39 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1183525lbb.31 for ; Tue, 17 Jul 2012 12:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5gXvSONPPdj5C85YZxSI0+vGfkoxkvU5LYQQWDCS3XA=; b=j5yBp6FyrJcZG+uXhj8bHFclAm+JFmMr2cHxOn3uUDmX1UkxErL0049BsX2Vx3BPEK yEjSqtWllwZW9NV8t88lLqcELnNSU3gv5ckFMv/sQrBcy0KfG8SJFBUG8OKqC0EUMWfE ySu30Lr+eA9rBdUNGWgXpx6C6QTk6hhnbXCMMQCKtRMQTCEqn+2ySO7BW5LvMy9JbCCP kZxWsnN7rYr07E6uTOL4gfuE/K2lOUvxpq9Ww+RtZ4dYTZ1rfZDqsThh8dRT1XLUcue7 +x1byh3LagVKAR5z8JQYf6bLcAXA9ORPggevU1fhtmMjb/W3thePUs1NPZ+i4/ZVzwBv 3ATA== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr330488lbn.10.1342552286971; Tue, 17 Jul 2012 12:11:26 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Tue, 17 Jul 2012 12:11:26 -0700 (PDT) In-Reply-To: <20120717163025.GT96149@mail.yitter.info> References: <20120717050910.11760.qmail@joyce.lan> <1725764.tjgqxi0i3Z@scott-latitude-e6320> <20120717163025.GT96149@mail.yitter.info> Date: Tue, 17 Jul 2012 12:11:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=bcaec554d63c2847fb04c50b5037 Cc: spfbis@ietf.org Subject: Re: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 19:10:40 -0000 --bcaec554d63c2847fb04c50b5037 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 17, 2012 at 9:30 AM, Andrew Sullivan wrote: > Moreover, _all_ our evidence about SPF is scanty: we didn't do the > kind of widespread investigation that would allow us to make highly > defensible strong statements about SPF. I'm surprised by this characterization. I think the data we collected represents a reasonable cross-section of the deployment, is quite comprehensive, and is fairly strong considering multiple independent surveys were done. Charter questions aside, let me ask this: What data would you consider acceptable to justify deprecation or removal of a feature? What's the bar here? It may be that we did collect the data, but simply didn't need to use it for the questions asked to resolve the experiment issue. > One might well argue that we _should_ be free to remove this feature, > both because it is little used and because it is dangerous. (On the > latter, I still am mulling over John Levine's argument.) That isn't > the same thing as saying that our charter permits us that freedom. So > far, I haven't convinced myself. > > One of the questions I'm asking myself here is: Should we go to PS with a feature that is almost unused and is dangerous, even though it was there before and a tiny number of people appear to be using it? If I were sitting on SECDIR, I'd make some noise about this during Last Call, for example. I'd prefer to go out without such concerns. The counter-argument I've heard is "It's only PS; when going to IS, the bar would be much higher." I'd rather not wait that long if it can be avoided. If we can solve that problem under the "unused" clause in the charter (and I'm of the opinion that it does fit), then I think that's a win. -MSK --bcaec554d63c2847fb04c50b5037 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 17, 2012 at 9:30 AM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
Moreover, _all_ our evidence about SPF is scanty: we didn't do the
kind of widespread investigation that would allow us to make highly
defensible strong statements about SPF.

I'm surpri= sed by this characterization.=A0 I think the data we collected represents a= reasonable cross-section of the deployment, is quite comprehensive, and is= fairly strong considering multiple independent surveys were done.

Charter questions aside, let me ask this: What data would you consider = acceptable to justify deprecation or removal of a feature?=A0 What's th= e bar here?

It may be that we did collect the data, but simply didn&= #39;t need to use it for the questions asked to resolve the experiment issu= e.

=A0
One might w= ell argue that we _should_ be free to remove this feature,
both because it is little used and because it is dangerous. =A0(On the
latter, I still am mulling over John Levine's argument.) =A0That isn= 9;t
the same thing as saying that our charter permits us that freedom. =A0So far, I haven't convinced myself.


One of the questions I'm asking myself here i= s: Should we go to PS with a feature that is almost unused and is dangerous= , even though it was there before and a tiny number of people appear to be = using it?=A0 If I were sitting on SECDIR, I'd make some noise about thi= s during Last Call, for example.=A0 I'd prefer to go out without such c= oncerns.=A0 The counter-argument I've heard is "It's only PS; = when going to IS, the bar would be much higher."=A0 I'd rather not= wait that long if it can be avoided.

If we can solve that problem under the "unused" clause in the= charter (and I'm of the opinion that it does fit), then I think that&#= 39;s a win.

-MSK
--bcaec554d63c2847fb04c50b5037-- From spf2@kitterman.com Tue Jul 17 12:21:02 2012 Return-Path: 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 C4E9321F865E for ; Tue, 17 Jul 2012 12:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, SARE_SUB_PCT_LETTER=0.784] 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 m3lxUFUN0msW for ; Tue, 17 Jul 2012 12:21:01 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7D53221F865A for ; Tue, 17 Jul 2012 12:20:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5AC5E20E40BD; Tue, 17 Jul 2012 15:21:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342552906; bh=RsuYCGGWYS8OeSP4wODp+DyH+5pnEAMYN5SAyljEBXk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=W/S6eNxyMJ4w53mbm4c15dTolFejE+byOsrShlmvBF97SyiC4nDPEWtek9fqmOnsR J26K8JeyLdJrdvSA6AHsDin2R7Bann8gG5kfVBeEQ6Ggar9zWz1KdMPz9kAn7+6Atr cc/U7VhykAVl47NoD/I8kUGhTiRpz5aFGTNRFYpI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3C60B20E409F; Tue, 17 Jul 2012 15:21:46 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 17 Jul 2012 15:21:45 -0400 Message-ID: <29188283.Md6KR1EyTt@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5005B227.6070803@isdg.net> References: <20120712022051.60587.qmail@joyce.lan> <6.2.5.6.2.20120716171913.08c8be40@resistor.net> <5005B227.6070803@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 19:21:02 -0000 On Tuesday, July 17, 2012 02:42:47 PM Hector Santos wrote: > SM, thanks for your follow up: > > IMV, there are apples and oranges being mixed up in this SPF WG > thread. I am wondering if I should bother to bring that up but I > don't think it is very clear what is exactly wanted and seems to be > going going over board by lumping it all together - PTR directive and > %p macro. > > My recollection in the IETF83 Jabber session was that it wasn't cut > and dry and Andrew wanted to get list input to make the case > for/against. I don't recall seeing many inputs here, if only Doug > Otis I seem to recall. > > My position was always that SPF receivers can not practically remove > support (for backward compatibility reasons) and specifically for PTR. > Macros such as %p I already felt was more unnecessary, has less > utility (IMV) and sure, it is hardly used. > > But PTR itself is very popular and perhaps I was too naive to believe > anyone would take it serious to remove a high utility item instantly > creating errors for SPF sessions. No matter what, SPF receivers MUST > support it. Recommending Publishers not use it is another thing, so > perhaps this is more about a BCP. > > PTR appears to me to be among the highest use directive among the > cache I see and we should not be surprise because the WIZARDS out > there makes it part of the easy setup defaults. By far, the #1 SPF > statement (among my cache) is: > > v=spf1 a mx ptr ~all Which is a brain dead recommendation. It's not random that openspf.org no longer provides a wizard. The old one produced awful garbage like this and no one wrote a new one yet. The one thing that all SPF wizards (AFAIK) have in common is they aren't much good. > Now, it seems we are mixing apples and oranges here with inconsistent > reasons for deprecation either PTR or %p or both: > > - Scott has a Slowness reason written in 03 > - I believe Doug cited security reasons, and now > - Several has indicated "unused" reasons, and > - Some indicated a complexity reason for new developers. > > So I think there are different angles to how the features is viewed. > > As I recall, the main reason against deprecation was that it was under > control with limits as there was no security issue. > > Nonetheless, with PTR itself, we will be losing a high utility in > functionality and what it offers. Using the PTR directive makes it > dynamic for 1 to MANY IP::A records sites to use a simple SPF policy > command like above created by a number of wizards. I have yet to run across a domain that couldn't write a correct/complete SPF record without PTR. It's more than just slowness. The PTR name of the IP address is very often not under control of the ADMD. Errors are common. I recently saw a case where the PTR lookups were getting SERVFAIL (the persistent kind) results and interfering with mail delivery. It's slow, unreliable, and unnecessary. Additionally, to the extent it is useful it's only useful for up to ten PTR records. Then you're either stuck with random answers (match/not match based on if the relevant PTR name is in the first 10) or some other method. That some other method works just fine if the number is one through nine as well. That said, it's marked deprecated, not removed, so existing records won't get broken. You're correct that it appears in too many records to simply remove it. Scott K From hsantos@isdg.net Tue Jul 17 13:01:39 2012 Return-Path: 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 5F7D321F86F9 for ; Tue, 17 Jul 2012 13:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.558 X-Spam-Level: X-Spam-Status: No, score=-101.558 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SARE_SUB_PCT_LETTER=0.784, 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 9pAZRX0ML3sX for ; Tue, 17 Jul 2012 13:01:38 -0700 (PDT) Received: from ftp.catinthebox.net (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3666221F865E for ; Tue, 17 Jul 2012 13:01:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5185; t=1342555336; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=BeDdXO/mFJ0vq1PGXXi6yub9bIg=; b=wAe+cCzEOcsFbgidh6cF jR3/zcskY0Se1hQcjSTsK6R4KfXhWuJC/C3vHr1cDCAiQtA41clY1Sy0Yw22vOOA 24nlWtqgxuGBejoU+RL4WZY5ffr8AAhWgjd31LctdNp/Vm8+969nWlZyXF1DzUAO WEX1CTeXWePNACsbyTPXuk8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 17 Jul 2012 16:02:16 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2872135679.16202.1692; Tue, 17 Jul 2012 16:02:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5185; t=1342555205; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=d9qz5lT f8AX/dV0LnAXO8n41ugLv1shdUvKPENRjpdM=; b=WJDXuS/Cn3QgPnRRB+H5bDG FYGW7OASdLuAG5xYQcgJta4cPmTyc/6HNe20s0l1SxrNmj/y++LF4iTfxq8ZBHB+ iVMZ2jn6+tmNYQ4Z1Ck8ITGoZx2YDDtCvz7+9h0JUY2/OpuHlbUJkPawz0fFn8Lx Sexn+MiFNpayNjf3uA/0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 17 Jul 2012 16:00:05 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3470970598.9.1456; Tue, 17 Jul 2012 16:00:04 -0400 Message-ID: <5005C4D8.5030201@isdg.net> Date: Tue, 17 Jul 2012 16:02:32 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <20120712022051.60587.qmail@joyce.lan> <6.2.5.6.2.20120716171913.08c8be40@resistor.net> <5005B227.6070803@isdg.net> <29188283.Md6KR1EyTt@scott-latitude-e6320> In-Reply-To: <29188283.Md6KR1EyTt@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:01:39 -0000 Hi Scott, I think the way it is written PTR is being deprecated which to some will mean it does not need to be coded and/or provides the excuse why it wasn't in the advent of an error dispute - finger pointing begins. PTR as written in 03, it is parenthetically written as deprecated. That can provide the erroneous sense it is no longer necessary. Just like you represented the OpenSPF.org wizard no longer provides the "brain dead" expert system answer to operator input, this is more of a publishing recommendation and thus the BIS should be written in that manner. IOW, this is more about a BCP to not publish SPF policies with any higher overhead DNS query requirement, not just PTR. It should be noted that increasingly more systems have SMTP frontend logic before SPF takes place which do place an PTR requirement on the client. This removes the "slowness" concern written in 03 in regards to SPF. Overall, for this version of SPF, PTR is not deprecated in my view. It is just recommended not to be used (published) for possible DNS performance reasons. Are there other higher overhead directives? If so, then if SLOWNESS is a concern for PTR, should they be lumped together in a SPF DNS Performance section? Maybe complete removal can be reserved for SPF v3.0, but for SPF v2.0 it needs to remain and the way its written now possibly helping the perception it is "unused" it can be removed via deprecation. Thanks -- HLS Scott Kitterman wrote: > On Tuesday, July 17, 2012 02:42:47 PM Hector Santos wrote: >> SM, thanks for your follow up: >> >> IMV, there are apples and oranges being mixed up in this SPF WG >> thread. I am wondering if I should bother to bring that up but I >> don't think it is very clear what is exactly wanted and seems to be >> going going over board by lumping it all together - PTR directive and >> %p macro. >> >> My recollection in the IETF83 Jabber session was that it wasn't cut >> and dry and Andrew wanted to get list input to make the case >> for/against. I don't recall seeing many inputs here, if only Doug >> Otis I seem to recall. >> >> My position was always that SPF receivers can not practically remove >> support (for backward compatibility reasons) and specifically for PTR. >> Macros such as %p I already felt was more unnecessary, has less >> utility (IMV) and sure, it is hardly used. >> >> But PTR itself is very popular and perhaps I was too naive to believe >> anyone would take it serious to remove a high utility item instantly >> creating errors for SPF sessions. No matter what, SPF receivers MUST >> support it. Recommending Publishers not use it is another thing, so >> perhaps this is more about a BCP. >> >> PTR appears to me to be among the highest use directive among the >> cache I see and we should not be surprise because the WIZARDS out >> there makes it part of the easy setup defaults. By far, the #1 SPF >> statement (among my cache) is: >> >> v=spf1 a mx ptr ~all > > Which is a brain dead recommendation. It's not random that openspf.org no > longer provides a wizard. The old one produced awful garbage like this and no > one wrote a new one yet. The one thing that all SPF wizards (AFAIK) have in > common is they aren't much good. > >> Now, it seems we are mixing apples and oranges here with inconsistent >> reasons for deprecation either PTR or %p or both: >> >> - Scott has a Slowness reason written in 03 >> - I believe Doug cited security reasons, and now >> - Several has indicated "unused" reasons, and >> - Some indicated a complexity reason for new developers. >> >> So I think there are different angles to how the features is viewed. >> >> As I recall, the main reason against deprecation was that it was under >> control with limits as there was no security issue. >> >> Nonetheless, with PTR itself, we will be losing a high utility in >> functionality and what it offers. Using the PTR directive makes it >> dynamic for 1 to MANY IP::A records sites to use a simple SPF policy >> command like above created by a number of wizards. > > I have yet to run across a domain that couldn't write a correct/complete SPF > record without PTR. It's more than just slowness. The PTR name of the IP > address is very often not under control of the ADMD. Errors are common. I > recently saw a case where the PTR lookups were getting SERVFAIL (the > persistent kind) results and interfering with mail delivery. It's slow, > unreliable, and unnecessary. Additionally, to the extent it is useful it's > only useful for up to ten PTR records. Then you're either stuck with random > answers (match/not match based on if the relevant PTR name is in the first 10) > or some other method. That some other method works just fine if the number is > one through nine as well. > > That said, it's marked deprecated, not removed, so existing records won't get > broken. You're correct that it appears in too many records to simply remove > it. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From spf2@kitterman.com Tue Jul 17 13:06:25 2012 Return-Path: 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 001CC11E809B for ; Tue, 17 Jul 2012 13:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, SARE_SUB_PCT_LETTER=0.784] 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 eswyGRg3eww4 for ; Tue, 17 Jul 2012 13:06:24 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0E64411E8087 for ; Tue, 17 Jul 2012 13:06:24 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 07C0C20E40BD; Tue, 17 Jul 2012 16:07:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342555632; bh=FdCctBdAh6348GQs13aQkWp83uZdt2Xq412/GFapQ6c=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZeTsVcA1ZTbR1jHfZ2TqNiMMNCK3eYoyVu0WS5GigWqtsg5wLGhlgBAkxyWla92T0 7qA9SS8hn+/Abx1SJUVX2Caq2z+A9Y8VucvhjUzX236BpSUDx3q3mnNSsHQYVfln/x t4m9DumC0ou89CeFPq03J+mu4izy9Zh2GPTGYS6Q= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DB3A920E409F; Tue, 17 Jul 2012 16:07:11 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 17 Jul 2012 16:07:11 -0400 Message-ID: <1826475.5qE2FsLujJ@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5005C4D8.5030201@isdg.net> References: <20120712022051.60587.qmail@joyce.lan> <29188283.Md6KR1EyTt@scott-latitude-e6320> <5005C4D8.5030201@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:06:25 -0000 On Tuesday, July 17, 2012 04:02:32 PM Hector Santos wrote: > Hi Scott, > > I think the way it is written PTR is being deprecated which to some > will mean it does not need to be coded and/or provides the excuse why > it wasn't in the advent of an error dispute - finger pointing begins. > PTR as written in 03, it is parenthetically written as deprecated. > That can provide the erroneous sense it is no longer necessary. > > Just like you represented the OpenSPF.org wizard no longer provides > the "brain dead" expert system answer to operator input, this is more > of a publishing recommendation and thus the BIS should be written in > that manner. > > IOW, this is more about a BCP to not publish SPF policies with any > higher overhead DNS query requirement, not just PTR. It should be > noted that increasingly more systems have SMTP frontend logic before > SPF takes place which do place an PTR requirement on the client. This > removes the "slowness" concern written in 03 in regards to SPF. > > Overall, for this version of SPF, PTR is not deprecated in my view. It > is just recommended not to be used (published) for possible DNS > performance reasons. Are there other higher overhead directives? If > so, then if SLOWNESS is a concern for PTR, should they be lumped > together in a SPF DNS Performance section? > > Maybe complete removal can be reserved for SPF v3.0, but for SPF v2.0 > it needs to remain and the way its written now possibly helping the > perception it is "unused" it can be removed via deprecation. > > Thanks > > > On Tuesday, July 17, 2012 02:42:47 PM Hector Santos wrote: > >> SM, thanks for your follow up: > >> > >> IMV, there are apples and oranges being mixed up in this SPF WG > >> thread. I am wondering if I should bother to bring that up but I > >> don't think it is very clear what is exactly wanted and seems to be > >> going going over board by lumping it all together - PTR directive and > >> %p macro. > >> > >> My recollection in the IETF83 Jabber session was that it wasn't cut > >> and dry and Andrew wanted to get list input to make the case > >> for/against. I don't recall seeing many inputs here, if only Doug > >> Otis I seem to recall. > >> > >> My position was always that SPF receivers can not practically remove > >> support (for backward compatibility reasons) and specifically for PTR. > >> Macros such as %p I already felt was more unnecessary, has less > >> utility (IMV) and sure, it is hardly used. > >> > >> But PTR itself is very popular and perhaps I was too naive to believe > >> anyone would take it serious to remove a high utility item instantly > >> creating errors for SPF sessions. No matter what, SPF receivers MUST > >> support it. Recommending Publishers not use it is another thing, so > >> perhaps this is more about a BCP. > >> > >> PTR appears to me to be among the highest use directive among the > >> cache I see and we should not be surprise because the WIZARDS out > >> there makes it part of the easy setup defaults. By far, the #1 SPF > >> > >> statement (among my cache) is: > >> v=spf1 a mx ptr ~all > > > > Which is a brain dead recommendation. It's not random that openspf.org no > > longer provides a wizard. The old one produced awful garbage like this > > and no one wrote a new one yet. The one thing that all SPF wizards > > (AFAIK) have in common is they aren't much good. > > > >> Now, it seems we are mixing apples and oranges here with inconsistent > >> > >> reasons for deprecation either PTR or %p or both: > >> - Scott has a Slowness reason written in 03 > >> - I believe Doug cited security reasons, and now > >> - Several has indicated "unused" reasons, and > >> - Some indicated a complexity reason for new developers. > >> > >> So I think there are different angles to how the features is viewed. > >> > >> As I recall, the main reason against deprecation was that it was under > >> control with limits as there was no security issue. > >> > >> Nonetheless, with PTR itself, we will be losing a high utility in > >> functionality and what it offers. Using the PTR directive makes it > >> dynamic for 1 to MANY IP::A records sites to use a simple SPF policy > >> command like above created by a number of wizards. > > > > I have yet to run across a domain that couldn't write a correct/complete > > SPF record without PTR. It's more than just slowness. The PTR name of > > the IP address is very often not under control of the ADMD. Errors are > > common. I recently saw a case where the PTR lookups were getting > > SERVFAIL (the persistent kind) results and interfering with mail > > delivery. It's slow, unreliable, and unnecessary. Additionally, to the > > extent it is useful it's only useful for up to ten PTR records. Then > > you're either stuck with random answers (match/not match based on if the > > relevant PTR name is in the first 10) or some other method. That some > > other method works just fine if the number is one through nine as well. > > > > That said, it's marked deprecated, not removed, so existing records won't > > get broken. You're correct that it appears in too many records to simply > > remove it. Please read the definition of deprecated in -03 (that I mailed to the list earlier today). I hope that will resolve your concerns. Additionally, I emailed a diff from Alessandro yesterday that I plan for -04 to add additional discussion in Section 9 about the importance of minimizing the DNS cost of published records. I do think that your concerns are either resolved with the -03 definition of deprecated or on their way to being resolved with what's planned for -04. Scott K From sm@elandsys.com Tue Jul 17 13:26:14 2012 Return-Path: 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 A05C521F871A for ; Tue, 17 Jul 2012 13:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.198 X-Spam-Level: X-Spam-Status: No, score=-102.198 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, SARE_SUB_PCT_LETTER=0.784, 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 sG0ezI9GZ+Tm for ; Tue, 17 Jul 2012 13:26:13 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF1B21F86A0 for ; Tue, 17 Jul 2012 13:26:13 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.85]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6HKQdp3007418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2012 13:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342556812; bh=frB49js2nu/bWVKLKRReUi5nTu+wvdcMgGNrYN/v9fY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0MctM8Ul/YZOIyoDUsTcmy4icGS5wX7OE7PLHrfq16Yn7WO/KPEVyVP7h7LbsFYb6 4MdVQv5QoJ2QXQmanvr6W1bcCPPewVxeE4m/vo0WdhofVmyDDFrUgpFfam2TxXC1Ec 96Ddq6AKR+PcQrB7jvpqfcu41rJIjSAxkYshPwmc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342556812; i=@elandsys.com; bh=frB49js2nu/bWVKLKRReUi5nTu+wvdcMgGNrYN/v9fY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WfXbLzcTYQFJGL06mIf1LWRaPIXh7qkQ/E5Xq4VyfuomiuWQeGR7L2oAaZgga5SHj kqkbFnYGrhxZgWfrlhCcjXLYhz+uJsaKEyLVvx9RD6eQ7Zz3/9oYTfCO0+mwQJqS4O SQqZbTJWbDKBZHgSITy5lQzhqCWqsnROHieV0I68= Message-Id: <6.2.5.6.2.20120717114613.08066c40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Jul 2012 13:22:21 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <5005B227.6070803@isdg.net> References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> <50047A0F.5050907@isdg.net> <6.2.5.6.2.20120716171913.08c8be40@resistor.net> <5005B227.6070803@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:26:14 -0000 Hi Hector, At 11:42 17-07-2012, Hector Santos wrote: >My recollection in the IETF83 Jabber session was that it wasn't cut >and dry and Andrew wanted to get list input to make the case >for/against. I don't recall seeing many inputs here, if only Doug >Otis I seem to recall. I'll explain my view. The minutes of the SPFBIS session at IETF83 is quite extensive. I use the information in there to understand what was discussed and what conclusions were reached. Andrew can ask for list input to make the case for or against. If WG participants do not make the case for or against there is much the WG Chairs can do. There are times when there is significant input and times when there are a few individuals discussing about an issue. I prefer to see more input on the issues. >My position was always that SPF receivers can not practically remove >support (for backward compatibility reasons) and specifically for >PTR. Macros such as %p I already felt was more unnecessary, has less >utility (IMV) and sure, it is hardly used. I am not looking at that part of the specification as I write this message. My reading of the SPFBIS Charter is that it restricts changes so that the working group does not end up writing a specification which is not compatible with the existing RFC. >But PTR itself is very popular and perhaps I was too naive to >believe anyone would take it serious to remove a high utility item >instantly creating errors for SPF sessions. No matter what, SPF >receivers MUST support it. Recommending Publishers not use it is >another thing, so perhaps this is more about a BCP. One of the individual comments I made about a different issue was that "deprecation can be done by clients not sending it but receivers supporting it, meaning that things will continue parsing the header for some time". For what it is worth I was commenting about how that can be done, and not arguing for or against deprecation. That gets you the "MUST support". If you ask me whether it should be a BCP my answer is that I don't know as I have not thought about it yet. If you ask me to think about it I'll need information which has not been considered previously (see http://www.ietf.org/mail-archive/web/spfbis/current/msg01869.html as an example). >PTR appears to me to be among the highest use directive among the >cache I see and we should not be surprise because the WIZARDS out >there makes it part of the easy setup defaults. By far, the #1 SPF >statement (among my cache) is: > > v=spf1 a mx ptr ~all > >Now, it seems we are mixing apples and oranges here with >inconsistent reasons for deprecation either PTR or %p or both: > > - Scott has a Slowness reason written in 03 > - I believe Doug cited security reasons, and now > - Several has indicated "unused" reasons, and > - Some indicated a complexity reason for new developers. > >So I think there are different angles to how the features is viewed. Yes. I'll point out that it is up to WG participants to explain the angles so that the working group ends up with a better view of the problem. >As I recall, the main reason against deprecation was that it was >under control with limits as there was no security issue. Some of the arguments are in the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00808.html >Nonetheless, with PTR itself, we will be losing a high utility in >functionality and what it offers. Using the PTR directive makes it >dynamic for 1 to MANY IP::A records sites to use a simple SPF policy >command like above created by a number of wizards. I suggest reviewing the text at http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-03#section-5.5 If you or anyone else has an objection to Section 5.5 I'll need information to determine why the conclusion is incorrect. Regards, S. Moonesamy From ajs@anvilwalrusden.com Tue Jul 17 13:27:01 2012 Return-Path: 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 915CF21F86D3 for ; Tue, 17 Jul 2012 13:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 iHyqaP0Iak4e for ; Tue, 17 Jul 2012 13:27:00 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C130721F86A0 for ; Tue, 17 Jul 2012 13:27:00 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 0BBA28A031 for ; Tue, 17 Jul 2012 20:27:39 +0000 (UTC) Date: Tue, 17 Jul 2012 16:27:38 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120717202737.GC761@mail.yitter.info> References: <20120717050910.11760.qmail@joyce.lan> <1725764.tjgqxi0i3Z@scott-latitude-e6320> <20120717163025.GT96149@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:27:01 -0000 On Tue, Jul 17, 2012 at 12:11:26PM -0700, Murray S. Kucherawy wrote: > On Tue, Jul 17, 2012 at 9:30 AM, Andrew Sullivan wrote: > I'm surprised by this characterization. I think the data we collected > represents a reasonable cross-section of the deployment, is quite > comprehensive, and is fairly strong considering multiple independent > surveys were done. The problem is that we started from domains that we knew or somehow had contact with, and not a cross-section of "the Internet". I don't even know how you'd do a really defensible sample for this sort of thing. We had enough anyway, IMO, to justify concluding the experiment and following through on our charter. I don't think we had enough to get creative with our interpretation of "used" so that we can call things unused when we have clear published examples. > Charter questions aside, let me ask this: What data would you consider > acceptable to justify deprecation or removal of a feature? What's the bar > here? There is, as SM has already pointed out, a difference between "deprecation" as we've styled it, and removal. And given that I am engaged here as co-chair, I don't feel comfortable asking the question without considering the charter. But people seem to be converging around "deprecation", with some reluctance, and I'm certainly comfortable with that approach. > One of the questions I'm asking myself here is: Should we go to PS with a > feature that is almost unused and is dangerous, even though it was there The "dangerous" issue is one that I'm still thinking about. Some of what John Levine says upthread concerns me because I suspect it applies to a number of other things. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Tue Jul 17 13:34:50 2012 Return-Path: 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 67ADE21F8663 for ; Tue, 17 Jul 2012 13:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 8fr8stJ7w96G for ; Tue, 17 Jul 2012 13:34:49 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 801FB21F8627 for ; Tue, 17 Jul 2012 13:34:49 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A4E8220E40BD; Tue, 17 Jul 2012 16:35:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342557337; bh=dpfMY8UKYSAjVnrWEtWZf3lQDjIN/FPmgJ44P9sc+hY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=npiV208KIVDThzD5XbYN1ddJzhXcPH7Ffvou7bb9w+6euXg4OFCYJxlhcrBPOugH3 ls30vPnNUZXCIktlUaarmusQH3hGET4esY3ypAGQxJes5/etKANZGP5ApPWhZ6oAhR 4RZY7vFK28PaGVYBsrenIB2WzQLyIzCDBDEjUxGQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8A7BF20E409F; Tue, 17 Jul 2012 16:35:37 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 17 Jul 2012 16:35:36 -0400 Message-ID: <4319255.4Q9nvChn8x@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120717202737.GC761@mail.yitter.info> References: <20120717050910.11760.qmail@joyce.lan> <20120717202737.GC761@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:34:50 -0000 On Tuesday, July 17, 2012 04:27:38 PM Andrew Sullivan wrote: > > One of the questions I'm asking myself here is: Should we go to PS with a > > feature that is almost unused and is dangerous, even though it was there > > The "dangerous" issue is one that I'm still thinking about. Some of > what John Levine says upthread concerns me because I suspect it > applies to a number of other things. I think dangerous puts it backwards. Some have stated a concern about safety due to a number of reasons such as potential lack of testing of macro related code. Saying it may not be safe because of X, Y, and Z (some of which I think is a reasonable concern) is not the same as it's dangerous because of X, Y, and Z. I think that given the charter's bias towards compatibility with RFC 4408, there is a burden on those wanting to break backwards compatibility that goes well beyond "We think that in theory ....". That said, deprecation doesn't break backward compatibility, so if that's what we converge on, it's a non-issue. Scott K From superuser@gmail.com Tue Jul 17 14:29:14 2012 Return-Path: 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 B642811E80AD for ; Tue, 17 Jul 2012 14:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_PCT_LETTER=0.784] 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 ztSYWFGM6BgS for ; Tue, 17 Jul 2012 14:29:14 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD5511E80A4 for ; Tue, 17 Jul 2012 14:29:13 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1337902lbb.31 for ; Tue, 17 Jul 2012 14:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uxoH1x/zFrcs6Wqun5NDx4kX//2Kfys8ntj7ch23Chg=; b=xrim3dDAkPyU+v2JX0wHigTXTcH2X72mioOyZjhKsGTL1IUO5pM1qAGbq7qp8xg/si PH20sepYSaNKWBh2HnPuyTIayw6UNt8DsEvczuV3axBPDrybzQrmqVh+Ige1KlOF9Jym 7i0uz1lZeebHkkf2P5tFfHwwyLFuZ+zrwb7kjPUTShQ1oOb+3ErjpgAr/5NVZe16Nofu fsAPQTruxlHzkG3STccSqHv4mR0113YYHoDuplG3OahYTT36GxFMut//ZnQg2M3Rqrek y5kauRBLRduqWvJCEUEWuxxr11Rf18+aIixlngOc6MX9RAhlcv0qjiRyyCsfoG23qLII S7sw== MIME-Version: 1.0 Received: by 10.152.124.180 with SMTP id mj20mr511066lab.43.1342560601253; Tue, 17 Jul 2012 14:30:01 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Tue, 17 Jul 2012 14:30:01 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120717114613.08066c40@resistor.net> References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> <50047A0F.5050907@isdg.net> <6.2.5.6.2.20120716171913.08c8be40@resistor.net> <5005B227.6070803@isdg.net> <6.2.5.6.2.20120717114613.08066c40@resistor.net> Date: Tue, 17 Jul 2012 14:30:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d0434bfdeba27dd04c50d3f60 Cc: spfbis@ietf.org Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 21:29:14 -0000 --f46d0434bfdeba27dd04c50d3f60 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 17, 2012 at 1:22 PM, S Moonesamy wrote: > One of the individual comments I made about a different issue was that > "deprecation can be done by clients not sending it but receivers supporting > it, meaning that things will continue parsing the header for some time". > For what it is worth I was commenting about how that can be done, and not > arguing for or against deprecation. That gets you the "MUST support". > I'm a little confused by this, now that you mention it. If the force of this is that verifiers have to continue to support PTR and macros and whatever else we formally decide to deprecate, I wonder what we've gained. The verifier is where all of the real work is done and where the risk is arguably highest. The sender is advised to stop using them, but there's really no impact if they don't. What's the point? Wouldn't it be better to say that verifiers SHOULD ignore deprecated features, but if they don't, they should simply be ignored (rather than returning "permerror")? -MSK --f46d0434bfdeba27dd04c50d3f60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 17, 2012 at 1:22 PM, S Moonesamy <sm+ietf@elandsys.com= > wrote:
One of the individual comments I made about a different issue was that &quo= t;deprecation can be done by clients not sending it but receivers supportin= g it, meaning that things will continue parsing the header for some time&qu= ot;. =A0For what it is worth I was commenting about how that can be done, a= nd not arguing for or against deprecation. =A0 That gets you the "MUST= support".

I'm a little confused by this, now that you menti= on it.=A0 If the force of this is that verifiers have to continue to suppor= t PTR and macros and whatever else we formally decide to deprecate, I wonde= r what we've gained.=A0 The verifier is where all of the real work is d= one and where the risk is arguably highest.

The sender is advised to stop using them, but there's really no imp= act if they don't.

What's the point?

Wouldn't it = be better to say that verifiers SHOULD ignore deprecated features, but if t= hey don't, they should simply be ignored (rather than returning "p= ermerror")?

-MSK

--f46d0434bfdeba27dd04c50d3f60-- From superuser@gmail.com Tue Jul 17 14:36:41 2012 Return-Path: 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 31E5611E80BB for ; Tue, 17 Jul 2012 14:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 byn-jQtMKXA7 for ; Tue, 17 Jul 2012 14:36:40 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4016511E80A4 for ; Tue, 17 Jul 2012 14:36:40 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1345840lbb.31 for ; Tue, 17 Jul 2012 14:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bDSRU8g0lZw4TKCL4Z2XmZno2s4+6rNv+0uGYaefx1w=; b=hTayBwmtMcxLoknnmvneoMbhHWc4bdw1+mr5YxXyo7hBC101Low8xOjDWYyuK8Trri hxZkzqhWOuDkJH6qem6bIuoKS32xBGMYDV+LFgJr3O5BGDvxn6ZAPulUAraWyj2DXODk s1JX69daDBy5aJqzwl4IFrzWI+zdmIrHQTyXkd+ZtIYoDv6vT5pF2TLc4DhXHdhPp2FE JLAscpV4ruFpd5c73WvYSRim+oEvxwfNR0zGkYZdHV/HqKvIWHrs4VBWdws4FCo9fnRN XTbEgL/sXOpWLr7iI9sqSRZlLgCylbPdtsyI7sTfiY/IYYqlPT9VvP2fkdZoS6NlPRdJ hpcw== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr668593lab.9.1342561047885; Tue, 17 Jul 2012 14:37:27 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Tue, 17 Jul 2012 14:37:27 -0700 (PDT) In-Reply-To: <20120717202737.GC761@mail.yitter.info> References: <20120717050910.11760.qmail@joyce.lan> <1725764.tjgqxi0i3Z@scott-latitude-e6320> <20120717163025.GT96149@mail.yitter.info> <20120717202737.GC761@mail.yitter.info> Date: Tue, 17 Jul 2012 14:37:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=e89a8f22c41159377204c50d5a7a Cc: spfbis@ietf.org Subject: Re: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 21:36:41 -0000 --e89a8f22c41159377204c50d5a7a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 17, 2012 at 1:27 PM, Andrew Sullivan wrote: > The problem is that we started from domains that we knew or somehow > had contact with, and not a cross-section of "the Internet". I don't > even know how you'd do a really defensible sample for this sort of > thing. > > That's true for the TDP survey (which queried domains with which any of its reporting sites had contact). The Cisco survey polled the top million domains based on Alexa rankings, not domains with which it had contact. Still not a true broad Internet survey given the number of domains that do exist, but as you say it's not clear how to construct a 100% defensible survey. I wonder if people would be satisfied with a survey that can be shown to be statistically significant yet not biased in any "bad" way. The absoluteness of some of the replies here have me doubting it, but statistics is a well-established discipline. -MSK --e89a8f22c41159377204c50d5a7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 17, 2012 at 1:27 PM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
The problem is that we started from domains that we knew or somehow
had contact with, and not a cross-section of "the Internet". =A0I= don't
even know how you'd do a really defensible sample for this sort of
thing.


That's true for the TDP survey (which queried= domains with which any of its reporting sites had contact).=A0 The Cisco s= urvey polled the top million domains based on Alexa rankings, not domains w= ith which it had contact.=A0 Still not a true broad Internet survey given t= he number of domains that do exist, but as you say it's not clear how t= o construct a 100% defensible survey.

I wonder if people would be satisfied with a survey that can be shown t= o be statistically significant yet not biased in any "bad" way.= =A0 The absoluteness of some of the replies here have me doubting it, but s= tatistics is a well-established discipline.

-MSK
--e89a8f22c41159377204c50d5a7a-- From spf2@kitterman.com Tue Jul 17 16:16:40 2012 Return-Path: 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 8C01411E80E5 for ; Tue, 17 Jul 2012 16:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, SARE_SUB_PCT_LETTER=0.784] 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 xLHcXPtYPGpg for ; Tue, 17 Jul 2012 16:16:39 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id BEB3B11E80E3 for ; Tue, 17 Jul 2012 16:16:39 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id C7782D0407F; Tue, 17 Jul 2012 18:17:27 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342567047; bh=YWTZVC6yxNaUxmN8M+i+8NQPi4lInOlYjH8OBlXLdUc=; h=References:In-Reply-To:Subject:From:Date:To:From; b=VWR3NDTIZdN0sycKxbsuPnRrLotlVXvOZJyj+TRnMyRoDVNBpevpB4OpS6jIY57Qq O8Xc46GyGLYmOYmAeByTHUt4oEuJAAt3igswUUIQ4ubW183+bHgJFHrlwIJpp+BSDQ Pxwk0ItMowQNopljso4L1V0AZ2alFHefKhbHUP5Y= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 65FAFD04057; Tue, 17 Jul 2012 18:17:27 -0500 (CDT) References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> <50047A0F.5050907@isdg.net> <6.2.5.6.2.20120716171913.08c8be40@resistor.net> <5005B227.6070803@isdg.net> <6.2.5.6.2.20120717114613.08066c40@resistor.net> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 17 Jul 2012 19:17:19 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 23:16:40 -0000 "Murray S. Kucherawy" wrote: >On Tue, Jul 17, 2012 at 1:22 PM, S Moonesamy >wrote: > >> One of the individual comments I made about a different issue was >that >> "deprecation can be done by clients not sending it but receivers >supporting >> it, meaning that things will continue parsing the header for some >time". >> For what it is worth I was commenting about how that can be done, >and not >> arguing for or against deprecation. That gets you the "MUST >support". >> > >I'm a little confused by this, now that you mention it. If the force >of >this is that verifiers have to continue to support PTR and macros and >whatever else we formally decide to deprecate, I wonder what we've >gained. >The verifier is where all of the real work is done and where the risk >is >arguably highest. > >The sender is advised to stop using them, but there's really no impact >if >they don't. > >What's the point? > >Wouldn't it be better to say that verifiers SHOULD ignore deprecated >features, but if they don't, they should simply be ignored (rather than >returning "permerror")? That would also be substantially backward incompatible. As an example, it would make: v=spf1 ptr -all and v=spf1 -all into equivalent records. I don't think that's what we'd want. FWIW, that first record isn't a theoretical one. That was the cisco.com SPF record for several years. What deprecation achieves is a path towards removal without pulling the rug out from under people. I'd expect in a couple of years or so we'll be back to advance along the standards track. At that time, I'd expect the charter to cover removal of features that are either unused or were previously marked deprecated. Scott K From kurta@drkurt.com Tue Jul 17 16:24:21 2012 Return-Path: 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 00FD211E80E3 for ; Tue, 17 Jul 2012 16:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 MmQjwT7tPuW7 for ; Tue, 17 Jul 2012 16:24:19 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6191511E80E2 for ; Tue, 17 Jul 2012 16:24:18 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1453621lbb.31 for ; Tue, 17 Jul 2012 16:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20110616; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=aqCAxXHtd7OZ3N4oJUUDbdxYMtd+Vb8vxjx8LNosa3g=; b=DV3lxVgPZsWCwvRDGmle1k4Xmxx+hNReN5CGLDDPB+cp6oQ7JVs0CZyDbj7v0L0Xnz HpvX6fFxufuweVUIIzSEt48IvGcJ8W6XfvHJz74v3oCBIBShi092ANI4Szu/k0OFqd/2 AH5lsY5v5FKzXgPd5vuZ0ahU6ZGyeZoKYhFsg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=aqCAxXHtd7OZ3N4oJUUDbdxYMtd+Vb8vxjx8LNosa3g=; b=RSxWAPS31FdWzamblkBdlx7d1tGEcM9ltqx5XNNYBR37/F6P2TEskmnavPS3EoAuRo J/dtsHAuQunwHKjI2XBVOVQ2S18eRyltNTO/7o7mDeEQ6FpFWxRxMbSzK2KpIX/20MWX h9e8X/etG+Ijps2fSySHWLu773io676PJ9qjsWXirU28Dh0/JcR8DobftdTUia222DYW uWCcxLLXcXTe5Qe03MALvx18qplt6w6i/whLtfqw4oPQ+ZMizd8luvQIOQX2NZoOJVPZ HHw2oBwacHWqK5opHDd6ZCpTLsVzyg2TIjrd02d05ZtB/AstXxtL251SGJOUg/3xK/nv /0Ww== MIME-Version: 1.0 Received: by 10.152.103.109 with SMTP id fv13mr893180lab.33.1342567506173; Tue, 17 Jul 2012 16:25:06 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.114.2.176 with HTTP; Tue, 17 Jul 2012 16:25:06 -0700 (PDT) In-Reply-To: References: <20120717050910.11760.qmail@joyce.lan> <1725764.tjgqxi0i3Z@scott-latitude-e6320> Date: Tue, 17 Jul 2012 16:25:06 -0700 X-Google-Sender-Auth: 6GILV-CzrLT9wTFj73ORyD1NYDs Message-ID: From: Kurt Andersen To: spfbis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk8GNru6M9o/aknCuTjfd0dt56XVjnqq2CcDWbB5mrmkT3UW9TU4aQxSsnp9OwiMFGrXIO5 Subject: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 23:24:21 -0000 Apologies if this distributes through the list twice - I've been having fun getting my mail client to do the right thing... --Kurt On Tue, Jul 17, 2012 at 8:36 AM, Scott Kitterman wrote: > > Removal/deprecation of macros does impact at least one use case that's difficult > to replicate and there might be others. I don't have personal knowledge of > how or why publishers actually use macros in the wild except for the logging > record suggested in RFC 4408 section 9.1: > > v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all > > Trying to figure out SPF deployments is hard. The above use of macros is one > of the few reliable ways to get feedback on where receivers think your mail is > coming from. . . Speaking personally, this usage is exactly what the postmaster team at a previous employer had in mind when we implemented SPF. We actually used the %{l} macro to blacklist commonly spoofed localparts with a -exists construct and then followed that with a "survey" entry that would tell us who was spoofing our domain (by IP and localpart). With over 300 domains under management, macro expansion was critical to doing this in a manageable fashion. We received daily query reports from our domain's authoritative name servers. Only "bad" mail hit those "expensive" lookups, not the majority good mail that was accepted with the initial ip4 entries. Unfortunately, we ran into a problem much like the hypothetical cases that have been in discussion here. A widely deployed perimeter email appliance in China had a broken SPF implementation which choked on the macro expansion of the SPF records and, since we could not get any traction with the vendor, management elected to discontinue the use of all SPF records rather than dealing with the frequent delivery failures to a growing market segment. Regretfully, I think that we should deprecate the %{l} macro, but Murray's point that deprecation does not solve the problem of broken (or flawed) implementations on checkers is a valid point. Deprecation paves the way to eliminate it - but not for a few years or the next "version" of the spec. In the meantime, everyone who implements SPF checkers still bears the burden of doing it right - or we have to define an alternate result for non-implemented quasi-optional elements (different than PERMERROR). Cheers, Kurt Andersen From sm@elandsys.com Tue Jul 17 16:55:41 2012 Return-Path: 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 0BA1B11E80E4 for ; Tue, 17 Jul 2012 16:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.191 X-Spam-Level: X-Spam-Status: No, score=-102.191 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, SARE_SUB_PCT_LETTER=0.784, 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 OZINYqrMT7xz for ; Tue, 17 Jul 2012 16:55:39 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 015A711E80D2 for ; Tue, 17 Jul 2012 16:55:38 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.85]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6HNu8Fv019942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2012 16:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342569381; bh=dxXmjVxIcjO4GfJT0gH9VlKApg6ZcKl+/W83nayFa6s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=j7ERf+FEuwaAjdfnTDzOKf1r6DullX3WvamPEb4TJYKoQkRgEEuYEHNLi9Bke9n4M JgAIu3GVgnPxf0G1sR53IYTfgPoL7Cjj57hnDw+5VriF/4H+eVFNPBVmXGVIkV/GMw LjWAXMAVTBmRTw8aCCGjN2ty0eh7f7lTrrA8hQ0E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342569381; i=@elandsys.com; bh=dxXmjVxIcjO4GfJT0gH9VlKApg6ZcKl+/W83nayFa6s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OiN/w3kEXGGlsLUYhFhnn2D3Xf4P0J9PxhHKEt/hyNO8j6bFoFDuKo0cYgMM2E4gA P4stkqoh8WTHAD3o+JG6+QPb0FGAoqhCNOzo2Hx8r95FMkdlsOWioo6S5lUtB1Bk5Z 4Cbnm76oUo2SoMjnDwpL3XVE/IGfblGQm0b16Lsw= Message-Id: <6.2.5.6.2.20120717144053.099bd988@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Jul 2012 16:55:44 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> <50047A0F.5050907@isdg.net> <6.2.5.6.2.20120716171913.08c8be40@resistor.net> <5005B227.6070803@isdg.net> <6.2.5.6.2.20120717114613.08066c40@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 23:55:41 -0000 Hi Murray, At 14:30 17-07-2012, Murray S. Kucherawy wrote: >I'm a little confused by this, now that you mention it. If the >force of this is that verifiers have to continue to support PTR and >macros and whatever else we formally decide to deprecate, I wonder >what we've gained. The verifier is where all of the real work is >done and where the risk is arguably highest. I was trying to explain "MUST support" in terms of a previous discussion. >The sender is advised to stop using them, but there's really no >impact if they don't. > >What's the point? > >Wouldn't it be better to say that verifiers SHOULD ignore deprecated >features, but if they don't, they should simply be ignored (rather >than returning "permerror")? In terms of a protocol we can remove a feature or we can deprecate it. Let's say that we decide to make "ptr" obsolete. Some parsers might break, some parsers might ignore that. If we want a transition we can deprecate a feature. We can look at this in terms of senders do not generate and receivers will process. We could also have chosen the "please ignore" approach where receivers will not process. The "verifiers SHOULD ignore deprecated features" is a generic recommendation. If we want to see an immediate impact we are forgoing gradual transition. Regards, S. Moonesamy From ajs@anvilwalrusden.com Tue Jul 17 18:53:28 2012 Return-Path: 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 0000121F865E for ; Tue, 17 Jul 2012 18:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 F2OjJtkaN1uE for ; Tue, 17 Jul 2012 18:53:27 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3A321F865D for ; Tue, 17 Jul 2012 18:53:27 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id A740D8A031 for ; Wed, 18 Jul 2012 01:54:14 +0000 (UTC) Date: Tue, 17 Jul 2012 21:54:07 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120718015407.GA1417@mail.yitter.info> References: <20120717050910.11760.qmail@joyce.lan> <1725764.tjgqxi0i3Z@scott-latitude-e6320> <20120717163025.GT96149@mail.yitter.info> <20120717202737.GC761@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] why get rid of local part macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 01:53:28 -0000 No hat. On Tue, Jul 17, 2012 at 02:37:27PM -0700, Murray S. Kucherawy wrote: > Still not a true broad Internet survey given the number of domains that do > exist, but as you say it's not clear how to construct a 100% defensible > survey. Right. If I wanted to attack the samples, I'd say that they were either biased in favour of domains "we know" or else in favour of large sites that have different use patterns than small sites. Or something like that. The point is that these samples are not a random sample of "the Internet", which seems like a pretty tall order. Aside: I've often thought (especially lately) that the problem we have is that we're trying to measure things in much the way that the physical and sometimes social sciences do, and what we probably want to do is something more like economic modelling. The problem, of course, is that economic modelling is well known to produce almost useless results most of the time :) > I wonder if people would be satisfied with a survey that can be shown to be > statistically significant yet not biased in any "bad" way. The > absoluteness of some of the replies here have me doubting it, but > statistics is a well-established discipline. Our problem in this case is not a statistics problem, but a sampling one. What we need is a representative sample of the population. If Dave thinks that we've been arguing about semantic problems by discussing what "unused" means, I can't wait until we discuss what is "representative". It still seems to me to be much easier here to deprecate but not remove the feature, but I still haven't thought very hard about the "dangerous" claim. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Jul 17 19:03:34 2012 Return-Path: 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 3C16B11E80E9 for ; Tue, 17 Jul 2012 19:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 PO5Son0XE1RK for ; Tue, 17 Jul 2012 19:03:33 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B3F6F11E80D6 for ; Tue, 17 Jul 2012 19:03:33 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 192CC8A031 for ; Wed, 18 Jul 2012 02:04:21 +0000 (UTC) Date: Tue, 17 Jul 2012 22:04:18 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120718020418.GC1417@mail.yitter.info> References: <20120710111308.GC79014@mail.yitter.info> <20120713000901.GB92752@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120713000901.GB92752@mail.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Things that need discussion face to face? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 02:03:34 -0000 Dear colleagues, As you will no doubt note, the IETF agenda for our session now reads "cancelled" (well, "canceled", but I learned to spell in Canada). Thanks for the productive discussion on the list! Best, A On Thu, Jul 12, 2012 at 08:09:01PM -0400, Andrew Sullivan wrote: > Dear colleagues, > > Unless I missed something significant, the disucussion has not > revealed anything that should be handled face to face instead of in > person. So our plan is to cancel this session. If you object to this > very strongly, please propose a clear agenda item with questions to be > answered in the face to face meeting by 17:00 EDT tomorrow (that's > 21:00 UTC). Otherwise, we'll inform the secretariat. > > Thanks for the productive discussion on the list. > > Best, > > A > > On Tue, Jul 10, 2012 at 07:13:09AM -0400, Andrew Sullivan wrote: > > Dear colleagues, > > > > The Vancouver IETF meeting is approaching, as is the deadline for a WG > > meeting agenda. > > > > Speaking only for myself, I haven't seen a great deal of discussion > > here of the sort that seems to require face to face time. Are there > > particular issues people think we need to discuss in person, or should > > we cede the time back to the rest of the IETF? > > > > Best, > > > > A > > > -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Tue Jul 17 22:19:06 2012 Return-Path: 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 3B58211E8123 for ; Tue, 17 Jul 2012 22:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.184 X-Spam-Level: X-Spam-Status: No, score=-102.184 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, SARE_SUB_PCT_LETTER=0.784, 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 wcfan7f60BDj for ; Tue, 17 Jul 2012 22:19:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 356D411E80FC for ; Tue, 17 Jul 2012 22:19:01 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.233]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6I5Jc2R007944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2012 22:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342588789; bh=SDkk+g78G0VRClMtEWHeeVgY4FbVo/biwqKJJFiLmaU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=f3EvVQRcFlOEX83FNmQIjbi/0GqH2iq+Zo3fbWiemzokubnVrnGZUX7O4VjGB0ygF m1ywfGwj8SYriL2J+MfJS/Hc2f1FblM7akAllWIe2DKpU8VPMxF2LkrVf8UbYU0OKk 8Hlqnnaj91SQRLxFEr+5lLACgyhmQNtKl0GA2SUk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342588789; i=@elandsys.com; bh=SDkk+g78G0VRClMtEWHeeVgY4FbVo/biwqKJJFiLmaU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=abTFvp8loxR/cvHrIN9kZ20U/mVEyCcH+umSfHRhBTI/37Sd9bN5nDFJa2sAJd0hu zJsC0N9heAW7wEvXM7AzZWw9nJB+agiu8ETKQsj8FGy4cZFzMYXJmH8eSo7wqfsr+b ecvlUQQmoJW3pu3HUNvXcP3bZRVnoZXXbOU1guBY= Message-Id: <6.2.5.6.2.20120717184307.099f7408@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Jul 2012 20:35:07 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> <50047A0F.5050907@isdg.net> <6.2.5.6.2.20120716171913.08c8be40@resistor.net> <5005B227.6070803@isdg.net> <6.2.5.6.2.20120717114613.08066c40@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 05:19:06 -0000 At 16:17 17-07-2012, Scott Kitterman wrote: >That would also be substantially backward incompatible. As an >example, it would make: > >v=spf1 ptr -all > >and > >v=spf1 -all > > >into equivalent records. I don't think that's what we'd want. FWIW, >that first record isn't a theoretical one. That was the cisco.com >SPF record for several years. Here's the text in Section 5.5 of draft-ietf-spfbis-4408bis-03: "This mechanism tests whether the DNS reverse-mapping for exists and correctly points to a domain name within a particular domain. This mechanism is deprecated and SHOULD NOT be used." 'Note: This mechanism has been deprecated because it is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the arpa name servers. If used, proper PTR records must be in place for the domain's hosts and the "ptr" mechanism should be one of the last mechanisms checked. After many yaers of SPF deployment experience it has been concluded it is unnecessary and more reliable alternatives used instead.' From Section 1.3.4: 'There are several [RFC4408] features that are marked "deprecated". In the context of this document, deprecated means that senders SHOULD NOT publish SPF records that make use of the feature in question. Its use is NOT RECOMMENDED and it might be removed entirely in future updates to the protocol. Such features do, however, remain part of the SPF protocol and receiving systems MUST support them unless this specification says otherwise.' After reading the above I end up with diverse interpretations of what to do. I suggest forgetting about Section 1.3.4 for now. Please review Section 5.5 to determine whether there is any ambiguity. Please consider whether any proposed change has any adverse effect on other parts of the draft. Regards, S. Moonesamy SPFBIS WG co-chair From sm@resistor.net Tue Jul 17 22:42:11 2012 Return-Path: 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 3E03F11E80AE for ; Tue, 17 Jul 2012 22:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 Xn8jKsLVmLZV for ; Tue, 17 Jul 2012 22:42:06 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D1C11E811B for ; Tue, 17 Jul 2012 22:42:06 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6I5gpa6024861 for ; Tue, 17 Jul 2012 22:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342590175; bh=P5mkccSrrtOjgRqnqaMgmWlPWLpwKAI9alztvMQUDhU=; h=Date:To:From:Subject:Cc; b=QeY4us2nHA1vMtX1cyvWY43oY3EQl1xRTr3O7BXRzc7PymB0oyY4yR43xY9ij0H6X F4jqa45zX4Q9VA6T42bfXOtT3t4KFYMdM5T35/PQ+LPhP4mlHSXCgeVXAv5slr0Gsr mW7J63Py/TjLsMIDla9twsV1ItkIYPpPc5WmJKmA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1342590175; i=@resistor.net; bh=P5mkccSrrtOjgRqnqaMgmWlPWLpwKAI9alztvMQUDhU=; h=Date:To:From:Subject:Cc; b=4z6Vq36QAk96oN1iOPYiHLtLvpj1JzhBDrW6ZLkSEuwW2e03c986cfTDPX5hj9fzN qOZwIrYQAHuv7BskxZEr3iI+YLQiUAc/YSZok/8dnm49wYEtFE1Hn2MyhuvQIOgve2 VS6XUCvY25Vs/ZD+abE3mQTzR1IaGs2A3OU/6k6M= Message-Id: <6.2.5.6.2.20120717221940.08d5eb40@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Jul 2012 22:41:21 -0700 To: spfbis@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Bug in SPFBIS Charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 05:42:11 -0000 The SPFBIS Charter has the following: "Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language." and: "Discussion of extensions to the SPF protocols or removal of existing features shall only be discussed after completion of current charter items in anticipation of rechartering the working group." The working group can remove unused features and it shall not discuss about removing existing features. Is this a bug? :-) Regards, -sm From superuser@gmail.com Tue Jul 17 22:46:27 2012 Return-Path: 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 B024011E80AE for ; Tue, 17 Jul 2012 22:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 nnMhu8ghK4xl for ; Tue, 17 Jul 2012 22:46:27 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D271221F8525 for ; Tue, 17 Jul 2012 22:46:26 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1782222lbb.31 for ; Tue, 17 Jul 2012 22:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J4TNeG0Kg4emjwjJshqua05olMUtt3AMu8USrsF2A70=; b=Fzx2bxT5fq8yGLLkuViAzbWL7qY2spc00DqT+b1VvD9bPIDSZOXeIzy0BbsmZDGt4U gCQQESZiQyzaJVofoP8A+SS/SIRhF55LURzleHOvP644wimxwfZ42He6nvAu76hEZNzw B9iu0MbuRcnF0gbrk8Jez5znfCcEAs5Bh9gGX1bNf6WmyX70swiMB5vtJeBhQaY19/c+ 0w0m+FSYJEEfo26Jc5smdYtr4OSGpGWPZ8Xjz3VkqXidT59+c0AxOFOAIKlrcAgcWJdY nITcaGsOX62iakZphktJK0smQ6Ma6yUq8QqlMFxsWQ022b8KvjL94EIkDwCBalZxAcms HcUg== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr1105052lbn.10.1342590435340; Tue, 17 Jul 2012 22:47:15 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Tue, 17 Jul 2012 22:47:15 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120717221940.08d5eb40@elandnews.com> References: <6.2.5.6.2.20120717221940.08d5eb40@elandnews.com> Date: Tue, 17 Jul 2012 22:47:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: multipart/alternative; boundary=bcaec554d63cfa339d04c514312d Cc: spfbis@ietf.org Subject: Re: [spfbis] Bug in SPFBIS Charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 05:46:27 -0000 --bcaec554d63cfa339d04c514312d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 17, 2012 at 10:41 PM, SM wrote: > The SPFBIS Charter has the following: > > "Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language." > > and: > > "Discussion of extensions to the SPF protocols or removal of > existing features shall only be discussed after completion of > current charter items in anticipation of rechartering the working > group." > > The working group can remove unused features and it shall not discuss > about removing existing features. Is this a bug? :-) > > Nice one. The second part is the bug, I would think. -MSK --bcaec554d63cfa339d04c514312d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 17, 2012 at 10:41 PM, SM <sm@resistor.net> wrote:<= br>
The SPFBIS Charter has the following:

=A0 "Changes to the SPF specification will be limited to the correctio= n
=A0 =A0of errors, removal of unused features, addition of any enhancements<= br> =A0 =A0that have already gained widespread support, and addition of
=A0 =A0clarifying language."

and:

=A0 "Discussion of extensions to the SPF protocols or removal of
=A0 =A0existing features shall only be discussed after completion of
=A0 =A0current charter items in anticipation of rechartering the working =A0 =A0group."

The working group can remove unused features and it shall not discuss about= removing existing features. =A0Is this a bug? :-)


Nice one.

The second part is the bug, I wo= uld think.

-MSK

--bcaec554d63cfa339d04c514312d-- From vesely@tana.it Wed Jul 18 02:10:06 2012 Return-Path: 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 8B79C21F8643 for ; Wed, 18 Jul 2012 02:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.241 X-Spam-Level: X-Spam-Status: No, score=-4.241 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4, SARE_SUB_PCT_LETTER=0.784] 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 ACCk-pudwmLa for ; Wed, 18 Jul 2012 02:09:59 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8622D21F8606 for ; Wed, 18 Jul 2012 02:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342602647; bh=LU0E3xKNLAPUEu+2IcvO4mJMvexUEJzidRuy9fdGMZs=; l=1548; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=RtHfOaBGKokExCcnXdMrgfzir81kyhgTYg+IVxnMW9N6Cj+x8XfUEEFJJxjG/moCL 4QSY+sWdShgrtAUaAkWhy8WMQEhNWv+nraThEyODde/Dpq4/S+3Hkfh+LM1kQxR1w3 CaBRCeDKmC8eIGRfwldyibPtFnqR+rwltRzCbHsE= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 18 Jul 2012 11:10:47 +0200 id 00000000005DC039.0000000050067D97.00006881 Message-ID: <50067D97.5080408@tana.it> Date: Wed, 18 Jul 2012 11:10:47 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120712022051.60587.qmail@joyce.lan> <6.2.5.6.2.20120716171913.08c8be40@resistor.net> <5005B227.6070803@isdg.net> <29188283.Md6KR1EyTt@scott-latitude-e6320> In-Reply-To: <29188283.Md6KR1EyTt@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] Wizards, was PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 09:10:06 -0000 On Tue 17/Jul/2012 21:21:45 +0200 Scott Kitterman wrote: > On Tuesday, July 17, 2012 02:42:47 PM Hector Santos wrote: >> Recommending Publishers not use it is another thing, so perhaps >> this is more about a BCP. >> >> PTR appears to me to be among the highest use directive among the >> cache I see and we should not be surprise because the WIZARDS out >> there makes it part of the easy setup defaults. By far, the #1 SPF >> statement (among my cache) is: >> >> v=spf1 a mx ptr ~all > > Which is a brain dead recommendation. It's not random that > openspf.org no longer provides a wizard. The old one produced > awful garbage like this and no one wrote a new one yet. The one > thing that all SPF wizards (AFAIK) have in common is they aren't > much good. Good point! Should the definition of "Deprecated" address wizards? For example (after incorporating Murray's change): There are several [RFC4408] features that are marked "deprecated". In the context of this document, deprecated means that senders SHOULD NOT publish SPF records that make use of the features in question, and tools that generate generic SPF records based on users' input MUST NOT propose them. Use of these features is not advised, as they might be removed entirely in future updates to the protocol. Such features do, however, remain part of the SPF protocol and receiving systems MUST support them unless this specification says otherwise. That way, people would be able to tell which wizards are not compliant with 4408bis. From vesely@tana.it Wed Jul 18 02:12:28 2012 Return-Path: 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 3BEE621F8650 for ; Wed, 18 Jul 2012 02:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.625 X-Spam-Level: X-Spam-Status: No, score=-4.625 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 guTkKsmyVRBq for ; Wed, 18 Jul 2012 02:12:27 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0EE21F8643 for ; Wed, 18 Jul 2012 02:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342602796; bh=7dy8akGJEX0iUHt8KgzrfVz61lmfCji8ZsxWTCphO64=; l=1046; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=l9GCnUOOR5au3/l6AFKghhi8nZ35lE4diRWs5G/DSlAzpQs9esOUtEaUhocl2odMV zuHmtCGAwyxNpyoBy3Q5iFthyup9YKgtuQThYtKCH+4+fbROkJh1oASI8y3atYFbj9 bzXOiCPiVSOoB/cR9agbTrOzjuF07jVOw6CLs1+c= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 18 Jul 2012 11:13:16 +0200 id 00000000005DC039.0000000050067E2C.00006923 Message-ID: <50067E2C.3030103@tana.it> Date: Wed, 18 Jul 2012 11:13:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120717221940.08d5eb40@elandnews.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Bug in SPFBIS Charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 09:12:28 -0000 On Wed 18/Jul/2012 07:47:15 +0200 Murray S. Kucherawy wrote: > On Tue, Jul 17, 2012 at 10:41 PM, SM wrote: > >> The SPFBIS Charter has the following: >> >> "Changes to the SPF specification will be limited to the correction >> of errors, removal of unused features, addition of any enhancements >> that have already gained widespread support, and addition of >> clarifying language." >> >> and: >> >> "Discussion of extensions to the SPF protocols or removal of >> existing features shall only be discussed after completion of >> current charter items in anticipation of rechartering the working >> group." >> >> The working group can remove unused features and it shall not >> discuss about removing existing features. Is this a bug? :-) > > Nice one. > > The second part is the bug, I would think. It's not a bug. Unused features don't "exist" --by reversing the ontological argument-- since their mere existence would entail some kind of use. We can regard "existing" and "in use" as synonyms :-/ From vesely@tana.it Wed Jul 18 04:32:26 2012 Return-Path: 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 AE11921F86EE for ; Wed, 18 Jul 2012 04:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.327 X-Spam-Level: X-Spam-Status: No, score=-4.327 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] 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 ksUv-7SCga9X for ; Wed, 18 Jul 2012 04:32:24 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2DD21F869D for ; Wed, 18 Jul 2012 04:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342611184; bh=g8bU1T04SnUdYlHR8qUd23k5t29dm9igsZZg4a30Fks=; l=1832; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=iY2ugy18Hdrrg25/8N5DYYirXK7RMiByVE/T+11MmZ505pHihxi1GQoAaTfS8oii8 Vt3phpIpAyyhS+aqJS7VB54vsWDdzU3M5LPtZrv8uU76l8+dpdjs+s70i4iOFjVQQs zL52EqrK0hNWO+kDwItyaamxyvB8eR2iYjsdWVTc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 18 Jul 2012 13:33:04 +0200 id 00000000005DC03F.0000000050069EF0.00000B9D Message-ID: <50069EEF.9040607@tana.it> Date: Wed, 18 Jul 2012 13:33:03 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <1991186.y8zxGRhPli@scott-latitude-e6320> <50044E4C.5080308@tana.it> <5246369.WNxnjnS4q5@scott-latitude-e6320> In-Reply-To: <5246369.WNxnjnS4q5@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #28: i18n for EAI compatibility, was Review of draft-ietf-spfbis-4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 11:32:26 -0000 On Mon 16/Jul/2012 20:27:03 +0200 Scott Kitterman wrote: > On Monday, July 16, 2012 07:24:28 PM Alessandro Vesely wrote: > >> Could we try and see how it works, or at least state the pros and cons >> we'd expect? > > Current implementations don't deal with UTF-8. To the extent they > might, they are buggy. True. But then we can have funky local-parts even without UTF-8. > I think that converting to an A-label is the best we can do without > breaking backward compatibility, which, as I read the charter we > aren't allowed to do for non-essential reasons. We don't break backward compatibility. To publishers and senders, we can non-normatively suggest to use A-labels, which is just common sense as of today, unless they know that all their receivers are SMTPUTF8-compliant. Receivers who are not SMTPUTF8-compliant normatively MUST return permerror when they see non-ASCII or invalid chars either in the smtp.mailfrom or in the SPF record. That's consistent with EAI, and is not different from what we'd do anyway. In addition, it prompts developers to make sure they check the strings they get. Relying on callers in order to skip parameters validation is not a good practice for library functions... > Given the level of EAI deployment, I don't think it's such a reason. Now that Andrew is questioning our sampling, I note I never saw any IDN domain using SPF, let alone UTF-8 local-parts. However, EAI has been experimental for quite a while. Didn't they ever send mail to one another? According to http://eggert.org/meter/spf there is some 56.9% SPF domains in South Korea. Do they use IDN? By s/US-ASCII/UTF-8/ we'd just put our 2 cents for that slow, global change. We can continue undisturbed in our ASCII world, yet allow those who need extra characters to use them. jm2c From ajs@anvilwalrusden.com Wed Jul 18 06:44:22 2012 Return-Path: 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 37A8921F861B for ; Wed, 18 Jul 2012 06:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 nguj8PFq8LWE for ; Wed, 18 Jul 2012 06:44:21 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 959A121F856C for ; Wed, 18 Jul 2012 06:44:21 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 776E38A031 for ; Wed, 18 Jul 2012 13:45:11 +0000 (UTC) Date: Wed, 18 Jul 2012 09:45:09 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120718134509.GC340@mail.yitter.info> References: <6.2.5.6.2.20120717221940.08d5eb40@elandnews.com> <50067E2C.3030103@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50067E2C.3030103@tana.it> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Bug in SPFBIS Charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 13:44:22 -0000 On Wed, Jul 18, 2012 at 11:13:16AM +0200, Alessandro Vesely wrote: > It's not a bug. Unused features don't "exist" --by reversing the > ontological argument-- since their mere existence would entail some > kind of use. We can regard "existing" and "in use" as synonyms :-/ The ontological argument only works for the philosopher's God, and not for anything else. As important as I'm sure SPF is, I have pretty grave doubts that it is the font of being ;-) A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Wed Jul 18 07:32:52 2012 Return-Path: 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 DA17721F877E for ; Wed, 18 Jul 2012 07:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 NnDhQja4eoKp for ; Wed, 18 Jul 2012 07:32:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1862521F8777 for ; Wed, 18 Jul 2012 07:32:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B880F20E40BD; Wed, 18 Jul 2012 10:33:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342622021; bh=oklY1PodKuq/e8tUzzq5EeA7wD+kcxGNwpStZGdPZeo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=k2U5c0EJ74fEgZhq/WMa5GLlCUGlX+Hzs5eT2WbsSq8aQcfArVysGeA3F2dp0VdpP Hk0cC2xzvfALmOGIS3wFfoA0qeYrwgABijyyH7cU1N7Y49R1iuv6mhaqGNLkgx5W2C MDScsiOYgBI0zCGU8nkpszNR3YUnu+ncF5eXMyr8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9994D20E4081; Wed, 18 Jul 2012 10:33:41 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 18 Jul 2012 10:33:40 -0400 Message-ID: <8608902.aGNSBUvAEH@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120717221940.08d5eb40@elandnews.com> References: <6.2.5.6.2.20120717221940.08d5eb40@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Bug in SPFBIS Charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 14:32:53 -0000 On Tuesday, July 17, 2012 10:41:21 PM SM wrote: > The SPFBIS Charter has the following: > > "Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language." > > and: > > "Discussion of extensions to the SPF protocols or removal of > existing features shall only be discussed after completion of > current charter items in anticipation of rechartering the working > group." > > The working group can remove unused features and it shall not discuss > about removing existing features. Is this a bug? :-) I think the second part was intended to be limited to enhancements that don't already have widespread support and deletion of used features. Scott K From dhc@dcrocker.net Wed Jul 18 07:37:39 2012 Return-Path: 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 824BF21F8798 for ; Wed, 18 Jul 2012 07:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 SoYnE1d7nhky for ; Wed, 18 Jul 2012 07:37:39 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E48721F8787 for ; Wed, 18 Jul 2012 07:37:38 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6IEcSH6008154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Jul 2012 07:38:29 -0700 Message-ID: <5006CA63.1010206@dcrocker.net> Date: Wed, 18 Jul 2012 07:38:27 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Scott Kitterman References: <6.2.5.6.2.20120717221940.08d5eb40@elandnews.com> <8608902.aGNSBUvAEH@scott-latitude-e6320> In-Reply-To: <8608902.aGNSBUvAEH@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 18 Jul 2012 07:38:29 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] Bug in SPFBIS Charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 14:37:39 -0000 On 7/18/2012 7:33 AM, Scott Kitterman wrote: > I think the second part was intended to be limited to enhancements that don't > already have widespread support and deletion of used features. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From derek.diget+spfbis@wmich.edu Wed Jul 18 10:04:43 2012 Return-Path: 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 6D38D21F8733 for ; Wed, 18 Jul 2012 10:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.815 X-Spam-Level: X-Spam-Status: No, score=-5.815 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_PCT_LETTER=0.784] 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 Jz-bpg8JB+mr for ; Wed, 18 Jul 2012 10:04:42 -0700 (PDT) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76F21F872D for ; Wed, 18 Jul 2012 10:04:42 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0M7D0040I8T2KL60@mta01.service.private> for spfbis@ietf.org; Wed, 18 Jul 2012 13:05:27 -0400 (EDT) X-WMU-Spam: Gauge=X, Probability=10% on Wed Jul 18 13:05:27 2012, Report=' WMU_MSA_SMTP+ 0, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NS ' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.18.165719 - Wed Jul 18 13:05:27 2012 Date: Wed, 18 Jul 2012 13:05:26 -0400 (EDT) From: Derek Diget X-X-Sender: diget@spaz.oit.wmich.edu To: spfbis@ietf.org In-reply-to: <6.2.5.6.2.20120717144053.099bd988@elandnews.com> Message-id: References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> <50047A0F.5050907@isdg.net> <6.2.5.6.2.20120716171913.08c8be40@resistor.net> <5005B227.6070803@isdg.net> <6.2.5.6.2.20120717114613.08066c40@resistor.net> <6.2.5.6.2.20120717144053.099bd988@elandnews.com> Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 17:04:43 -0000 On Jul 17, 2012 at 16:55 -0700, S Moonesamy wrote: =>At 14:30 17-07-2012, Murray S. Kucherawy wrote: =>> I'm a little confused by this, now that you mention it. If the force of =>> this is that verifiers have to continue to support PTR and macros and =>> whatever else we formally decide to deprecate, I wonder what we've gained. =>> The verifier is where all of the real work is done and where the risk is =>> arguably highest. => =>I was trying to explain "MUST support" in terms of a previous discussion. => =>> The sender is advised to stop using them, but there's really no impact if =>> they don't. =>> =>> What's the point? =>> =>> Wouldn't it be better to say that verifiers SHOULD ignore deprecated =>> features, but if they don't, they should simply be ignored (rather than =>> returning "permerror")? => =>In terms of a protocol we can remove a feature or we can deprecate it. Let's =>say that we decide to make "ptr" obsolete. Some parsers might break, some =>parsers might ignore that. If we want a transition we can deprecate a =>feature. We can look at this in terms of senders do not generate and =>receivers will process. We could also have chosen the "please ignore" =>approach where receivers will not process. The "verifiers SHOULD ignore =>deprecated features" is a generic recommendation. If we want to see an =>immediate impact we are forgoing gradual transition. At what point do we have to say that the changes proposed for 4408bis will force the SPF record to jump to v=spf3 because the protocol has changed enough that interoperability issues (deprecated/removed/?added? items) are introduced? I know (or think) this line of thought is probably outside the group's charter, but as a email admin, I am starting to feel that the more that is deprecated or removed, the more that I will run into issues with a sender saying one thing (either a "legacy" 4408 SPF record or an updated 4408bis SPF record) and my (receiver) software evaluating it differently than the publisher wanted. Heck, I have had an open ticket with @kohls.com for almost a weak about their broken (dual TXT) SPF record. Don't get me started on how I had to tell one of the DNS admins how to use dig to look it up. :( -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** From hsantos@isdg.net Wed Jul 18 11:42:22 2012 Return-Path: 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 1122C21F8494 for ; Wed, 18 Jul 2012 11:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, SARE_SUB_PCT_LETTER=0.784, 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 RF2Bad0mFJNB for ; Wed, 18 Jul 2012 11:42:21 -0700 (PDT) Received: from ntbbs.santronics.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BB65521F85B6 for ; Wed, 18 Jul 2012 11:42:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2005; t=1342636978; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=KhOlsjEa7r0AtKVedrPoEIOesoo=; b=E5sqatEPzKQI48DBXArY B1BEA6fL+FQQqnQ5QWzvLO8Oynt18JZjBIkyGlOdq9evI9/QZ5gqXxEP0vPDn/3S aC2IwEl6jFiikfEURaQkap8jTO7/PlsIMVuBI168lwAkBXF2HODdrV1pwgf4Jazj PyPsCJSSO3EtuQB2IGx59fM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 18 Jul 2012 14:42:58 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2953776633.17122.4268; Wed, 18 Jul 2012 14:42:56 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2005; t=1342636845; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=kD/m4T7 iRHUkdSG1AMWYuSJkByNjJkck6mVDrwtkxh4=; b=0k6ABklLLfFNnEnh+/zYqfy 0FeJwtaHM0v6QIdsKEtiFe1LfjhidXPgJDgqZLOrFdBnnSAxRyhVbT9sfaXqpDCf Wg5H26lcJjiP+qDcIXWOyJiJOzXFi0BGGEs8bKQdGdzFFSB858VgBnEoVmFxULU8 tRFsNtex2KaOq8Am9UUY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 18 Jul 2012 14:40:45 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3552609988.9.3736; Wed, 18 Jul 2012 14:40:43 -0400 Message-ID: <500703FA.9030308@isdg.net> Date: Wed, 18 Jul 2012 14:44:10 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alessandro Vesely References: <20120712022051.60587.qmail@joyce.lan> <6.2.5.6.2.20120716171913.08c8be40@resistor.net> <5005B227.6070803@isdg.net> <29188283.Md6KR1EyTt@scott-latitude-e6320> <50067D97.5080408@tana.it> In-Reply-To: <50067D97.5080408@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Wizards, was PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 18:42:22 -0000 I don't think its a good idea to blame wizards, especially branding any specific ones in a specification. IMO, they were not the problem and I am not convince there was ever a problem requiring to deprecate specifically PTR. Its going to cause more harm, than good to promote the deprecation. I am not looking forward to changing all our SPF policies for our domains using PTR. -- HLS Alessandro Vesely wrote: > On Tue 17/Jul/2012 21:21:45 +0200 Scott Kitterman wrote: >> On Tuesday, July 17, 2012 02:42:47 PM Hector Santos wrote: >>> Recommending Publishers not use it is another thing, so perhaps >>> this is more about a BCP. >>> >>> PTR appears to me to be among the highest use directive among the >>> cache I see and we should not be surprise because the WIZARDS out >>> there makes it part of the easy setup defaults. By far, the #1 SPF >>> statement (among my cache) is: >>> >>> v=spf1 a mx ptr ~all >> Which is a brain dead recommendation. It's not random that >> openspf.org no longer provides a wizard. The old one produced >> awful garbage like this and no one wrote a new one yet. The one >> thing that all SPF wizards (AFAIK) have in common is they aren't >> much good. > > Good point! Should the definition of "Deprecated" address wizards? > For example (after incorporating Murray's change): > > There are several [RFC4408] features that are marked "deprecated". > In the context of this document, deprecated means that senders SHOULD > NOT publish SPF records that make use of the features in question, > and tools that generate generic SPF records based on users' input > MUST NOT propose them. Use of these features is not advised, as > they might be removed entirely in future updates to the protocol. > Such features do, however, remain part of the SPF protocol and > receiving systems MUST support them unless this specification says > otherwise. > > That way, people would be able to tell which wizards are not compliant > with 4408bis. From sm@elandsys.com Wed Jul 18 13:09:26 2012 Return-Path: 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 C46B511E8095 for ; Wed, 18 Jul 2012 13:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 SmTLfcL6isf8 for ; Wed, 18 Jul 2012 13:09:26 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8E311E8166 for ; Wed, 18 Jul 2012 13:09:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.220]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6IKA4KH004422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jul 2012 13:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342642216; bh=kob8HSjOhH/sMf5E0YCAK5FOCusmojy5mitGwps6p+Q=; h=Date:To:From:Subject:Cc; b=Adw/2V+Qf8CYNEnPT5uoxhLQwclxGzaOaCrHderdVScNff5eR22dNundP7wYh2JaS ErtwNbfyB7HUN8L2+0unlPK/LhXtFN9OPZ4nqgeiEEJRXgGkXbiS583KJEo8tbEtMM sgVHM/5szzS9C4kSzoEwMytiYy2R9o+8G2MnKv9w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342642216; i=@elandsys.com; bh=kob8HSjOhH/sMf5E0YCAK5FOCusmojy5mitGwps6p+Q=; h=Date:To:From:Subject:Cc; b=T5hDVExxbZQGNlFvkuijwOTzK5euvYngDx7uuwIdLDUSV9FtEPuoVbMeYr2Y7iwAT PcADfbe7jx9zLQvu+658uN7vzdl+aA42CjgcFW3cPw0A3YnWfj9sZaXnvAeNQvjDfA 8Zqv8jD8l1tw58zyJ3y+fqqUNzSp7mdpMMOMPDOU= Message-Id: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 18 Jul 2012 13:09:36 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 20:09:26 -0000 Hello, The second and last deliverable for the working group is to produce a standards track document defining SPF by December 2012. The SPFBIS Charter mentions features. Instead of commenting about features I'll look at this from another angle. (i) RFC 4408 has not been reviewed by the IETF (ii) There are multiple implementations of RFC 4408 (iii) The Errata for RFC 4408 does not mention Issue #9 draft-ietf-spfbis-4408bis is unusual work as Experimental RFCs generally go through (i). It can be argued that the draft can be published as a RFC with (iii) as the significant change and some editorial changes. Murray Kucherawy mentioned the following [1]: "If I were sitting on SECDIR, I'd make some noise about this during Last Call, for example." draft-ietf-spfbis-4408bis will be reviewed by the IETF Security Directorate (SECDIR). It is expected that the working group will give some serious thought to the security considerations aspect before the Last Call. Scott Kitterman raised an interesting point: backward incompatibility [2]. The question that comes to my mind is whether draft-ietf-spfbis-4408bis has to be backward compatible with RFC 4408. Section 4 of RFC 4408 has the following requirement: "Mail receivers that perform this check MUST correctly evaluate the check_host() function as described here." There is a reference in that Section 4 to Section 2.5. In Section 2.5.5, there is: 'A "SoftFail" result should be treated as somewhere between a "Fail" and a "Neutral".' Depending on how one interprets RFC 2119 there may or may not be a recommendation in that sentence. Assuming that it is a recommendation (SHOULD) the "somewhere between" two possible results is ambiguous. Section 5 defines the mechanisms. Section 6 defines the modifiers. I'll assume that a change in these sections can affect the results (Section 4). The macros defined in Section 8 indirectly affects mechanisms and modifiers. In my individual opinion RFC 4408 is not ready for publication as a Proposed Standard as an IESG Evaluation would generate DISCUSSes (issues the working group must fix). Kurt Andersen commented about why "management elected to discontinue the use of all SPF records [3]. Derek Diget mentioned that 'as a email admin, I am starting to feel that the more that is deprecated or removed, the more that I will run into issues with a sender saying one thing (either a "legacy" 4408 SPF record or an updated 4408bis SPF record) and my (receiver) software evaluating it differently than the publisher wanted' [4]. draft-ietf-spfbis-experiment did not generate any DISCUSSes as the working group discussed the issues and possible issues. My suggestions are: 1. Demonstrate that a RFC 4408 implementation and a draft-ietf-spfbis-4408bis implementation will produce the same results 2. If (1) is not possible, provide an explanation for the change Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg01879.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg01888.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg01889.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg01902.html From WebMaster@Commerco.Net Wed Jul 18 15:00:35 2012 Return-Path: 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 3CB2211E8157 for ; Wed, 18 Jul 2012 15:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 qIpU0XtUfmOT for ; Wed, 18 Jul 2012 15:00:34 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6546F11E8087 for ; Wed, 18 Jul 2012 15:00:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=yGdCQ2NjeyEouLaIWuNX7NaZRoTq5HqCFQJmZdY/JLFFm5P1oPbHURdTAUHyBTaVsbANwUyFuy2IaZKhMuc7dhs7XnA3ylwiwUHoGARKq5u38SO4VdswkWqvRxFhzjQhUGrJst8s2QrYmvGGwMeH2F0toRsiqNt+6t68bDqq2x0= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]); Wed, 18 Jul 2012 22:01:25 +0000 Message-ID: <5007322E.9080009@Commerco.Net> Date: Wed, 18 Jul 2012 16:01:18 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org, S Moonesamy References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> In-Reply-To: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 22:00:35 -0000 On 7/18/2012 2:09 PM, S Moonesamy wrote: > Hello, > > The second and last deliverable for the working group is to produce a > standards track document defining SPF by December 2012. The SPFBIS > Charter mentions features. Instead of commenting about features I'll > look at this from another angle. > > (i) RFC 4408 has not been reviewed by the IETF > > (ii) There are multiple implementations of RFC 4408 > > (iii) The Errata for RFC 4408 does not mention Issue #9 > > draft-ietf-spfbis-4408bis is unusual work as Experimental RFCs generally > go through (i). It can be argued that the draft can be published as a > RFC with (iii) as the significant change and some editorial changes. > Murray Kucherawy mentioned the following [1]: > > "If I were sitting on SECDIR, I'd make some noise about this during Last > Call, > for example." > > draft-ietf-spfbis-4408bis will be reviewed by the IETF Security > Directorate (SECDIR). It is expected that the working group will give > some serious thought to the security considerations aspect before the > Last Call. > > Scott Kitterman raised an interesting point: backward incompatibility > [2]. The question that comes to my mind is whether > draft-ietf-spfbis-4408bis has to be backward compatible with RFC 4408. > Yow! As I understood the charter, the idea here was to spend the time and energy of all involved in formalizing and correcting any errors and / or omissions in the specification for surviving branch of SPF as 4408bis. In that charter, I understood that the goal would be to do things like clean up incorrect or invalid wording, take the experience we have with some 8 years of SPF in the wild and apply that to the 4408bis document in order to have a stronger standard from which to work for future implementers and perhaps clean up some misunderstandings by those who are existing implementers (both from a code provider and DNS publisher standpoint). What I did not understand as a charter goal was the redefinition of SPF to the point that it would not become interoperable with that which correctly exists in the wild. If we were to do that, the the point raised recently about SPF V3 on this list is probably valid, but I am fairly sure that our charter is not to create SPF V3 (a future version which may or may not be backwards compatible, but then that is a whole other working group... I think). I guess the question for me really is are we fixing something that is really broken or breaking something that actually works? I am certainly hopeful that it is the former rather than the latter. Alan M. From dhc@dcrocker.net Wed Jul 18 15:08:52 2012 Return-Path: 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 76D0F11E8087 for ; Wed, 18 Jul 2012 15:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3CI84+sny5Z5 for ; Wed, 18 Jul 2012 15:08:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A213221F8629 for ; Wed, 18 Jul 2012 15:08:51 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6IM9QML031339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Jul 2012 15:09:26 -0700 Message-ID: <50073414.7060502@dcrocker.net> Date: Wed, 18 Jul 2012 15:09:24 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Commerco WebMaster References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> In-Reply-To: <5007322E.9080009@Commerco.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 18 Jul 2012 15:09:26 -0700 (PDT) Cc: spfbis@ietf.org, S Moonesamy Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 22:08:52 -0000 On 7/18/2012 3:01 PM, Commerco WebMaster wrote: > What I did not understand as a charter goal was the redefinition of SPF > to the point that it would not become interoperable with that which > correctly exists in the wild. Removing unused features is an essential part of this type of exercised. Unused feature add cost, complexity and bugs. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Wed Jul 18 15:20:45 2012 Return-Path: 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 DB50711E80BA for ; Wed, 18 Jul 2012 15:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 y0ds+saicfQE for ; Wed, 18 Jul 2012 15:20:45 -0700 (PDT) Received: from ntbbs.santronics.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0393A11E80AD for ; Wed, 18 Jul 2012 15:20:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=873; t=1342650088; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=4Uo8pHPIB0L7sqMaoPW5GfxQJiw=; b=py0OPyHf8MiWrCzi/J3N R1EXuNKRkwAtfE3kzaQZ7vwXdksjxKk8poS4iSpgu9F3EvQqE6OPgvCPDZ5suEm6 TF8aLpXem+UHwrmN/cz5XgKa24B+fhi0w4thqV7xcr+t2bRhmFUv/nOSa16F12pi sZ877wgUu31fsMeUkpdgXq4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 18 Jul 2012 18:21:28 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2966887020.17122.5588; Wed, 18 Jul 2012 18:21:27 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=873; t=1342649957; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ZXH7kBT uRFl64uMw6JTJRVUqIXfKMKBJDRR83S55f9U=; b=EbRerM7kstNwf7KqdoTM6Kw W+W4LVW5u2jztAwaFeQqcsSdUPcynanXtNgeRB21pf1oyJfrqR6atCAIs8X4zeed woOA4A/j/ObHVv9/mSW7EW+pEuj0M7C0XOJl+3DmoZUUCb1U1XMK+so76/TRcgL9 X4nRBi8wupM1fSl1fcJ0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 18 Jul 2012 18:19:17 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3565722629.9.6400; Wed, 18 Jul 2012 18:19:16 -0400 Message-ID: <50073705.8030105@isdg.net> Date: Wed, 18 Jul 2012 18:21:57 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: dcrocker@bbiw.net References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <50073414.7060502@dcrocker.net> In-Reply-To: <50073414.7060502@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Commerco WebMaster , S Moonesamy Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 22:20:46 -0000 This is an generality that has not been shown to be the case for PTR, include the %p macro. All this has been tested by implementators and deployments long ago. No problem, no bugs and that cost has already been spent. What is being suggested to create change, and with change chaos begins - time, energy, cost all to reach equilibrium again. We are at equilibrium now. That said, I have yet to see a legit reason to remove a USED feature in PTR. Dave Crocker wrote: > > > On 7/18/2012 3:01 PM, Commerco WebMaster wrote: >> What I did not understand as a charter goal was the redefinition of SPF >> to the point that it would not become interoperable with that which >> correctly exists in the wild. > > > Removing unused features is an essential part of this type of exercised. > Unused feature add cost, complexity and bugs. > > d/ -- HLS From hsantos@isdg.net Wed Jul 18 15:37:37 2012 Return-Path: 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 6E81B11E81AB for ; Wed, 18 Jul 2012 15:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 Pf6ko+qhMcUY for ; Wed, 18 Jul 2012 15:37:36 -0700 (PDT) Received: from ntbbs.santronics.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 832AD11E80BA for ; Wed, 18 Jul 2012 15:37:36 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2939; t=1342651098; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=QQ6Q3MSknBRrchrkHEBub3izwcw=; b=Ge7SB84ERWGIz+nKdHkH JqcBlb2tE/F16I4zKikdosoOYH0RTQ2kOaLiTMv84ODSfZOwnMAGvCsnJw1WEFMg V0kaLtLvg+uJ9f+kgYsG9AstBD/B07PuCGWjHvn1dr5JNtvJ6wDEchZjMQcxVGpc 9bOKgAlKlUDPGweaNySIY/Y= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 18 Jul 2012 18:38:18 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2967897345.17122.2392; Wed, 18 Jul 2012 18:38:17 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2939; t=1342650968; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=UApQs9c /OiFSvhULQ2W2kpMr2MSnkVfaIzqiGJU3D8M=; b=2kUJ7uv0BphpFncw7hmBrnA AoImQG6ZQCL9m2oOrgUuJVnn8c233PVOOV8VwWUAWLeLCSiwMsJQmDmTil7K1Zxb YEI6uOYHoxvZWZZ4iIC045bt4XK4s66viGhQowMdofrQucpUcqDp4bGFR43gZ9rZ fMpqNDe5bLRBFxHY73pI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 18 Jul 2012 18:36:08 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3566733395.9.8120; Wed, 18 Jul 2012 18:36:07 -0400 Message-ID: <50073AFB.8000501@isdg.net> Date: Wed, 18 Jul 2012 18:38:51 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Commerco WebMaster References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> In-Reply-To: <5007322E.9080009@Commerco.Net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, S Moonesamy Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 22:37:37 -0000 +1 to all you stated. Commerco WebMaster wrote: > On 7/18/2012 2:09 PM, S Moonesamy wrote: >> Hello, >> >> The second and last deliverable for the working group is to produce a >> standards track document defining SPF by December 2012. The SPFBIS >> Charter mentions features. Instead of commenting about features I'll >> look at this from another angle. >> >> (i) RFC 4408 has not been reviewed by the IETF >> >> (ii) There are multiple implementations of RFC 4408 >> >> (iii) The Errata for RFC 4408 does not mention Issue #9 >> >> draft-ietf-spfbis-4408bis is unusual work as Experimental RFCs generally >> go through (i). It can be argued that the draft can be published as a >> RFC with (iii) as the significant change and some editorial changes. >> Murray Kucherawy mentioned the following [1]: >> >> "If I were sitting on SECDIR, I'd make some noise about this during Last >> Call, >> for example." >> >> draft-ietf-spfbis-4408bis will be reviewed by the IETF Security >> Directorate (SECDIR). It is expected that the working group will give >> some serious thought to the security considerations aspect before the >> Last Call. >> >> Scott Kitterman raised an interesting point: backward incompatibility >> [2]. The question that comes to my mind is whether >> draft-ietf-spfbis-4408bis has to be backward compatible with RFC 4408. >> > > Yow! > > As I understood the charter, the idea here was to spend the time and > energy of all involved in formalizing and correcting any errors and / or > omissions in the specification for surviving branch of SPF as 4408bis. > > In that charter, I understood that the goal would be to do things like > clean up incorrect or invalid wording, take the experience we have with > some 8 years of SPF in the wild and apply that to the 4408bis document > in order to have a stronger standard from which to work for future > implementers and perhaps clean up some misunderstandings by those who > are existing implementers (both from a code provider and DNS publisher > standpoint). > > What I did not understand as a charter goal was the redefinition of SPF > to the point that it would not become interoperable with that which > correctly exists in the wild. > > If we were to do that, the the point raised recently about SPF V3 on > this list is probably valid, but I am fairly sure that our charter is > not to create SPF V3 (a future version which may or may not be backwards > compatible, but then that is a whole other working group... I think). > > I guess the question for me really is are we fixing something that is > really broken or breaking something that actually works? > > I am certainly hopeful that it is the former rather than the latter. > > Alan M. > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From superuser@gmail.com Wed Jul 18 18:55:50 2012 Return-Path: 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 E459921F86A5 for ; Wed, 18 Jul 2012 18:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 stOXaoM+q2Eu for ; Wed, 18 Jul 2012 18:55:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9251A21F86A3 for ; Wed, 18 Jul 2012 18:55:49 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3197134lbb.31 for ; Wed, 18 Jul 2012 18:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wok2OoS8F+on3cLFPe8XdFfriRDvc010bi1AR9AHE14=; b=TxhFJPbF/22ft0UnMxz/LayO+x07DPAWHIOIafmNglA0YJA50cNSoWTJ+3+3/+aM0p 5ZLV7+upMTXQ90/E0EqZ9Ve6qUUJPWxwGkVUvjVIKGMXWrOhn4D1aCfLFn0DJFlZEz0m XaYutq17/A4dHIlzb3hxc8D6YnCmDClw5r4oFynqcRaqeJ+iK5zeqs7n41Mj00jvtjF+ d9pB4+oNCeTXfR3Ny5h90ROxKiEGcoy64IV5GTdwDbFpn71ebRrgOsdFblyY747Llzjz yhj7Rcq6ya428Ac94YIAScYNpnnI89v62jN+su4G9Wn1asCfGhGfJR8Wh9yXFjidThU7 d44A== MIME-Version: 1.0 Received: by 10.112.84.168 with SMTP id a8mr156260lbz.92.1342663000354; Wed, 18 Jul 2012 18:56:40 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 18 Jul 2012 18:56:40 -0700 (PDT) In-Reply-To: <5007322E.9080009@Commerco.Net> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> Date: Wed, 18 Jul 2012 18:56:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: Commerco WebMaster Content-Type: multipart/alternative; boundary=f46d04016cad306e7804c52517dc Cc: spfbis@ietf.org, S Moonesamy Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 01:55:51 -0000 --f46d04016cad306e7804c52517dc Content-Type: text/plain; charset=ISO-8859-1 Hi Alan, On Wed, Jul 18, 2012 at 3:01 PM, Commerco WebMaster wrote: > What I did not understand as a charter goal was the redefinition of SPF to > the point that it would not become interoperable with that which correctly > exists in the wild. > The two surveys I referenced show that both the "ptr" mechanism and macros in general are in use in the wild, but by a very tiny percentage of the deployed base. It's true that removing them entirely would render those few sites incompatible with the Proposed Standard. In my view (and I believe Dave's and the two John Ls, at least), that is a cost offset by the fact that the two features we're talking about removing are costly: "ptr" is expensive in terms of performance and can be accomplished by other extant, less expensive means, and macros are expensive in terms of their complexity and thus high maintenance cost and risk of misimplementation ("dangerous", as John Levine put it), not to mention the DNS issues it raises. The TDP survey shows a fraction of a percent using "ptr" or macros. The Cisco survey shows exactly one out of a million domains using "ptr", and none using macros. Hector claims heavier "ptr" use in his data, but has not provided the details. Based on that, I maintain the spec is "broken" (as you've used the term) and needs fixing. I also maintain that the charter allows such removals under its "unused" clause. Further, I don't much like the idea of going onto the Standards Track for the first time with two features we know see very little use, have known costs, and have basically agreed should at least be deprecated. That just feels completely sloppy to me. I recognize there's a big deployed base for SPF, but approximately none of that base uses the stuff we're talking about. Keeping it creates more of a burden than it solves. The counter-argument is basically "It's only a 'proposed' standard, and we can remove these things before it goes along the RFC6410 route." Those of us who have been around long enough know that such advancement is rare indeed (which is why we recently went from three maturity levels down to two), so on the premise that such a revision is also statistically unlikely, I think the proper thing to do is get it right up front. As I said in an earlier post, if something were to land in front of me, as a SECDIR reviewer or an IESG member, with two sections that basically say "We know this is broken, please don't use it in TXT records but receivers MUST support it anyway", I'd be asking questions about why it's going for the Standards Track in the first place.. -MSK --f46d04016cad306e7804c52517dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alan,

On Wed, Jul 18, 2012 at 3:01 PM, Commerco WebMaster <= WebMaster@commerco.net> wrote:
=
What I did not understand as a charter goal was the redefinition of SPF to = the point that it would not become interoperable with that which correctly = exists in the wild.

The two surveys I referenced s= how that both the "ptr" mechanism and macros in general are in us= e in the wild, but by a very tiny percentage of the deployed base.=A0 It= 9;s true that removing them entirely would render those few sites incompati= ble with the Proposed Standard.=A0 In my view (and I believe Dave's and= the two John Ls, at least), that is a cost offset by the fact that the two= features we're talking about removing are costly: "ptr" is e= xpensive in terms of performance and can be accomplished by other extant, l= ess expensive means, and macros are expensive in terms of their complexity = and thus high maintenance cost and risk of misimplementation ("dangero= us", as John Levine put it), not to mention the DNS issues it raises.<= br>
The TDP survey shows a fraction of a percent using "ptr" or m= acros.=A0 The Cisco survey shows exactly one out of a million domains using= "ptr", and none using macros.=A0 Hector claims heavier "ptr= " use in his data, but has not provided the details.

Based on that, I maintain the spec is "broken" (as you've= used the term) and needs fixing.=A0 I also maintain that the charter allow= s such removals under its "unused" clause.

Further, I don&= #39;t much like the idea of going onto the Standards Track for the first ti= me with two features we know see very little use, have known costs, and hav= e basically agreed should at least be deprecated.=A0 That just feels comple= tely sloppy to me.=A0 I recognize there's a big deployed base for SPF, = but approximately none of that base uses the stuff we're talking about.= =A0 Keeping it creates more of a burden than it solves.

The counter-argument is basically "It's only a 'proposed&#= 39; standard, and we can remove these things before it goes along the RFC64= 10 route."=A0 Those of us who have been around long enough know that s= uch advancement is rare indeed (which is why we recently went from three ma= turity levels down to two), so on the premise that such a revision is also = statistically unlikely, I think the proper thing to do is get it right up f= ront.

As I said in an earlier post, if something were to land in front of me,= as a SECDIR reviewer or an IESG member, with two sections that basically s= ay "We know this is broken, please don't use it in TXT records but= receivers MUST support it anyway", I'd be asking questions about = why it's going for the Standards Track in the first place..

-MSK

--f46d04016cad306e7804c52517dc-- From spf2@kitterman.com Wed Jul 18 19:08:51 2012 Return-Path: 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 F15CC21F85FD for ; Wed, 18 Jul 2012 19:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 0GtudTlon5oQ for ; Wed, 18 Jul 2012 19:08:50 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id EBA6F21F85FB for ; Wed, 18 Jul 2012 19:08:49 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 2D279D0407F; Wed, 18 Jul 2012 21:09:41 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342663781; bh=FB3J28hAxWU5cB7z3uEWr8IeQ/GS4hGxlpmrfAXrT1I=; h=References:In-Reply-To:Subject:From:Date:To:From; b=or56v9aa3y5z+Vxv6Ihii/ddOdgdGgEFa5z+dmeAp7jbs1vunUl7AD8gfYmCwkizn WzfhwVX2yNvC/IUXrV+Y2rxpr3dHPzl8T3R4Bw1SPtSU/b6xe5v/2lSrzsPRKB7EbT u1YyNkTtgjsVfLk9Jb2n5db9OWZM+igIUnd4XNfw= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EE3BBD04057; Wed, 18 Jul 2012 21:09:40 -0500 (CDT) References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 18 Jul 2012 22:09:39 -0400 To: spfbis@ietf.org Message-ID: <20f4303a-b51b-4ece-8547-518bd79b0bea@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 02:08:51 -0000 "Murray S. Kucherawy" wrote: >Hi Alan, > >On Wed, Jul 18, 2012 at 3:01 PM, Commerco WebMaster >wrote: > >> What I did not understand as a charter goal was the redefinition of >SPF to >> the point that it would not become interoperable with that which >correctly >> exists in the wild. >> > >The two surveys I referenced show that both the "ptr" mechanism and >macros >in general are in use in the wild, but by a very tiny percentage of the >deployed base. It's true that removing them entirely would render >those >few sites incompatible with the Proposed Standard. In my view (and I >believe Dave's and the two John Ls, at least), that is a cost offset by >the >fact that the two features we're talking about removing are costly: >"ptr" >is expensive in terms of performance and can be accomplished by other >extant, less expensive means, and macros are expensive in terms of >their >complexity and thus high maintenance cost and risk of misimplementation >("dangerous", as John Levine put it), not to mention the DNS issues it >raises. > >The TDP survey shows a fraction of a percent using "ptr" or macros. >The >Cisco survey shows exactly one out of a million domains using "ptr", >and >none using macros. Hector claims heavier "ptr" use in his data, but >has >not provided the details. > >Based on that, I maintain the spec is "broken" (as you've used the >term) >and needs fixing. I also maintain that the charter allows such >removals >under its "unused" clause. > >Further, I don't much like the idea of going onto the Standards Track >for >the first time with two features we know see very little use, have >known >costs, and have basically agreed should at least be deprecated. That >just >feels completely sloppy to me. I recognize there's a big deployed base >for >SPF, but approximately none of that base uses the stuff we're talking >about. Keeping it creates more of a burden than it solves. > >The counter-argument is basically "It's only a 'proposed' standard, and >we >can remove these things before it goes along the RFC6410 route." Those >of >us who have been around long enough know that such advancement is rare >indeed (which is why we recently went from three maturity levels down >to >two), so on the premise that such a revision is also statistically >unlikely, I think the proper thing to do is get it right up front. Up front was in 2005. >As I said in an earlier post, if something were to land in front of me, >as >a SECDIR reviewer or an IESG member, with two sections that basically >say >"We know this is broken, please don't use it in TXT records but >receivers >MUST support it anyway", I'd be asking questions about why it's going >for >the Standards Track in the first place.. > >-MSK Was the ip6 mechanism used more or less than ptr? Scott K From superuser@gmail.com Wed Jul 18 19:23:51 2012 Return-Path: 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 6E0C221F8675 for ; Wed, 18 Jul 2012 19:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 wXtzxJWxga09 for ; Wed, 18 Jul 2012 19:23:51 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 957E921F8674 for ; Wed, 18 Jul 2012 19:23:50 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3226902lbb.31 for ; Wed, 18 Jul 2012 19:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P0U/v183rSwMERTUAc+PyGyWOqp8eJfDEDmUqwlKJm0=; b=t7BTnQAE7463uWOEEbG9hObGSJFldiGpMuiZGSZqkmKeSxX888bAW7s7wyQ1tKFFv6 owDJ8eFYW2xE5XDxFkK6kCATOAXh493SJm4BekogY51mR0f4c6qoC8/k67cmAom5Pw4t lFG0XN5IlXrHXnuqJ0t53OT1QIwUeHACk4jWaYA6pU98LseksEVyzgC0VBwWM3W+WlWd 9zMz7I03RXS5Q8GIfVNplOAQ2O56Qm2zx2/smIsFQ9B3ExfcD/pwxwRzVQdy5mpomOIa 3YgVlkRNUxByNHSZ1S77DwUrL6AHxtwJ+jSRZVDUHQH92zzJnKhDXCB8RjKWeBBsHiBt bmKw== MIME-Version: 1.0 Received: by 10.152.112.138 with SMTP id iq10mr35649lab.13.1342664681705; Wed, 18 Jul 2012 19:24:41 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 18 Jul 2012 19:24:41 -0700 (PDT) In-Reply-To: <20f4303a-b51b-4ece-8547-518bd79b0bea@email.android.com> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20f4303a-b51b-4ece-8547-518bd79b0bea@email.android.com> Date: Wed, 18 Jul 2012 19:24:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0408da0767d29704c5257b0c Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 02:23:51 -0000 --f46d0408da0767d29704c5257b0c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 7:09 PM, Scott Kitterman wrote: > > Up front was in 2005. > As SM has pointed out, RFC4408 didn't undergo the rigors of formal IETF review back then. It is now. Was the ip6 mechanism used more or less than ptr? > > In the TDP survey, "ptr" had 93 distinct domains using it; ip6 had 0. In the Cisco survey, "ptr" had 1 domain using it; ip6 had 0. If the move here is to ask me if I'd also deprecate ip6 based on the data, the answer is "no" because IPv6 match logic is far simpler than macros, for example. I don't find that notion to be complex or dangerous. -MSK --f46d0408da0767d29704c5257b0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 7:09 PM, Scott Kitterman <spf2@kitterman.com&= gt; wrote:

Up front was in 2005.

As SM has pointe= d out, RFC4408 didn't undergo the rigors of formal IETF review back the= n.=A0 It is now.

Was the ip6 mechanism used more or less than ptr?


In the TDP survey, "ptr" had 93 distinc= t domains using it; ip6 had 0.

In the Cisco survey, "ptr" = had 1 domain using it; ip6 had 0.

If the move here is to ask me if I= 'd also deprecate ip6 based on the data, the answer is "no" b= ecause IPv6 match logic is far simpler than macros, for example.=A0 I don&#= 39;t find that notion to be complex or dangerous.

-MSK

--f46d0408da0767d29704c5257b0c-- From spf2@kitterman.com Wed Jul 18 19:54:10 2012 Return-Path: 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 BD5FD21F866E for ; Wed, 18 Jul 2012 19:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.595 X-Spam-Level: X-Spam-Status: No, score=-3.595 tagged_above=-999 required=5 tests=[AWL=1.004, BAYES_00=-2.599, GB_I_LETTER=-2] 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 SQ8nhcUl0rPO for ; Wed, 18 Jul 2012 19:54:10 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 07CE621F866D for ; Wed, 18 Jul 2012 19:54:10 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4447620E40BD; Wed, 18 Jul 2012 22:55:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342666501; bh=WhLpLKN4d6th31008IEe9/bcT9o9IHmnX2jpt3IrBsw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=S2vEIFwmXUgmmjV8Uprb1jlMZ3dZl//Pqa6Q8722q9NNn0UEvFslYw9D0zQVbF2rx YUppxShwdZL4kPvYHZIwjBuaoEcD2lQ9En4un/+XY7g5EwfwIZHBxT8mOC/CQrsseL abkV0I9kj7+lVxzf5Bd/Q0pOMx9Q/+sUc75UDQqg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 254A920E4081; Wed, 18 Jul 2012 22:55:00 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 18 Jul 2012 22:55 -0400 Message-ID: <1421911.K86mT8c64i@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <20f4303a-b51b-4ece-8547-518bd79b0bea@email.android.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 02:54:10 -0000 On Wednesday, July 18, 2012 07:24:41 PM Murray S. Kucherawy wrote: > On Wed, Jul 18, 2012 at 7:09 PM, Scott Kitterman wrote: > > Up front was in 2005. > > As SM has pointed out, RFC4408 didn't undergo the rigors of formal IETF > review back then. It is now. Sure, but you can't have it both ways. You can't both claim that this is a normal transition from experimental to standards track because by the letter of the IETF process, that's what it is, but then on the other hand claim that the letter of the IETF standards advancement process isn't realistic and we can't consider it reasonable that features we deprecate now will be removed when SPF is advanced. I think you either get to pick the letter of the IETF process or a realist view of it, not whichever is convenient. > Was the ip6 mechanism used more or less than ptr? > > > In the TDP survey, "ptr" had 93 distinct domains using it; ip6 had 0. > > In the Cisco survey, "ptr" had 1 domain using it; ip6 had 0. > > If the move here is to ask me if I'd also deprecate ip6 based on the data, > the answer is "no" because IPv6 match logic is far simpler than macros, for > example. I don't find that notion to be complex or dangerous. OK. So to be clear, being unused is not a criteria for removal? It's being unused and problematic in some manner? Scott K From ajs@anvilwalrusden.com Wed Jul 18 20:14:19 2012 Return-Path: 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 CD7F011E8096 for ; Wed, 18 Jul 2012 20:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 Q0K3-hKWve9I for ; Wed, 18 Jul 2012 20:14:19 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8696421F85B1 for ; Wed, 18 Jul 2012 20:14:19 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 600D48A031 for ; Thu, 19 Jul 2012 03:15:09 +0000 (UTC) Date: Wed, 18 Jul 2012 23:15:08 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120719031507.GG1323@crankycanuck.ca> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 03:14:20 -0000 No hat. On Wed, Jul 18, 2012 at 06:56:40PM -0700, Murray S. Kucherawy wrote: > As I said in an earlier post, if something were to land in front of me, as > a SECDIR reviewer or an IESG member, with two sections that basically say > "We know this is broken, please don't use it in TXT records but receivers > MUST support it anyway", I'd be asking questions about why it's going for > the Standards Track in the first place.. We have a glib answer to such questions, though: "It's what the IETF chartered us to do. If you think that needs changing, then the WG needs to be rechartered to fix these problems." Moreover, there is an interoperability argument available, which is that we have positive evidence that some people publish these sorts of records, and that therefore receivers need to be able to process them. This kind of issue is one we face in DNS-land all the time: once something is out there, it is all but impossible to get rid of it. Why do you think IDNA is the miserable hack it is? Why do you think we haven't introduced any new CLASSes since CHAOS? Why do you think the absurd and conceptually broken underscore convention has been embraced instead of just using new RRTYPEs? The counter-argument available to us, of course, is that we are moving from the experimental track. But for that argument to work, the charter would need to be more permissive in what it says we can remove. Moreover, suppose you are an SPF receiver and you get one of these records. What are you going to do with it? Drop it on the floor? No, of course not. You're going to use your hoary old 4408 code to handle it anyway. If that's true, then we should document it. (Note that deprecation _does_ mean that publisher-side tools can drop support for these things immediately.) I am having a really hard time accepting "nobody _we_ know uses this" as the meaning of "unused". To my mind, that's what these claims of "it's not an important use" amount to. The charter says quite explicitly that we're not allowed to remove "existing features that are in current use." The attempt to redefine "in current use" so that it doesn't include cases that are observed examples of the feature actually being deployed (even if it's a stupid feature) makes me very uneasy. The arguments from increased simplicity are good and convincing ones, but they are _irrelevant_ given our charter. The charter doesn't say, "You can't remove things in use, unless it makes the protocol better by virtue of simplicity."[1] . It says, "You can't remove things in use." The charter also doesn't say, "You can't remove things in use, unless you think the use is a bad idea," or, "You can't remove things in use, unless only a few people are using it," or anything of the kind. It is crystal clear. If we don't like that, the answer is not to try to weasel around the problem by stretching the meaning of "unused" past the breaking point even of English. The answer is to go back to the community and say, "This charter is stupidly restrictive for something coming from the experimental track and moving to the standards track." I am personally disinclined to lead that charge; but if people really want to do it, I won't try to stop anyone. Alternatively, we can embrace the "deprecated" route that is already in the draft. This has the conisderable benefit that it gets us around both the charter and interoperation issues while yet broadcasting the point that these mechanisms already don't work reliably and shouldn't be used. If interoperability is really our core concern, that approach addresses it while still saying the features need to go away. Best, A [1] It does of course say, "You can remove things in use if they're errors." That's the way we get away with removing RRTYPE 99 support: 4408 has an error that causes interoperation failure between two conforming implementations. There is more than one way to fix this, but an obvious one is to remove TYPE 99, so we chose that partly based on observed use. If people want to try out that line of attack on local-part macros, go nuts. -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Wed Jul 18 20:17:53 2012 Return-Path: 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 CB05011E80A4 for ; Wed, 18 Jul 2012 20:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 ISfriwAth0ww for ; Wed, 18 Jul 2012 20:17:53 -0700 (PDT) Received: from groups.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CBD3A11E8096 for ; Wed, 18 Jul 2012 20:17:52 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=558; t=1342667914; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=xemME3Tr+KGFS418QpUoyAvwTRQ=; b=RMkkFQEJ3kMoeEXl2egz s7SwszcpZyZZGj31iQ5pjyxW3iMr6yAcyuNkVMU+psBVHCqdrXRdaqRQTfz4ja8Y oxTuxgN8IOC1qnGy+APWC4noOl4ceIicmYoVXTEOT0XJCaUgQ6MQeQeJxAxVqq1k fl70MYIzD2R+PCIl3JW6U7M= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 18 Jul 2012 23:18:34 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2984712724.17122.2968; Wed, 18 Jul 2012 23:18:33 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=558; t=1342667783; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2YwuOI2 cE3oVy4DszfFDMwfWFVrfY1nQ+AMcmnI3lfA=; b=ry/ib8CDKrCtgzgT2UessJ4 r0d7cna1qnCVUHp8JkHIEMaZA/Nyexle0JCRG6UB38WxlQ6pEdgOor36sHwsEx92 vd4tSGMfpvQZpfjeaHPaK2vLICuPF0WfNUeopLUzzOJljDXiKs9b/iyRNYtkT1js 1dLinLhFeTXEHUjpHjfM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 18 Jul 2012 23:16:23 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3583548770.9.2572; Wed, 18 Jul 2012 23:16:22 -0400 Message-ID: <50077CD0.9050208@isdg.net> Date: Wed, 18 Jul 2012 23:19:44 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20f4303a-b51b-4ece-8547-518bd79b0bea@email.android.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 03:17:53 -0000 Murray S. Kucherawy wrote: > Was the ip6 mechanism used more or less than ptr? >> > In the TDP survey, "ptr" had 93 distinct domains using it; ip6 had 0. > > In the Cisco survey, "ptr" had 1 domain using it; ip6 had 0. Either its flawed or they have an extremely different set and unique of Personal Network Community (PCN) of domains that don't use it. Highly unique. I can easily post 361 domains from a cache of 1 day with SPF policies having PTR directives, but I won't. BTW, for IP6, 15 domains had ip6 in their SPF policies. -- HLS From WebMaster@Commerco.Net Wed Jul 18 20:20:38 2012 Return-Path: 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 93B2211E808A for ; Wed, 18 Jul 2012 20:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 DUpquN3Ca9wQ for ; Wed, 18 Jul 2012 20:20:36 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9393C11E8085 for ; Wed, 18 Jul 2012 20:20:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=WFwo4H1lSvZMa7FabQG+SYyfkVGkTexpRmvW9PiSyu49mvVKUiUBfFfDRmfsz7xa6TCfBMNoxIgSwgFnK6aApSyHQ9nJ9Fs+BruUdpsFLe4E3vxLRjW5/PznUjmrlmeJHCNsxS2QWlxqzfWKKvdkCL2v+cJCPTueFQ3fdMFt5pM= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]); Thu, 19 Jul 2012 03:21:22 +0000 Message-ID: <50077D2B.4020805@Commerco.Net> Date: Wed, 18 Jul 2012 21:21:15 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" , spfbis@ietf.org References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: S Moonesamy Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 03:20:38 -0000 Hi Murray, On 7/18/2012 7:56 PM, Murray S. Kucherawy wrote: > Hi Alan, > > On Wed, Jul 18, 2012 at 3:01 PM, Commerco WebMaster > > wrote: > > What I did not understand as a charter goal was the redefinition of > SPF to the point that it would not become interoperable with that > which correctly exists in the wild. > > > The two surveys I referenced show that both the "ptr" mechanism and > macros in general are in use in the wild, but by a very tiny percentage > of the deployed base. It's true that removing them entirely would > render those few sites incompatible with the Proposed Standard. In my > view (and I believe Dave's and the two John Ls, at least), that is a > cost offset by the fact that the two features we're talking about > removing are costly: "ptr" is expensive in terms of performance and can > be accomplished by other extant, less expensive means, and macros are > expensive in terms of their complexity and thus high maintenance cost > and risk of misimplementation ("dangerous", as John Levine put it), not > to mention the DNS issues it raises. > > The TDP survey shows a fraction of a percent using "ptr" or macros. The > Cisco survey shows exactly one out of a million domains using "ptr", and > none using macros. Hector claims heavier "ptr" use in his data, but has > not provided the details. > > Based on that, I maintain the spec is "broken" (as you've used the term) > and needs fixing. I also maintain that the charter allows such removals > under its "unused" clause. > > Further, I don't much like the idea of going onto the Standards Track > for the first time with two features we know see very little use, have > known costs, and have basically agreed should at least be deprecated. > That just feels completely sloppy to me. I recognize there's a big > deployed base for SPF, but approximately none of that base uses the > stuff we're talking about. Keeping it creates more of a burden than it > solves. > > The counter-argument is basically "It's only a 'proposed' standard, and > we can remove these things before it goes along the RFC6410 route." > Those of us who have been around long enough know that such advancement > is rare indeed (which is why we recently went from three maturity levels > down to two), so on the premise that such a revision is also > statistically unlikely, I think the proper thing to do is get it right > up front. > > As I said in an earlier post, if something were to land in front of me, > as a SECDIR reviewer or an IESG member, with two sections that basically > say "We know this is broken, please don't use it in TXT records but > receivers MUST support it anyway", I'd be asking questions about why > it's going for the Standards Track in the first place.. > > -MSK > The primary reason I piped up was in response to our co-chair's remark about removing SPF backward compatibility in the specification. Perhaps it was my conditioning by a former employer (who was a well known "Measurement and Computation" company) in my younger days that cause the reaction. The group I worked with viewed backward compatibility as one of the key selling features of a line of their business computers because it preserved client's investments in software development. Actually, I don't really disagree with the idea of depreciating support for PTR (because of reasons discussed by John Levine and others re the recent SPFbis list posts). I also don't have any irons in the fire as regards macros (we don't publish them), so I am pretty neutral there. My thinking is to perhaps consider these features depreciated but still usable as extensions to the MUST part of the specification, if they don't break SPF. Perhaps something like: --- Over a number of years preceding RFC 4408bis, SPF operated as an experimental protocol. During those years, SPF software implementers and publishers both observed cases where issues were encountered surrounding the use of both PTR and support for SPF macros used in SPF software implementations and published DNS TXT SPF records. Such issues include . In order to preserve backward compatibility, implementers and publisher MAY choose to implement these features, but they should be considered as depreciated or alternatively as optional extensions some may choose to adopt at their own peril, as their use has even been deemed dangerous by some. ---- The above may only work if the statements can be considered true. I guess I would now ask the list, can they be considered true and does it even make sense to look at the PTR and Macros issue in this way to try to find consensus to move forward? My mind drifts back to RFC 821 (yes, I know depreciated by 5321, but even before it was depreciated, this thought might have applied) and the concept of a minimum implementation with other commands (e.g., SAML / SOML) which I believe were not widely implemented in circa 1995 and beyond SMTP servers. That is the source of my hope for finding a compromise that works for SPF. In other words, can we find a workable middle ground to move us ahead in this process? Best, Alan M. From hsantos@isdg.net Wed Jul 18 20:25:24 2012 Return-Path: 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 02B2D11E8085 for ; Wed, 18 Jul 2012 20:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 3dHHWtDYHhCL for ; Wed, 18 Jul 2012 20:25:23 -0700 (PDT) Received: from groups.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D471811E8088 for ; Wed, 18 Jul 2012 20:25:22 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=957; t=1342668369; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=AV9qfcVDTaMhHw1ka0OV5fCDyFM=; b=Mk1OeMbdNi9p6bki+UbB 0gpoVhsy00s8U8ftJa0uTNzOqbqxQKqGtUQcUeJtOLXgI95rn7YUQgBQNcyYuk0X R3QEdi3a2T5fjCTl0SL6p16aRfGBEW13vK6htwGX9HeggXp6bducdofJc5r6PmTJ MR8/w7+mFzUB5I3mxBwMm9E= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 18 Jul 2012 23:26:09 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2985167794.17122.3644; Wed, 18 Jul 2012 23:26:08 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=957; t=1342668237; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=ajg4Qyh WyPc+BfjyZh/cWtGygS6corNOdH2lvx/3DzQ=; b=u8Rjz8LWOXY+Ghw6xQUxRFd +AM5KJq9KtKwGNR7sEYnIJKwYjOAndmZuAX/aymvCAQvdqRW0nYormBky2HjfgsT BEGhJbgbvJeiXSTedfyfeLIq5hYaLjNxHw00c77lHo6USZXjdnxj5oDte5fbEhg1 lNyqxvm4b9t9E0lEk8Jo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 18 Jul 2012 23:23:57 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3584002676.9.672; Wed, 18 Jul 2012 23:23:56 -0400 Message-ID: <50077E96.3030504@isdg.net> Date: Wed, 18 Jul 2012 23:27:18 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 03:25:24 -0000 Murray S. Kucherawy wrote: > As I said in an earlier post, if something were to land in front of me, as > a SECDIR reviewer or an IESG member, with two sections that basically say > "We know this is broken, please don't use it in TXT records but receivers > MUST support it anyway", I'd be asking questions about why it's going for > the Standards Track in the first place.. hmmmm, the same was done for DKIM with its SHA1 vs SHA256. There are other examples I am sure we can find in the annals for IETF protocol development and updates. I'm lost as to why this is a big issue. PTR is in used. It shouldn't be deprecated. But if technocrats prefer to recommend PTR not be published, that shouldn't be basis for promoting removing from processors because it is a high utility item already in use. This is no different from recommending EHLO over HELO. HELO still must be supported otherwise your software will not worth much. -- HLS From hsantos@isdg.net Wed Jul 18 20:51:17 2012 Return-Path: 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 0F23421F8636 for ; Wed, 18 Jul 2012 20:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 kV4C7-tPdtdP for ; Wed, 18 Jul 2012 20:51:16 -0700 (PDT) Received: from groups.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2333A21F85F4 for ; Wed, 18 Jul 2012 20:51:16 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1900; t=1342669919; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=xcmqFrdem2HADyVytjMpopw1ZhU=; b=WrnBb4Uq6Q+O2tMLDcQM aCK/CV/yluZFb4Lhlzc5nwNxyJ9tu1LDgpD1uBfg6cUFpZEWH6GPuORKhqOILsPp mbtED/9OEoEAwsyL9+Kk8UeFFxVsIZHZLJ+JpMj7yOY072rJKeyjon5gic6CKbm6 25r+0nKGz/7y3bTSxyJM7Qs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 18 Jul 2012 23:51:59 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2986718023.17122.1536; Wed, 18 Jul 2012 23:51:58 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1900; t=1342669788; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=D3EuiSf 7a2pXIc9cKae+PxMW2qAuh3ofDlWHymMkEls=; b=tnWE68kkcuYG5MnWxW27/qy BQ64w9B/jGsnSUmSfQx4Ny8mSx55k/SpXuIanG74aI2Oqr0pBV2IRfRZtB01oXYE vRJSewhXTD5BiPRHy7zHfo0TpH9bqM5gRFBZSjqzJlY6fv8EBwlh1fu7+PuPsxoD JDJ5jRNG4sL0xBQxQZgs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 18 Jul 2012 23:49:48 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3585553098.9.1972; Wed, 18 Jul 2012 23:49:47 -0400 Message-ID: <500784A5.9010907@isdg.net> Date: Wed, 18 Jul 2012 23:53:09 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Commerco WebMaster References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <50077D2B.4020805@Commerco.Net> In-Reply-To: <50077D2B.4020805@Commerco.Net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, S Moonesamy Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 03:51:17 -0000 Commerco WebMaster wrote: > > The primary reason I piped up was in response to our co-chair's remark > about removing SPF backward compatibility in the specification. Perhaps > it was my conditioning by a former employer (who was a well known > "Measurement and Computation" company) in my younger days that cause the > reaction. The group I worked with viewed backward compatibility as one > of the key selling features of a line of their business computers > because it preserved client's investments in software development. Most Product Vendors would go out of business if they didn't provide backward compatibility, especially in an customer environment where there is coding and/or operator settings, configurations involved. You can do more with "Canned" Applications, but if the customer has settings, coding, i.e. DNS management or even a tertiary market of 3rd party developers, the barriers are higher to change an existing protocol especially when there is very little basis to do so, and the 'unused' statements are patently incorrect (in regards to PTR). Scott has a legitimate technical reason such as Slowness, but I submit this was more of a concern early on but no such much today. First, more and more SMTP servers are already requiring a PTR for the connecting client, so this result will already be in server's DNS resolver cache by the time SPF is checked and processed. Second, if "Slowness" is a problem, there are other parts of SPF that are either as much or more expensive than PTR - any directive that starts additional SPF or recursive lookups (i.e., INCLUDE, REDIRECT, EXIST) has a "Slowness" attribute to it. I submit having INCLUDE (and related commands), especially those SPF domains with multiple INCLUDES, can be very expensive and complex compared to a PTR. Why don't we deprecate INCLUDE on the basis of Slowness? -- HLS From superuser@gmail.com Wed Jul 18 21:18:28 2012 Return-Path: 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 8614421F851C for ; Wed, 18 Jul 2012 21:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.575 X-Spam-Level: X-Spam-Status: No, score=-4.575 tagged_above=-999 required=5 tests=[AWL=1.023, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ON285HS4CdDB for ; Wed, 18 Jul 2012 21:18:27 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A28621F84F8 for ; Wed, 18 Jul 2012 21:18:26 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3337677lbb.31 for ; Wed, 18 Jul 2012 21:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s7anvolXQJXnEZQDYmPb0+VNtS9oIrD0Flc2QjsIbBU=; b=sJovt0vU8Arf1LjyowBZBY0J/HbHVJphQXSUwmlO9cpCIJVTKVKnbzgsd5c/BHp0QR Fw4NQX9VzxZ1gZRE5AemjUcq/UTgTlR96R8gTefJLW2ziAdrMRAzqI80UgmgPodCKk0H japEode6h2zzcoqb391G2z7+nRlInjywJZNI4On+Z9EpWbWmUyqIjSCkGFpX1piYrzZ8 7Pyw5IOCu05Gnq81/wqsKP/eec1EoHdYAOgMqEm82SaN7AMZNpO/iVi+mvwM/Ck5JcWW b5mj1pliWLkFjfYN+laIHHzcpY6R9pr4UvNuI8shytdcJJSU3maitIkmz0En+/7R2RWk v9gQ== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr248977lab.40.1342671553320; Wed, 18 Jul 2012 21:19:13 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 18 Jul 2012 21:19:13 -0700 (PDT) In-Reply-To: <1421911.K86mT8c64i@scott-latitude-e6320> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <20f4303a-b51b-4ece-8547-518bd79b0bea@email.android.com> <1421911.K86mT8c64i@scott-latitude-e6320> Date: Wed, 18 Jul 2012 21:19:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d040838d3fc57ca04c52714d6 Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 04:18:28 -0000 --f46d040838d3fc57ca04c52714d6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 7:55 PM, Scott Kitterman wrote: > Sure, but you can't have it both ways. You can't both claim that this is a > normal transition from experimental to standards track because by the > letter > of the IETF process, that's what it is, but then on the other hand claim > that > the letter of the IETF standards advancement process isn't realistic and we > can't consider it reasonable that features we deprecate now will be removed > when SPF is advanced. > I never made the latter claim. I think it is realistic, and I also understand the nuances of it as I was part of the whole debate that resulted in RFC6410. In fact I believe we could (if we agree to it) go down the path of deprecating these features now and removing them later. What I'm saying is that often enough, "later" never actually happens, which means these warts on the protocol will never actually go away; calling them "deprecated" is merely hand-waving and ultimately ineffective at solving the problem. If we're trying to protect people from themselves by discouraging use of these features, attaching an easily ignored labels will not achieve that goal. -MSK --f46d040838d3fc57ca04c52714d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 7:55 PM, Scott Kitterman <spf2@kitterman.com&= gt; wrote:
Sure, but you can't have it both ways. =A0You can't both claim that= this is a
normal transition from experimental to standards track because by the lette= r
of the IETF process, that's what it is, but then on the other hand clai= m that
the letter of the IETF standards advancement process isn't realistic an= d we
can't consider it reasonable that features we deprecate now will be rem= oved
when SPF is advanced.

I never made the latter clai= m.=A0 I think it is realistic, and I also understand the nuances of it as I= was part of the whole debate that resulted in RFC6410.

In fact I be= lieve we could (if we agree to it) go down the path of deprecating these fe= atures now and removing them later.=A0 What I'm saying is that often en= ough, "later" never actually happens, which means these warts on = the protocol will never actually go away; calling them "deprecated&quo= t; is merely hand-waving and ultimately ineffective at solving the problem.=

If we're trying to protect people from themselves by discouraging u= se of these features, attaching an easily ignored labels will not achieve t= hat goal.

-MSK
--f46d040838d3fc57ca04c52714d6-- From superuser@gmail.com Wed Jul 18 21:28:20 2012 Return-Path: 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 635A511E8089 for ; Wed, 18 Jul 2012 21:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Xr0Yd-CrtiYY for ; Wed, 18 Jul 2012 21:28:19 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0055411E8073 for ; Wed, 18 Jul 2012 21:28:18 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3347043lbb.31 for ; Wed, 18 Jul 2012 21:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q7DEaKnaIBZi7TawdCQ9L19nrHDhIJUuLkTjtPWp7Gc=; b=zMsjeH0gzCsxwMJqqDHwNNcBvuPF01nvRnPIg+BhddnDdXJRpRFWeUQoevSgVpG2K1 Tju+/EB52DjwDo26/t7XwDvIuaqE7T5oqtWJHZTKMB0F8pJyrzJQaeNoa1gLPVj+khdb cK5pCAgegc8zUlJoNNI1tcnbZZwNaab6z9BlEkVdFGXmpX/RIF16m7r1uEGxu9wrR/ol a49UGWmEx8szHbKOvGcbO2gJjwJA9kV28UOTjU2JxkUWFDIecNdNCvMnhTh3JMey0N2B GKNxO5JcnHM1p13foSrSWjiAjuI2uptjicuHbyhAE5fh9QRBETbx2DP8BII/aVQEMIsd 05Ww== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr367814lbn.10.1342672150131; Wed, 18 Jul 2012 21:29:10 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 18 Jul 2012 21:29:10 -0700 (PDT) In-Reply-To: <20120719031507.GG1323@crankycanuck.ca> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20120719031507.GG1323@crankycanuck.ca> Date: Wed, 18 Jul 2012 21:29:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=bcaec554d63c8ef2b504c527380e Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 04:28:20 -0000 --bcaec554d63c8ef2b504c527380e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 8:15 PM, Andrew Sullivan wrote: > Moreover, there is an interoperability argument available, which is > that we have positive evidence that some people publish these sorts of > records, and that therefore receivers need to be able to process them. > This kind of issue is one we face in DNS-land all the time: once > something is out there, it is all but impossible to get rid of it. > Why do you think IDNA is the miserable hack it is? Why do you think > we haven't introduced any new CLASSes since CHAOS? Why do you think > the absurd and conceptually broken underscore convention has been > embraced instead of just using new RRTYPEs? > Isn't it desirable, then, to get rid of this stuff while it's Experimental and not Proposed Standard? Would it make people satisfied if I were to chase down all 203 domains that we found publishing SPF records with macros in them and ask them if they would complain if that aspect of the protocol were removed? I'd be happy to do that. > The counter-argument available to us, of course, is that we are moving > from the experimental track. But for that argument to work, the > charter would need to be more permissive in what it says we can > remove. Moreover, suppose you are an SPF receiver and you get one of > these records. What are you going to do with it? Drop it on the > floor? No, of course not. You're going to use your hoary old 4408 > code to handle it anyway. If that's true, then we should document it. > (Note that deprecation _does_ mean that publisher-side tools can drop > support for these things immediately.) > It's not true for me. Given what I know, I wouldn't implement ptr or macros. They'd get permerror or something. > > I am having a really hard time accepting "nobody _we_ know uses this" > as the meaning of "unused". To my mind, that's what these claims of > "it's not an important use" amount to. That's not the intent I have in mind. I have in mind the same logic we had with DKIM when we removed "g=": Nine domains out of a million-plus were using it, so we dumped it. > If we don't like that, the answer is not to try to weasel around the > problem by stretching the meaning of "unused" past the breaking point > even of English. The answer is to go back to the community and say, > "This charter is stupidly restrictive for something coming from the > experimental track and moving to the standards track." I am > personally disinclined to lead that charge; but if people really want > to do it, I won't try to stop anyone. > I'd support that, if it breaks this logjam. I suspect though that it would be split along party lines, so to speak. > > Alternatively, we can embrace the "deprecated" route that is already > in the draft. This has the conisderable benefit that it gets us > around both the charter and interoperation issues while yet > broadcasting the point that these mechanisms already don't work > reliably and shouldn't be used. If interoperability is really our > core concern, that approach addresses it while still saying the > features need to go away. > I don't find interoperability when moving from Experimental to Proposed Standard to be as critical as others do. I would find that argument far more compelling if we were moving from Proposed Standard to Internet Standard. Yes, I recognize the ample deployed base, but it's not like the word "Experimental" in RFC4408 was concealed. -MSK --bcaec554d63c8ef2b504c527380e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 8:15 PM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
Moreover, there is an interoperability argument available, which is
that we have positive evidence that some people publish these sorts of
records, and that therefore receivers need to be able to process them.
This kind of issue is one we face in DNS-land all the time: once
something is out there, it is all but impossible to get rid of it.
Why do you think IDNA is the miserable hack it is? =A0Why do you think
we haven't introduced any new CLASSes since CHAOS? =A0Why do you think<= br> the absurd and conceptually broken underscore convention has been
embraced instead of just using new RRTYPEs?

Isn= 9;t it desirable, then, to get rid of this stuff while it's Experimenta= l and not Proposed Standard?

Would it make people satisfied if I wer= e to chase down all 203 domains that we found publishing SPF records with m= acros in them and ask them if they would complain if that aspect of the pro= tocol were removed?=A0 I'd be happy to do that.


The counter-argument available to us, of course, is that we are moving
from the experimental track. =A0But for that argument to work, the
charter would need to be more permissive in what it says we can
remove. =A0Moreover, suppose you are an SPF receiver and you get one of
these records. =A0What are you going to do with it? =A0Drop it on the
floor? =A0No, of course not. =A0You're going to use your hoary old 4408=
code to handle it anyway. =A0If that's true, then we should document it= .
(Note that deprecation _does_ mean that publisher-side tools can drop
support for these things immediately.)

It's no= t true for me.=A0 Given what I know, I wouldn't implement ptr or macros= .=A0 They'd get permerror or something.
=A0

I am having a really hard time accepting "nobody _we_ know uses this&q= uot;
as the meaning of "unused". =A0To my mind, that's what these = claims of
"it's not an important use" amount to.

T= hat's not the intent I have in mind.=A0 I have in mind the same logic w= e had with DKIM when we removed "g=3D": Nine domains out of a mil= lion-plus were using it, so we dumped it.
=A0
If we don't like that, the= answer is not to try to weasel around the
problem by stretching the meaning of "unused" past the breaking p= oint
even of English. =A0The answer is to go back to the community and say,
"This charter is stupidly restrictive for something coming from the experimental track and moving to the standards track." =A0I am
personally disinclined to lead that charge; but if people really want
to do it, I won't try to stop anyone.

I'd = support that, if it breaks this logjam.=A0 I suspect though that it would b= e split along party lines, so to speak.
=A0

Alternatively, we can embrace the "deprecated" route that is alre= ady
in the draft. =A0This has the conisderable benefit that it gets us
around both the charter and interoperation issues while yet
broadcasting the point that these mechanisms already don't work
reliably and shouldn't be used. =A0If interoperability is really our core concern, that approach addresses it while still saying the
features need to go away.

I don't find interop= erability when moving from Experimental to Proposed Standard to be as criti= cal as others do.=A0 I would find that argument far more compelling if we w= ere moving from Proposed Standard to Internet Standard.=A0 Yes, I recognize= the ample deployed base, but it's not like the word "Experimental= " in RFC4408 was concealed.

-MSK

--bcaec554d63c8ef2b504c527380e-- From superuser@gmail.com Wed Jul 18 21:34:17 2012 Return-Path: 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 B742C11E8093 for ; Wed, 18 Jul 2012 21:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 D7KIyL2lfty4 for ; Wed, 18 Jul 2012 21:34:17 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BBE1C11E8091 for ; Wed, 18 Jul 2012 21:34:16 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3353039lbb.31 for ; Wed, 18 Jul 2012 21:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a6/Ncqn40jeE/dOFS2tAx9+cETSQNZcCwMpu29aRxrY=; b=iieEUDNyrEUw682XTCKQRvQ2voRZ/ne9tHz9uq1ioCHpbhmeUyekRxNX0vghYtp58N pQMs+E1eQVv2IFy2Kx/SJn0zLnQTF0r0/p7jEAFHPKnxMI/A4fuqeFO8RfsNq4qlcbgD YCpX8gWkMDVkkbTEh9eWja1ZViFUdQWnOAnY9+KcVtIoB6nWRMmP5e9I4X/Rk/XMFQX6 KUR/NldxJTrq9Hu6ooQgjT+CAn1jj8wK1TahguqHewMkr/KGIqtnycfov91AHxTEvJmY gKBb6LMqi32oJ0nMPd17Cfx/pFezJEjgAVBmH3bc1wzvVq6mVIG7MKfoPdiqfDf+F32M LxIA== MIME-Version: 1.0 Received: by 10.152.124.180 with SMTP id mj20mr287110lab.43.1342672508108; Wed, 18 Jul 2012 21:35:08 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 18 Jul 2012 21:35:07 -0700 (PDT) In-Reply-To: <50077CD0.9050208@isdg.net> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20f4303a-b51b-4ece-8547-518bd79b0bea@email.android.com> <50077CD0.9050208@isdg.net> Date: Wed, 18 Jul 2012 21:35:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=f46d0434bfdee53dcb04c5274d67 Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 04:34:17 -0000 --f46d0434bfdee53dcb04c5274d67 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 8:19 PM, Hector Santos wrote: > I can easily post 361 domains from a cache of 1 day with SPF policies > having PTR directives, but I won't. BTW, for IP6, 15 domains had ip6 in > their SPF policies. > > If you won't provide data, your claim isn't meaningful. The TDP and Cisco surveys amount to reproducible experiments. Your say-so isn't. -MSK --f46d0434bfdee53dcb04c5274d67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 8:19 PM, Hector Santos <hsantos@isdg.net> wrote:
I can easily post 361 domains from a cache of 1 day with SPF policies havin= g PTR directives, but I won't. =A0BTW, for IP6, 15 domains had ip6 in t= heir SPF policies.


If you won't provide data, your= claim isn't meaningful.

The TDP and Cisco surveys amount to rep= roducible experiments.=A0 Your say-so isn't.

-MSK

--f46d0434bfdee53dcb04c5274d67-- From dhc@dcrocker.net Wed Jul 18 21:58:20 2012 Return-Path: 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 BC1EB21F853E for ; Wed, 18 Jul 2012 21:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HS2ReIa+cFOD for ; Wed, 18 Jul 2012 21:58:18 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 510A321F848A for ; Wed, 18 Jul 2012 21:58:17 -0700 (PDT) Received: from [192.168.1.9] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6J4x5Y0003984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Jul 2012 21:59:06 -0700 Message-ID: <50079416.7060204@dcrocker.net> Date: Wed, 18 Jul 2012 21:59:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20120719031507.GG1323@crankycanuck.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 18 Jul 2012 21:59:06 -0700 (PDT) Cc: spfbis@ietf.org, Andrew Sullivan Subject: [spfbis] Is a feature desirable in practical terms? (was - Re: A standards track document defining SPF) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 04:58:20 -0000 On 7/18/2012 9:29 PM, Murray S. Kucherawy wrote: > Isn't it desirable, then, to get rid of this stuff while it's > Experimental and not Proposed Standard? This strikes me as the single-most basic and compelling question, and it seems to be getting ignored. Everything ought to flow from the answer to that question. Debating the meaning of "unused", for example, should only come after agreeing whether a feature is in fact desirable, based on the experience of more than a few years in the field. If someone is claiming that PTR or macros are indeed practically desirable, based on the community's extensive experience, they should make that case. We have, I think, plenty of evidence to the contrary. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Wed Jul 18 22:00:50 2012 Return-Path: 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 4CB4B21F8552 for ; Wed, 18 Jul 2012 22:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] 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 nIGVc1A0SMLj for ; Wed, 18 Jul 2012 22:00:48 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4F51121F8548 for ; Wed, 18 Jul 2012 22:00:48 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E750920E40BD; Thu, 19 Jul 2012 01:01:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342674100; bh=gt6U6Z9iIZNKUtInazlpKtX8HrZMhuEoXiQVL2JMC/I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nLSiqn5oNxkABGNtpuf8ZvukN+h0kW+siOyK5gAbkVsL0xn7Lpmx35zJzy39uNZZZ 22Ni+70nkuEGbP+rhdmKrsXSVeegKMBsYiA+lZZx/YVLBrYg+7G2qAmk7isq9V3vsx 2HBCdkjeoM6wzMKXJMJ2SSRb+85KkOaTJ8BR5vFA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C9D8920E4081; Thu, 19 Jul 2012 01:01:39 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Jul 2012 01:01:39 -0400 Message-ID: <1854566.3loDmVqy4f@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <20120719031507.GG1323@crankycanuck.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 05:00:50 -0000 On Wednesday, July 18, 2012 09:29:10 PM Murray S. Kucherawy wrote: > On Wed, Jul 18, 2012 at 8:15 PM, Andrew Sullivan wrote: > > Moreover, there is an interoperability argument available, which is > > that we have positive evidence that some people publish these sorts of > > records, and that therefore receivers need to be able to process them. > > This kind of issue is one we face in DNS-land all the time: once > > something is out there, it is all but impossible to get rid of it. > > Why do you think IDNA is the miserable hack it is? Why do you think > > we haven't introduced any new CLASSes since CHAOS? Why do you think > > the absurd and conceptually broken underscore convention has been > > embraced instead of just using new RRTYPEs? > > Isn't it desirable, then, to get rid of this stuff while it's Experimental > and not Proposed Standard? > > Would it make people satisfied if I were to chase down all 203 domains that > we found publishing SPF records with macros in them and ask them if they > would complain if that aspect of the protocol were removed? I'd be happy > to do that. If it's going to be gotten rid of, I think it's appropriate to do so after providing a warning/transition time (which is why I think deprecate is reasonable). If you're willing to contact the 203 domain owners, I think the more useful thing to do would be find out why they are using macros and what problem they solve for them. Part of my own rationale for deprecating PTR was that I've helped quite a few people convert records that used PTR to those that didn't and it has never been very hard (despite other claims that it's essential, my personal experience is that it isn't and the reason - when asked "why did you use PTR to start with" - was generallly "that's what the SPF wizard said to use). Maybe if we understood why, we could understand reasonable alternatives. BTW, I'm sure altavista.com didn't show up on your list, since it sends no mail, but it's got one of these records too (in fact it's similar or identical to the DNS logging record in RFC 4408). I can put you in touch with the person that put that up in 2003/2004 if you want. > > The counter-argument available to us, of course, is that we are moving > > from the experimental track. But for that argument to work, the > > charter would need to be more permissive in what it says we can > > remove. Moreover, suppose you are an SPF receiver and you get one of > > these records. What are you going to do with it? Drop it on the > > floor? No, of course not. You're going to use your hoary old 4408 > > code to handle it anyway. If that's true, then we should document it. > > (Note that deprecation _does_ mean that publisher-side tools can drop > > support for these things immediately.) > > It's not true for me. Given what I know, I wouldn't implement ptr or > macros. They'd get permerror or something. If you aren't going to implement the entire thing, I'd recommend treating these as None. Raising errors on thing you don't like in the protocol isn't good citizenship. > > I am having a really hard time accepting "nobody _we_ know uses this" > > as the meaning of "unused". To my mind, that's what these claims of > > "it's not an important use" amount to. > > That's not the intent I have in mind. I have in mind the same logic we had > with DKIM when we removed "g=": Nine domains out of a million-plus were > using it, so we dumped it. If those nine domains kept using it, what would happen (I don't recall)? > > If we don't like that, the answer is not to try to weasel around the > > problem by stretching the meaning of "unused" past the breaking point > > even of English. The answer is to go back to the community and say, > > "This charter is stupidly restrictive for something coming from the > > experimental track and moving to the standards track." I am > > personally disinclined to lead that charge; but if people really want > > to do it, I won't try to stop anyone. > > I'd support that, if it breaks this logjam. I suspect though that it would > be split along party lines, so to speak. No doubt. I think the charter is constraining us from doing precisely stuff it was meant to constrain us from doing. > > Alternatively, we can embrace the "deprecated" route that is already > > in the draft. This has the conisderable benefit that it gets us > > around both the charter and interoperation issues while yet > > broadcasting the point that these mechanisms already don't work > > reliably and shouldn't be used. If interoperability is really our > > core concern, that approach addresses it while still saying the > > features need to go away. > > I don't find interoperability when moving from Experimental to Proposed > Standard to be as critical as others do. I would find that argument far > more compelling if we were moving from Proposed Standard to Internet > Standard. Yes, I recognize the ample deployed base, but it's not like the > word "Experimental" in RFC4408 was concealed. How many people outside IETF professional pay attention to such labels? It's not many. My reading of the IETF note has always been that SPF was experimental because MARID failed and there wasn't a single protocol to advance. The reasons were not related to the technical maturity of the protocol. Among the group of people that know what an experimental RFC is and have been interested in RFC 4408, a large fraction (IME, almost all) know that the reasons it's experimental aren't limited to technical issues. As a result, the IETF's label got pretty soundly ignored. Concluding the deployed based doesn't count because RFC 4408 was 'experimental' is a great way to reinforce the degree of connection a lot of people think the IETF has with the real world. Scott K From superuser@gmail.com Wed Jul 18 22:03:45 2012 Return-Path: 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 165AF21F85F8 for ; Wed, 18 Jul 2012 22:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 TUuss6HVnmbO for ; Wed, 18 Jul 2012 22:03:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67D4421F85FD for ; Wed, 18 Jul 2012 22:03:43 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3380816lbb.31 for ; Wed, 18 Jul 2012 22:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uYuO8QWyatPlQ1bCToHgsbT5HbmSiRy3p45Ghleo/ww=; b=xMLqPFMMQagx1oMXVuXuZu7Ec7Ds2jRwXNkLuoMpCboLlj6PgQjWN+mnp5czctLlnd 6FoONIdqb2f+0a1iJupWdXKfh7TYBP5Ib92l/4ojbfcM1M1XHFC2y+bmywGboijZNR4p u6/w08ZJf5BJM9waXAjn3A5LKFZg3mqCs6/ukzAJpQbYHaVW30p1fMhdncUqdgVlz7Zx yUHnqx13MNbDQb36owe/bfvVBlWMkz+wnLx0qj7uDGzR7z93lK7P25SoGRMQ7ImGyfEz eGcUHgG8pvHv83rZB518rRVVrGr+cUbmG09r3sREoAmchK66Db92FzvdCf6zjzmTna+L 3yxw== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr366746lab.40.1342674274240; Wed, 18 Jul 2012 22:04:34 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 18 Jul 2012 22:04:34 -0700 (PDT) In-Reply-To: <1854566.3loDmVqy4f@scott-latitude-e6320> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <20120719031507.GG1323@crankycanuck.ca> <1854566.3loDmVqy4f@scott-latitude-e6320> Date: Wed, 18 Jul 2012 22:04:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d040838d32a49e604c527b778 Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 05:03:45 -0000 --f46d040838d32a49e604c527b778 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 10:01 PM, Scott Kitterman wrote: > > I'd support that, if it breaks this logjam. I suspect though that it > would > > be split along party lines, so to speak. > > No doubt. I think the charter is constraining us from doing precisely > stuff it > was meant to constrain us from doing. > As the charter's author, I can assure you that wasn't the intent. -MSK --f46d040838d32a49e604c527b778 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 10:01 PM, Scott Kitterman <spf2@kitterman.com= > wrote:
> I'd support that, if it breaks this logjam. =A0I suspect though th= at it would
> be split along party lines, so to speak.

No doubt. =A0I think the charter is constraining us from doing precis= ely stuff it
was meant to constrain us from doing.

As the chart= er's author, I can assure you that wasn't the intent.

-MSK
--f46d040838d32a49e604c527b778-- From superuser@gmail.com Wed Jul 18 22:10:49 2012 Return-Path: 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 ADB4521F8634 for ; Wed, 18 Jul 2012 22:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 QO1XAwUVJKOd for ; Wed, 18 Jul 2012 22:10:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B58021F8638 for ; Wed, 18 Jul 2012 22:10:48 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3387931lbb.31 for ; Wed, 18 Jul 2012 22:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rtm9EXLcl/kJ/9ZXrFVxLrMr6UXR5FV4vdxNV6JOB9Y=; b=P54eMs2IDd7MabK6g+de/Waz2gks/j86h96LkXD2bSHeWDHxAKc0pXXcwiVxZ0CK84 /eI0ZDyUWXT21dFrd0gtg5eV01gGTeifUii3MLzNZUAaNqjLsLkoFyYF81zF7lQ9Qz1v gf2vQB3DbRc3UX71Twu1l/UVcR09LSRZHciDyeraMTVziv4d8ko4BHUx6Om9XsO/3Vpp iI8ulevHM4Q8ifjtFCUYRiwrqO5+GC8rtuBjo13hn1pipfwBtnqoswtAzOEA7+xzvCXb KAew59opR55yW9Y0DMyNecUyExAOgdkhl0AhYwoYIJogV8ReMNyjIAAb1Ll+berRRVW6 UaYw== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr470259lab.9.1342674695826; Wed, 18 Jul 2012 22:11:35 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 18 Jul 2012 22:11:35 -0700 (PDT) In-Reply-To: <1854566.3loDmVqy4f@scott-latitude-e6320> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <20120719031507.GG1323@crankycanuck.ca> <1854566.3loDmVqy4f@scott-latitude-e6320> Date: Wed, 18 Jul 2012 22:11:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=e89a8f22c4114b2e3b04c527d053 Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 05:10:49 -0000 --e89a8f22c4114b2e3b04c527d053 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 10:01 PM, Scott Kitterman wrote: > How many people outside IETF professional pay attention to such labels? > It's > not many. My reading of the IETF note has always been that SPF was > experimental because MARID failed and there wasn't a single protocol to > advance. The reasons were not related to the technical maturity of the > protocol. Among the group of people that know what an experimental RFC is > and > have been interested in RFC 4408, a large fraction (IME, almost all) know > that > the reasons it's experimental aren't limited to technical issues. As a > result, the IETF's label got pretty soundly ignored. > > Concluding the deployed based doesn't count because RFC 4408 was > 'experimental' is a great way to reinforce the degree of connection a lot > of > people think the IETF has with the real world. > > So "Experimental", like "deprecated", is ultimately a meaningless label? Seems like there's not a lot of solid ground left around here. -MSK --e89a8f22c4114b2e3b04c527d053 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 10:01 PM, Scott Kitterman <spf2@kitterman.com= > wrote:
How many people outside IETF professional pay attention to such labels? =A0= It's
not many. =A0My reading of the IETF note has always been that SPF was
experimental because MARID failed and there wasn't a single protocol to=
advance. =A0The reasons were not related to the technical maturity of the protocol. =A0Among the group of people that know what an experimental RFC i= s and
have been interested in RFC 4408, a large fraction (IME, almost all) know t= hat
the reasons it's experimental aren't limited to technical issues. = =A0As a
result, the IETF's label got pretty soundly ignored.

Concluding the deployed based doesn't count because RFC 4408 was
'experimental' is a great way to reinforce the degree of connection= a lot of
people think the IETF has with the real world.


So "Experimental", like "deprecate= d", is ultimately a meaningless label?

Seems like there's n= ot a lot of solid ground left around here.

-MSK

--e89a8f22c4114b2e3b04c527d053-- From spf2@kitterman.com Wed Jul 18 22:12:15 2012 Return-Path: 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 1875121F8645 for ; Wed, 18 Jul 2012 22:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] 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 RNIBStzw+cKm for ; Wed, 18 Jul 2012 22:12:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C877C21F8643 for ; Wed, 18 Jul 2012 22:12:13 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A3FD620E40E3; Thu, 19 Jul 2012 01:13:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342674782; bh=as8EJkWDKL4r5tIyX5k+v2DK+yiTHcpiFO/MiTcxQBo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Fa6EfPCRwR70vTM4Cij1SvRhBAwdiBqRzQpf2Ol+TUQKJxSA0LY/dzP1mwpDPBCnv 6tSl0V5JkY6rBTOH19em2joADrNmS8ikqKTH+Ci0Wo4PXEwR+hzZ9elq9wZKGBSPVX j/kXsudUSCqmiqS6afayjpvgKherE1y6Tiqzk04Q= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 86AD220E4081; Thu, 19 Jul 2012 01:13:02 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Jul 2012 01:13:01 -0400 Message-ID: <1988807.rgypmf6EXz@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <1854566.3loDmVqy4f@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 05:12:15 -0000 On Wednesday, July 18, 2012 10:04:34 PM Murray S. Kucherawy wrote: > On Wed, Jul 18, 2012 at 10:01 PM, Scott Kitterman wrote: > > > I'd support that, if it breaks this logjam. I suspect though that it > > > > would be split along party lines, so to speak. > > > > No doubt. I think the charter is constraining us from doing precisely > > stuff it was meant to constrain us from doing. > > As the charter's author, I can assure you that wasn't the intent. As one of the people that reviewed it, I can assure you I thought it was. If I thought the current charter allowed us to toss out backward compatibility on the basis of "oh, it seems simpler this way", I'd have never supported it. Scott K From spf2@kitterman.com Wed Jul 18 22:17:50 2012 Return-Path: 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 EF7C221F866E for ; Wed, 18 Jul 2012 22:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] 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 wfL93m7dbqQ0 for ; Wed, 18 Jul 2012 22:17:50 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCB521F8649 for ; Wed, 18 Jul 2012 22:17:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2AE7220E40E3; Thu, 19 Jul 2012 01:18:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342675122; bh=5u0Kr4EqBa1BjgDTCbBEDLos2ZH3AXDNhqLWcr/Drsc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dSpkql6pIHlXnVx++QMYORKcMfaM2+kHHE7adnsgrT0TBTZP+tso0O1m7v+hDXiez MXBaoapodZmXDpsDgJpkFZdF8D+8Zlm42o+IXB/JPn8K8JzOkFb0IxeMZAbNDJIg4P Uq0UEwulCJKeqqFueM6a57Cx6/SeNtmHFLsUToQI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0C48020E4081; Thu, 19 Jul 2012 01:18:41 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Jul 2012 01:18:41 -0400 Message-ID: <1429461.E6inaCrjqj@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <1854566.3loDmVqy4f@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 05:17:51 -0000 On Wednesday, July 18, 2012 10:11:35 PM Murray S. Kucherawy wrote: > On Wed, Jul 18, 2012 at 10:01 PM, Scott Kitterman wrote: > > How many people outside IETF professional pay attention to such labels? > > > > It's not many. My reading of the IETF note has always been that SPF was > > experimental because MARID failed and there wasn't a single protocol to > > advance. The reasons were not related to the technical maturity of the > > protocol. Among the group of people that know what an experimental RFC is > > and > > have been interested in RFC 4408, a large fraction (IME, almost all) know > > that > > the reasons it's experimental aren't limited to technical issues. As a > > result, the IETF's label got pretty soundly ignored. > > > > Concluding the deployed based doesn't count because RFC 4408 was > > 'experimental' is a great way to reinforce the degree of connection a lot > > of people think the IETF has with the real world. > > So "Experimental", like "deprecated", is ultimately a meaningless label? > > Seems like there's not a lot of solid ground left around here. I think the operative bits around the definition of deprecated in the current draft are SHOULD NOT. It's that versus removal (MUST NOT). I think the IESG of the day used Experimental to dodge it's way out of a problem with Microsoft. Given the reality of 2005, I don't know that they could have realistically done any different, but RFC 4408 was never 'experimental' in the same say an experimental RFC written up after a few people have spent some time in a lab is 'experimental'. People understood that. I think it's not appropriate to go back now and pretend it was other than it was. Scott K From superuser@gmail.com Wed Jul 18 22:23:21 2012 Return-Path: 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 EB45C21F854B for ; Wed, 18 Jul 2012 22:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 KM+HW4VTlkA6 for ; Wed, 18 Jul 2012 22:23:20 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1163521F8543 for ; Wed, 18 Jul 2012 22:23:19 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3400202lbb.31 for ; Wed, 18 Jul 2012 22:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SsvJ28Zk0WxZVoNVyNFPQ4LBa2GdaMt25yQ7z591X7k=; b=bBh84IiFtfsxjHKUX3MGuikUZg6UdE3Ibu7g7ffnNoME0cqo/JwmclZVxSLevlWZ61 BbwaNe0kXZunHiXQhYcWFox+hYJeZ5y6rusIW1XwVyrcZpcZ8wVv3dSYC0FxMCg0AznX LQIe0F9qy0tkISUtMNvJvov4naDBppykzU1DrNdB2LkyIFBM0cyMjFfgTJxmLUCYu8Y9 rgYVWpSPsa3HU2bFP+phw7Hlfbo5M+s95Jm5pa5Eb68gnlocsiXxZJKQo3fymPRT/Te0 crw0kEl1/k4dvC3cqWMC49FyL8f3zyiFJhIJRIFWx7xOclxgSQK/fYOqalkLRgDiF7dd EYOg== MIME-Version: 1.0 Received: by 10.112.46.9 with SMTP id r9mr389640lbm.81.1342675451504; Wed, 18 Jul 2012 22:24:11 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 18 Jul 2012 22:24:11 -0700 (PDT) In-Reply-To: <1988807.rgypmf6EXz@scott-latitude-e6320> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <1854566.3loDmVqy4f@scott-latitude-e6320> <1988807.rgypmf6EXz@scott-latitude-e6320> Date: Wed, 18 Jul 2012 22:24:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0401236f55e93a04c527fdc6 Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 05:23:21 -0000 --f46d0401236f55e93a04c527fdc6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 10:13 PM, Scott Kitterman wrote: > As one of the people that reviewed it, I can assure you I thought it was. > If > I thought the current charter allowed us to toss out backward > compatibility on > the basis of "oh, it seems simpler this way", I'd have never supported it. > > > And you really believe that's a fair characterization of the arguments being made? -MSK --f46d0401236f55e93a04c527fdc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 10:13 PM, Scott Kitterman <spf2@kitterman.com= > wrote:
As one of the people that reviewed it, I can assure you I thought it was. = =A0If
I thought the current charter allowed us to toss out backward compatibility= on
the basis of "oh, it seems simpler this way", I'd have never = supported it.



And you really believe that's a fair characterization of the arg= uments being made?

-MSK

--f46d0401236f55e93a04c527fdc6-- From WebMaster@Commerco.Net Wed Jul 18 22:24:55 2012 Return-Path: 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 5717C21F863D for ; Wed, 18 Jul 2012 22:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 CYGlo493DaJJ for ; Wed, 18 Jul 2012 22:24:54 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7894B21F8634 for ; Wed, 18 Jul 2012 22:24:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=iQKlM/Jee9crxfeXLGRrbJAi0NIoNksxFzl1SFSENBo7Gzt6Aaq2K40w2Di7O4r/apc//MTPabZ8CJvPX+VSRknlzLUluFGINTx6xDRVIwxa9tNEsomXBZle9kdAVeECyWcSTCqLVgJkrEX0QovYVi4FtZGR4lFBuywY7RnpCu4= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]); Thu, 19 Jul 2012 05:25:37 +0000 Message-ID: <50079A4A.1040406@Commerco.Net> Date: Wed, 18 Jul 2012 23:25:30 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20120719031507.GG1323@crankycanuck.ca> <50079416.7060204@dcrocker.net> In-Reply-To: <50079416.7060204@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: spfbis@ietf.org, Dave Crocker , "Murray S. Kucherawy" , Andrew Sullivan Subject: Re: [spfbis] Is a feature desirable in practical terms? (was - Re: A standards track document defining SPF) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 05:24:55 -0000 Dave, On 7/18/2012 10:59 PM, Dave Crocker wrote: > > > On 7/18/2012 9:29 PM, Murray S. Kucherawy wrote: >> Isn't it desirable, then, to get rid of this stuff while it's >> Experimental and not Proposed Standard? > > > This strikes me as the single-most basic and compelling question, and it > seems to be getting ignored. > > Everything ought to flow from the answer to that question. > > Debating the meaning of "unused", for example, should only come after > agreeing whether a feature is in fact desirable, based on the experience > of more than a few years in the field. > > If someone is claiming that PTR or macros are indeed practically > desirable, based on the community's extensive experience, they should > make that case. We have, I think, plenty of evidence to the contrary. > > d/ This seems a pretty reasonable approach. As much as I personally dislike anything that breaks compatibility with earlier work product, the reasoning founded upon the experimental status of SPF is a pretty good argument. Sometimes beta software when it becomes released product has some removed features which proved themselves as unproductive for the majority of the consumers who might use the software during the shakedown of the beta. Perhaps there is a parallel. I think that if we were to setup a list of bullet point reasons pro and con for the disputed PTR and Macro features, perhaps that might help us figure out and make the best choices in resolving the matter. Alan M. From superuser@gmail.com Wed Jul 18 22:38:43 2012 Return-Path: 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 1879821F85BB for ; Wed, 18 Jul 2012 22:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ywYgUc8tBbV8 for ; Wed, 18 Jul 2012 22:38:42 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4166721F85B8 for ; Wed, 18 Jul 2012 22:38:42 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3416030lbb.31 for ; Wed, 18 Jul 2012 22:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LnIeOAIrI/wF7VP4Wfb3M/HaC7mBNnZrxaFH2vaHyE8=; b=NPgz9cyLw5uNlHGkCBo9yumd+A0vp2UzpTjo/l1f6EPATL9FDxTQjJb3S0wg93uCnQ Znr2SDFVoevHUX5CB9dZvazCBzkyWWqfR1PSaoeLmmGOOpDCkBwQRwqt7nGv7f1M/cbx xuGZVlBKQf69Pbj4Cevz3bexmn9Km7W3TpSrMVJKxFH+eShauJ2mLBnHD9bJNLpALI1u liyFddByWFXhT0/JvW6XFKDLCbTE5BlpXNRabPNbvz7pZ42144x8qkSdRgLa/IJCkTNc shidDJRW08Bm1BOW9BwbWBuqCov4TMu0iJPTarF7wqOefobDgQjYKxDiXDHn+pJbLOyW DtLA== MIME-Version: 1.0 Received: by 10.112.83.169 with SMTP id r9mr410127lby.66.1342676373570; Wed, 18 Jul 2012 22:39:33 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 18 Jul 2012 22:39:33 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20120719031507.GG1323@crankycanuck.ca> Date: Wed, 18 Jul 2012 22:39:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=f46d0401fc434b842104c528348b Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 05:38:43 -0000 --f46d0401fc434b842104c528348b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 9:29 PM, Murray S. Kucherawy wrote: > Would it make people satisfied if I were to chase down all 203 domains > that we found publishing SPF records with macros in them and ask them if > they would complain if that aspect of the protocol were removed? I'd be > happy to do that. > > I was worried I'd put my foot in it when I said that, but I just discovered that more than half of that 203 is a single ESP that uses a subdomain for each customer. So the actual number of "users" is far smaller than I'd originally thought. I'll try to contact all of them, though probably not until next week due to other obligations. -MSK --f46d0401fc434b842104c528348b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 9:29 PM, Murray S. Kucherawy <= superuser@gmail.co= m> wrote:
Would it make people satisfied if I were to chase down all 203 domains that= we found publishing SPF records with macros in them and ask them if they w= ould complain if that aspect of the protocol were removed?=A0 I'd be ha= ppy to do that.


I was worried I'd put my foot in = it when I said that, but I just discovered that more than half of that 203 = is a single ESP that uses a subdomain for each customer.=A0 So the actual n= umber of "users" is far smaller than I'd originally thought.<= br>
I'll try to contact all of them, though probably not until next wee= k due to other obligations.

-MSK

--f46d0401fc434b842104c528348b-- From spf2@kitterman.com Wed Jul 18 22:46:38 2012 Return-Path: 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 1AA7621F862F for ; Wed, 18 Jul 2012 22:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] 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 QDMLGrEbdwS6 for ; Wed, 18 Jul 2012 22:46:37 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 30D8F21F8629 for ; Wed, 18 Jul 2012 22:46:37 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 34A8520E40BD; Thu, 19 Jul 2012 01:47:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342676849; bh=eTHSDjIYBSLXF3xZLOT72/mRxZEbiFUvyr6vXGC+8aY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qXlpFOXucsXKaoHKlgR+V57/QsfQyLRREz44gznWiaOwURwWBK1UMixrpTspGvFGB Co2NkPkkFiCv+wg2VbIi3cfcQzcGVL7HR5nbKGvnMvADplRw6OWExGQE919eusqUd+ u1INMfUhI0ouP/VpWznn+YdY4fj3eGm+JbSI7ti4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1761D20E4081; Thu, 19 Jul 2012 01:47:28 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Jul 2012 01:47:28 -0400 Message-ID: <9732144.jm9I0jS2He@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <1988807.rgypmf6EXz@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 05:46:38 -0000 On Wednesday, July 18, 2012 10:24:11 PM Murray S. Kucherawy wrote: > On Wed, Jul 18, 2012 at 10:13 PM, Scott Kitterman wrote: > > As one of the people that reviewed it, I can assure you I thought it was. > > > > If I thought the current charter allowed us to toss out backward > > compatibility on > > the basis of "oh, it seems simpler this way", I'd have never supported it. > > And you really believe that's a fair characterization of the arguments > being made? I'm not convinced that the arguments against macros are anything other than an interesting theory. A slightly longer version of what I wrote above would be: 1. Usage is very low. Close enough to zero that we can call it zero. 2. We have a number of theories why keeping it is bad: a. It adds complexity to the protocol b. The code behind these protocol elements won't be well tested and is buggy. c. Local-part macros in particular make EAI harder. d. The impact on DNS cachability of some macros (including local-part) is a problem. I don't argue 2.a. The only real evidence for 2.b is one report of a problem with one provider. For 2.c, I think we'd agreed that there's a subset of international local- parts that could be represented in the local-part macro and the rest can't. It's true that getting full EAI support for local-part macros would be hard, but no one has argued it's needed (in fact it's been suggested we might be best off to ignore it entirely for now). For 2.d, there's not a lot of evidence that SPF records of any type are substantially cached for any but the largest domains. The practical impact of some macros inhibiting cachability seems to be nil. So while the language I used was a bit flip, I think it's a reasonable short form. It would have been more complete to say "Oh, we have some theories and in any case it's simpler this way", but I don't see that any case based on anything other than simplicity and lack of use has really been made. Scott K From superuser@gmail.com Wed Jul 18 23:09:14 2012 Return-Path: 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 89EF211E808A for ; Wed, 18 Jul 2012 23:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 TOB0XSovteiZ for ; Wed, 18 Jul 2012 23:09:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8656411E8086 for ; Wed, 18 Jul 2012 23:09:13 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3448022lbb.31 for ; Wed, 18 Jul 2012 23:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j4ecVtpg1rnL9PK5vHYxoSp1odHJTsCa+yE5wbhUbiw=; b=b8E0m0os7hdervLduSOxOlUTUesRqifzfg7nEq1aSTJ2nU69bu/aC9ifY2aSQpXjDU hEbthOiWWKIcvb93QhfanmQBG/RSmeVBU939A2SMXnIOoJUJcBQUINrqpOJ4Wz6IG+jR I/UUPsaJabls7pjmC8O5NYmNS8/r61AzywZa/l/+CG93bnx8d5fbIi9YaxSrLTRdFw8i qI8uHBrD4Zc0h9CgW+zkUc7vFFhRaTjwNlwvbnLwDHUaopZaV2wXMaWDIHIVa/uem8tu ylw6WWdB8WSO3eGGlM1m8Cs1fKrxcXYgkYYTG5cySGSKYt2fz02ODVFDRkyl2KmV9RSh oueQ== MIME-Version: 1.0 Received: by 10.152.124.180 with SMTP id mj20mr550534lab.43.1342678205048; Wed, 18 Jul 2012 23:10:05 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 18 Jul 2012 23:10:04 -0700 (PDT) In-Reply-To: <9732144.jm9I0jS2He@scott-latitude-e6320> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <1988807.rgypmf6EXz@scott-latitude-e6320> <9732144.jm9I0jS2He@scott-latitude-e6320> Date: Wed, 18 Jul 2012 23:10:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0434bfde75a5d104c528a1fc Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 06:09:14 -0000 --f46d0434bfde75a5d104c528a1fc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 10:47 PM, Scott Kitterman wrote: > I'm not convinced that the arguments against macros are anything other > than an > interesting theory. A slightly longer version of what I wrote above would > be: > > 1. Usage is very low. Close enough to zero that we can call it zero. > 2. We have a number of theories why keeping it is bad: > a. It adds complexity to the protocol > b. The code behind these protocol elements won't be well tested and is > buggy. > These are the three arguments I'm focused on, so I'll ignore the rest or let others carry them forward. But it's derisive and plain wrong to dismiss any of them, much less all of them, as theoretical. > > So while the language I used was a bit flip, I think it's a reasonable > short > form. It would have been more complete to say "Oh, we have some theories > and > in any case it's simpler this way", but I don't see that any case based on > anything other than simplicity and lack of use has really been made. > > You find those last two points to be uninteresting, while I find them critical. I could be equally dismissive and characterize your position as "Oh, even one user shown to be using this stuff means (to use Alan's example) this broken Beta feature that we don't really want to support has to stay in the released product for the foreseeable future." To me, that line of thinking makes neither good protocol design sense nor good business sense. -MSK --f46d0434bfde75a5d104c528a1fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 10:47 PM, Scott Kitterman <spf2@kitterman.com= > wrote:
I'm not convinced that the arguments against macros are anything other = than an
interesting theory. =A0A slightly longer version of what I wrote above woul= d be:

1. =A0Usage is very low. =A0Close enough to zero that we can call it zero.<= br> 2. =A0We have a number of theories why keeping it is bad:
a. =A0It adds complexity to the protocol=A0
b. =A0The code behind these protocol elements won't be well tested and = is buggy.

These are the three arguments I'm fo= cused on, so I'll ignore the rest or let others carry them forward. But= it's derisive and plain wrong to dismiss any of them, much less all of= them, as theoretical.
=A0

So while the language I used was a bit flip, I think it's a reasonable = short
form. =A0It would have been more complete to say "Oh, we have some the= ories and
in any case it's simpler this way", but I don't see that any c= ase based on
anything other than simplicity and lack of use has really been made.

= =A0
You find those last two points to be uninteresting, while I = find them critical.=A0 I could be equally dismissive and characterize your = position as "Oh, even one user shown to be using this stuff means (to = use Alan's example) this broken Beta feature that we don't really w= ant to support has to stay in the released product for the foreseeable futu= re."=A0 To me, that line of thinking makes neither good protocol desig= n sense nor good business sense.

-MSK
--f46d0434bfde75a5d104c528a1fc-- From spf2@kitterman.com Wed Jul 18 23:13:16 2012 Return-Path: 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 6CD7E21F8597 for ; Wed, 18 Jul 2012 23:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] 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 V6Ap7eTGVa0Q for ; Wed, 18 Jul 2012 23:13:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 23F3F21F854D for ; Wed, 18 Jul 2012 23:13:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 156D120E40BD; Thu, 19 Jul 2012 02:14:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342678447; bh=E6y7Q2hz6ihAMu4xtqktazT13SXsDrHFFaEnkPJHFuk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iOyBhvgKaR2NcnkbMS+r+MFWSXIq0+on9Yp5TxZPHULrfnh6cmMfRFF3YSCt6UZgO LoAtVgPs1jiqNok8IGq6KMe7dyQUrJPQa25X97t4xT0qM4VdFFL7nGBek48tyqC41o mbFi4DFZU/PtfB+PjabPfYioePR9ha1zUb9tvOfw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EAC0020E4081; Thu, 19 Jul 2012 02:14:06 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Jul 2012 02:14:06 -0400 Message-ID: <1757737.ROyR1GoduU@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <9732144.jm9I0jS2He@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 06:13:16 -0000 On Wednesday, July 18, 2012 11:10:04 PM Murray S. Kucherawy wrote: > On Wed, Jul 18, 2012 at 10:47 PM, Scott Kitterman wrote: > > I'm not convinced that the arguments against macros are anything other > > than an > > interesting theory. A slightly longer version of what I wrote above would > > be: > > > > 1. Usage is very low. Close enough to zero that we can call it zero. > > 2. We have a number of theories why keeping it is bad: > > a. It adds complexity to the protocol > > b. The code behind these protocol elements won't be well tested and is > > > buggy. > > These are the three arguments I'm focused on, so I'll ignore the rest or > let others carry them forward. But it's derisive and plain wrong to dismiss > any of them, much less all of them, as theoretical. > > > So while the language I used was a bit flip, I think it's a reasonable > > short > > form. It would have been more complete to say "Oh, we have some theories > > and > > in any case it's simpler this way", but I don't see that any case based on > > anything other than simplicity and lack of use has really been made. > > You find those last two points to be uninteresting, while I find them > critical. I could be equally dismissive and characterize your position as > "Oh, even one user shown to be using this stuff means (to use Alan's > example) this broken Beta feature that we don't really want to support has > to stay in the released product for the foreseeable future." To me, that > line of thinking makes neither good protocol design sense nor good business > sense. I think the comparison between a protocol that's been in Internet scale production for close to a decade and a beta software release is far fetched, but that's not important. I got lost in the issue counting and the line wrapping above, so would you please restate the arguments you're focused on? Scott K From vesely@tana.it Thu Jul 19 00:27:40 2012 Return-Path: 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 7B8AF11E80EE for ; Thu, 19 Jul 2012 00:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.624 X-Spam-Level: X-Spam-Status: No, score=-4.624 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 08J3UvxWosgP for ; Thu, 19 Jul 2012 00:27:39 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 59D0811E80C5 for ; Thu, 19 Jul 2012 00:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342682910; bh=AW6/IfVJh2qjf2byc1CzqNlq+jLhECQQqYSgG+Z8fOE=; l=3936; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=fdXt52AiMl/77nURklSIeoLNOLJNixGLix/Fgb3FSx9geVyV50X6kcdcyt0AxmxQ6 sNDIf12EEIQqXs3lDpRKb7c6EHgh6XsCxC7FFO58GgqfimxyIx+InS/2bWOGuvggFI uqzpTFS1GTRxM60bIymjTskkxKpQeo5h0xe4w9IE= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 19 Jul 2012 09:28:29 +0200 id 00000000005DC039.000000005007B71D.000024D2 Message-ID: <5007B71E.3010701@tana.it> Date: Thu, 19 Jul 2012 09:28:30 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> In-Reply-To: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 07:27:40 -0000 On Wed 18/Jul/2012 22:09:36 +0200 S Moonesamy wrote: > > draft-ietf-spfbis-4408bis is unusual work as Experimental RFCs > generally go through [IETF revision]. It can be argued that the > draft can be published as a RFC with (iii) as the significant > change and some editorial changes. Murray Kucherawy mentioned the > following [1]: > > "If I were sitting on SECDIR, I'd make some noise about this > during Last Call, for example." > > draft-ietf-spfbis-4408bis will be reviewed by the IETF Security > Directorate (SECDIR). It is expected that the working group will give > some serious thought to the security considerations aspect before the > Last Call. I'm rather lost. What are we talking about? We agreed to drop historical questions and just clean up the protocol. We devised a path to deprecate unwanted features. While that path can be ameliorated (see below), even Dave and Murray seem to agree that it may be a reasonable compromise. Thus, the question boils down to specific considerations, e.g. on the status of %{l}: Its usage in mechanisms is discouraged with the same normative strength as deprecation, but it's not formally deprecated. Thus, it can still be used for explanations. What are we going to do with the latter use? I don't know what SECDIR will say, but don't understand why we should get ahead of ourselves trying to guess what they'll object and fix unbroken stuff based on conjectures. Can't we cross that bridge when we get to it? > Scott Kitterman raised an interesting point: backward incompatibility > [2]. The question that comes to my mind is whether > draft-ietf-spfbis-4408bis has to be backward compatible with RFC 4408. > > Section 4 of RFC 4408 has the following requirement: > > "Mail receivers that perform this check MUST correctly evaluate > the check_host() function as described here." > > There is a reference in that Section 4 to Section 2.5. In Section > 2.5.5, there is: > > 'A "SoftFail" result should be treated as somewhere between a "Fail" > and a "Neutral".' > > Depending on how one interprets RFC 2119 there may or may not be a > recommendation in that sentence. Assuming that it is a recommendation > (SHOULD) the "somewhere between" two possible results is ambiguous. Hm... "SHOULD NOT be treated more severely than fail NOR more mildly than neutral"? Part of that belongs to the cleanup. Some ambiguity originates from the fact that the intended treatment is underspecified in general. I trust we'll explicate it better, but that's issues #12, #13, and #29. > My suggestions are: > > 1. Demonstrate that a RFC 4408 implementation and a > draft-ietf-spfbis-4408bis implementation will produce the same > results > > 2. If (1) is not possible, provide an explanation for the change I don't think they need to produce the same results. It is enough that they are interoperable and produce compatible results. In particular, I like Scott's idea to stretch the meaning of "none" in order to allow (new) implementations to skip processing of some features. I'm not sure about header fields saying "none", as the usual interpretation of that is "the sender publishes no record". Alternatively, they could pretend not to be carrying out any SPF check --which is already possible, obviously. The explanations should go in their own section/appendix. Scott is currently keeping a log of changes, and I propose that it remains that way until the document is almost ready. At that point we can add detailed explanations of the reasons why we made those changes. For PTR, besides what Hector already recalled, there is also the underspec that Murray noted (xebay.com), and the fact that .arpa delegations are often omitted or not in sync. -- > 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg01879.html > 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg01888.html From sm@elandsys.com Thu Jul 19 03:30:56 2012 Return-Path: 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 56B1521F8763 for ; Thu, 19 Jul 2012 03:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.57 X-Spam-Level: X-Spam-Status: No, score=-103.57 tagged_above=-999 required=5 tests=[AWL=1.029, BAYES_00=-2.599, GB_I_LETTER=-2, 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 zttIpu6iSckI for ; Thu, 19 Jul 2012 03:30:54 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1485D21F875A for ; Thu, 19 Jul 2012 03:30:54 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.62]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6JAVWYV001438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Jul 2012 03:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342693905; bh=J0+aI49eDHlosR9rSgTnn3rI6tAUzmJs1RRGSmbYcPQ=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=uvtJmDqeKhTUUXf8shQ6dN0J5FFWofi7s6qtRVY6ppJlEPuD/jhNSv8sNkNxVL4gG +CfVOZhv7FHol+kovbqNZdRZ3Ealb/f7OMRfF31UZT6kPBm2gw8wPaUFcVhL5zl4Qr Ewj7S3cwUNfJjacz1HSJ80arVAAG8sEfXFS/Lj2U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342693905; i=@elandsys.com; bh=J0+aI49eDHlosR9rSgTnn3rI6tAUzmJs1RRGSmbYcPQ=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=rHtRiiu0H4Bu8HnbmNNWpX/dvRZ+yQxTPAkGTRu/1BSHwYahO73j3ASMijilnxQ9v A5Eabye+AvvaE0zToS+s5mNeA1AKcUY0hKRgBk/k1JI0ZJsQAviAtO5JbvdMTS18PU 7bmCT9diL4bUTrnxkjFzMAPO8fCh7z+8wAE9Ja2Y= Message-Id: <6.2.5.6.2.20120718232149.09b9fc40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Jul 2012 03:25:24 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120719031507.GG1323@crankycanuck.ca> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20120719031507.GG1323@crankycanuck.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 10:30:56 -0000 At 20:15 18-07-2012, Andrew Sullivan wrote: >even of English. The answer is to go back to the community and say, >"This charter is stupidly restrictive for something coming from the >experimental track and moving to the standards track." I am >personally disinclined to lead that charge; but if people really want >to do it, I won't try to stop anyone. The working group has a charter. It was cleared spelled out that it will work on moving a specification from Experimental to the Standards Track. Even if I am convinced about a change or non-change to the specification I cannot overlook the restrictions in the charter. I cannot go back to the community and say that the charter needs to be changed. I am ok if a WG participant decides to go back to the community to ask for a change to the charter. The only advice I can provide is to be prepared to spend the time and energy to convince the IETF community. In a message posted on December 1, 2011, backward compatibility was mentioned [1]. If Andrew Sullivan asks me about that I'll quote the following paragraph: "Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language." At 00:28 19-07-2012, Alessandro Vesely wrote: >I'm rather lost. What are we talking about? What I was talking about is to take security considerations seriously. It is up to the working group to do that work. >that it may be a reasonable compromise. Thus, the question boils down I like the word "compromise". Here are equivalent terms: - compromis - kompromiss - compromesso - compromiso - kompromiss >unbroken stuff based on conjectures. Can't we cross that bridge when >we get to it? Yes, as long as the working group carefully considers the issues. >Some ambiguity originates from the fact that the intended treatment is >underspecified in general. I trust we'll explicate it better, but >that's issues #12, #13, and #29. It is up to the working group to identify the ambiguities. At 15:01 18-07-2012, Commerco WebMaster wrote: >I guess the question for me really is are we fixing something that >is really broken or breaking something that actually works? The working group might want to think very carefully about that. I understand that the issues are not always clear-cut. Any WG participant who breaks something may be asked to fix it. At 18:56 18-07-2012, Murray S. Kucherawy wrote: >Further, I don't much like the idea of going onto the Standards >Track for the first time with two features we know see very little >use, have known costs, and have basically agreed should at least be >deprecated. That just feels completely sloppy to me. I recognize >there's a big deployed base for SPF, but approximately none of that >base uses the stuff we're talking about. Keeping it creates more of >a burden than it solves. > >The counter-argument is basically "It's only a 'proposed' standard, >and we can remove these things before it goes along the RFC6410 >route." Those of us who have been around long enough know that such >advancement is rare indeed (which is why we recently went from three >maturity levels down to two), so on the premise that such a revision >is also statistically unlikely, I think the proper thing to do is >get it right up front. > >As I said in an earlier post, if something were to land in front of >me, as a SECDIR reviewer or an IESG member, with two sections that >basically say "We know this is broken, please don't use it in TXT >records but receivers MUST support it anyway", I'd be asking >questions about why it's going for the Standards Track in the first place.. The above is the IETF angle. I am excluding "features" in my comment or else I would not be able to comment. Two of the questions which the document shepherd has to answer are: 1. What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? 2. Why is this the proper type of RFC?" At 19:55 18-07-2012, Scott Kitterman wrote: >I think you either get to pick the letter of the IETF process or a realist >view of it, not whichever is convenient. I am in favor of a practical approach. It entails taking all the factors into consideration including IETF process. At 20:21 18-07-2012, Commerco WebMaster wrote: >The primary reason I piped up was in response to our co-chair's >remark about removing SPF backward compatibility in the >specification. Perhaps it was my conditioning by a former It was an individual comment. I posted an argument to find some way to reach the goal. At 20:27 18-07-2012, Hector Santos wrote: >hmmmm, the same was done for DKIM with its SHA1 vs SHA256. There >are other examples I am sure we can find in the annals for IETF >protocol development and updates. I am more interesting in hearing about other examples. At 21:19 18-07-2012, Murray S. Kucherawy wrote: >If we're trying to protect people from themselves by discouraging >use of these features, attaching an easily ignored labels will not >achieve that goal. There are four instances of the word "discouraged" in RFC 4408. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00020.html From hsantos@isdg.net Thu Jul 19 04:23:48 2012 Return-Path: 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 27B1D21F8722 for ; Thu, 19 Jul 2012 04:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 XmI7fThd+Y+5 for ; Thu, 19 Jul 2012 04:23:47 -0700 (PDT) Received: from mail.santronics.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 256EE21F8720 for ; Thu, 19 Jul 2012 04:23:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1475; t=1342697075; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=k435RcUt81iBUJrm7Vy2gklfq20=; b=B1h20yJ9awZd0bpWOjHq S3IpeRm8ME0fGKyHLBgoDsLOtlcadP2umhnuRYRnxgcdHEyY+6afkENZUuJ/PciA hl4UtRJGanTFIsI5qmHTqsRGDjSE1tSXsDGEwG6v9/6/Rt44QJzY/3nrfQ7QJhTM nqo26Ar1+Qqyd8ZekQzOk3c= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 19 Jul 2012 07:24:35 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3013873445.18069.3728; Thu, 19 Jul 2012 07:24:34 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1475; t=1342696942; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0U1XWGo LCWCXcSCXwkGakSPJUB3rYJohKNVqFHE+cA0=; b=IsIwVGGfkzNB/IulBxxFuV0 LBMlsL+VexwyOnj6zKx8RnHO8a6EN9jy6yWQ8F2JY5ReokAby7U7+dOz6LKDHNO3 fx9Czri8jhAzzgHI+XSKr+F3L8yxxoVslEKedf2YKBsgfLgZ700Dm0WGpEbOePoz idMswN7/UqPFPM0VkPNU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 19 Jul 2012 07:22:22 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3612707285.9.1980; Thu, 19 Jul 2012 07:22:21 -0400 Message-ID: <5007EEB6.7030803@isdg.net> Date: Thu, 19 Jul 2012 07:25:42 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20f4303a-b51b-4ece-8547-518bd79b0bea@email.android.com> <50077CD0.9050208@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 11:23:48 -0000 Murray S. Kucherawy wrote: > On Wed, Jul 18, 2012 at 8:19 PM, Hector Santos wrote: > >> I can easily post 361 domains from a cache of 1 day with SPF policies >> having PTR directives, but I won't. BTW, for IP6, 15 domains had ip6 in >> their SPF policies. >> >> > If you won't provide data, your claim isn't meaningful. > > The TDP and Cisco surveys amount to reproducible experiments. Your say-so > isn't. And thats the whole problem with someone and my original compliant with this group where someone who was a militant anti-SPF, public opponent of SPF with no SPF history, no SPF deployment field experiences, with his own site/company and/or thousands of customers, a extremely disturbing high propensity to ignore participants input COULD NOT be the chair and author of SPFBIS. We have 9 years of LMAP and SPF experience, in implementation for 3rd party usage, site deployment and field deployment and support experiences with customers. You do not. The years of facts there existed wizards producing PTR statement is unknown to you, all the examples and documentation that exist. The facts there there are PTR usage is unknown to you from all angles, the high utility it offers especially practical experience is all missing. You're wasting people time with this nonsense. How do the chairs what the PTR data? I can post a small sample here, a full attachment (waste of bandwidth) or a provide a link? -- HLS From ajs@anvilwalrusden.com Thu Jul 19 04:37:36 2012 Return-Path: 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 2296421F87B3 for ; Thu, 19 Jul 2012 04:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 ZG-T3tzrkaWI for ; Thu, 19 Jul 2012 04:37:35 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 91EAF21F87A3 for ; Thu, 19 Jul 2012 04:37:35 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id A2E6F8A031 for ; Thu, 19 Jul 2012 11:38:27 +0000 (UTC) Date: Thu, 19 Jul 2012 07:38:22 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120719113822.GA2101@mail.yitter.info> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20120719031507.GG1323@crankycanuck.ca> <50079416.7060204@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50079416.7060204@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Is a feature desirable in practical terms? (was - Re: A standards track document defining SPF) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 11:37:36 -0000 No hat. Dave, On Wed, Jul 18, 2012 at 09:59:02PM -0700, Dave Crocker wrote: > This strikes me as the single-most basic and compelling question, > and it seems to be getting ignored. I was not ignoring it. I was arguing instead that, given our charter, it's not the most basic and compelling question, even if one believes it should be. > If someone is claiming that PTR or macros are indeed practically > desirable Irrelevant. It doesn't matter whether they are desirable, given the charter. It matters whether they are used. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu Jul 19 04:53:48 2012 Return-Path: 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 4BD8121F8759 for ; Thu, 19 Jul 2012 04:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 yevKdgK95jHd for ; Thu, 19 Jul 2012 04:53:46 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAC321F8704 for ; Thu, 19 Jul 2012 04:53:46 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 1192F8A031 for ; Thu, 19 Jul 2012 11:54:36 +0000 (UTC) Date: Thu, 19 Jul 2012 07:54:32 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120719115430.GB2101@mail.yitter.info> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20120719031507.GG1323@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 11:53:48 -0000 No hat. On Wed, Jul 18, 2012 at 09:29:10PM -0700, Murray S. Kucherawy wrote: > Would it make people satisfied if I were to chase down all 203 domains that > we found publishing SPF records with macros in them and ask them if they > would complain if that aspect of the protocol were removed? I'd be happy > to do that. No. The surveys check a tiny percentage of the domains on the Internet. We don't even know what percentage, because we don't have a practical way of actually enumerating the domains on the Internet. What the surveys show is that these features are in use by a very small percentage of the population. If we assume that our sample is representative of the Internet (and that's a big leap, but for the sake of this argument it doesn't matter), we may conclude that the features are in use in a tiny percentage of the Internet population's case. Now, since we don't have a way of contacting every operator of every domain on the Internet, even if you contacted those 203 people and found that they were using these features in a way such that they could easily adapt to elimination of the feature, that would in no way provide you with evidence that the features are "unusued". Your only evidence is still your starting evidence, which is that the feature is used by a tiny percentage of the population. Again, to me this is a charter issue. If we want literally to make this removal, then the charter needs to change. > > these records. What are you going to do with it? Drop it on the > > floor? No, of course not. You're going to use your hoary old 4408 > > code to handle it anyway. > > It's not true for me. Given what I know, I wouldn't implement ptr or > macros. They'd get permerror or something. That's an even better response than, "I'll do what 4408 does," because if we are to remove the features knowing that they used to be published by people, we will need to say what one does when confronted with use of that feature. (The analogy with RRTYPE 99 fails here, because by removing it we actually ensure that it doesn't get looked up; so no software needs to accommodate running into it.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Thu Jul 19 06:11:03 2012 Return-Path: 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 11E9421F87DA for ; Thu, 19 Jul 2012 06:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Sv2DXm3se-kf for ; Thu, 19 Jul 2012 06:11:02 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D18F721F87B9 for ; Thu, 19 Jul 2012 06:11:01 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3997706lbb.31 for ; Thu, 19 Jul 2012 06:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+6H/8E6uTQdsRWqEkGCZc+ylFi8z6Vnq9z4kJFNx+fA=; b=XyPcWwJFROEIWpXlAfIZjHzbCOHLD8Qq3Bbd6fXQZUShGhj+ywIISYwPyplyZHsdPG HfKS6NjeoB8EWstOMD0KG4DUrTjFy7xH0BVr7uZqwcIb/7S8YN4AgjH3SRSQ3hNfCAPL 7NXc5PTxVM1Pzo9G+WeTEpi3h0b3DPWoySBSGc+p/SNiADT6s0Pq+EWYYbw7+0/fEV3+ QD0/nBjFKIoLCNohrx7VhZ3X13UwnJJzEP0OdbsiG1ixIWdbyrD+p+3My/ymydh1paPb xi0vIeO6rrsBECId0OOeFOABsN0LK/Hsiq6TNmHY7lDYJQx8P06d03Vt+7torDbv8bqx l5ow== MIME-Version: 1.0 Received: by 10.112.46.9 with SMTP id r9mr1142876lbm.81.1342703513245; Thu, 19 Jul 2012 06:11:53 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 19 Jul 2012 06:11:53 -0700 (PDT) In-Reply-To: <20120719115430.GB2101@mail.yitter.info> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20120719031507.GG1323@crankycanuck.ca> <20120719115430.GB2101@mail.yitter.info> Date: Thu, 19 Jul 2012 06:11:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=f46d0401236ff2175904c52e852d Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 13:11:03 -0000 --f46d0401236ff2175904c52e852d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 19, 2012 at 4:54 AM, Andrew Sullivan wrote: > Now, since we don't have a way of contacting every operator of every > domain on the Internet, even if you contacted those 203 people and > found that they were using these features in a way such that they > could easily adapt to elimination of the feature, that would in no way > provide you with evidence that the features are "unusued". Your only > evidence is still your starting evidence, which is that the feature is > used by a tiny percentage of the population. > > If we're going to accept that these are representative samples, then discovering that the 203 would be willing to adapt to elimination of the feature also means we have to accept that the same is likely true of those domains the survey didn't explicitly discover. As you said, and I agree, the best we could ever hope to achieve is a representative sample. That logic worked for reaching the conclusions in draft-ietf-spfbis-experiment, and I don't see why it doesn't apply now. -MSK --f46d0401236ff2175904c52e852d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 19, 2012 at 4:54 AM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
Now, since we don't have a way of contacting every operator of every domain on the Internet, even if you contacted those 203 people and
found that they were using these features in a way such that they
could easily adapt to elimination of the feature, that would in no way
provide you with evidence that the features are "unusued". =A0You= r only
evidence is still your starting evidence, which is that the feature is
used by a tiny percentage of the population.


If we're going to accept that these are repre= sentative samples, then discovering that the 203 would be willing to adapt = to elimination of the feature also means we have to accept that the same is= likely true of those domains the survey didn't explicitly discover.
As you said, and I agree, the best we could ever hope to achieve is a r= epresentative sample.=A0 That logic worked for reaching the conclusions in = draft-ietf-spfbis-experiment, and I don't see why it doesn't apply = now.

-MSK
--f46d0401236ff2175904c52e852d-- From spf2@kitterman.com Thu Jul 19 06:22:17 2012 Return-Path: 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 C368D21F87A3 for ; Thu, 19 Jul 2012 06:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] 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 LOGjYR4dD6kz for ; Thu, 19 Jul 2012 06:22:17 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDC221F8794 for ; Thu, 19 Jul 2012 06:22:16 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 945BB20E4126; Thu, 19 Jul 2012 09:23:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342704189; bh=CggBrC/4TmhcaJB8IEEoIUlIq7HV8W17o1pPwB/vtqs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ROYCGkdZUJOM1BD8Rmur9IG73xq2fm+4EbFheRsfAc+BQ8zxbOsIvqu0VLZwPjsis skqIJZeLjakjzwpvcbUkfcXp/dcg7yeuhUOb6miHP1fhvibba1MJ2xn9DxHTIWNnbL 4ESteaA5PGQUPdbvK+/un8iiuKxyTHveH2MjVz2c= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7617420E40E3; Thu, 19 Jul 2012 09:23:09 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Jul 2012 09:23:08 -0400 Message-ID: <10918896.ovqHJodpgA@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120718232149.09b9fc40@resistor.net> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <20120719031507.GG1323@crankycanuck.ca> <6.2.5.6.2.20120718232149.09b9fc40@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 13:22:18 -0000 On Thursday, July 19, 2012 03:25:24 AM S Moonesamy wrote: > At 21:19 18-07-2012, Murray S. Kucherawy wrote: > >If we're trying to protect people from themselves by discouraging > >use of these features, attaching an easily ignored labels will not > >achieve that goal. > > There are four instances of the word "discouraged" in RFC 4408. Actually it's two "discouraged" and two "discourage". The former are relevant to this discussion. Use of PTR is "discouraged". Use of wildcards and SPF records is "discouraged". Use of macros that can't be cached (including the dreaded local-part macro) is something that one "should avoid". I find it interesting that the precise features RFC 4408 pushed people away from are among the ones we find little uptake for. I think that's at least indicative of the idea that people actually read the RFC and take what it says into account. Scott K From spf2@kitterman.com Thu Jul 19 06:26:27 2012 Return-Path: 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 77F1621F87DD for ; Thu, 19 Jul 2012 06:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599] 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 T9LQ7M6vLfcm for ; Thu, 19 Jul 2012 06:26:26 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6C84921F87D8 for ; Thu, 19 Jul 2012 06:26:26 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 56D9120E4126; Thu, 19 Jul 2012 09:27:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342704439; bh=c39Bg9alwiP51guER5VVS7JMs5uyegRaND0h2Lv0oJ4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KQ9dGY30hvFBUORT5LUxpcpLpxnMEf04E26zQlJfpvH9qsAyKTem5JtC7uZW5JUV+ xC8MHwHUk9SeT7mS/S7NM/n+nZ/2Q6ElN9n53oInf0cW0ZWeCX2qXhf/YqohC3vp4R xPGZkerPkgfDi/g9IR+2auhlzff/xYEJf6Ra1Zcw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3750A20E40E3; Thu, 19 Jul 2012 09:27:19 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Jul 2012 09:27:18 -0400 Message-ID: <2379070.HYkGckbxF8@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5007B71E.3010701@tana.it> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007B71E.3010701@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 13:26:27 -0000 On Thursday, July 19, 2012 09:28:30 AM Alessandro Vesely wrote: ... > In particular, I like Scott's idea to stretch the meaning of "none" in > order to allow (new) implementations to skip processing of some > features. I'm not sure about header fields saying "none", as the > usual interpretation of that is "the sender publishes no record". > Alternatively, they could pretend not to be carrying out any SPF check > --which is already possible, obviously. ... If you aren't implementing all the functionality of the protocol, you aren't performing an SPF check, so some variant of "Decided not to check this one" is correct. I actively don't like my idea, I just think it's slightly better than implementations doing a subset of the specification and then claiming domains that use the parts they chose not to implement are somehow in error. Scott K From ajs@anvilwalrusden.com Thu Jul 19 06:54:06 2012 Return-Path: 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 5F6D221F8709 for ; Thu, 19 Jul 2012 06:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 snsntI8VGXqo for ; Thu, 19 Jul 2012 06:54:05 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C163321F862B for ; Thu, 19 Jul 2012 06:54:04 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id F207D8A031 for ; Thu, 19 Jul 2012 13:54:56 +0000 (UTC) Date: Thu, 19 Jul 2012 09:54:50 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120719135450.GA2193@mail.yitter.info> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <20120719031507.GG1323@crankycanuck.ca> <20120719115430.GB2101@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 13:54:06 -0000 Still hatless. On Thu, Jul 19, 2012 at 06:11:53AM -0700, Murray S. Kucherawy wrote: > If we're going to accept that these are representative samples, then > discovering that the 203 would be willing to adapt to elimination of the > feature also means we have to accept that the same is likely true of those > domains the survey didn't explicitly discover. I think that's false for two reasons. 1. It is one thing to assume that things we look up in the DNS are representative of what DNS operators are doing generally. It is quite another thing to assume that the motivations and trade-offs people have made in configuring their DNS zones that way are also all the same, or that the same considerations would apply uniformly if everyone faced the same stimuli. (In fact, Kenneth Arrow made a name for himself investigating these matters. Cf. Arrow's impossibility theorem. A key insight is that, even if individual preferences are transitive, group preferences are not. Empirically, however, it turns out that individual preferences aren't transitive, either, which has some nasty implications for what we think of as reason. This is rather off topic, though :) ) 2. By contacting the operators of the 203, you give them an advantage that nobody else who is using the features has: you're warning them explicitly. If you ask someone, "Given that we're going to change this, can you adapt?" they automatically know to look for a change. Anyone else who is using these features won't get that warning, and so they will necessarily be affected differently than these 203. (In effect, you are introducing a change to the sample that you aren't introducing to the population, and then concluding that the sample's response to that change is indicative of the population's response. This might be true, but the population doesn't get that change, so it doesn't matter.) In general, the "unused" argument isn't going to work _given our charter_ for the case where we persuade known users to change their minds. Having evidence of use in hand, I think we can't argue "unused", even if we persuade some people to stop using. Let me make a different argument. Perhaps I am being heavily influenced by my experiences in DNS-land. In the DNS community, we simply accept that anything that gets turned on anywhere is something we're going to have to live with for a very long time. When we deprecate something, it takes years to get rid of it. Similarly in this case, 4408 has some features we (or anyway, I) don't like. We know that people are using them. Stating outright that the feature is deprecated is actually _better_ than just removing the feature, because we explicitly interoperate with the code in the wild while yet saying what we think people should be doing. The argument for "just getting rid of" these features leaves us with the problem of what to do when a 4408bis system encounters a 4408 system using these features. We need to say something about that, in my opinion, or we're not doing our job -- and that's true even if we say that systems MUST NOT publish such records and MUST NOT interpret them. I prefer Scott's version of deprecation for this because I think it maximizes interoperability while yet directing people on the right path. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu Jul 19 07:01:49 2012 Return-Path: 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 AA38121F869E for ; Thu, 19 Jul 2012 07:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 SkKt3qoJNdHP for ; Thu, 19 Jul 2012 07:01:49 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4471721F869D for ; Thu, 19 Jul 2012 07:01:49 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E51E08A031 for ; Thu, 19 Jul 2012 14:02:41 +0000 (UTC) Date: Thu, 19 Jul 2012 10:02:39 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120719140239.GB2193@mail.yitter.info> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <50077D2B.4020805@Commerco.Net> <500784A5.9010907@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <500784A5.9010907@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 14:01:49 -0000 No hat. On Wed, Jul 18, 2012 at 11:53:09PM -0400, Hector Santos wrote: > First, more and more SMTP servers are already requiring a PTR for > the connecting client, so this result will already be in server's > DNS resolver cache by the time SPF is checked and processed. Whoa. Some time ago, DNSOP failed to reach consensus on a draft, which died as draft-ietf-dnsop-reverse-mapping-considerations-06. There were plenty of things wrong with that draft (not least of which was the way it became a soggy blancmange in an attempt to address everyone's objections), but one distinction it made that is useful is between _existing_ reverse mapping data and _matching_ reverse mapping data. In my experience, most SMTP servers that are checking for a reverse mapping are in fact checking that there is a reverse mapping entry at all. They are checking for existing reverse data. Many spam-scoring systems also check for match, but a forward-reverse match is _much_ harder to ensure, and that can lead to a high false positive rate. The ptr mechansim in 4408 checks for matching reverse data. This is both a higher bar to leap, and more expensive to process, than a mere existence check. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From SRS0=QKIJm=FU==stuart@gathman.org Thu Jul 19 08:59:52 2012 Return-Path: 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 5397021F873E for ; Thu, 19 Jul 2012 08:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, SARE_SUB_PCT_LETTER=0.784] 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 IwO67fKSpDpn for ; Thu, 19 Jul 2012 08:59:50 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5737A21F871C for ; Thu, 19 Jul 2012 08:59:49 -0700 (PDT) Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=72.209.196.211 (fairfax.gathman.org); auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q6JG0XNk018885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Jul 2012 12:00:34 -0400 Resent-From: Stuart Gathman Resent-To: spfbis@ietf.org Resent-Date: Thu, 19 Jul 2012 12:00:33 -0400 Resent-Message-Id: <50082F21.4010608@gathman.org> Resent-User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 Message-ID: <500791EC.1080205@gathman.org> Date: Thu, 19 Jul 2012 00:49:48 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120712022051.60587.qmail@joyce.lan> <4FFEE210.8040505@dcrocker.net> <1580918.8gPlF2dls6@scott-latitude-e6320> <4FFEE64C.6000308@dcrocker.net> <20120713141719.GE93613@mail.yitter.info> <50006EB2.7040601@dcrocker.net> <20120713200317.GA55459@verdi> <20120716105805.GB96149@mail.yitter.info> <50047A0F.5050907@isdg.net> <6.2.5.6.2.20120716171913.08c8be40@resistor.net> <5005B227.6070803@isdg.net> <6.2.5.6.2.20120717114613.08066c40@resistor.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:02:21 -0000 PTR not needed: One use case of PTR is when a home user is forced to send mail through his ISP, and the ISP provides no SPF record of its own, but the smtp servers all end in "isp.com". A typical SPF record for this situation is "v=spf1 ?ptr:isp.com -all" - which documents plausible origins for the home users personal email domain. How is this accomplished without ptr? PTR is slow and loads arpa servers: MTAs already fetch the PTR records. While you could argue that they shouldn't, as long as they do, PTR is the fastest DNS mechanism in SPF since it is already cached. Wierd chars on %p substitution: Since only a *validated* ptr is substituted, you are guaranteed that the substitution came from a DNS A or AAAA record, and that the receivers DNS machinery was able to look it up. If you are concerned about A/AAAA RRs with strange chars, the standard could require receivers to ignore A and AAAA RRs with strange chars when validating PTR. %p ambiguity: The definition says "validated domain name of " - but there can be more than 1 (up to 10 according to the processing limits). If the choice is arbitrary, this may result in varying SPF result depending on which name is chosen. In practice, though, %p would be used with exists for logging - but still, it is an ambiguity. The definition of %p says "validated name of " - but there can be From johnl@iecc.com Thu Jul 19 09:11:56 2012 Return-Path: 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 6D94D21F87E0 for ; Thu, 19 Jul 2012 09:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.753 X-Spam-Level: X-Spam-Status: No, score=-110.753 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, SARE_SUB_PCT_LETTER=0.784, 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 gk9DXP+7jnw3 for ; Thu, 19 Jul 2012 09:11:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8C421F8770 for ; Thu, 19 Jul 2012 09:11:55 -0700 (PDT) Received: (qmail 67959 invoked from network); 19 Jul 2012 16:12:48 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Jul 2012 16:12:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50083200.xn--9vv.k1207; i=johnl@user.iecc.com; bh=sP3xtE7CFRX7EEng/+xZI0vvfYHFYOwMO6BFVdQtYtA=; b=TwYVAndgUG4X0hixzQxm5xJLN4tqg1ynLFFVkCq7EvcmWemIpfmwWTlp+ZFhpthKr3qDqaCRu25aIvQXh1nhc/vk032ub7z3EUXTmoktDAm78nSCQorpE2ZSRw0oslyDiTmimh8cpvAsfil0Knk9MlKOCKubX5NCeMBS9wpZCb0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50083200.xn--9vv.k1207; olt=johnl@user.iecc.com; bh=sP3xtE7CFRX7EEng/+xZI0vvfYHFYOwMO6BFVdQtYtA=; b=nzJnRztnZ1K3YA63osStFUcRMOsHTwzxrhRlZMYpgNLErtcYWBswWJ7YdSFWD4Yq6xVUpkkRtHvUJoxvFJgzW8QEl4V+4cPT7OotP0LEasw6vJbpLTMer1i7zay07yvocGLMkJ2fxaHYkmmdPE2t4BoR2R3w3IhIcPUpcg06cuc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 19 Jul 2012 16:12:26 -0000 Message-ID: <20120719161226.63420.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <500791EC.1080205@gathman.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: stuart@gathman.org Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:11:56 -0000 >servers all end in "isp.com". A typical SPF record for this situation >is "v=spf1 ?ptr:isp.com -all" - which documents plausible origins for >the home users personal email domain. How is this accomplished without ptr? Everyone I know does it by including the ISP's SPF record. R's, John From spf2@kitterman.com Thu Jul 19 09:27:18 2012 Return-Path: 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 E140421F8624 for ; Thu, 19 Jul 2012 09:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, SARE_SUB_PCT_LETTER=0.784] 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 ldpL8F5a9hZK for ; Thu, 19 Jul 2012 09:27:17 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 45ED321F860B for ; Thu, 19 Jul 2012 09:27:17 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4D13420E4126; Thu, 19 Jul 2012 12:28:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342715290; bh=plvBUgNE6ImQijtrLtFFZ+pbyrGrOBmpR30NlUhNERk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PdMzukcqBvEWok+8vs9fAIPmEQS3BmZUGyCjTC/3yq1DwXJ56phLt1L61wUTzMA7U N//X13nK+TRQybW8PxP5hSX4Lo/hHfAocM8Tq3MXYsni7uT94fbhw0PpXUiCTivULi Ky7e/TG4jkhyZRpj4Q+tbptJ2JTdZSRGJhxVaE6U= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2F6F520E40E3; Thu, 19 Jul 2012 12:28:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Jul 2012 12:28:09 -0400 Message-ID: <1499497.VWKDhNC7j9@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120719161226.63420.qmail@joyce.lan> References: <20120719161226.63420.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:27:18 -0000 On Thursday, July 19, 2012 04:12:26 PM John Levine wrote: > >servers all end in "isp.com". A typical SPF record for this situation > >is "v=spf1 ?ptr:isp.com -all" - which documents plausible origins for > >the home users personal email domain. How is this accomplished without > >ptr? > Everyone I know does it by including the ISP's SPF record. Yes, but he specified the case where the ISP doesn't publish one, so that's not much of a solution. I'm not much of a fan of his solution either. Back in ancient history, when I was stuck in this kind of a situation I sent myself a bunch of mail to an external mailbox, figured out the MTA hostname naming pattern, made use of dig to figure out which names in that pattern existed, and constructed a list of ip4: mechanisms to add to my SPF record. That's not much fun to do, but ultimately produces a much better solution than ptr. Scott K From johnl@iecc.com Thu Jul 19 09:29:27 2012 Return-Path: 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 0C7DD21F86F7 for ; Thu, 19 Jul 2012 09:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.136 X-Spam-Level: X-Spam-Status: No, score=-111.136 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 4HleC2HxSPxJ for ; Thu, 19 Jul 2012 09:29:25 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E1F6421F8575 for ; Thu, 19 Jul 2012 09:29:24 -0700 (PDT) Received: (qmail 70750 invoked from network); 19 Jul 2012 16:30:17 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Jul 2012 16:30:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=50083619.xn--i8sz2z.k1207; i=johnl@user.iecc.com; bh=H2nwNYnVEKXdp5RkjfiOb1JJtG2rfATG6fokA8e38Ew=; b=oE+LkhRnz677y6MmGDlDfyzOHdJ/PCtplT1j7Vv41abTd/iB+SvUhthQ39kek5Ik7sZB/bNPD876jJWDKnRvbr1bQgNS/j9W7/bG0KlTl9sJ/7Dh8Yd1M+qsKHjbYo0SMdgxDVo1+mWbAAiN2EXex91B36bbYFnLNjp4Fl43j3M= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=50083619.xn--i8sz2z.k1207; olt=johnl@user.iecc.com; bh=H2nwNYnVEKXdp5RkjfiOb1JJtG2rfATG6fokA8e38Ew=; b=dz7ZTN8GK2w/oaM6S6/4Ye4slVGU5pfm5/oyhvTmCbaHHjQ15+4/hjQkytFHMyaq1k4ItyBeDN5A+m4Y9cZ8yHQ6mXfI/5moFO4VrepqpIwAb2hbSK6sfzOewyH6lDnn1ZdusLXJK1bwYQMS2KZixljYek/rDISM9xPYhOB+MoE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 19 Jul 2012 16:29:55 -0000 Message-ID: <20120719162955.68199.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:29:27 -0000 We sure are talking past each other here. As far as I can tell, the main disagreement here is what it means for a feature to be unused. Does it mean that nobody uses at all anywhere, or does it mean that the benefit to the small set of people who use it is outweighed by the cost of keeping it in for everyone else. If you look at the history of mail standards, it's quite clear that the working definition is the latter one. If it were the former, we'd still be insisting that SMTP servers support SOML and source routes. With respect to localpart macros, beyond the problem that they're ill specified now, they're a time bomb. If EAI gets significant uptake, which I think is fairly likely in view of the level of interest from Chinese ISPs, we're stuck because there is no way to make them work with EAI -- by design you cannot turn an EAI localpart into a domain name. So the world will thank us if we get rid of them now rather than later. R's, John From spf2@kitterman.com Thu Jul 19 09:39:39 2012 Return-Path: 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 CAC4A21F86EE for ; Thu, 19 Jul 2012 09:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] 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 DxsQAHPZCPFq for ; Thu, 19 Jul 2012 09:39:39 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9F121F87C9 for ; Thu, 19 Jul 2012 09:39:38 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7DDB420E4126; Thu, 19 Jul 2012 12:40:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342716029; bh=7pNBl1SdwTYj9k5OP5C0gVg40HwUENqvCwdbcqQMf14=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cqVLwOjIGMUULDhtGZ5PR2eLcLLLdKNYTbmVg7MjwrX5alM+4TW7ErLCrOGN2YlLq w3LaQxAn4SmS4ag8GRlkCABDmDUGKzWWZa9ELgUyl70/7B9w4nArAWcGG4iTz4mAQ6 ElFk2QXP374ZXk9hjKCaLcxql1UFuSkcASbCEhrQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6428120E40E3; Thu, 19 Jul 2012 12:40:29 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Jul 2012 12:40:28 -0400 Message-ID: <1404184.NWtd9atLfT@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120719162955.68199.qmail@joyce.lan> References: <20120719162955.68199.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:39:40 -0000 On Thursday, July 19, 2012 04:29:55 PM John Levine wrote: ... > With respect to localpart macros, beyond the problem that they're ill > specified now, they're a time bomb. If EAI gets significant uptake, > which I think is fairly likely in view of the level of interest from > Chinese ISPs, we're stuck because there is no way to make them work > with EAI -- by design you cannot turn an EAI localpart into a domain > name. ... Not quite right. Some you can. Some you can't. Saying something like "You can only use EAI local-parts that convert to a legal domain name in local-part macros" means that senders have a choice. This is, admittedly, a more complex solution than removal (but then that's true of everything). It would also lead to, if EIA takes off, local-part macros becoming less useful over time. I don't see that as a problem (making it easy to remove later if we deprecate it now). While I agree that EAI is one of the issues around local-part macros, I don't think it's an issue that can only be resolved through removal. Scott K From ajs@anvilwalrusden.com Thu Jul 19 09:51:20 2012 Return-Path: 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 6952F21F86D9 for ; Thu, 19 Jul 2012 09:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 w5QrOwJJ-4F0 for ; Thu, 19 Jul 2012 09:51:19 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 572B221F86B3 for ; Thu, 19 Jul 2012 09:51:19 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 617318A031 for ; Thu, 19 Jul 2012 16:52:12 +0000 (UTC) Date: Thu, 19 Jul 2012 12:52:10 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120719165210.GJ2231@mail.yitter.info> References: <20120719162955.68199.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120719162955.68199.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:51:20 -0000 Mostly no hat. See inline for exception. On Thu, Jul 19, 2012 at 04:29:55PM -0000, John Levine wrote: > As far as I can tell, the main disagreement here is what it means for > a feature to be unused. Does it mean that nobody uses at all > anywhere, or does it mean that the benefit to the small set of people > who use it is outweighed by the cost of keeping it in for everyone > else. > > If you look at the history of mail standards, it's quite clear that > the working definition is the latter one. If it were the former, we'd > still be insisting that SMTP servers support SOML and source routes. And if you look at the history of DNS, the working definition is very nearly the former. This is even more true in deployed practice than it is in the specifications. Since SPF interacts with both of these systems, appeal to the traditions in one or the other isn't going to help us. And as I've already argued, it seems to me that if one wants to make changes to the protocol for little-used features and ones we think are too complicated, the charter should _say that_ instead of promising something else. If I put my hat on for a moment, either SM or I would have to shepherd this document. We would have to explain to the IESG that, yes, our charter said we wouldn't remove any features we knew to be in use, and yes, we had evidence that these features were sometimes, only rarely, in use by some people; but we decided to ditch them anyway, because we didn't care about those uses and thought they were dumb and decided not to count those people because there were too few of them. As a simple process matter, that's a problem. (Hat off again.) > With respect to localpart macros, beyond the problem that they're ill > specified now, they're a time bomb. […] > with EAI -- by design you cannot turn an EAI localpart into a domain > name. First, the latter claim is flat-out false. DNS labels are octets, period. We could put anything we wanted in there. We could also specify ways of processing SPF records so that they process such UTF-8 data. One might ask why IDNA doesn't use UTF-8. That's because a large amount of the deployed software out there -- consuming software, not the serving software -- can't handle anything outside the ASCII range, and we didn't want the answer for "deploy IDNs" to depend on the step, "Upgrade the Internet." But for the very same reasons EAI decided that the mail case was different to the DNS case, because in email the people affected are already interested parties, we could decide that supporting these rules using UTF-8 in the DNS is acceptable in a way that it wouldn't have been for IDNs. More importantly, however, if the document says that localpart macros are deprecated, then why doesn't that defuse the time bomb anyway? We maximise interoperability with actually deployed software on the Internet today, and yet tell people that this particular feature isn't likely to work forever. I would be perfectly comfortable if the draft included words about how the feature is probably completely broken in the face of some software that might, someday, be widely deployed on the Internet. (I also note that your argument is that we should break interoperation with existing systems known to have been deployed for some time in order that we maybe won't have a problem with software that maybe will be deployed in the future. I think that has the burden of proof wrong.) I've said enough on this topic that I won't post on it again without a hat. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Thu Jul 19 12:37:21 2012 Return-Path: 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 4F46321F8737 for ; Thu, 19 Jul 2012 12:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] 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 KjRh8pnVK2-a for ; Thu, 19 Jul 2012 12:37:20 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 623AD21F8742 for ; Thu, 19 Jul 2012 12:37:20 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C821E20E411E; Thu, 19 Jul 2012 15:38:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342726693; bh=z84HflnCF+olOGT2V01ettHm/7o+oJ5mu99NyBx9m30=; h=From:To:Subject:Date:From; b=FDlq3/oLinm/xIkhs9BQmLgrVe2HRmi0mDSdrVyPjFvbwP4hCoRfVP8CXOsp4/+o/ 4FnUi1LKxBUMvf80oT6eS2DWyzILRzdlDgvG8ddOYM0c6dszeqT98dIHB3sZr4eUG6 qi4FvplGqjjsXXPj4/m2eql4Z3WSWZFKa8nxP0Pk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A954420E408E; Thu, 19 Jul 2012 15:38:13 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 19 Jul 2012 15:38:12 -0400 Message-ID: <3917257.BAkeplDhzE@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Opinon on macros X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 19:37:21 -0000 I was asked offlist what my opinion on macros was and since I took the time to write, it, I thought it was better to be transparent and send it (this is actually very slightly changed, since I realized one thing I wrote before wasn't quite accurate) to the list too. This is not meant to spark a lot of debate (I expect I'll be sadly disappointed about that, please surprise me). What's below is my opinion. It may be wrong, but it is my opinion, so just telling me it's wrong isn't worth your time to write it or my time to read it. I'm certainly open to new facts or ones I've missed, but repetition won't help the ones already on the table. Scott K My understanding of the charter leads me to believe that it is a strong goal for the WG that organizations that have published SPF records or SPF checking software based on RFC 4408 will not HAVE to do anything to interoperate with records and checking software based on 4408bis. I think it's not at all a problem if there are some things they SHOULD do eventually, as long as there are no MUST do's. I think the design goal is 100%. In order to override that goal, it has to be shown that the existing RFC 4408 design is broken and that the only reasonable method of repair will require some change. So far (and I'm always open to new data) the only issue that, in my opinion, has risen to that level is the Type TXT versus Type SPF issue. There isn't ay 100% backward compatible way to solve that issue. Since we established that the very few domains that published Type SPF only records were already experiencing a poor level of interoperation, I think it was quite reasonable for the WG to conclude as it did. Macros are different. There are some potential risks in the RFC 4408 design, but the design is not fundamentally defective (I admit to it being complex, but not more so than it needs to be if SPF is going to have macros). They also support at least one very important use case (the DNS logging SPF record listed in section 9.1) that is does not yet have a well deployed alternative (RFC 6652 or DMARC could replace this in the future, but not today). They can also be useful in exp= modifiers to help return a more specific result. As a result of the lack of clear defects and the legitimate use cases that don't have good alternatives, I think removal is not appropriate. I have no strong objection to deprecation (I don't agree it's necessary, but I don't think it's unreasonable). If we can make a good push for deployment of 6652 as a deployment validation mechanism and/or DMARC gets standardized as an appropriate solution for SPF feedback/validation (the currently published spec is not) and we give users time to migrate to different approaches, I think it will be appropriate to consider removal, particularly of local-part, in the future. From johnl@iecc.com Thu Jul 19 13:29:33 2012 Return-Path: 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 DB4E721F8634 for ; Thu, 19 Jul 2012 13:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.745 X-Spam-Level: X-Spam-Status: No, score=-110.745 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, SARE_SUB_PCT_LETTER=0.784, 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 la9EVB8N9fQC for ; Thu, 19 Jul 2012 13:29:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2B23B21F86AD for ; Thu, 19 Jul 2012 13:29:31 -0700 (PDT) Received: (qmail 9110 invoked from network); 19 Jul 2012 20:30:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Jul 2012 20:30:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50086e61.xn--i8sz2z.k1207; i=johnl@user.iecc.com; bh=wp3dP/v70m09Uqr6I+6gMRHRqmsUQhQTE/VL7j14xTg=; b=OI0fvvf7eitW/YD4BcGkPceuGiqQ/KdFFBwys/m+BnHKsPZPnH7R/vYRAQeGSU13J0LVPHQIwmMeip0I330HMwqKUC7krHi2JWCzBDkpmR0Egzf0i77PxcoABeo7hScQBllNtSjOu2vJ4ToUYxeRk5edPq6bb3O0mCYSRKevtpA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50086e61.xn--i8sz2z.k1207; olt=johnl@user.iecc.com; bh=wp3dP/v70m09Uqr6I+6gMRHRqmsUQhQTE/VL7j14xTg=; b=D7+fNz6adSLkKPCJJTbpmo1SDc/6CakJC6TpQP5kx8Ul/9779Tmjnzb3aIDIdLLsThBQ6IcY+xhYx16pqfTgQ4+h7EHpHoz1Phy5IVoH0k/QDjnNhzlvipTM4nvHGg5FZQPbadqtN5VztVoySTLV+4d2G5L+isNKqm3W7vZDLm4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 19 Jul 2012 20:30:03 -0000 Message-ID: <20120719203003.94069.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1499497.VWKDhNC7j9@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] PTR vs %p - Consider it as a BCP item X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:29:34 -0000 >Back in ancient history, when I was stuck in this kind of a situation I sent >myself a bunch of mail to an external mailbox, figured out the MTA hostname >naming pattern, made use of dig to figure out which names in that pattern >existed, and constructed a list of ip4: mechanisms to add to my SPF record. >That's not much fun to do, but ultimately produces a much better solution than >ptr. Makes sense. Beyond some point, it's not your correspondents' job to help work around your lousy configuration. R's, John From johnl@iecc.com Thu Jul 19 13:42:34 2012 Return-Path: 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 50A8521F8646 for ; Thu, 19 Jul 2012 13:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.129 X-Spam-Level: X-Spam-Status: No, score=-111.129 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 k-pN8upiVt4j for ; Thu, 19 Jul 2012 13:42:33 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2208C21F8634 for ; Thu, 19 Jul 2012 13:42:32 -0700 (PDT) Received: (qmail 11177 invoked from network); 19 Jul 2012 20:43:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Jul 2012 20:43:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5008716d.xn--30v786c.k1207; i=johnl@user.iecc.com; bh=goxwlKLtYsgA3AYEZKPyJjkQErn2Uv9VYKygiZhlyZY=; b=mwiM0lsB0JmPYdqMEVG2GZ05eVPYmCY3kQJmDXTAvz7Fp2n1tZRRPSH2OQBVSECEkoGnxKmKSHPSD2SWYXwHTeOzX+RJSSpCfKOt4tzgasmyMjf83CRyUwjIENj0l2jbUUc12E5Mk3C/TdT3mnd++DSZRxrJMFkwwIPtULE6BwU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5008716d.xn--30v786c.k1207; olt=johnl@user.iecc.com; bh=goxwlKLtYsgA3AYEZKPyJjkQErn2Uv9VYKygiZhlyZY=; b=D6RpaFBm2XASwFsqrnLjp8q/gYSMnJ4i7/R5OrdwWFfHxiO5Kdw1fMC7JMvhJ5/CEjpslH8m78B4U08pLxEG5/kWFBBfCBcaHGZsX7BeE8Fpvp7tu7o6ls02RSyyk2dtU7gMZRy8RUyeY8sFRr3s+ysCTxYG78uP/ldJjijiUnY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 19 Jul 2012 20:43:03 -0000 Message-ID: <20120719204303.97623.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20120719165210.GJ2231@mail.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ajs@anvilwalrusden.com Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:42:34 -0000 >More importantly, however, if the document says that localpart macros >are deprecated, then why doesn't that defuse the time bomb anyway? That doesn't address the security issues. I think you're schrod with the IESG either way. R's, John PS: If someone suggests that we should tidy up localpart macros to tell servers to defend against localparts with spaces and backslashes and ampersands, we will of course jump up and down and demand that you prove that nobody uses addresses with those characters. PPS: With respect to DNS history, it's not all upward compatible. The restriction of host names to ldh probably broke some names with other punctuation. From dhc@dcrocker.net Thu Jul 19 15:08:01 2012 Return-Path: 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 ACC4821F85F3 for ; Thu, 19 Jul 2012 15:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 RrcoGH1zjhAs for ; Thu, 19 Jul 2012 15:08:00 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CC01321F85F4 for ; Thu, 19 Jul 2012 15:08:00 -0700 (PDT) Received: from [172.19.80.106] (64.125.189.90.t00817-23.above.net [64.125.189.90] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6JM8qO3019815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Jul 2012 15:08:53 -0700 Message-ID: <50088570.5010207@dcrocker.net> Date: Thu, 19 Jul 2012 15:08:48 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Andrew Sullivan References: <20120719162955.68199.qmail@joyce.lan> <20120719165210.GJ2231@mail.yitter.info> In-Reply-To: <20120719165210.GJ2231@mail.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 19 Jul 2012 15:08:53 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 22:08:01 -0000 Andrew, On 7/19/2012 9:52 AM, Andrew Sullivan wrote: > Mostly no hat. See inline for exception. > > On Thu, Jul 19, 2012 at 04:29:55PM -0000, John Levine wrote: >> As far as I can tell, the main disagreement here is what it means for >> a feature to be unused. Does it mean that nobody uses at all >> anywhere, or does it mean that the benefit to the small set of people >> who use it is outweighed by the cost of keeping it in for everyone >> else. >> >> If you look at the history of mail standards, it's quite clear that >> the working definition is the latter one. If it were the former, we'd >> still be insisting that SMTP servers support SOML and source routes. > > And if you look at the history of DNS, the working definition is very > nearly the former. For example, SMTP clients are still required to process the earlier alternatives to the DNS' MX RR? Also, are you saying that the incremental, Internet-wide/systemic cost of that retention is comparable to support for SPF macros? > This is even more true in deployed practice than > it is in the specifications. An issue with something like macros is that it can't be ignored. It affects the core, receiver-side SPF engine. This makes macros fundamentally more expensive, system-wide, than an RR feature falling out of use. If a receiver plays SPF, it /must/ support that component of it. > appeal to the traditions in one or the other isn't going to > help us. The point being made was not about "tradition" but of an interpretation for the word "unused". The example provided demonstrates an existence proof for deciding that it does /not/ require using a definition employing mathematical zero. Some of us are used to this looser definition; indeed it has a long history in the IETF. That some of us choose the tighter definition justifies a debate between the two positions, rather than automatically requiring that the tighter definition apply to the SPFbis effort. That someone at some time might have required mathematical zero usage for some specification is not the point. The point is that there is plenty of IETF precedence for permitting the definition to be "great than zero". Also, there is a difference between determining whether a feature has gained traction, versus deciding how to handle ones that have not. Debating the definition of 'unused' is the former, not the latter. >> With respect to localpart macros, beyond the problem that they're ill >> specified now, they're a time bomb. > […] >> with EAI -- by design you cannot turn an EAI localpart into a domain >> name. > > First, the latter claim is flat-out false. DNS labels are octets, > period. We could put anything we wanted in there. Hostnames are not pure octets. > We could also > specify ways of processing SPF records so that they process such UTF-8 > data. Now you appear to be describing a significant enhancement to the SPF specification and it is in anticipation of established practice for dealing with UTF-8 in domain names, rather than after the practice is established. > One might ask why IDNA doesn't use UTF-8. That's because a large > amount of the deployed software out there -- consuming software, not > the serving software -- can't handle anything outside the ASCII range, > and we didn't want the answer for "deploy IDNs" to depend on the step, > "Upgrade the Internet." It's probably better not to pursue the topic of why (or even what) things have been done in the IDN or EAI space. That space has a very long and very messy history -- up through the present -- and touching that tar baby is very likely to get us stuck in its muck. > > But for the very same reasons EAI decided that the mail case was > different to the DNS case, because in email the people affected are > already interested parties, we could decide that supporting these > rules using UTF-8 in the DNS is acceptable in a way that it wouldn't > have been for IDNs. And how exactly does this fit within the current working group charter? > More importantly, however, if the document says that localpart macros > are deprecated, then why doesn't that defuse the time bomb anyway? It retains support for macros. There is cost in that retention, including an argument for later problems. It also invites interaction between macros and any emerging EAI usage. > We > maximise interoperability with actually deployed software on the > Internet today, and yet tell people that this particular feature isn't > likely to work forever. Because it is going to be easier to drop it when moving from Proposed to Full than it is now, going from Experimental to Proposed? > I would be perfectly comfortable if the draft > included words about how the feature is probably completely broken in > the face of some software that might, someday, be widely deployed on > the Internet. Offhand, I'd expect text like that in a specification to be considered rather odd, at best. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From vesely@tana.it Fri Jul 20 08:54:55 2012 Return-Path: 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 1D6B621F861B for ; Fri, 20 Jul 2012 08:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.629 X-Spam-Level: X-Spam-Status: No, score=-4.629 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 x3zPVbjOwjtn for ; Fri, 20 Jul 2012 08:54:54 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2900C21F8617 for ; Fri, 20 Jul 2012 08:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342799747; bh=FlRtE7hsXtAWG/398fdxwy6a/IvinfiDe51C6OL/nEQ=; l=3876; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=NfRTKplj1UrqfMdKIR8vKnCMz3ADo6A3Oci7QLZlcTY8/Xt2NE5eH7lpghgbLfYgr fkjBn9aBRPC71nEAWxjbMDGKwXahK0Z/may2bAJTk488VW39jPKACjWEs/R0jPmXYa s/QsI9qYyyXwSRcfP00tSnYA0b7ppHrHDP3JL6ac= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 20 Jul 2012 17:55:47 +0200 id 00000000005DC033.0000000050097F83.00005F90 Message-ID: <50097F83.7010902@tana.it> Date: Fri, 20 Jul 2012 17:55:47 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Dave Crocker , Andrew Sullivan References: <20120719162955.68199.qmail@joyce.lan> <20120719165210.GJ2231@mail.yitter.info> <50088570.5010207@dcrocker.net> In-Reply-To: <50088570.5010207@dcrocker.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 15:54:55 -0000 Please let mi chime in. As Andrew said he'll reply on this subject wearing his hat, I'd like that to be a successful call for consensus. On Fri 20/Jul/2012 00:08:48 +0200 Dave Crocker wrote: > On 7/19/2012 9:52 AM, Andrew Sullivan wrote: > > An issue with something like macros is that it can't be ignored. It > affects the core, receiver-side SPF engine. This makes macros > fundamentally more expensive, system-wide, than an RR feature falling > out of use. If a receiver plays SPF, it /must/ support that component > of it. As Scott said, a receiver who plays SPFbis MAY want to omit SPF checking for that particular record. If the claim that those dangerous macros are unused is correct, that is a holdable choice for new or upgraded implementations. OTOH, older software and records can continue to work undisturbed and still be compliant, which is a good interpretation of "backward compatibility". >> […] >> We could also specify ways of processing SPF records so that they >> process such UTF-8 data. > > Now you appear to be describing a significant enhancement to the SPF > specification and it is in anticipation of established practice for > dealing with UTF-8 in domain names, rather than after the practice is > established. EAI is now a proposed standard, so it would be an error not to consider the possibility of UTF-8 names. draft-ellermann-spf-eai was first written in 2008, so this is not exactly a new feature. OTOH, removing local-part macros will not disallow UTF-8 in domain names. >> But for the very same reasons EAI decided that the mail case was >> different to the DNS case, because in email the people affected are >> already interested parties, we could decide that supporting these >> rules using UTF-8 in the DNS is acceptable in a way that it wouldn't >> have been for IDNs. > > And how exactly does this fit within the current working group charter? Could we pass it as an error correction? It does look like a due upgrade to me. >> More importantly, however, if the document says that localpart macros >> are deprecated, then why doesn't that defuse the time bomb anyway? > > It retains support for macros. There is cost in that retention, > including an argument for later problems. See above for verifiers that omit checking in case a record contains unused features. Of course, we cannot force existing software to upgrade immediately. > It also invites interaction between macros and any emerging EAI > usage. For some of Dave's reasons that I didn't quote, I'd avoid linking macro removal to EAI issues. Sanitizing labels before looking them up has to be done also for US-ASCII names. >> We maximise interoperability with actually deployed software on >> the Internet today, and yet tell people that this particular >> feature isn't likely to work forever. Moreover, deprecated features may gradually stop working as upgraded verifiers drop support of macros. Developers may choose between security costs and support for unused features. That's the essence of the compromise that Scott proposed[1&2]. Like him, I'm not enthusiast of this solution, but that's the nature of compromises. [1] http://www.ietf.org/mail-archive/web/spfbis/current/msg01922.html [2] http://www.ietf.org/mail-archive/web/spfbis/current/msg01940.html > Because it is going to be easier to drop it when moving from Proposed > to Full than it is now, going from Experimental to Proposed? Hm... will that be in 2021? And if that will use some SPF3 RRTYPE, possibly binary encoded, it will have to be recycled at Proposed. That's OT here, except for considering that 8 years from 4408 to 4408bis are such a long time already that giving up this charter because we fear the cost of Chinese macro expansion is probably not the best service we can do to the IETF :-/ From spf2@kitterman.com Fri Jul 20 10:04:52 2012 Return-Path: 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 4E51321F85E3 for ; Fri, 20 Jul 2012 10:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] 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 fJaim1iA2uiT for ; Fri, 20 Jul 2012 10:04:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1F521F85DF for ; Fri, 20 Jul 2012 10:04:51 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 56C9C20E411E; Fri, 20 Jul 2012 13:05:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342803947; bh=t4vlTl7eCvt5k4nIXhv5A1FRMdEJyRoOshgiuUHasF8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jTWcdU5fO86tW3wNYfjmS+MZ0kUNtPdCcD0C/1VCjQkSgxplcJIW5YSmP5ytG4PbQ TLBDAWTyfS4YrWxJEucSomB7PCe+CndWzhzWVK4/DIM0HMxhdSeskdDm0gXt00uFEp bnidyEip4FV061kdmUYGSLjYDHNptAZ79XqN7K6s= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3BDA420E4064; Fri, 20 Jul 2012 13:05:47 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 20 Jul 2012 13:05:43 -0400 Message-ID: <4493351.o1zlKi289H@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50097F83.7010902@tana.it> References: <20120719162955.68199.qmail@joyce.lan> <50088570.5010207@dcrocker.net> <50097F83.7010902@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 17:04:52 -0000 On Friday, July 20, 2012 05:55:47 PM Alessandro Vesely wrote: > As Scott said, a receiver who plays SPFbis MAY want to omit SPF > checking for that particular record. If the claim that those > dangerous macros are unused is correct, that is a holdable choice for > new or upgraded implementations. OTOH, older software and records can > continue to work undisturbed and still be compliant, which is a good > interpretation of "backward compatibility". Note: I didn't say I thought this was a good idea. I don't. I merely think it's better than partial implementations of the protocol issuing errors for things that are valid, but they've chosen not to implement. Scott K From wwwrun@rfc-editor.org Fri Jul 20 10:12:44 2012 Return-Path: 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 8FFA211E80C7; Fri, 20 Jul 2012 10:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.253 X-Spam-Level: X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 X11j8nr4Xr6R; Fri, 20 Jul 2012 10:12:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id EEAD711E80C9; Fri, 20 Jul 2012 10:12:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0520CB1E005; Fri, 20 Jul 2012 10:12:58 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120720171258.0520CB1E005@rfc-editor.org> Date: Fri, 20 Jul 2012 10:12:58 -0700 (PDT) Cc: spfbis@ietf.org, rfc-editor@rfc-editor.org Subject: [spfbis] RFC 6686 on Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 17:12:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6686 Title: Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments Author: M. Kucherawy Status: Informational Stream: IETF Date: July 2012 Mailbox: superuser@gmail.com Pages: 12 Characters: 26421 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-spfbis-experiment-11.txt URL: http://www.rfc-editor.org/rfc/rfc6686.txt In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (SPF) and Sender ID: two proposed email authentication protocols. Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required all of these documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) to be published as Experimental RFCs and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the SPF Update Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From hsantos@isdg.net Fri Jul 20 10:50:54 2012 Return-Path: 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 E5C7E21F867E for ; Fri, 20 Jul 2012 10:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.122 X-Spam-Level: X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 4io4wafJ8Xcg for ; Fri, 20 Jul 2012 10:50:52 -0700 (PDT) Received: from ftp.catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A4CAF21F8680 for ; Fri, 20 Jul 2012 10:50:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1918; t=1342806697; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=/+zBDxYslte2VnH1m70uY8lJ7C0=; b=vdkkC5J5a69tePzdYPhq +V5mzoPoH5Nmi1FhNrUTaHvhZEtEHg7yV2E/lkEJNULQvyupmkQTbtjsWKl0DiIf I7xWqL7WkHHhhN0SVOSPzvWsDvJuz/XopEgbmVDIQjVA6oBtMnli9vV9XHOIiDCz MmNhobCxMwlBdJwhtWQBGKE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 20 Jul 2012 13:51:37 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3123494692.19142.4736; Fri, 20 Jul 2012 13:51:36 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1918; t=1342806562; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=VcoZIAi til02V4q3z2s/ajNaAh67oHh/1kqHRyf/ceE=; b=u72GIKhZx+n07Warr679qxf +mrtLCwk1j08MSAdVdFm+eRYAKezP0fEpxXoC9t0GeQHjj8ZDatTdHu/rRxRNFCW ovkqG3p3hyNs80XXplWbNPYSIaHPdKmPQ5+zJBbmyuBVMPYJ40jGzRebkSvYhXJO nhjD67NDTuow9mEEAaaw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 20 Jul 2012 13:49:21 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3722326691.9.6000; Fri, 20 Jul 2012 13:49:20 -0400 Message-ID: <50099AF7.8000204@isdg.net> Date: Fri, 20 Jul 2012 13:52:55 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <20120719162955.68199.qmail@joyce.lan> <50088570.5010207@dcrocker.net> <50097F83.7010902@tana.it> <4493351.o1zlKi289H@scott-latitude-e6320> In-Reply-To: <4493351.o1zlKi289H@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 17:50:55 -0000 Scott Kitterman wrote: > On Friday, July 20, 2012 05:55:47 PM Alessandro Vesely wrote: >> As Scott said, a receiver who plays SPFbis MAY want to omit SPF >> checking for that particular record. If the claim that those >> dangerous macros are unused is correct, that is a holdable choice for >> new or upgraded implementations. OTOH, older software and records can >> continue to work undisturbed and still be compliant, which is a good >> interpretation of "backward compatibility". > > Note: I didn't say I thought this was a good idea. I don't. I merely think > it's better than partial implementations of the protocol issuing errors for > things that are valid, but they've chosen not to implement. If I read this correct, then this a broken protocol by BIS design which is not what BIS is suppose to be about. IMTO, we should spit the issues up. PTR vs %p are two different things. PTR is used, %p is rare. Alternatively, if the ITCH is that big to have deprecated, removed, obsolete features, then do a SPF3.0 but do it properly so there is logic backward and upward path for both: v=spf1 continues supporting PTR, %p v=spf3 does not support PTR, %p and whatever else you wish to strip. You're text describing v=spfX can simply note what 3.0 does not offers and this allows new developers to decide. But an graceful error will be needed for a v=spf3 receiver seeing an PTR, which to me, means "I don't support SPF" for the session. But of the v=spf3 receiver wants to support v=spf1 features, he could - it would have a wider coverage. The current v=spf1 receiver can now take his sweet time to add support for v=spf3 which in this case, itn't much because it already supports PTR. If other good things are added, this also gives SPF3.0 some payoff and incentive for other to support this version. Nothing breaks which is what is bring proposed now. -- HLS From sm@elandsys.com Fri Jul 20 12:13:26 2012 Return-Path: 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 6B94D21F8505 for ; Fri, 20 Jul 2012 12:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 hfhCp4lJHpGv for ; Fri, 20 Jul 2012 12:13:24 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F8F21F84FE for ; Fri, 20 Jul 2012 12:13:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.14]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6KJE4So026750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jul 2012 12:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342811656; bh=f0AWk1pzJGfmCc8iLeOL0UMYfLYtIHQ/BCvLPmyrvgM=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=sxwYFWjXpzGXO0G/qzh9KaPo79jP3pYywYYs7oajq01LwWn887O3/Xc4pFqYBl2mk TRn0KB4IjPnKzKcnsG9JpG4ESVova/2vFZP4BTGyk+q4rNOnJ7wqxnLL0NCCUYHkel OtHhaiGMvNvZU+i/TZXhMV0+1GZ62htPrxOzZPu4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342811656; i=@elandsys.com; bh=f0AWk1pzJGfmCc8iLeOL0UMYfLYtIHQ/BCvLPmyrvgM=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=sHR/LEb2HKyHrXfCjr6YqLuuHEcIfw+N73wcEM+2bntK6rxCPKvJlGDoBau25uBlD 4lp5EoImVBPE41B2X3HLLpvbYgTGesDI6or6O2oXpy72xPR1uisIQWKaKEBl4Gx80V WU1YKVmJn6AWDDC+DWryjV+iz/GhwAb+3lK2KGb4= Message-Id: <6.2.5.6.2.20120720113142.0a63a6f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 20 Jul 2012 12:03:51 -0700 To: "Murray S. Kucherawy" , spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120720171258.0520CB1E005@rfc-editor.org> References: <20120720171258.0520CB1E005@rfc-editor.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] RFC 6686 on Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 19:13:26 -0000 At 10:12 20-07-2012, rfc-editor@rfc-editor.org wrote: >A new Request for Comments is now available in online RFC libraries. > > > RFC 6686 > > Title: Resolution of the Sender Policy > Framework (SPF) and Sender ID Experiments > Author: M. Kucherawy > Status: Informational > Stream: IETF I would like to thank Murray for the time and effort in getting RFC 6686 published. I would also like to thank everyone in the SPFBIS WG who reviewed and commented on the document. Regards S. Moonesamy (as document shepherd) P.S. Most of you have seen the trick of the rabbit and the hat. There can be accidents, for example, pulling the rabbit from the hat and letting it loose. Everyone watches the rabbit instead of the hat. :-) From sm@elandsys.com Sat Jul 21 04:27:20 2012 Return-Path: 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 324B321F86A3 for ; Sat, 21 Jul 2012 04:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 4ia7sKM8oxEk for ; Sat, 21 Jul 2012 04:27:17 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5ED321F8694 for ; Sat, 21 Jul 2012 04:27:17 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.242]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6LBS2mC002332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Jul 2012 04:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342870094; bh=Uz1vlr9ZpFh4IE8ekrUrL+luTCdaQirNIdBbuCB2z1A=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=MPL4jHf96zhQPTeQGmcsSDhUqRdVOQN/FpAi0awj0MskLkAdMyF6qMEnwMQy2xhkq aL7ula2GocUZkHbi4uJcAqHqCuJNnGNkV0BBNQKculImH+u67WmVKapMYA7M+0pVHK x2iXIBWHcorpli/SGWR6B1w79XjVs9M8MiKW4BAI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1342870094; i=@elandsys.com; bh=Uz1vlr9ZpFh4IE8ekrUrL+luTCdaQirNIdBbuCB2z1A=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=cIAu6HdUS3FFhonKMv6cb/Abp13tyIl6L/p85R//0uQiq/0d6BMvxKEWOv92uERTi QbZf1lkvjZq91By2QRdoj9Fm6xwYoRpNpB1y1EM5V5f9ZSevajQA4Qycbwmtg0cJXN cr6XenGh0a4eW4EAdp/6w0aECCHROgQmenzCZN8Q= Message-Id: <6.2.5.6.2.20120721004529.0a666138@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 21 Jul 2012 03:50:33 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <50099AF7.8000204@isdg.net> References: <20120719162955.68199.qmail@joyce.lan> <50088570.5010207@dcrocker.net> <50097F83.7010902@tana.it> <4493351.o1zlKi289H@scott-latitude-e6320> <50099AF7.8000204@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 11:27:20 -0000 Hello, Here is a rough summary of this thread. John Levine mentioned that "the main disagreement here is what it means for a feature to be unused. Does it mean that nobody uses at all anywhere, or does it mean that the benefit to the small set of people who use it is outweighed by the cost of keeping it in for everyone else. If you look at the history of mail standards, it's quite clear that the working definition is the latter one" [1]. Andrew Sullivan commented that "and if you look at the history of DNS, the working definition is very nearly the former. This is even more true in deployed practice than it is in the specifications. Since SPF interacts with both of these systems, appeal to the traditions in one or the other isn't going to help us" [2]. Dave Crocker mentioned that 'The point being made was not about "tradition" but of an interpretation for the word "unused". The example provided demonstrates an existence proof for deciding that it does /not/ require using a definition employing mathematical zero. Some of us are used to this looser definition; indeed it has a long history in the IETF. That some of us choose the tighter definition justifies a debate between the two positions, rather than automatically requiring that the tighter definition apply to the SPFbis effort. That someone at some time might have required mathematical zero usage for some specification is not the point. The point is that there is plenty of IETF precedence for permitting the definition to be "great than zero". Also, there is a difference between determining whether a feature has gained traction, versus deciding how to handle ones that have not. Debating the definition of 'unused' is the former, not the latter' [3]. Alessandro Vesely commented that "developers may choose between security costs and support for unused features" [4]. My comment is that the problem being discussed is the following in the SPFBIS charter: "Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language." There is a message [5] and some comments on other threads about "deprecated" not being the same as "removal". The bone of contention is the "removal of unused features" in the paragraph quoted above. So what's my opinion about the meaning of "unused"? I would go for simple; it's not used. You would ask me whether it is zero. I would say that it is unlikely that it is zero. My opinion about the meaning of the word does not matter. What matters is that the WG may decide to remove unused features and the WG Chairs might say that's not what it was chartered to do. In my opinion it is not worth going there if there may be a way to resolve the problem. I don't know what that way is. I would not use any of the above arguments, whether for or against, in an explanation to an Area Director or an IETF participant during the Last Call. This is more about spending less energy to achieve the same outcome. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg01946.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg01948.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg01952.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg01953.html 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg01874.html From vesely@tana.it Sat Jul 21 04:27:20 2012 Return-Path: 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 7F9FD21F8694 for ; Sat, 21 Jul 2012 04:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.731 X-Spam-Level: X-Spam-Status: No, score=-3.731 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_37=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] 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 dimiVXnAWkFU for ; Sat, 21 Jul 2012 04:27:19 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2E77321F8698 for ; Sat, 21 Jul 2012 04:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1342870096; bh=zjtAuzP3GIdFxKA7ZgCu6fnqn35emJd1GwN+m34PMgo=; l=4462; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ar5eMUGKveyDzNbFfnZLawMNkARo2uvvzt/l1bYAvVxK2C/LN+z4KMPNNqu4aipFF 1w8k0kUPUwauHr9Fk5tx+WjwwayB5/oViOcQ3rb63Dsp75Mutaqnl+SEdP4Tv4p6+3 OFDpdH0SwcEuMwegAVZrGUpZpWpSGyrpzZCRgVdQ= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 21 Jul 2012 13:28:16 +0200 id 00000000005DC03F.00000000500A9250.00006452 Message-ID: <500A9250.1090709@tana.it> Date: Sat, 21 Jul 2012 13:28:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120719162955.68199.qmail@joyce.lan> <50088570.5010207@dcrocker.net> <50097F83.7010902@tana.it> <4493351.o1zlKi289H@scott-latitude-e6320> <50099AF7.8000204@isdg.net> In-Reply-To: <50099AF7.8000204@isdg.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 11:27:20 -0000 On Fri 20/Jul/2012 19:52:55 +0200 Hector Santos wrote: > Scott Kitterman wrote: >> On Friday, July 20, 2012 05:55:47 PM Alessandro Vesely wrote: >>> As Scott said, a receiver who plays SPFbis MAY want to omit >>> SPF checking for that particular record. If the claim that >>> those dangerous macros are unused is correct, that is a >>> holdable choice for new or upgraded implementations. OTOH, >>> older software and records can continue to work undisturbed and >>> still be compliant, which is a good interpretation of "backward >>> compatibility". >> >> Note: I didn't say I thought this was a good idea. I don't. I >> merely think it's better than partial implementations of the >> protocol issuing errors for things that are valid, but they've >> chosen not to implement. draft-schlitt-spf-classic-00 discouraged PTR in 2004, so dropping it in 2012 shouldn't come as much of a surprise. > If I read this correct, then this a broken protocol by BIS design > which is not what BIS is suppose to be about. > > IMTO, we should spit the issues up. PTR vs %p are two different > things. PTR is used, %p is rare. I'm unable to guess the meaning of that "T" in "IMTO". True? Tough? Typical? Tergiversatory? > Alternatively, if the ITCH is that big to have deprecated, removed, > obsolete features, then do a SPF3.0 but do it properly so there is > logic backward and upward path for both: > > v=spf1 continues supporting PTR, %p > v=spf3 does not support PTR, %p and whatever else you wish to strip. I don't see how this would help anything, since the publisher doesn't have a say about what SPF version, if any, receivers apply. Let's consider Stuart's example: "v=spf1 ?ptr:isp.com -all". That client wouldn't know what to write in a v=spf3 record, so I'm unable to guess what advantages might result from a version change. More on that example: On Thu 19/Jul/2012 06:49:48 +0200 Stuart Gathman wrote: > the ISP provides no SPF record of its own, but the smtp servers all > end in "isp.com". IMHO, the trick lays in the problem statement: How can one know that all their smtp servers end in "isp.com", given that the most obvious place to make such a statement would be an SPF record? Obviously, ISPs can change host names without notice. How meaningful is that name suffix? RFC 5451 formalizes an "iprev" authentication method, which is similar to the PTR mechanism, but easier to pass, as it doesn't take such name. A receiver who implements both methods could mark a message from that client like so: Authentication-Results: SPFbis.example; iprev=pass policy.iprev=192.0.2.30; spf=neutral smtp.mailfrom=client-of-isp.com Received-SPF: neutral mechanism=ptr client-ip=192.0.2.30 I note that the speculated "isp.com" string is not reported. In case the message is abusive, I wouldn't know where to send a complaint. RFC 5451 doesn't use the term "discouraged", but says: There is some contention regarding the wisdom and reliability of this test. For example, in some regions it can be difficult for this test ever to pass because the practice of arranging to match the forward and reverse DNS is infrequently observed. Therefore, the actual implementation details of how a verifier performs an "iprev" test are not specified here. The verifier MAY report a successful or failed "iprev" test at its discretion having done some kind of check of the validity of the connection's identity using DNS. It is incumbent upon an agent making use of the reported "iprev" result to understand what exactly that particular verifier is attempting to report. Extensive discussion of reverse DNS mapping and its implications can be found in [DNSOP-REVERSE]. In particular, it recommends that applications avoid using this test as a means of authentication or security. Its presence in this memo is not an endorsement, but is merely acknowledgement that the method remains common and provides the means to relay the results of that test. NB: [DNSOP-REVERSE] is the "blancmange" document that Andrew referred in a parallel thread a couple of days ago. An interesting reading, rich of historical details, that document is alas also an example of a topic which can yield not-published-as-an-RFC. There's plenty of different topics to discuss in 4408bis. [DNSOP-REVERSE] http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 From hsantos@isdg.net Sat Jul 21 07:42:15 2012 Return-Path: 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 B429321F860B for ; Sat, 21 Jul 2012 07:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 54MFr9heSCdZ for ; Sat, 21 Jul 2012 07:42:14 -0700 (PDT) Received: from mail.santronics.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C729121F85F4 for ; Sat, 21 Jul 2012 07:42:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3420; t=1342881789; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=giTCsrTY68bSqLBj2+Xysf2D/3w=; b=NrXOyjk7YOk29gC8LnUn q8iMd5Fz4zBCROggp+n7J1Gl+RmXlfRrPGHrSpMU1+zndiMvzGF87rReHCLDijgF YQiyW1lQ+q8rb20Xt3rFyISNgRSBqOqaasKlELrOPMlCKMr2vVNaRK9zBK8I22sH ak9R0BhCqJBs427wrEiqx4s= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 21 Jul 2012 10:43:09 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3198585570.19973.4572; Sat, 21 Jul 2012 10:43:08 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3420; t=1342881656; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Ss34w6l 6H0u0jA2EBMHSYmrrwMJUbxM7LhccULHD6js=; b=RsgiGMomX92CysLVW/1BF69 s4Y98hEoCMkn6KSfGj/wk/OfWaVUg6vjYFDOfYzUkOVW/dJeGFoYqlalURxc+w3A ndnNnXhM2/cmOFPB5gnjPIcBAoRx4Qqv+ZMDxI8GaBDPkZNjLiSrvqfJXCbB06op e4ZJc4h37/Dpij9Wm8tA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 21 Jul 2012 10:40:56 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3797421020.9.1404; Sat, 21 Jul 2012 10:40:54 -0400 Message-ID: <500AC028.9080701@isdg.net> Date: Sat, 21 Jul 2012 10:43:52 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <20120719162955.68199.qmail@joyce.lan> <50088570.5010207@dcrocker.net> <50097F83.7010902@tana.it> <4493351.o1zlKi289H@scott-latitude-e6320> <50099AF7.8000204@isdg.net> <6.2.5.6.2.20120721004529.0a666138@resistor.net> In-Reply-To: <6.2.5.6.2.20120721004529.0a666138@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 14:42:15 -0000 And Hector stated PTR is in heavy use, by his measures of 16-19%. It can posted if so desired. See inline. S Moonesamy wrote: > Hello, > > Here is a rough summary of this thread. > > John Levine mentioned that "the main disagreement here is what it means > for a feature to be unused. Does it mean that nobody uses at all > anywhere, or does it mean that the benefit to the small set of people > who use it is outweighed by the cost of keeping it in for everyone > else. If you look at the history of mail standards, it's quite clear > that the working definition is the latter one" [1]. It is not quit clear and if this was the case in history, you would gave major anti-trust issues, legal issues and what would be quite clear, no one would trust standards any more if businesses were beholding of technocrats making decisions that can cause major chaos. The devil is in the details but it was never as quite clear as it been stated. > Andrew Sullivan commented that "and if you look at the history of DNS, > the working definition is very nearly the former. This is even more > true in deployed practice than it is in the specifications. Since SPF > interacts with both of these systems, appeal to the traditions in one or > the other isn't going to help us" [2]. > Dave Crocker mentioned that 'The point being made was not about > "tradition" but of an interpretation for the word "unused". The example > provided demonstrates an existence proof for deciding that it does /not/ > require using a definition employing mathematical zero. Only one problem - PTR is in heavy used. > Alessandro Vesely commented that "developers may choose between security > costs and support for unused features" [4]. Business also decide on strategic plans and operation and using a standard is one of them. PTR is in used. It is not a unused feature. > My comment is that the problem being discussed is the following in the > SPFBIS charter: > > "Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language." > > There is a message [5] and some comments on other threads about > "deprecated" not being the same as "removal". The bone of contention is > the "removal of unused features" in the paragraph quoted above. So > what's my opinion about the meaning of "unused"? I would go for simple; > it's not used. You would ask me whether it is zero. I would say that > it is unlikely that it is zero. This is unethical for attempting to change the charter that was altered in the beginning for these these very concerns. You can not change the rules of the games in order to get what you want. Besides PTR is in used. > My opinion about the meaning of the word does not matter. What matters > is that the WG may decide to remove unused features and the WG Chairs > might say that's not what it was chartered to do. In my opinion it is > not worth going there if there may be a way to resolve the problem. I > don't know what that way is. I would not use any of the above > arguments, whether for or against, in an explanation to an Area Director > or an IETF participant during the Last Call. This is more about > spending less energy to achieve the same outcome. Surreal. -- HLS From hsantos@isdg.net Sat Jul 21 08:20:19 2012 Return-Path: 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 DF52F21F8577 for ; Sat, 21 Jul 2012 08:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 9hSgenxUBLXF for ; Sat, 21 Jul 2012 08:20:17 -0700 (PDT) Received: from mail.santronics.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4551821F8522 for ; Sat, 21 Jul 2012 08:20:17 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3610; t=1342884069; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=7w0rQLfl1TFuS+5wSh72RAWArv0=; b=IUK87aeTEgeRUbOQL0tE /oj6SJfggnJ7wq0HIOiHTS7LRDwo6BXPuHYLnW402RmzPwieoIs0QNYb3RkvMuk3 /1aMjARjFuKmykJZEy6AfD2NtlqPTJ1hsl4RflT5eBUwSBIT9hQjQDT3rffkZVFq e4dS8Rh55nuwrCCavF/g49k= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 21 Jul 2012 11:21:09 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3200865868.19973.2004; Sat, 21 Jul 2012 11:21:08 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3610; t=1342883933; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=BfmP18k SNZ84Fh+XNHP4D3r+a4AaH4UGaudqKInBMyo=; b=DYI675hyOAX19o84lDuWFMN 7XZW7LuD7DAfpB3ZNX5nZDprJDEQsfSIhXHZTj/rv2CklxkcSpwEJ5MK2d0sQ7Ra vRrt2OFfhtdaYFj+5b2CZCAp3kvGRghpNOhwa+KV/fKqqg3cAE/mjsQKOvsNnKiy JjaW7PofOjKvTRbZ4bYY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 21 Jul 2012 11:18:53 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3799698473.9.1444; Sat, 21 Jul 2012 11:18:52 -0400 Message-ID: <500AC90F.4010309@isdg.net> Date: Sat, 21 Jul 2012 11:21:51 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alessandro Vesely References: <20120719162955.68199.qmail@joyce.lan> <50088570.5010207@dcrocker.net> <50097F83.7010902@tana.it> <4493351.o1zlKi289H@scott-latitude-e6320> <50099AF7.8000204@isdg.net> <500A9250.1090709@tana.it> In-Reply-To: <500A9250.1090709@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 15:20:19 -0000 Alessandro Vesely wrote: > On Fri 20/Jul/2012 19:52:55 +0200 Hector Santos wrote: >>> Note: I didn't say I thought this was a good idea. I don't. I >>> merely think it's better than partial implementations of the >>> protocol issuing errors for things that are valid, but they've >>> chosen not to implement. > > draft-schlitt-spf-classic-00 discouraged PTR in 2004, so dropping it > in 2012 shouldn't come as much of a surprise. If that was the case, then aren't you surprise that is still in use and you still have wizards creating them? OpenSPF.org wizard isn't the only one. Yes it is surprise because the concerns back then was just like it always was for DNS PTR usage in general - it was a highest expense of queries and in an age where bandwidth was lower but increasing, arguably lesser optimized DNS servers, networks, hardware but getting better of course, using PTR was not par for the course, it was discouraged and it didn't take rocket science to know this. Today it is used and the fact the major players and growing among many servers who are following the "market leaders" are using PTR as a requirement for SMTP clients. In 2010, with performance concerns, we finally added support for rDNS in our scripting languages for SMTP operators to use: Aug 2010 Update History Summary: http://www.winserver.com/public/aup/aup453-4.htm#WCSAP That was only done after the market has increasing began to do this, so we "followed" the market place. For the most part, if you want to get "serious" about the "big boys" doing the right thing, having a better DNS cache is a prerequisite, and more so today because of all the DNS related protocols, especially in areas of AVS: CBV RBL SPF DKIM ADSP VBR Did I forget any? And we support all of them. With all these increase amount of DNS related queries and it is now prudent to have an improved cache arrangement. We completed that effort in July 2011: July 2011 Update History Summary: http://www.winserver.com/public/aup/aup454-1.htm#WCDNS In summary, for a large multi-internet hosting application product framework, we consolidated and single source all the DNS queries from all the different components into a single DNS API/local cache layer. With all the different queries for a complete coverage, this is very necessary for all scales. > I'm unable to guess the meaning of that "T" in "IMTO". True? Tough? > Typical? Tergiversatory? oy vey Alessandro. try 'In my Technical Opinion' :) >> v=spf1 continues supporting PTR, %p >> v=spf3 does not support PTR, %p and whatever else you wish to strip. > > I don't see how this would help anything, since the publisher doesn't > have a say about what SPF version, if any, receivers apply. > > ... > Let's > consider Stuart's example: "v=spf1 ?ptr:isp.com -all". That client > wouldn't know what to write in a v=spf3 record, so I'm unable to guess > what advantages might result from a version change. A publisher of v=spf1 with a PTR would only be covered by v=spf1 receivers and by "cross your fingers" v=spf3 receiver sites who want to offer original v=spf1 feature support. This is really not to hard, but is what hard and IMEO borderline unethical is to pull the rug from under the feet of existing businesses and operations with published records where an new "Upgrade SPFBIS" is now promising new developers and also current who follow it, to remove PTR support - their end work of deprecation. I can't believe we are really trying to alter the protocol with this BIS. -- HLS From hsantos@isdg.net Sat Jul 21 13:11:57 2012 Return-Path: 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 A3F7221F8495 for ; Sat, 21 Jul 2012 13:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.297 X-Spam-Level: X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_92=0.6, SARE_HTML_URI_LHOST30=1.666, 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 YZoMulzIw4tP for ; Sat, 21 Jul 2012 13:11:54 -0700 (PDT) Received: from pop3.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0B16221F855D for ; Sat, 21 Jul 2012 13:11:53 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5352; t=1342901569; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=evEeonFXOoOlX3F7pky/f9xgi90=; b=k9FtieFild6VAh4W7Iyh gJGt+4WWqDkJPvT3OeAl6OltfvQyL//5XAIQUt5n9m1Je8+MjlJZv62NVznUHl4I TBoEAgh4oQKaEiMfWMNY49D9IUYUG0v4OWgDWN47vGetDyZTfizB8W10ZMQ1/RLB 3RI3+m6xiri49QhYBDjG6vg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 21 Jul 2012 16:12:49 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3218366092.19973.3936; Sat, 21 Jul 2012 16:12:49 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5352; t=1342901434; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ukI4RxK +j1BNkGansdsZuKgynSSAI7dSmKAkDagS5Vg=; b=jXDf4z4ftzDDyR4W7HMy/oT v59//spDS1tvorzo2/HtF7hMYmnrNOPWv2orhmIZGCrm7TKrGRGwncsrygV3iyPN IF+fIdtCJWhMxsDCPdE001nqnNdgbhKCXY7gLJ0UaJTimqnPnFl4B91GKq6w2TIS BWwPciwKOTpOnINvoHw8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 21 Jul 2012 16:10:34 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3817200348.9.3900; Sat, 21 Jul 2012 16:10:34 -0400 Message-ID: <500B0D6E.10409@isdg.net> Date: Sat, 21 Jul 2012 16:13:34 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120719162955.68199.qmail@joyce.lan> <50088570.5010207@dcrocker.net> <50097F83.7010902@tana.it> <4493351.o1zlKi289H@scott-latitude-e6320> <50099AF7.8000204@isdg.net> <6.2.5.6.2.20120721004529.0a666138@resistor.net> <500AC028.9080701@isdg.net> In-Reply-To: <500AC028.9080701@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: S Moonesamy Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 20:11:57 -0000 Hector Santos wrote: > And Hector stated PTR is in heavy use, by his measures of 16-19%. It > can post [it] if so desired. Back in early April 2012, data was posted by Murray and Philip: http://www.ietf.org/mail-archive/web/spfbis/current/msg01032.html This contained 1/2 million records. The main focus back then was type 99/SPF analysis. Rather than work on my own data (since Murray doesn't honor it anyway, we are "too small" I guess), lets use the data he posted. Imported into MySql, an ad hoc query to search for PTR policies: select distinct domain, data from spfdb where data like "%ptr%" Produced over 42,874 unique domains/data pairs or about 8% of the half million. It covers the big to small boys to the random unknowns out there. Many domains show up twice to reflect two records - one SPF1 and one SPF2.0 (Sender ID Policy). This is real technical and practical field information that the PTR command is in use and it covers all market size segments. I will venture most sites will have a near statistical average all depending on the type of domains they attack. Below I posted a sample of the first 100+ domains from the 42 thousand. I really don't think there is any engineering merit to attempt to deprecate PTR. However, I agree there could be a BIS BCP section to discuss its usage along with others performance factoring deployments such as using INCLUDES at multiple levels. But specifically with PTR, in my SPF engineering opinion there are good engineering recommendations: - Don't use it if you don't need to. - Place it as the last or near last directive. BAD --> v=spf1 ptr a mx [-|~ALL] BETTER --> v=spf1 a mx ptr [-|~ALL] and things of that nature. Regard wizards, there are many SPF wizards out there and I have not checked them all, but all were mostly started using the early OpenSPF wizard model which did include the PTR as part of this "SPF expert system" modeling for creating SPF records. A simple GOOGLE search for: spf wizard will show you it is extensive. We don't have the justification nor the engineering merits of a real problem to consider removing PTR. This will create issues for existing publishers I will venture many have done a "Set it and Forget it" for their SPF policy - we are one of them and I don't have the time nor looking forward to be changing our policies without any real urgency to do so. IMO, we will find many people in the same boat - unless there is a obvious problem, not many are going to change or bother to allocate time/resource to address this come looking at supporting SPFBIS time. I believe there are other more useful, more critical, higher payoff items we can do to make SPFBIS a useful end product. Removing items and breaking the SPF1 is not one of them (again, when there is no technical basis to do so). Thanks PS: Personally I won't like to end my input on this, doctor's orders, and I am hoping using Murray's and I guess Philip's own data is "Good Enough" there is no technical merit to deprecate/remove PTR creating an immediate issue for SPFBIS supporters against all current SPF1 policy holders with an PTR directive. Sample 100 domains with PTR SPF policies, sorted, no searching for "high value" or recognized domains done. Please there is no need to begin a "Domain Quality" debate arguing whether the list "represents" spammers and therefore don't count. 1000gems.com 4ssl.us abbyynews.com abelssoft.de abelssoft.net aceindustries.com acore.org aeecenter.org ahmdirect.com aikema.nl aim.com albawheelsup.com alertsite.com alwayskit.info amazingabsformula.com americanhomeinspectordirectory.com americanstandard.com angeliquedeparis.com annfry.com aol.com apps.jobserve.com artbizcoach.com balinbestdesigns.net bankatfirst.com bankersinsurance.com beallsflorida.com beallsinc.com biddingforgood.org bizx.com blairworldwidehunting.com bombingdragg.com bookit.com bootignite.com broadjam.com brokeragejobs-mail.com buffalospree.com buildcentral.com burns-wilcox.com bustamante.com.ec buyermax.com cabelas.com cadlink.com cdiemail.com celanaeasyweb.net census.gov cesa6.org chartercom.com cheappetes.com cheatcodes.com chicagohopeacademy.org chickenbrickstudios.com claimyourpowernow.com cokesburycommunity.com connectionstosuccess.org coupons.com couponsurfer.com courts.state.ny.us cpmsnewsletter.com creativesocialmedia.org creditrights.org csba.org customercare.publicstorage.com da.org danc.org davidakaminsky.com deflowth.info delong.com dimensioni.net diskeepermail.com docmagic.com docutemp.com drgnewsletters.com easternshoreparent.com easyecm.xerox.com egroups.njscpa.org egroups.nsba.org elderpagesonline.com email.joann.com emailer.scholastic.com enamor.com enews.aeglive.com enews.opticsplanet.com ere.net esellerate.net ethereal.net exfactory.net farmprogress.com fbacchog.com firstmedianc.com ftdreminders.com fulfillmentprocessing.com fullcontactgeek.com gandi.net geeks.com geeks.org golffacility.com golflink.com.au goosync.com govdelivery.com greatamerican.com greencard.by harborfreight22.com harthosp.org hinghamweather.com hjortnesscpa.com hnseek.com hoptoitkidsparties.com hosting.com hotwire-travel.com -- HLS From superuser@gmail.com Sat Jul 21 21:01:39 2012 Return-Path: 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 2FF1E21F84C9 for ; Sat, 21 Jul 2012 21:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Lxb0p5wm5Gmi for ; Sat, 21 Jul 2012 21:01:38 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B971621F84D0 for ; Sat, 21 Jul 2012 21:01:37 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so7230716lbb.31 for ; Sat, 21 Jul 2012 21:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=x75/RR6o16v9BfMB2DKhk2SXj5SftXFlFVbTFl1/GHo=; b=JleBX0eUwtvCVtZW4mpE31MUPBrkqzFh/fn9SgsIohBY/tX+XlRAyFmxdzE7cFmpli ah9T/PXWkeAnGctsILAOlPBVWikMyyPnqwCTJcLFCvp7DWA0k6L31vyvvUN+tkf66fcC tFw5s6VFv7nR0PVtWmCD7FiK0126sbUm+Kyc1ble1XNLePpqDmoNkEQpG+qjrkhNeEMS tgF/gm4Pkv+0gDVNw+hWU/96hBTScgfk8TtZH/E9RIE2lPr53CP7Q4ZNVWWIkcg5Tzld 4NkllIEifld8Q3YytrjaQZa7JEdaie2FL3TdCt9EQCB9C0usWoKdl8REPiZdvZFVG2pX 5BoQ== MIME-Version: 1.0 Received: by 10.152.104.171 with SMTP id gf11mr12048240lab.5.1342929757505; Sat, 21 Jul 2012 21:02:37 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sat, 21 Jul 2012 21:02:37 -0700 (PDT) In-Reply-To: <500B0D6E.10409@isdg.net> References: <20120719162955.68199.qmail@joyce.lan> <50088570.5010207@dcrocker.net> <50097F83.7010902@tana.it> <4493351.o1zlKi289H@scott-latitude-e6320> <50099AF7.8000204@isdg.net> <6.2.5.6.2.20120721004529.0a666138@resistor.net> <500AC028.9080701@isdg.net> <500B0D6E.10409@isdg.net> Date: Sat, 21 Jul 2012 21:02:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: spfbis@ietf.org Content-Type: multipart/alternative; boundary=f46d04083de727896104c563335e Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 04:01:39 -0000 --f46d04083de727896104c563335e Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 21, 2012 at 1:13 PM, Hector Santos wrote: > Hector Santos wrote: > > And Hector stated PTR is in heavy use, by his measures of 16-19%. It can >> post [it] if so desired. >> > > Back in early April 2012, data was posted by Murray and Philip: > > http://www.ietf.org/mail-**archive/web/spfbis/current/**msg01032.html > > This contained 1/2 million records. The main focus back then was type > 99/SPF analysis. > > Rather than work on my own data (since Murray doesn't honor it anyway, we > are "too small" I guess), lets use the data he posted. > That appears not to be the case, since your SUBMITTER data was cited in RFC6686 and you got credit for providing it. I'm happy to honour anyone's data, provided we all get access to it and to a description of the way the survey was done so that anyone else can reproduce the results. As for PTR, you haven't provided any data other than a sentence saying it's in use, which doesn't provide solid evidence. Data others can look at, such as what Philip and I have provided, are really want's needed to prove a point in a working group and to the satisfaction of reviewers and the IESG. It helps if someone independently could repeat what you did and come to the same conclusion. > > Imported into MySql, an ad hoc query to search for PTR policies: > > select distinct domain, data from spfdb > where data like "%ptr%" > > Produced over 42,874 unique domains/data pairs or about 8% of the half > million. It covers the big to small boys to the random unknowns out there. > Many domains show up twice to reflect two records - one SPF1 and one > SPF2.0 (Sender ID Policy). > > It's actually even higher than that. The most recent data set says 284,475 domains surveyed, 154,090 responding with what look like valid SPF records, 54,385 appear to include a "ptr" mechanism. That's 35% of responding domains with valid records, and 19% of all domains. However, the Cisco survey's numbers are 1,000,000, 359,659, 409, 0.11% and 0.004%, respectively. As a reminder, the difference between the two surveys is that the TDP survey includes domains that are actually sending data, pulled from over 20 live mail streams all but one of which is outside of my control, while the Cisco survey is based on Alexa rankings that may or may not reflect what's seen in live mail streams. But I don't think anyone's arguing that PTR is unused. The point is that we believe it shouldn't be used any longer, because it's a bad idea. -MSK --f46d04083de727896104c563335e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jul 21, 2012 at 1:13 PM, Hector Santos <hsantos@isdg.net> wrote:
Hector Santos wrote:

And Hector stated PTR is in heavy use, by his measures of 16-19%. =A0It can= post [it] if so desired.

Back in early April 2012, data was posted by Murray and Philip:

=A0 http://www.ietf.org/mail-archive/web/spfbis= /current/msg01032.html

This contained 1/2 million records. The main focus back then was type 99/SP= F analysis.

Rather than work on my own data (since Murray doesn't honor it anyway, = we are "too small" I guess), lets use the data he posted.

That appears not to be the case, since your SUBMITTER dat= a was cited in RFC6686 and you got credit for providing it.

I'm happy to honour anyone's data, provided we all get access t= o it and to a description of the way the survey was done so that anyone els= e can reproduce the results.=A0 As for PTR, you haven't provided any da= ta other than a sentence saying it's in use, which doesn't provide = solid evidence.=A0 Data others can look at, such as what Philip and I have = provided, are really want's needed to prove a point in a working group = and to the satisfaction of reviewers and the IESG.=A0 It helps if someone i= ndependently could repeat what you did and come to the same conclusion.
=A0

Imported into MySql, an ad hoc query to search for PTR policies:

=A0 select distinct domain, data from spfdb
=A0 =A0 where data like "%ptr%"

Produced over 42,874 unique domains/data pairs or about 8% of the half mill= ion. It =A0covers the big to small boys to the random unknowns out there. = =A0Many domains show up twice to reflect two records - one SPF1 and one SPF= 2.0 (Sender ID Policy).


It's actually even higher than that.=A0 The m= ost recent data set says 284,475 domains surveyed, 154,090 responding with = what look like valid SPF records, 54,385 appear to include a "ptr"= ; mechanism.=A0 That's 35% of responding domains with valid records, an= d 19% of all domains.

However, the Cisco survey's numbers are 1,000,000, 359,659, 409, 0.= 11% and 0.004%, respectively.

As a reminder, the difference between = the two surveys is that the TDP survey includes domains that are actually s= ending data, pulled from over 20 live mail streams all but one of which is = outside of my control, while the Cisco survey is based on Alexa rankings th= at may or may not reflect what's seen in live mail streams.

But I don't think anyone's arguing that PTR is unuse= d.=A0 The point is that we believe it shouldn't be used any longer, bec= ause it's a bad idea.

-MSK
--f46d04083de727896104c563335e-- From superuser@gmail.com Sat Jul 21 21:16:47 2012 Return-Path: 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 40CE321F84D2 for ; Sat, 21 Jul 2012 21:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 DAVB4gAju+07 for ; Sat, 21 Jul 2012 21:16:46 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF00A21F84C8 for ; Sat, 21 Jul 2012 21:16:45 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so7237697lbb.31 for ; Sat, 21 Jul 2012 21:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Htx3g8owmdqeceDyLsdbGJmOyiaBvRRIlDTKqNgSjf4=; b=yhNRitFB6Cyg8Jev9MTxz8xMFS371ZDvyp/m5WLqVZoVKF9HP3aDwnCXgfUqvF/rMR lqJvqmbrxh38SyJOVnS70l64XEQf/uooWKA6+zWsbh6kJz0/Wc5NgSgxajOnEv3XfoP4 zr5YJxpB/aXiQXZ1mTrPJZxcIyZcbwbHcxxj+PyCa1ugcDZtTsB1zpaugfS2TVuE7zH0 DWQ34Fcd+r2dsMGia2t3ceVth9M+w5wbuvaisgf8wkXGYufbVG/gFsIrJZue+NI2eGSc x1/eEjis90BVnqvhKOIrA/zpcBGDkEvsWD98u9hxl/w1eR7gDFEOfglmLY2mPvk0zazh QVwA== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr11860086lab.47.1342930665668; Sat, 21 Jul 2012 21:17:45 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sat, 21 Jul 2012 21:17:45 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> Date: Sat, 21 Jul 2012 21:17:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: spfbis@ietf.org Content-Type: multipart/alternative; boundary=f46d0435c1d248ff5904c563692d Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 04:16:47 -0000 --f46d0435c1d248ff5904c563692d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 6:56 PM, Murray S. Kucherawy wrote: > The TDP survey shows a fraction of a percent using "ptr" or macros. > Mea culpa. I got the first part of this claim wrong. Hector's analysis of my data is roughly right about the PTR data in our survey. There's a nuance of the selection phrase I was using in SQL that I wasn't aware of, which produced a very restricted result. His query was also not quite accurate, but his result is a lot closer to the truth. Others should feel free to download Philip's and my databases to verify these claims for themselves. Again, they are available at http://www.blackops.org/~msk/spfbis. The "live" TDP database is more current than the one available there but only by a relatively small number of records. To be clear: TDP's survey claims about 35% of SPF-aware sites are using "ptr", not a fraction of a percent. However, as I said in another thread, non-use of PTR is not (as I understand it) the basis for lobbying for its deprecation or removal, but rather its very design. -MSK --f46d0435c1d248ff5904c563692d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2012 at 6:56 PM, Murray S. Kucherawy <= superuser@gmail.co= m> wrote:
The TDP survey shows a fraction of a percent using "ptr" or macro= s.

Mea culpa.=A0 I got the first part of this clai= m wrong.

Hector's analysis of my data is roughly right about the= PTR data in our survey.=A0 There's a nuance of the selection phrase I = was using in SQL that I wasn't aware of, which produced a very restrict= ed result.=A0 His query was also not quite accurate, but his result is a lo= t closer to the truth.

Others should feel free to download Philip's and my databases to ve= rify these claims for themselves.=A0 Again, they are available at http://www.blackops.org/~msk/spfbi= s.=A0 The "live" TDP database is more current than the one av= ailable there but only by a relatively small number of records.

To be clear: TDP's survey claims about 35% of SPF-aware sites are u= sing "ptr", not a fraction of a percent.

However, as I sai= d in another thread, non-use of PTR is not (as I understand it) the basis f= or lobbying for its deprecation or removal, but rather its very design.

-MSK
--f46d0435c1d248ff5904c563692d-- From superuser@gmail.com Sat Jul 21 21:24:52 2012 Return-Path: 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 EA9EC21F847C for ; Sat, 21 Jul 2012 21:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 NXcAluKfNNDg for ; Sat, 21 Jul 2012 21:24:52 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1688621F8471 for ; Sat, 21 Jul 2012 21:24:51 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so7241335lbb.31 for ; Sat, 21 Jul 2012 21:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BDbEhGKQzMoGuDjgVFrZDyqwxpMZrxYHvg7vvjeooDQ=; b=A5b4W8F+OnTQln4a36E4cL/6SzMBOw74wmVlHtRhALkmi2DI9U9NCg4BZ+HxfEGPRv yo2qUgQEaNteM4FSg2VOcMMHQLIc7wwi3w+TTNyzY1WS6auZYewPwzLxvOMNjQx0+K53 V7RtRAgz9Vv3p/iJq4oEBH3Kvnu6ofjjkajaPQ4SYayxU6vU+YEYpwmhEtkVgJUy3AXc TNjIeBJwBDv2rdfVbDtD3g9i9VN1jTN7SygxtKUq4GLhQYX1uMDHcvChe3wrbrIVNiXt 0h2O4zYqBBFJAgA8Ksv92o9uWaiD69RC6AmbYCOboTx+YUQ2gwS7Y44Yqm/FPP+7SpOY 2FOw== MIME-Version: 1.0 Received: by 10.152.104.171 with SMTP id gf11mr12094152lab.5.1342931151850; Sat, 21 Jul 2012 21:25:51 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sat, 21 Jul 2012 21:25:51 -0700 (PDT) In-Reply-To: <20120719140239.GB2193@mail.yitter.info> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <50077D2B.4020805@Commerco.Net> <500784A5.9010907@isdg.net> <20120719140239.GB2193@mail.yitter.info> Date: Sat, 21 Jul 2012 21:25:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=f46d04083de7438c1104c5638647 Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 04:24:53 -0000 --f46d04083de7438c1104c5638647 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 19, 2012 at 7:02 AM, Andrew Sullivan wrote: > In my experience, most SMTP servers that are checking for a reverse > mapping are in fact checking that there is a reverse mapping entry at > all. They are checking for existing reverse data. > At least sendmail checks for both. If the matching check fails, it claims the value returned in the PTR payload "may be forged" and logs it as such, and in fact won't inform attached filters of the name it found just to be safe. I don't know about others, though I imagine postfix is the same since it tries to conform to that same filtering API. -MSK --f46d04083de7438c1104c5638647 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 19, 2012 at 7:02 AM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
In my experience, most SMTP servers that are checking for a reverse
mapping are in fact checking that there is a reverse mapping entry at
all. =A0They are checking for existing reverse data.
<= br>At least sendmail checks for both.=A0 If the matching check fails, it cl= aims the value returned in the PTR payload "may be forged" and lo= gs it as such, and in fact won't inform attached filters of the name it= found just to be safe.

I don't know about others, though I imagine postfix is the same sin= ce it tries to conform to that same filtering API.

-MSK

--f46d04083de7438c1104c5638647-- From johnl@iecc.com Sat Jul 21 21:59:56 2012 Return-Path: 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 4961121F84D0 for ; Sat, 21 Jul 2012 21:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.126 X-Spam-Level: X-Spam-Status: No, score=-111.126 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 TI8we7F-ufQX for ; Sat, 21 Jul 2012 21:59:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D6EC621F84C8 for ; Sat, 21 Jul 2012 21:59:54 -0700 (PDT) Received: (qmail 92133 invoked from network); 22 Jul 2012 05:00:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Jul 2012 05:00:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=500b8905.xn--btvx9d.k1207; i=johnl@user.iecc.com; bh=4a4wOVY2lcALUfyYKv4kY78pIrpd4xeH0Wsn7GTYpGI=; b=aOiaG169WlCX6xISRgpTM9z7H1uQIefEqG3KmqLOTKZuJHC7S1jgIrjnGtW11efx5137Nr6yT/46RXxbPdL8rjhezVnVAGtpyk5OUdz8If85fl9D8jMitJfDAiGhS71aVVjyrKvi93bNw7GRhgZPfqbUq0dJKtyxFX5NqIrUgn8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=500b8905.xn--btvx9d.k1207; olt=johnl@user.iecc.com; bh=4a4wOVY2lcALUfyYKv4kY78pIrpd4xeH0Wsn7GTYpGI=; b=sOmzTK0wWzjqQowtsIFDSiKVIHAwqVUBkchQUKRZrj+cJbMV7YmEdW+FDplq8U0k/VFVMpiI22VU4ZVXjpRj6e3pwil59ovHSTR+6s96fZBakntgpz5pxd3EN9jhObVfU03a1vHmBieaEMR1L+QS1WTZKTIthqmvzKrB/LzkaXg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 22 Jul 2012 05:00:31 -0000 Message-ID: <20120722050031.5326.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: superuser@gmail.com Subject: Re: [spfbis] PTR checking, was A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 04:59:56 -0000 >I don't know about others, though I imagine postfix is the same since it >tries to conform to that same filtering API. For those of us running qmail and its many variants, it's optional to check that the rDNS resolves forward to the connecting IP, but my impression is that everyone turns the option on. If the check fails, it doesn't log any name in the Received: line, just the IP. R's, John From hsantos@isdg.net Sat Jul 21 22:58:59 2012 Return-Path: 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 0D23C21F84F6 for ; Sat, 21 Jul 2012 22:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 FvnRmpim3oWb for ; Sat, 21 Jul 2012 22:58:57 -0700 (PDT) Received: from ntbbs.santronics.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEE621F84F4 for ; Sat, 21 Jul 2012 22:58:57 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3672; t=1342936791; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=+W+xIp84BTHNXPbYfjoeqtJMygE=; b=Ge6tC5L7+HymjJb2Ucxj oEddeUWUVKy3oI0AVZlXDIOMjBzklQXSKIWP8IRoaF+5vjfWHE29BJVZdalnU24V SzNTrf9qE9HOJTzFmMjTjF3akVRu/y22dCTUb3GV3eqDGv16tVcv7KC7vEB8Fzlt JB5CmuXoXahHEN8Rl0wAbUI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 22 Jul 2012 01:59:51 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3253586890.20801.4376; Sun, 22 Jul 2012 01:59:50 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3672; t=1342936654; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5Mzz6IF CzTEqsAYoxIkjGOeebjO5Ht7iBXZ7XEeZHTU=; b=BKqj2qntR0kloMc0xmz/xDg LXilojxGfhywJLRFaiQiK2SL2noVhImo9cQRMp7fiyftioKyWFZoLSigJfe7VkrF IM4a5UMgj8haE90q8fr5BePNSC8ZcfXc+6JUSieXwg5ne6reZVJvnqvuhM8ph7Wu iu/AAOXiIKG+bftNsgK8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 22 Jul 2012 01:57:34 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3852419629.9.7112; Sun, 22 Jul 2012 01:57:33 -0400 Message-ID: <500B970B.1070801@isdg.net> Date: Sun, 22 Jul 2012 02:00:43 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120719162955.68199.qmail@joyce.lan> <50088570.5010207@dcrocker.net> <50097F83.7010902@tana.it> <4493351.o1zlKi289H@scott-latitude-e6320> <50099AF7.8000204@isdg.net> <6.2.5.6.2.20120721004529.0a666138@resistor.net> <500AC028.9080701@isdg.net> <500B0D6E.10409@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] What unused means X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 05:58:59 -0000 Murray S. Kucherawy wrote: > > But I don't think anyone's arguing that PTR is unused. The point is that > we believe it shouldn't be used any longer, because it's a bad idea. Thanks. Its much easier to deal with the question based on technical merits. On the unused issue, as a side point and case in point, we could "argue" redirect and exist should be deprecated. Perform a sql query on other commands like the following and I get: include 46,735 redirect 1,202 exist 309 For comparison, ptr 42,874 On system performance related, in my engineering opinion, there is good argument that using redirect, include and exist are also "bad ideas" because they add additional DNS queries and I would suggest good APIs use a recursive functional or class object. That adds stack and memory overhead and to resolve it requires complex non-recursive coding - of course, a piece of cake for the paid computer science major, programmer. But looking at just one domain with multiple DNS query levels: Query1: abc.nc.gov v=spf1 redirect=its.nc.gov Query2: its.nc.goc v=spf1 ip4:149.168.220.0/24 include:spf.securence.com ?all Query3: spf.securence.com v=spf1 ip4:216.17.3.0/24 ip4:204.11.209.64/26 ip4:216.17.14.0/24 ip4:216.17.62.0/24 ip4:216.17.6.0/24 ip4:216.17.63.0/24 ip4:216.17.12.0/24 ip4:216.17.20.0/24 ip4:216.17.24.0/24 ip4:50.93.240.0/22 ip4:216.17.54.0/24 ~all What makes this wasteful is its three potential DNS queries. Its a softfail, be great if it was a hard fail to provide a useful payoff for such a long spf policy. Other similar policies where its not fail (-ALL), its not softfail (~ALL) and end up with a Unknown (?ALL) like gmail.com are very wasteful: query1: gmail.com v=spf1 redirect=_spf.google.com query2: _spf.google.com v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all" Only 2 queries, but it makes it even more wasteful for receivers to process the non-matching result with no value. What makes this worst, is its high spoofing attraction and the volume of gmail.com transactions - this adds to the overhead with there is no payoff for negative results. So in my view, this and many others like it can be also argued as a "Bad Idea" for SPF policies to have these complex, multilevel DNS queries, especially for high value domains who are targets by spoofers, ending up with a neutral or unknown SPF result. I believe we can definitely benefit from a BCP section or even separate document, but SPFBIS can cover it I think. This would be better and productive than debating on what is "unused" or what is considered a bad idea for DNS or the overall system. SPF is a very wasteful protocol and BCP can help BIS lower the waste/overhead. Finally, PTR for SPF and rDNS usage, although we all know it has an overhead, it really depends on how poor the site DNS server arrangement is. Poor = slow, Fast = no problem. It is very popular, like Levine pointed out, for logging purposes. A cache is important to these to address redundancy and IMV, that is why, we know its the "slowest" among the queries, but it has a high utility and purpose. For SPF, I can't speak for others, but for us, its possible that we may temporarily have a xyz.winserver.com subdomain used for some special email purpose. As long as we have an PTR record for its up, we don't have to change our SPF record. So it serves a very useful purpose with no extra SPF DNS maintenance required. -- HLS From spf2@kitterman.com Sat Jul 21 23:01:53 2012 Return-Path: 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 7EB4721F84F4 for ; Sat, 21 Jul 2012 23:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] 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 oZAQmr4gaTN9 for ; Sat, 21 Jul 2012 23:01:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A640B21F84F8 for ; Sat, 21 Jul 2012 23:01:46 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C534A20E411E; Sun, 22 Jul 2012 02:02:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1342936966; bh=J1MyMbiRRtbnCceMlCbIjJnhaipL3wxubPw0t7WiYO8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pBQAXCrRBLJz45kjIo0fixJ+hGDR7xpw6Xf5mUY3t8xVYbOnZSvFScuoWE8VO5pbv qNnal4NNKXNieRgfiXVr/Afm2/9oYs0j/2G1ujF+9c6QREEPcmTyN3su786Or90I6h xzEf//4Bv5Mr1G4IQo6iHF73vkhs71zVszzopDFQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A7F9420E409D; Sun, 22 Jul 2012 02:02:46 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 22 Jul 2012 02:02:43 -0400 Message-ID: <1383950.WIL4qTOrYv@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <20120719140239.GB2193@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 06:01:53 -0000 On Saturday, July 21, 2012 09:25:51 PM Murray S. Kucherawy wrote: > On Thu, Jul 19, 2012 at 7:02 AM, Andrew Sullivan wrote: > > In my experience, most SMTP servers that are checking for a reverse > > mapping are in fact checking that there is a reverse mapping entry at > > all. They are checking for existing reverse data. > > At least sendmail checks for both. If the matching check fails, it claims > the value returned in the PTR payload "may be forged" and logs it as such, > and in fact won't inform attached filters of the name it found just to be > safe. > > I don't know about others, though I imagine postfix is the same since it > tries to conform to that same filtering API. Postfix can reject mail that fails either the existence check or the matching check, depending on how it's configured. It doesn't write unverified PTR names into received headers. Scott K From ajs@anvilwalrusden.com Sun Jul 22 20:08:13 2012 Return-Path: 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 1BDB321F869C for ; Sun, 22 Jul 2012 20:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 QXBk9SZW9US1 for ; Sun, 22 Jul 2012 20:08:12 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A794821F8694 for ; Sun, 22 Jul 2012 20:08:09 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 29EF88A031 for ; Mon, 23 Jul 2012 03:08:08 +0000 (UTC) Date: Sun, 22 Jul 2012 23:08:10 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120723030810.GE6582@crankycanuck.ca> References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <50077D2B.4020805@Commerco.Net> <500784A5.9010907@isdg.net> <20120719140239.GB2193@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 03:08:13 -0000 On Sat, Jul 21, 2012 at 09:25:51PM -0700, Murray S. Kucherawy wrote: > At least sendmail checks for both. If the matching check fails, it claims > the value returned in the PTR payload "may be forged" and logs it as such, > and in fact won't inform attached filters of the name it found just to be > safe. That'll teach me to write quickly. Yes, most servers check for both IME. But in terms of actually rejecting mail, they check for existence. When checking for matches, they generally accept mail with a warning, log message, &c. This is because the matching-reverse test is just too strong, and there's no reason to expect it to work reliably in practice. Or anyway, that's what all the mail people I talked to (when I was working on the dnsop reverse-mapping draft) told me. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From vesely@tana.it Mon Jul 23 02:18:27 2012 Return-Path: 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 F089121F86D4 for ; Mon, 23 Jul 2012 02:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.612 X-Spam-Level: X-Spam-Status: No, score=-4.612 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 iLLU0dH4Jzj2 for ; Mon, 23 Jul 2012 02:18:26 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7678921F86CB for ; Mon, 23 Jul 2012 02:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1343035104; bh=kDTsKY+7mArZzFLZrRa0tmYzLzSdR65iJvT1NJAwOt8=; l=5072; h=Message-ID:Date:From:Mime-Version:To:References:In-Reply-To; b=YrvSGhsbqk6v6ovHxMXiyQ6gd+71BAc3YvvzhFzKiYFNTRfvZ4d9juBFE/6Mf7Gtc oAaKichdeKFFONgXA2rKMTvF7gbyBbypkI5sPEvbcxdf1ko27Wnf+0qN0WVUwZyMYW O76jMPjNHM9StGArTIT/R5iUbLMccEoMRQoR/tc4= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 23 Jul 2012 11:18:24 +0200 id 00000000005DC039.00000000500D16E0.00003EAE Message-ID: <500D16E0.3090607@tana.it> Date: Mon, 23 Jul 2012 11:18:24 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-16046-1343035104-0001-2" To: spfbis@ietf.org References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> In-Reply-To: Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 09:18:28 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_north-16046-1343035104-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Sun 22/Jul/2012 06:17:45 +0200 Murray S. Kucherawy wrote: > > Hector's analysis of my data is roughly right about the PTR data in > our survey. There's a nuance of the selection phrase I was using in > SQL that I wasn't aware of, which produced a very restricted result. > His query was also not quite accurate, but his result is a lot closer > to the truth. Oh well, query bugs had been eluding our analysis of statistical data reliability for too long... Thanks to Hector for pointing that out. I'd suggest we use `mysql --tee query.txt' and attach (part of) the resulting file, if at all possible. > To be clear: TDP's survey claims about 35% of SPF-aware sites are > using "ptr", not a fraction of a percent. Using an older version of your data I get 31%, but only 0.8% specify a target-text to be matched. Many of the records that use ptr have the form "v=spf1 a mx ptr ~all". Disregarding four of those idioms, I'd reckon the responsible use of ptr is somewhere between the former 0.8% and 6% of v=spf1 records. (The two "named" idioms can easily be traced back to https://my.bluehost.com/cgi/help/txt_record and https://my.hostmonster.com/cgi/help/txt_record .) The widespread use of (bad) idioms may indicate that a deployment document --specifically for wizards and verification sites-- would not be a bad idea after all. > However, as I said in another thread, non-use of PTR is not (as I > understand it) the basis for lobbying for its deprecation or removal, > but rather its very design. Yes, but PTR is now back to "unneeded". --=_north-16046-1343035104-0001-2 Content-Type: text/plain; charset=windows-1252; name="query.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="query.txt" Cm15c3FsPiBzZWxlY3QgY291bnQoKikgZnJvbSBzcGYgd2hlcmUgZGF0YSBybGlrZSAnXnY9 c3BmMSc7CistLS0tLS0tLS0tKwp8IGNvdW50KCopIHwKKy0tLS0tLS0tLS0rCnwgICAxMzM4 MzEgfAorLS0tLS0tLS0tLSsKMSByb3cgaW4gc2V0ICgwLjQwIHNlYykKCm15c3FsPiBzZWxl Y3QgY291bnQoKikgZnJvbSBzcGYgd2hlcmUgZGF0YSBybGlrZSAnXnY9c3BmMS4qIHB0cic7 CistLS0tLS0tLS0tKwp8IGNvdW50KCopIHwKKy0tLS0tLS0tLS0rCnwgICAgNDI1NTcgfAor LS0tLS0tLS0tLSsKMSByb3cgaW4gc2V0ICgxLjUxIHNlYykKCm15c3FsPiBzZWxlY3QgY291 bnQoKikgZnJvbSBzcGYgd2hlcmUgZGF0YSBybGlrZSAnXnY9c3BmMS4qIHB0cjonOworLS0t LS0tLS0tLSsKfCBjb3VudCgqKSB8CistLS0tLS0tLS0tKwp8ICAgICAxMTA2IHwKKy0tLS0t LS0tLS0rCjEgcm93IGluIHNldCAoMS43MSBzZWMpCgpteXNxbD4gc2VsZWN0IGNvdW50KCop IGFzIGMsIGRhdGEgZnJvbSBzcGYgd2hlcmUgZGF0YSBybGlrZSAnXnY9c3BmMS4qIHB0cicg Z3JvdXAgYnkgZGF0YSBvcmRlciBieSBjIGRlc2MgbGltaXQgNTsKKy0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKfCBjICAgICB8IGRh dGEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKKy0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKfCAyOTc5 OSB8IHY9c3BmMSBhIG14IHB0ciB+YWxsICAgICAgICAgICAgICAgICAgICAgICAgIHwKfCAg MjU0MiB8IHY9c3BmMSBhIG14IHB0ciBpbmNsdWRlOmJsdWVob3N0LmNvbSA/YWxsICAgIHwK fCAgMTIwNiB8IHY9c3BmMSBhIG14IHB0ciBpbmNsdWRlOmhvc3Rtb25zdGVyLmNvbSA/YWxs IHwKfCAgIDQ5NiB8IHY9c3BmMSBhIG14IHB0ciAtYWxsICAgICAgICAgICAgICAgICAgICAg ICAgIHwKfCAgIDEyOSB8IHY9c3BmMSBteCBwdHIgfmFsbCAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKKy0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsKNSByb3dzIGluIHNldCAoMS43NiBzZWMpCgpteXNxbD4gc2VsZWN0IGNv dW50KCopIGFzIGMsIGRhdGEgZnJvbSBzcGYgd2hlcmUgZGF0YSBybGlrZSAnXnY9c3BmMS4q IHB0cjonIGdyb3VwIGJ5IGRhdGEgb3JkZXIgYnkgYyBkZXNjIGxpbWl0IDU7CistLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwp8IGMgIHwgZGF0YSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKKy0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCnwgMzggfCB2PXNwZjEgcHRyOmV4Z2hv c3QuY29tIHB0cjphcHByaXZlci5jb20gfmFsbCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAp8IDM1IHwgdj1zcGYxIHB0cjphcHByaXZlci5j b20gfmFsbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKfCAyMyB8IHY9c3BmMSBwdHI6Y29ycGVhc2UubmV0IC1h bGwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CnwgMTggfCB2PXNwZjEgcHRyOm14bG9naWMubmV0IHB0cjpjb2xs YWJvcmF0aW9uaG9zdC5uZXQgaXA0OjIxNi4xNjYuMTIuMC8yNCBpbmNsdWRlOm14bG9naWMu bmV0IH5hbGwgfAp8IDEyIHwgdj1zcGYxIHB0cjpteGxvZ2ljLm5ldCBwdHI6Y29sbGFib3Jh dGlvbmhvc3QubmV0IGlwNDoyMTYuMTY2LjEyLjAvMjQgaW5jbHVkZTpteGxvZ2l4Lm5ldCB+ YWxsIHwKKy0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r CjUgcm93cyBpbiBzZXQgKDEuNzUgc2VjKQo= --=_north-16046-1343035104-0001-2-- From SRS0=olSFj=FZ==stuart@gathman.org Mon Jul 23 20:20:31 2012 Return-Path: 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 0028221F84D0 for ; Mon, 23 Jul 2012 20:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599] 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 65DhRGAA4hNd for ; Mon, 23 Jul 2012 20:20:30 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0417321F84C5 for ; Mon, 23 Jul 2012 20:20:24 -0700 (PDT) Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=72.209.196.211 (fairfax.gathman.org); auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q6O3KMdB010945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Jul 2012 23:20:22 -0400 Message-ID: <500E1476.9030306@gathman.org> Date: Mon, 23 Jul 2012 23:20:22 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <1442775.KUPRUp6gJF@scott-latitude-e6320> In-Reply-To: <1442775.KUPRUp6gJF@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Enhanced discussion of DNS limits/resource considerations X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 03:22:58 -0000 Long ago, Nostradamus foresaw that on 07/16/2012 12:15 PM, Scott Kitterman would write: > Alessandro Vesely sent me some proposed changes in section 9 to make some DNS > limits and costs more clear. I've attached an rfcdiff of the changes I think > should be incorporated. Feedback please. > The cost listed for PTR is misleading. Only the *first* ptr has that cost (and only if the MTA has not already looked it up). Subsequent ptr mechanisms are free DNS-wise - regardless of argument - because the PTR records and what they point to are cached. MX, on the other hand, potentially costs on every use (with unique argument). From spf2@kitterman.com Mon Jul 23 21:01:37 2012 Return-Path: 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 5A6BB11E810E for ; Mon, 23 Jul 2012 21:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] 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 up2zR2CwVXr6 for ; Mon, 23 Jul 2012 21:01:36 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A7E6811E8104 for ; Mon, 23 Jul 2012 21:01:36 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A133020E40C0; Tue, 24 Jul 2012 00:01:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343102495; bh=S2ZNxJQ0s/FB21GfyzTD8bE/cZ3LmD+HqbAn3NxJnk8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iDQwLkuF5qEFjBlNj+yvKn9fpKg6MUEJjaUWgf/oxIEMaLJMRyz1MLl9C9vJfN6kb vWQlRuQboSUWuYYQyCjfH277emHEM8kfhVlWB4WpY3INEAzzv+CRTOopcatYdxbsqh RjJ8ykSNa5q5bUly15FzzFfqp1yuliXlUnmbJF0c= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 876EB20E407F; Tue, 24 Jul 2012 00:01:35 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 24 Jul 2012 00:01:34 -0400 Message-ID: <1378487.kXQrr9pW9E@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <500E1476.9030306@gathman.org> References: <1442775.KUPRUp6gJF@scott-latitude-e6320> <500E1476.9030306@gathman.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Enhanced discussion of DNS limits/resource considerations X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 04:01:37 -0000 On Monday, July 23, 2012 11:20:22 PM Stuart Gathman wrote: > Long ago, Nostradamus foresaw that on 07/16/2012 12:15 PM, Scott > > Kitterman would write: > > Alessandro Vesely sent me some proposed changes in section 9 to make some > > DNS limits and costs more clear. I've attached an rfcdiff of the changes > > I think should be incorporated. Feedback please. > > The cost listed for PTR is misleading. Only the *first* ptr has that > cost (and only if the MTA has not already looked it up). Subsequent ptr > mechanisms are free DNS-wise - regardless of argument - because the PTR > records and what they point to are cached. MX, on the other hand, > potentially costs on every use (with unique argument). The bigger issue to me is reliability. I don't think PTR should be removed because people do use it, but I've yet to find a unique case for it where other ways of constructing an SPF record wouldn't work as well or better. RFC 4408 tries to warn people away from PTR for, I think, good reason. I think marking it deprecated, to be removed in the future is a good next step. Scott K From hsantos@isdg.net Tue Jul 24 00:00:43 2012 Return-Path: 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 3527F21F84DF for ; Tue, 24 Jul 2012 00:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 Q8gWiNwOs4xi for ; Tue, 24 Jul 2012 00:00:42 -0700 (PDT) Received: from ftp.catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2544021F84DE for ; Tue, 24 Jul 2012 00:00:41 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3265; t=1343113231; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=OJAA/DvY2F2xJq79qu4zH4CWnWU=; b=hvEp94mzFkMz/QTez9sh rK649M+FCDcpCgvDHbgkfwardDlSt22ims77cSDCaieDOCXSvIvkSb04EJxhn8TA 0DAZiampHpf2Dl8x/GaxqSmavlhARwO5XFTstwl0IM+jZds5XZGDapEDXhhTjqEu FIrkorl/IotOc+shvD1WXns= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 24 Jul 2012 03:00:31 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3430025190.22778.4232; Tue, 24 Jul 2012 03:00:30 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3265; t=1343113089; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=tmdd3iY yMtHj3sYoZaFr4X5LXSJXuUt5e6CSqg9lmcI=; b=ceYVH5TKAk/jh9Z43eX3CGn EPgTXP/jZTLvXouDFAvjGmQAtd07JGVOCeTGgnQVbXAGubyBJGj1Bs6VgA95bqHf 7dUHkx6F/OlwCXK8wBfvrT7pIiwsd5HR9J0u8hldWqzkcSyOXv+cbhrmOZxQJPG7 ojujaP7ZC+8yAAQ2xDoE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 24 Jul 2012 02:58:09 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4028854473.9.1116; Tue, 24 Jul 2012 02:58:08 -0400 Message-ID: <500E4846.3040703@isdg.net> Date: Tue, 24 Jul 2012 03:01:26 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <1442775.KUPRUp6gJF@scott-latitude-e6320> <500E1476.9030306@gathman.org> <1378487.kXQrr9pW9E@scott-latitude-e6320> In-Reply-To: <1378487.kXQrr9pW9E@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Enhanced discussion of DNS limits/resource considerations X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 07:00:43 -0000 Scott Kitterman wrote: > On Monday, July 23, 2012 11:20:22 PM Stuart Gathman wrote: >> Long ago, Nostradamus foresaw that on 07/16/2012 12:15 PM, Scott >> >> Kitterman would write: >>> Alessandro Vesely sent me some proposed changes in section 9 to make some >>> DNS limits and costs more clear. I've attached an rfcdiff of the changes >>> I think should be incorporated. Feedback please. >> The cost listed for PTR is misleading. Only the *first* ptr has that >> cost (and only if the MTA has not already looked it up). Subsequent ptr >> mechanisms are free DNS-wise - regardless of argument - because the PTR >> records and what they point to are cached. MX, on the other hand, >> potentially costs on every use (with unique argument). > > The bigger issue to me is reliability. I don't think PTR should be removed > because people do use it, but I've yet to find a unique case for it where other > ways of constructing an SPF record wouldn't work as well or better. RFC 4408 > tries to warn people away from PTR for, I think, good reason. I think marking > it deprecated, to be removed in the future is a good next step. Why is SPF taking the lead when DNS itself doesn't advocate deprecation? I think this move is premature, jumping the gun, imposing unnecessary change on operators, time/energy/cost to manage DNS more regularly when they don't have to today, lacks consideration for improved operations and DNS setups, lacks considerations for the automated caching of PTR already performed by OSes, etc, etc. Overall, it is a subjective consideration with little basis to thrust on existing operations where once again, many will find (the change they need to make and one more complex) unnecessary and remove what will be considered by many very useful despite what one may believe is not required or they can do a better job at configuration a network for SPF. As stated before if PTR is deemed a problem for SPF, there are certainly sound argument to be equally applied to other features, like EXIST, like REDIRECT, like INCLUDE which all can use some consultation for a better preparedness for less overhead on DNS. IMTO, this is a DNS management issue, a BCP. Not a SPF problem thus does not warrant the drastic change that is being advocated, and in addition, offered with no smooth upgrade or backward compatibility path. If one supports SPFBIS purely, it will instantly lack coverage for a relatively significant amount of the SPF market place. This removes the payoff value for SPF gained with the growth of SPF over the 8-9 years and will be a dip in the support for a number of unknown years before you can gain the wide SPF support. You will be assuming this DIP in growth which will correspond to increase error rates will be short, but we have no clue and I don't think it needs to be impose on SPF supporters and new developers who will suffer as well with lack of coverage. Please reconsider this move. I think it is better to have a BCP like section about "Optimizing SPF policies for DNS" than to begin suggesting deprecating features. IMO, it will serve the same purpose and quite frankly, more friendly, without complaints and well without pissing people off. :) -- HLS From hsantos@isdg.net Tue Jul 24 00:47:26 2012 Return-Path: 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 27FBD21F85E6 for ; Tue, 24 Jul 2012 00:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.209 X-Spam-Level: X-Spam-Status: No, score=-102.209 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 BYixCCf6NkOL for ; Tue, 24 Jul 2012 00:47:25 -0700 (PDT) Received: from ftp.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2992521F85F7 for ; Tue, 24 Jul 2012 00:47:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2276; t=1343116042; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=0aPjB64d6L4JvUagwXror9vFvZc=; b=huPoEuZvOfETrBCJ7GQm tfbM/szkdDwAJQRbMu8ZTtVJoCu2pxRMBGibC79M+wBln6cbPZ0a4DnAv54UwfLY gDKUiG3it045A+kGFbuL4YutOjJ4wLLii1/1gWrU95AMX/13CGCEwHE6+Z1ngvHn Gfy0wI7CWJ+d9dzZGmBKTCA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 24 Jul 2012 03:47:22 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3432835408.22778.1884; Tue, 24 Jul 2012 03:47:21 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2276; t=1343115900; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=po0WkNH 4YkBkmUKRLWjeoy6vlEtyCgkfSw17G+HF/Qw=; b=X8QXY5446+Caowo4CyeX2oL 3cljQS1ozR6cZpNtgG+HD8TV1vgHAA4POpNoOybQJ15u+m6dAttmnxqYFiPHGsrw kRLkPBtZjykrf74PL+2pDvDFHaEonDo07CbHNfR2OHqujXn39rYbR82Wp3oCV+KR cbWgD8yVCO9sYdQyYrrA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 24 Jul 2012 03:45:00 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4031665535.9.4796; Tue, 24 Jul 2012 03:44:59 -0400 Message-ID: <500E533F.9050002@isdg.net> Date: Tue, 24 Jul 2012 03:48:15 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alessandro Vesely References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <500D16E0.3090607@tana.it> In-Reply-To: <500D16E0.3090607@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 07:47:26 -0000 Alessandro Vesely wrote: >> However, as I said in another thread, non-use of PTR is not (as I >> understand it) the basis for lobbying for its deprecation or removal, >> but rather its very design. > > Yes, but PTR is now back to "unneeded". Up there in our support incident history, and often also upon unsolicited observation "Hey, you web site can be faster if..." during an unrelated support incident, our customers report their web site is "slower" than they preferred, page rendering is not "snappy." The answer is simple - check your DNS performance and/or disable rDNS which is only required to log the domains in their HTTP logs. Serves no other purpose. Does that mean they really don't need it to the extenr that we can now consider deprecating rDNS support and maybe, perhaps in a future version remove the rDNS checkbox option in the name of removing all future support calls and incidents? I don't think so. The fact is that was a higher issue in years past, but in the modern hosting world, everything is faster, including DNS server access. In fact, I know a number of customers who switched from there a relatively fast ISP uplink provider to a free super faster cache servers. Nothing is always free, they get you with the tracking and redirection of bad urls, etc, but no doubt, they are large and super fast. I believe Google is among them with free DNS IP server addresses. The PTR "Slowness" issue IME has become a "thing of the past' with faster hardware, high speed connectivity, better DNS databases, better DNS setups, records, automated caching and/or record assignments, temporary or otherwise makes the rDNS more feasible today and probably this is reflective in the greater amount of application enabling it, like many MTAs now requiring clients to have a PTR record. For me, this was a real case where we did follow the market trend, the market leaders because the overhead was there for the customer base we served. I pay very careful attention to optimizing our product because it pays in the long run to have a high QA out of the box with little support overhead, and in the two years since we implemented rDNS for our customer Anti-Spam scripts, I haven't heard one complaint yet. -- HLS From vesely@tana.it Tue Jul 24 07:27:18 2012 Return-Path: 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 43DCC21F8628 for ; Tue, 24 Jul 2012 07:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.014 X-Spam-Level: X-Spam-Status: No, score=-4.014 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_21=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] 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 Vvy5BrasnJrD for ; Tue, 24 Jul 2012 07:27:16 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id EB4CA21F85DB for ; Tue, 24 Jul 2012 07:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1343140022; bh=3wygGmdRQxl4jxmtYEveGGQQRzBKTXpXOk9QmyAwo5A=; l=54633; h=Message-ID:Date:From:Mime-Version:To:References:In-Reply-To; b=IG5d4eRQ+inhXG85ttR6Yzfse0il6a0yYf8LnIb/UKU2/h9+mCQ2LW19otnkfjDeN aWUWvWBWtRw28RYJrVdsB1JVHSSpPZHvJa9n0ZZw2YN1MeD+BFVsgg+B9yjfhD4g5S fxe00sf30s4SMC4k9ccJQzNWcMQecHAiGJTIAwcc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 24 Jul 2012 16:27:02 +0200 id 00000000005DC044.00000000500EB0B6.00005BB6 Message-ID: <500EB0B5.8040805@tana.it> Date: Tue, 24 Jul 2012 16:27:01 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-23478-1343140022-0001-2" To: spfbis@ietf.org References: <1442775.KUPRUp6gJF@scott-latitude-e6320> <500E1476.9030306@gathman.org> <1378487.kXQrr9pW9E@scott-latitude-e6320> In-Reply-To: <1378487.kXQrr9pW9E@scott-latitude-e6320> Subject: Re: [spfbis] Enhanced discussion of DNS limits/resource considerations X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 14:27:18 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_north-23478-1343140022-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Tue 24/Jul/2012 06:01:34 +0200 Scott Kitterman wrote: > On Monday, July 23, 2012 11:20:22 PM Stuart Gathman wrote: >> Long ago, Nostradamus foresaw that on 07/16/2012 12:15 PM, Scott Kitterman would write: >>> Alessandro Vesely sent me some proposed changes in section 9 to >>> make some DNS limits and costs more clear. I've attached an >>> rfcdiff of the changes I think should be incorporated. >>> Feedback please. >> >> The cost listed for PTR is misleading. Only the *first* ptr has >> that cost (and only if the MTA has not already looked it up). >> Subsequent ptr mechanisms are free DNS-wise - regardless of >> argument - because the PTR records and what they point to are >> cached. MX, on the other hand, potentially costs on every use >> (with unique argument). That seems to be correct. Perhaps ptr should have an additional note, e.g. like so: * N is the number of RRs found during a term evaluation $ for ptr the query cost is paid on the first evaluation only Would that sound like encouraging ptr over mx? > The bigger issue to me is reliability. I don't think PTR should be > removed because people do use it, but I've yet to find a unique > case for it where other ways of constructing an SPF record wouldn't > work as well or better. RFC 4408 tries to warn people away from > PTR for, I think, good reason. I think marking it deprecated, to > be removed in the future is a good next step. Hundreds of domains (0.3%) use multiple ptr's. It looks like people who understand the proper use of ptr can easily reiterate it (see graph). At the top, monarchinc.com use it 12 times. Making a better SPF record at the same cost is not trivial in this case. The other mechanisms are also repeated many times. The extremes of each kind are disconcertingly error prone. I attach some (hoping not to trespass size limits...) --=_north-23478-1343140022-0001-2 Content-Type: text/plain; charset=windows-1252; name="useofmechanism.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="useofmechanism.txt" DQogICAgICstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tKw0KICAgICB8T2NjdXJyZW5jZXMgfCAgICAgICAgSVA0IHwgICAgICAgICAgQSB8ICAg ICAgICAgTVggfCAgICBJTkNMVURFIHwgICAgICAgIFBUUiB8ICAgICAgIElQNiAgfCAgICAg RVhJU1RTIHwNCiAgICAgKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0rDQogICAgIHwgICAgICAgICAgMSB8ICAgICAgMTYzNDMgfCAgICAgIDE4 MDYxIHwgICAgICA3MTg4MSB8ICAgICAgMjQxNzEgfCAgICAgIDQxMzkwIHwgICAgICAgIDk1 ICB8ICAgICAgICAgNDMgfA0KICAgICB8ICAgICAgICAgIDIgfCAgICAgICA5NjI4IHwgICAg ICAgMjczOSB8ICAgICAgIDMyMTIgfCAgICAgICAzNzczIHwgICAgICAgIDI4MSB8ICAgICAg ICAzMCAgfCAgICAgICAgICAxIHwNCiAgICAgfCAgICAgICAgICAzIHwgICAgICAgNDE2MCB8 ICAgICAgIDE0MjUgfCAgICAgICAxMjQzIHwgICAgICAgMTUxNyB8ICAgICAgICAgODQgfCAg ICAgICAgIDMgIHwgICAgICAgICAgMiB8DQogICAgIHwgICAgICAgICAgNCB8ICAgICAgIDI4 ODYgfCAgICAgICAgOTQ5IHwgICAgICAgIDQ0NSB8ICAgICAgICA1NDAgfCAgICAgICAgIDMy IHwgICAgICAgICAxICB8ICAgICAgICAgMTAgfA0KICAgICB8ICAgICAgICAgIDUgfCAgICAg ICAyMTA3IHwgICAgICAgIDQ5MyB8ICAgICAgICAyMzggfCAgICAgICAgMTgwIHwgICAgICAg ICAxMiB8ICAgICAgICAgMiAgfCAgICAgICAgICAgIHwNCiAgICAgfCAgICAgICAgICA2IHwg ICAgICAgMTYxMiB8ICAgICAgICAyNzYgfCAgICAgICAgMTE1IHwgICAgICAgICA3OCB8ICAg ICAgICAgIDMgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8DQogICAgIHwgICAgICAgICAg NyB8ICAgICAgICA4MjQgfCAgICAgICAgMTg2IHwgICAgICAgICA0NSB8ICAgICAgICAgMzcg fCAgICAgICAgICAzIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfA0KICAgICB8ICAgICAg ICAgIDggfCAgICAgICAgODEwIHwgICAgICAgIDEzMyB8ICAgICAgICAgMjkgfCAgICAgICAg IDIyIHwgICAgICAgICAgMSB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwNCiAgICAgfCAg ICAgICAgICA5IHwgICAgICAgIDY1NiB8ICAgICAgICAgNzAgfCAgICAgICAgIDE2IHwgICAg ICAgICAgOSB8ICAgICAgICAgIDEgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8DQogICAg IHwgICAgICAgICAxMCB8ICAgICAgICA0MDYgfCAgICAgICAgIDIzIHwgICAgICAgICAxNCB8 ICAgICAgICAgIDEgfCAgICAgICAgICAxIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfA0K ICAgICB8ICAgICAgICAgMTEgfCAgICAgICAgMTk5IHwgICAgICAgICAxMyB8ICAgICAgICAg IDYgfCAgICAgICAgICAwIHwgICAgICAgICAgMCB8ICAgICAgICAgICAgfCAgICAgICAgICAg IHwNCiAgICAgfCAgICAgICAgIDEyIHwgICAgICAgIDE3NSB8ICAgICAgICAgIDUgfCAgICAg ICAgICAxIHwgICAgICAgICAgMSB8ICAgICAgICAgIDEgfCAgICAgICAgICAgIHwgICAgICAg ICAgICB8DQogICAgIHwgICAgICAgICAxMyB8ICAgICAgICAgMjkgfCAgICAgICAgICAyIHwg ICAgICAgICAgICB8ICAgICAgICAgIDEgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAg ICAgICAgICAgfA0KICAgICB8ICAgICAgICAgMTQgfCAgICAgICAgIDIzIHwgICAgICAgICAg NSB8ICAgICAgICAgICAgfCAgICAgICAgICAyIHwgICAgICAgICAgICB8ICAgICAgICAgICAg fCAgICAgICAgICAgIHwNCiAgICAgfCAgICAgICAgIDE1IHwgICAgICAgICAyMSB8ICAgICAg ICAgIDAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAg ICAgIHwgICAgICAgICAgICB8DQogICAgIHwgICAgICAgICAxNiB8ICAgICAgICAgNTYgfCAg ICAgICAgICAxIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAg ICAgICAgICB8ICAgICAgICAgICAgfA0KICAgICB8ICAgICAgICAgMTcgfCAgICAgICAgIDEx IHwgICAgICAgICAgMCB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8 ICAgICAgICAgICAgfCAgICAgICAgICAgIHwNCiAgICAgfCAgICAgICAgIDE4IHwgICAgICAg ICAgOSB8ICAgICAgICAgIDMgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAg ICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8DQogICAgIHwgICAgICAgICAxOSB8ICAg ICAgICAgIDMgfCAgICAgICAgICAyIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAg ICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfA0KICAgICB8ICAgICAgICAgMjAg fCAgICAgICAgICA1IHwgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwg ICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwNCiAgICAgfCAgICAgICAg IDIxIHwgICAgICAgICAgMyB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAg ICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8DQogICAgIHwgICAg ICAgICAyMiB8ICAgICAgICAgIDIgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAg ICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfA0KICAgICB8 ICAgICAgICAgMjMgfCAgICAgICAgIDIzIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfCAg ICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwNCiAg ICAgfCAgICAgICAgIDI0IHwgICAgICAgICAgMyB8ICAgICAgICAgICAgfCAgICAgICAgICAg IHwgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8 DQogICAgIHwgICAgICAgICAyNSB8ICAgICAgICAgIDYgfCAgICAgICAgICAgIHwgICAgICAg ICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAg ICAgfA0KICAgICB8ICAgICAgICAgMjYgfCAgICAgICAgICA1IHwgICAgICAgICAgICB8ICAg ICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAg ICAgICAgIHwNCiAgICAgfCAgICAgICAgIDI3IHwgICAgICAgICAgOSB8ICAgICAgICAgICAg fCAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwg ICAgICAgICAgICB8DQogICAgIHwgICAgICAgICAyOCB8ICAgICAgICAgIDEgfCAgICAgICAg ICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAg ICB8ICAgICAgICAgICAgfA0KICAgICsrLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLSsNCg== --=_north-23478-1343140022-0001-2 Content-Type: image/png; name="useofmechanism.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="useofmechanism.png" iVBORw0KGgoAAAANSUhEUgAABE0AAAJgBAMAAACNU4DAAAAAMFBMVEUFBAGEDSo6SRILS4n/ Th1qoDV3n8TdjYexs6+Szfz5vrD/1SjX2dX45pH78dj9//wgtadcAAAAAWJLR0QAiAUdSAAA IABJREFUeNrtnW+IJEl22Pvjfhgo2gjmWAYOEtsUuKGRS25OaM1+cKK5W8k7yFCgD95Z8HzR gsyw0IaTODxztSepVxorwRJ3W7C4WRgwxrIHpJMsUeqZ2eqTvYNWqk8LEiVtf9nFgvbStTU9 09ndVRWOP/kn/mVmRGZU1p9+OduzPdWRES8jf/3ixYuI9zYQXHAVXqMN6AO4gBO4gBO4gBO4 gBO4gBO4gBO4gBO44AJO4AJO4AJO4AJO4AJO4AJO4AJO4ILLJSejjQ31vgb0JnAi3QVYACeG nIyg84ATA06wQtlooBGugPwPf+E/+O8NMHiAE5GTEf7/CJOB/9egX/i7EQxIwInESYOyQhgZ IcoJ+w4u4CSDE1oPcAKcFHGy0Yj0CdgnwInJuAMTZuBEnhcDJ8BJMScECvIn4iS1T4AT4CS5 i5ohGw0U2ycbYJ8AJ3ABJ8AJXMAJXMAJXMAJXMAJXMAJXMAJXMAJc7FuNNgX+XAUOdLggovn hKCReuIbkXcVtgnAJXASLczEa8Dxyh4s1sAlcNIATuAytE+AE7iAE7jmy0m4Bxdc9030SaDg FarE1Vxo8RKsRiFHlY+AE+AEOIFCc+Ak088GnAAnJn574GT9ONmwuszWAYGT9ePk2qcW11Pg BDgBTqAQcAIILB0nFzeBE+CkmJMv/HvAyfpycu0pntDQb6pxMvP9N4CTdeaEMfK0Iidf+L7/ CDhZP04+wQQ8iDjBX9cqcoIxURQKcLIGnPS3yH8xJ08/dcDJLeBkDTnxPvUccnKKOQH7ZO04 6XvsehDZJ9eqcoJUdQKcrBUnZL7ztPJ8BysU4GQ9x529ZNwhkFTlBPlvAifryEnz007CyUbk RKnCyS74T9aSkweffpJw8qkDfbJ7EzhZc/+JE05+APOddffHAifASQEn7vYV/Bb47YETA05+ W1kwBk6AE01T4LcHToAT4MQVJ7uwXgycGHDyEDgBTgw4OfWBE+AEOLninFxzx8kJcLK2nDx9 6oSTVqv107KjDTgBTjSctGRHG3CyBpz8Za/X+zvHnNwCTtaWk2uFBgpwcpU5+WvMyaduOfmp N4CTNeOEaJMe1SgOOfmZm8DJ+tmxx70/JxDk7Xi05cQHTtaPk7/s/T92FPApcAKcZHPy19Q8 ccmJ7EABTtbCf/J57I295ogT2YECnKzR/linnNwCTtaUE3frgK3XEXACnJhwIu1UAk6AEw0n r6GHN4ET4KTgurODvvCBE+CkmJNT4AQ4KbreI5ycACfASQEnLXQhOtqAE+Akg5N7wMn6+tlY sMdr1TmRHCjAyfpwQhaLn17LXeUx5OQ3WwPgZM05cRDHD3NyV3K0ASdrwckb8ZBzzRknoqMN OFkHTn7i/0HKSd5uakNOHmBORAcKcLIOnPj+Gyye0tP8cI/G57xaXeBk3Tj5ic+uP4g4caBP gm4XnQkOFOBkjTiJrZPK9kkXcyI6UICT9Rh3brJjGW446RJOxIkxcLIeduz3Ek6q+0+6wMm6 zotvMn/sUyf+2IgTwYECnKyT3/4pc7ZlKxSbcUdwoAAnsA6ot2PFiTFwApyo1/vACXBixMk7 SHSgACfAiY6T1kB0oAAnwImmqe7v3RUnxsAJcCJdMxIk40+BE+Ck4CKc/Mld0YECnAAn8jXE nPzZ66IDBTgBTuTrEnPy/uvixBg4WbN8XsQlu0E9s9HXBv1nlF3SiJO/wpx094GT9eXkGsuH zv6KvuLPzPVJs9c76HRFBwpwsiacfEg4eRqBkagW/p/GnHjD3p96mBPegQKcrAcn3YQThoTI yVM7Tv5Z7w8JJ/zEGDhZC066jJN012MlTry253UHwMl6cfKsyy62jzqDE2rNGnOCL2LIcg4U 4ORqcGKnT/D1zr7gQAFO1mHc6cbjDrNRKnPS8bx/Ku4sAE7Wyj7BRDjgZOt3/xCDApys7XyH ElF9XjwIhnjk2eIdKMDJmvljN1I/GzsbaO9n20LB8R/+cwwK50ABTtbUb0/89E+Jr97eb4+b uuy1/h0GJZ0YAyewDqhpatp7753/7Hn/GDgBTvI4mfX+6Ge7fc97FTgBTnI4Qb0/eq27j0EZ ACfASQ4nwz/GnKAUFOAEONE1ddnb6X6ITv+R1wROgJNsTqa93zwnMVA8bxs4AU4yOZn1/uSc xED5nucFwAlwksUJ6v0JwgaKfyv0POBkvTghHjXqUMtOPCpxMsJfGw32RX4Q/xA3Nfxjxgm2 ZZvAyVpxci1OJfk0MwSKxAlBI/qDGtGfqKnL3uBZl+5A6RATBThZA04OW63Wa3F+wKfpYnER JyOKB2qQrxH75yhuato7wQYK2YEyIZNj4OQKc9LI4STsPTnvDujOgjEeeXBTA+DkinKCcjl5 jA0UloUHjzwhCreBk7XhxNI+yeFk8jsHmBOWhQePPCHqACerzclhi12/yvZKE04s5jsqJ+Ee vX6ut/d+d8//Nvm+4zXxf3twrfAljjuxPsnwqjzdu2+oT9C/6B1hQ5btQBmTLbOgT9bIPuGH nkrjDrrTezLp7rOjGWOyAx84AU60nBBDlh3NAE7WlRNjOzbLz4buEEP2Q7blHs+MgZP1yg9o Oy/O8tuj936uh867MSfhGDiBdUBdU4f/khiy7GjGeDtE8U4U4AQ44Zt63uo9Qd3/Qo9mjHFT Yy8AToATHSfEkI2OZuCmZIUCnAAn+Otl6/gAGyhRzIIQKQoFOAFOKCe/QwzZKGYBaUpSKMAJ cEI5+fe9o0n3J37SlKRQgBPgBH9NWneJIfv7KSeSQgFOgBPyV+v14WP07EcsZkHI3CgD4GQN /GxsnfjphitOjrGB8kMWs4CJ6G0BJ+vACUsmWT0vbcTJJdn7yCbGTERBoQAnKx3Xonq+0aip O69Ne0comhgzESe8QgFOVo+TXxY4cTPu3NlBxJD9wU1OxD6nUICTlePkkzbHiSv7BHMyPEDn bMITiTjhVgOBk5Xj5C/aDxL75Kkr++RwB11iQ/ZHdCt1LGLfA05WlJO/aLPrAZvvOLNPnrfI IR70AZ3wxCJyCgU4WVlOuP0nTjiZEQOFTngSETsecLKy4w6mJIn+6YyTl60B6j1G5yInYaJQ gJNV4+Qv5sRJQA1ZOjFORUwUCnCyipz82ySasCs79mXrLjFkEZ3wpCImCgU4WWU/mzu//QRz QjxtEieJQgFOYB2Q/t16HRFPG90iy4kYKxTgBDhJOMEGyktiyPIiRtsLgBPgJOHkuMfSevEi Rkc0gBPghP595zVEDRQy4RFEZCHbgBPghHGyg6in7Sc3JRGZQgFOgJOEE+JpO/XluFt0ygOc ACf070PCCTZQzvxAEpFOeYAT4IT+/byFSNzHk5n/PVnEjjcAToATjpMZNmT978gihnhuHKA+ cLKKnJAQw9fidIBxzGGW1KsUJ2QhkBoou9/el0XseEEw8YCTVeTkWrIM+FQM6HetCifDA2zI KpxMPC/oAyerxcn/ecDFP7lGY4NmxAi15OQuM1BO/a4ioudtecDJanHy8eYDHSeaPQZWnISU k2nv6ML/tRCd70uceMDJynFynYunlOalVQNwWXEyoZwQA8X/zgfnXeBktTn5eJNdD6LcsyyG 7Ma1ONP1RllO6AIPNVD8n+92FU46wMlqcsLrE8YH0yob1ypxgg2UhzdVTrYCJbQfcLLs487m NyT75NPYjv20vB1LFwLpEg82ZBVOBkHoSZFzgJMVsk9ccrKDmIFy5r8vc7JF/GwSKMDJknNy XfGfuJgXx5wc97AhK3NCC0mgACfLzcknnJ8t8se68LOxhUBqoPhYoWg4QR0BFOBkZfz2G7Ep G+fOqOC3Zws81EB56H9bywkBJT2aDpxcyXXAmBM8Mz71/Xe0nAigACdXkxO2wEMGHt/3f17P CQWlCZxcbU7YN1PCif9OhjyTCJTJfJMIAgJLzMld9k3vx5iT97PkCT1KyjiYaxJBQGBpOZnE nBxjhfKGbMjyEx262tOcaxJBQGBpOYkc94QTfP1tN0cemslpL/SAk6vMySXh5O8khSLK06cq BTi50pxMCSeo+2GuPH3gZJk52bC67DhhC4HEkO31fozOu7ny0KHHGwAny8mJZSE7Tnaib4aY kxMkDjwqJ82OAgpwchU4OYw5wQaKf0tSKConIfJSpxtwcnU4eR5zgg0U/w0kKhSFk60Qf0mg ACdXgpMWSgyUH/tIVCgKJwPc1DbxpTSBk6vKCTZQ/HtowiuUrKbIvGcLOLlKnMQLgdhA+YoY KKjbNWgq5EABTq4GJ3eTWqKBZ9+kKaJSAuDkynAScpwc90g8P06h5DXVYaBs40Jj4GTtOZlw nMx6P74lKJTcpphG8RD5Ak7WnZPEcU9qGfZIJp5UoRQ01aFu/GAMnFwxTqa9Hz/iFUpBUxMK SuABJ1eAk2SBJ6Rz4zd5hVLY1MRzeQgZEFhmTna4WrBCIW8/VijF8kSgbAEn687JezwnWKGQ FCuxU9ZAHi+6AuBkvTk5FDiZ9v4X+V+kUEw4aQYdGRXgZA05SRz3rJZh7xFVKANTToIg9OKt bgPg5KpwMu0doMSUNeEEF+okk+TmADhZU06SBZ6olmHvCYrnxgbyBCiOUDxJjoMBJ2vJyV2h llmvdxIrFEt5JtHUBzi5ApygSzryUIViLQ895TMI0WQbOFkzTiYyJ+gXeo8jhWIvT8gOg/WB k3XjJHHcJ7Wc9ggoxNkWoIm1PHjqszfxgJP15wT5vd7n1NkWSOc0jOTB5mwfOFk/TuIFnrSW s1+goHT33++W4GRc+jAYILDUnOwotTzEoBzNyAnBA+AEOGHXeyonyMegHBBO/rwMJ03gZA05 OdRwckpAIdefleHkk1DZagCcrDwnseNeqOWh/68pJ89KcLKF58WyQgFO1pMT5Pv/g3BSxo4l frZSh5ABgWXmJF7gEWs5830S6uLvSsoTSluXgJM14OSurpaH/q1hj3rcSsnTF+OdAycrz8lE zwkeef57j5ByVEqeSYmgBoDAMnMSO2Tlpi58v/fGVxIo5vKMBVMWOFlbTvDI82P/UfcvqW+2 hDzC3Bg4WX1OIse90hSJPPzmeXfIaxQLeQSFApysASffyubkDdTdJ0bKSQl5Oh5wslac7Oib OsWc3EPPuiQyykEJefi5MXCy+pwcZnBCFMoturFtloBiJU8ndbYBJ6vASYN9SH+w0ZBriRyy alNEobCNbdMYFCt5JpZBlwCBxXIyahBU2J8R/mPKycw/i0NAxqDYyZM624CTFeCkQfBAI/KF KDJiLZHjXtvUrh8dDoxAsZQncbYBJ8vPyQgVcXI3s6kzbMmyzY8EFJos4chCnmRuDJyshn2S x8kkhxOUxpSdsh0pVpwkzjbgZPU5QXmcnPqP4vAFEShW8owjUxY4WUVOwj3han1rL/vyv733 fvcD+u1/ojtm96wuz9uDazmv+7b6hDnuM5D8gliyUbqVY3WjQRG3ITNlQZ+swbjDHPcZTV3w 2RGOVfOkSB62BRI4WQdOdvKaeuin2RGm1vqEmLIBcLIy/tgcP1vkuM9q6jSZGtNgBnbzHTry 4KEnCpLCFQnVOwGBpfbbRw7ZzKbw1DiJ7Dc8SNeOTeXpY40STMSTGuNtTYZbQGCp1wGLODn1 01Chx0+O5TOCxUJjhRL0JU50GW4BgeXmhDnuM5viLdnLkyjgko3QZOSRTn6NdRluAYFl5+Ru blO7qSUbJgGXbIRWghGHajBRQGDpOZkUcML5ZFkw4oMynMRLgnEYUU9JXgoILDcnbCd1TlP+ m3HQ+5B5UZ7YciLCIVxNQGBdOEl9sqyQMPKYcLIV9EUtMvaaY297IpICCCw5J9Rxn9NUaskK QWbNORmQeXGfs0lohtvt2FLZAgRWg5OdgqZ2b0aWbFSIH3kMhN7ChfqK/2S8ndq0uJIBvm8C nCwzJ4dFnCSWbFyIG3lKCT3m/bFU0QRN/FEHOFlmTqijLbepaON9UogbeVwIzRI+haEHnKw2 J/FiYFJomKzzOBGaxjwP+8DJUnNCHbK5TcX7ZJNCs2Rjm6Me6egygwEnS8bJ3aKmon2yaaHL eIeBox6ZACdLz8mkmJNoMZArNIxMWVc9IjndgJPl44Q62vKbilwoXKHYlHXHSaiCApysGCeR C4UvFDlRnHGyFY4VUICTpeKEOGQLmmIulBCd7ycfMSeKM04GIfL60ioycLJcnOwUN0UXAz9I k2CTkeexwx7Zwh+N0SfiGjJwslScHBpwQhcD8bXPm7JHLnuEfhQKoAAnS8UJcbQVNcUsWYET 6kRxzAn1pAyAk5XlBFuyE0mfoMteyaQaeZxMOI0CnCwVJy9bQXFTp/5/kzlB8+CEggKcLCMn YeuuQVMk+qPECT2b/sQxJwSUJnCyhJxMjDjBluy5xAk9cnzkmhMCyhZwsnycEEdbcVPYkj17 JnEy00S6cJC/OIzcKMDJcnFy5zWTph76D39R4gSp5omTPNdRqifgZMk42TFp6sz3fZmT43mM O4hscmsCJ0vHyaERJySi7Hek1E2XPeXEsRNOUIfsswZOlouT5y2Tpma+qlCmPeXEsRtOaE6w AIIarCAnJPCw/2uSQjng9kC65IQkLkXBGA4hLxMnL1uBQVMXhBM5R3rA7YF0ygkeeYIAghos FSdh665JUw9ZBg250KU48rjiZOx5exDUYKk4Qa3XTZoiCuWRpFBIITHWhUNOPOBkFTlBD9/0 b56LCiVAcqwL4GR9ObnzmlFTZyRcm8qJOPIAJ2vMyY5pU7IlywoNuUCQ7jjZ7gAny8XJYcu0 qVNf9N1HhTi3rDtOENixS8bJc2NO0K7/flctNC2XRDCXk20UdDzgZJk4edn6xLSpC/+mhhN0 XCqJYN5HJKSBEu0POFkwJ79i3NRD/zv7mkKJieKKE3qfrFCAk4VyMrHgBJuy72gKzWITxSkn skIBThbKCWp9y7ypM//mvqZQbKI45URWKMDJYjm5Y8EJHnl+UVfouEyyyaKHlRQKcLJgTnZs mvL9R7pCzERxy4mkUICTBc+L8fW6cVNnJLOxWmhGN9875kRUKMDJKnGCfkAC56iFsIky1B3V qJR/R1AowMlKcXK+67+pK3RcIilp0cMKCgU4WSlO0Ae+f09XiIFy4pITQaEAJ6vFyfmPIltW LjTUnCStyMmYUyjAyWpxMun+PrNllc3WvRJJBAseFpIlrCwnqPvhQ/+mrtCle07GaZAl4GTF ODnvIrJbFt1DBgqlar7RVKEAJyvGCeruX/j+rQtfKdRTQanKSWqhACerxglWKGe+v+vfkgsd P/5KnhlXzl+cREQBThbrt6cxUCw52WcnvxQD5YhMeg6ccpIoFOBk4Zy8btkUSfH1EHNyS1No Jg491fOhd6JYXMDJojmhWb1smiL7qX2NQomSCPKgVOckjCLnACeL5uRwx7YpPPBk6RMKyoFD TsgpUuBkGThhadFtmsIK5SJLn4igOOBkwkxZ4GTRnLC06HacMIVyU1/oqxQUB5zQ+AXbNGg1 cLJITibKhKewqS5RKCfy1Dgp9FWycuyCEzzybHm4UDRD7idhZoGTWjlBlv6TyJL9jyR8ziN9 oWkMihNOSFzZ7XDMhh8unzpwUi8nytbHYnnwwBPQfdUZhQgon7NoxNU5oXB8gs2UkEuZDZzU zsmhPSdYoZBCD4WRRyg0xBplaBa0uvhh+azqWwycJnBSNyfKhMdAnu5+MOkK+6qlQrMh2+H2 2AUnKIakmQ5F28BJzZy8lA1ZE066D7AxK448UqGhdidkJU4Gwmw5mGwDJzVyohiyBvKQiPdd aeSRC810OyFLctIMpXNfY2876AMntXIie+4N5JlEnCDO26YUmrqyTxCe74QyJ94DDziplRPZ kDUadyJOzpKDGhqhj1ULpSQnuFBH5sQDTurlRDZkLcYdMvI8yhT6sncgg1KOE5ImKAROFsyJ vAXFRJ7zmJOLxJRVC816J1PJmC3HCQRxWwZOZEPWSJ73I07QaWzKagr1osHn8zlwsgWc1M2J 5JE1kyfmJDFls4QWcjq542TQAU5q5kQyUAzlicP6nUUKJVvoYUqKM062EHBSNyeSp81Qnmex QnnoF8XJGSaeFGecDFAAnNTMiWSgGMqTBKi+YHPjPKFnsSvFFSekUKcJnNTLiWigmMrTTRXK oyKhKSgnTvOUBmMPOKmXE9FAMZUnUSgzqlDyhaaguOXkigUPXQJORA+KsTyJQjklCqVI6Clb QTZZ8jGUINqLD5zUxQlqvVZGnjSFBlEohUJHoLjryb4HnNTLiTDwmMsjKJRioSkoB+56cuwN gJNaORFmxubyCArFROhj1Typ0JOTKxWMeBk4EQYeC3l4hWIi9KznLu8xLiQZKMDJ3Dk5bJWS h1cop/cMmtPscavQk30POKmXE37gsZGHUyjyuS9tTcODYc9RPtsAyQYKcDJ3TnhXm408nEKJ I0HmNnf5mDjxTxz15OQqBTdfDk6ep8dHreRJFMquRqGoNU2PkAxKlZ4EThxx0mA/iH+YU0tq yVrJEyuUM3Iy/ZGZ0ENhclylJ8UlHuCkLCejBkGF/Smo5TBRKHbyRAqFhli6Zyb0jE8/Wakn xx5w4oKTRgON8I/IV1EtkyQVj508sULxjcadMJ4eHznpydALgJPqnIyQOSdYodwtJc+zVKEY C82ln6zWk1coqcac7ROBk7fzamntlJMnVSj3jIVO009W60nBQAFOHHEya+fV8jwyZW3liRJg n95SBp6cmoaJA79ST4494MQ1J+Heb7T38q5W61f2ylzdD9j/f+B/1/ymXm/PwdXx9uCyuu4b 6JMv22/n0fay1SoVgIYpFFwoTs5jAvc0Hnkq/cZNrk6SnhrHnXY+J3jk2SklDwkpSwp94VsI PayYz5YVAk7cczJrt9v5tdxp7ZBI5i1LeejcOCQ7qm+ZCz2LtixV60nekAVOqvhjUz/bi0JO MChlOKHONlLooW8h9CUzZav15NgDTtxwkvrtv2yrA49US1iOE6JQSKEzcWpcIPSQOlGq9STv aQNO3KwDttuqQpGbelmKE6JQaKE0zIWB0NNKeY9ZocmVSQ5XGyczysnbBU2V4wQrlBCd77Od 98ZCHxOFUrEnuT1twIm7fQWyQnHECVYoIRl8ZoIlWyT0jCiUij3ZaQInc+BkJikUV5zQSFz7 kiVbKDRRKBV7kjNkgROH+5S+bM+FE/SMcSJMjQuFJgqlYk+GVyXZZM2cSArFFSfnkT5Buzdt nuxYe/TLqkdSQxY4cbnvUVQoek5es5cn5oS3ZIufbOaAky3gZB6ciApFz0nL/qDdJOKEnxob PNlx6fzYcaH0cAZw4nQftaBQ9AftJIViJM/LiJNT3+bJppoIBnY9MgZO5sOJoFD0TR22ShyM mbCtstzU2ODJdCcE7XokNWSBE7fnMj5rFzU1ESMsGcoTbZVNp8YmTzZUzRPLHrkiybDr5+QF p1AymjpslZEnjlF9y+LJjqtzsgWczIUT1H6rqKmXgkIxlSdSKMn+R5Mnu6w67qSGLHDimJMX 7cLd7ndaZeRhe++TqbHJk82qzndSQxY4cX1utH27qCkhIoq5POLU2OjJesfV/CepIQucuOYk nRpnNsXHgDSX5zxSKCfmT/bVVJkYW/ZIbMiWeydbuNA2cKKtJZ0aZzb1nFMoFvLQrbLx1Ngw 3+jwoFqPdLaqvBMPBWPgJKOWZGqc3RTna7OQh5my0dTYkJNLOQakZY/EhmxJTrZXI7L1QjhJ LNnsprhIFzby0LlxtGpsmr9YHngse2RchZPQ8/aAk8xaYks2uynO12YjD69QTDmRLVnLHokN 2TLdxpIiAydZtcSWbE5T6dTYSh6qUJivzZSTqeRCse2R6D2X6TYPOMnlZBpZsjlNpVNjK3mY Qtn1LThBkgvFtkeivY8luq3vbXteBzjJriUaePKaSiKi2MnzLFEoxpxc9ir1SGSg2HfbxGsi b+uBHAAdOEm/fdEubCqxZC3lSRSKMScz0ZK152RQrtv6+EZvEPSlwNbASfpt5ELJayqxZC3l Oe8OmEL5n6acSC4U2x6ZMEPWutsmRJE0VyTzxqLiPbKBJ7ep91rl5KGm7K4/809MORFdKNY9 wt6zdbdRPTTAhToecJJe3xNqYQNPblOxJWsrDzVlSQTIW6aciAOPdY8wQ9a627xmVGjsBcBJ cm3e42thA09+U9Eij7U8VKE81ERsy8z7Jgw81j3CDFlbMWO/SyAHor3qnGzeQ/LAk99UZMla y0MVyqlGoWRycsm7UKx7hL1xWzFjf/9qRMqvkxMBFDrwFBiIzJK1l4fMjUlEWd+UE8F3b90j 7DS6rZixElmNSPm1crLJHROfto8Km2KWbAl58MjzBcbkTWNOeN+9fY9QD4ilmIlRshqR8uvl 5FV+4Hm7sClmyZaQB488F1b6hPfd2/cIHTcsxUwmOasRAb1eTviBh6zxFDVFLdky8mCF8lCN UZ2Tv5jz3dv3yLgEJ4kKWY0I6LVy8k0kGCjF0QKoJVtGHqpQHu2KgXPyOOEGHvseoYasnZjp XHg1IqAvzI6lA09RU9SSLfWwz7qDX+/+0BdByeGEG3hK9AhRDnZiplOc1YiAXiMnN0R9QmbG hU2RkzzlHpacTO+eiaDkcMINPCV6hNgXdmKmYKxGBPT6OPl1JHGCZ8aFTRFLttzD0lAXxC17 y4yTdNG4RI8Q+8JKTG6gWY0I6HWu72zeEP6JZ8bFTWFLttzDPqOcUP/9IxNOUt99iR4hr91K TI6LAMkGypXn5FUkGSjFTT1vBRXGHcT8sicGnKS++zI9gocRKzG5PSerEdm6Tk7evS7++7O3 DJqiAVFeLyF0xAmdHz8y4CRZNC7TI9i+sOk2fivBakS2rpOT70ucvGgbNHVYlhMCCnOHJ6Dk cpIMPGV6BI8jNt3GmyOrEdm6Vk42kWSg/E1xU89LcxJECgXNYo9bLido2CuUJqgVAAAgAElE QVTfI9i+sOk2XnvEnAyAkwxOULt9Mk9OUBRjiYLyRiEnsQulVI942zbdxlsjqxHZul5OpI2g n6mZVpxykoCCLigoFye590UulFI90vFCtVhWTcLGpNWIbF0nJ7+1+Ug2UG7Pl5M0ETb1uJ2+ mXtf5Lsvp0+8T1DHtNuE/SarEdm6Tk5+W3Lck1Qrc+bkXADFz98yG4UuKMlJM/RMu03w0q9G ZOs6OXkgOWQJJyfz5QQ9i0celjP9zdz7WDK4kpx4HVNOxFW/1YhsXet+e5mTLzWp4Bxzkpoo DJTc+5gLpSwnnikn4i6C1YhsvVBO2m3VQNFyslNe6EnsRaGe2fwts8yFMndOxAOAAZINlCvP ybviAs9Mk7lJ2xQfNcda6NRE8fm1Hu191IUyb06kXY6rEdm6Xk6uy+aJaqBom5IVipXQCSin vrQfRbmPulBKcjI25UQcdrjI1gPghNXykYaTI5OmZIViJzTvl/Xv5d5HLNmyfjZTTsTNsCsS 2bpWTj6WHbLhl2+ZNSUpFEuhY1v2izcuZEtWuo9YsuU4QeFYPk+ur0kadlYksnWtnHytcPKi bdaUpFBshY5AOXuEx57cLbMs08oT+x4h+088edd8oBQLlcM6aZFEz9SKQMgEXXpOTsyaEhWK rdDnDBRSaFccebSpm56U65G+oCnG2ygINSFwpGFn0RGLx9uYlO3l4uRMdtyHM8WBktGUqFCs hWag4EL70sgj30cyrSihzE17RLBQ8GsPOion8rDDczJYBCdeiDpLx4liRSoOlKymBIViLzQF JSRBdE7zt1brMnyZ9gie8jS5F7CtC+U49rJqmiwksvXY21MCsCyak4nKyZdtw6YEhVJCaAJK SLXKLu9EUe677PUOSvdIx/OoE63jeboQfaoRg9xFti7NiSaS4KLj5MgO2RC9MOVEUChlhKYb 8FlS0ps59001Gb6Me2TiSdeWPCnK+92NLRfgROVk2jaNBs0rlFJCJ0lJv+C897oUX08q9Ehf JkUMvBT2c5wslSIWrxcnN5RaZEM2uylOoVTjBOUe1RiWt0+YVojUCLVPRFA8L9cZF0aGbM2c NFVP8qI5efdVlZPbpk1xCqWc0AknZ6kpq03x9djFO2HznQ4PSsEi0KRCxOLShfp4vuNJgb8W zonkuCe1yIZsTlOpQikpNAGFZNRADxMniibF1+OhnBmhHCfbNBUGD0rRYuEiOPG2yBxsa7k4 kR33IVIM2ZymUoVSVuhYo8wSJ4omxdfRTJ7xlEtxEPljOykbRZyUj2xduhA7KCBvsVo0J1+r nMiGbF5TSbKV0kKnedPfyLnvWDJlq72TTuJVwd/kbnorHdm6fCF28CiUBp4l5ET2yOY1lYSo Li/0fuTCj933+vt64shT8Z3Q2XKTJscIczfRhiUjFlcohEecECkRJxfNyZl0MoPUYsFJkim9 itDndIPbRbSnWn/fVBx5qr6TMJkkh7mb8iclIxZX4WQ7b6/D4ji5p9QibS3IbSpObFxJ6PPo fPrNnPuOhTlP5XfCQGkGqOCQD7Mna+SETMVz9k4tipMLDSeSIZvbVBzzvprQ53TSs0s332fd JywG1vbi+s2aOYkDt0gGyqI5mUgOWcbJiXlTUfamikJTE2VG97b914z7pjwotb24cpGtKxRK AkHp9+wuihOk4UQyZPObimLeVxU6yvrlP7qQ90Em9x1ztmxtL65cZOsKhZLAcqKBsnhObqi1 2HASxbyvKvR5tM7j78qhQ9P7hqktW9+LKxXZunyhNFBl31sqTiTHPa3ls9sWTTFfW2WhnyUh dJSTGsl9KSj1vTj6a11fc3RrVJh8tzycSI57WovouS9qik6NqwvNFnp2NSc10nTcyU6UOl/c gpqb6M6yLo4TyXFPa3lhxQmdGlcX+rwbc6KAktw3jVcE6xwIBgtSX7qz8Yvj5GsNJzPhDE9R Uy/J1NiB0JH7Pro4a/Ys3ZwSg1Lfi5vYRyx2ZA4JhuxSciIasoVNEUvWgdBMofjidRNFOW1T UI5qnoBs1dgcnxBGF5NlcZxIjvuIk9s2TZFFHgdCTyKFcovFMUhREc6qH1NQauSk7y1oGj5e Mk7uqbUInvtiefDA40Jodpg0ipzzUGAFCaAMyRb8k5o4GXsLcuuFmlhgi+PkQseJYMgWy4MH HhdCs4HnQihwwTjhg19QStStkPNbcNle0DKBGltwgZxIjvuYkxMbeV62AidCJ0cEFVKEqEsU lIO6OEF1ctLhlx35PW2Lz1+s40Tw3BvIQ0NUVxea+tqU+3bloAYz3UnS+XHS8erjRNjGoMa0 XSgnNzS1LIaTcy0nzKrlnbRTzUnSeW4wG9TFiZjIXY2RvUhORMd9VAvvua+PExQdOVYUCrFq pZGntvkOmavWxUkocTJYJk6ua2rhPfc1ckIGHvU+4md7KDhpL9WTGnPeAF8PJ+J2XH7Cs3hO PtZx8mIxnJx3M+8TTBTdwDPfAAIGAUkcNNcXt20rOTwWyYnokI2zwnITnho5QTSEgfY+MfpF 7++VCc9cAwiQsz81NCcdA1FyAi0dJ/yEZzk4Qaf85HionNSY70FO5NXCSQRGiJQJzwI4GeGv jUZSi+i4j2tZECd44Mm8j49+EZL9svVx4o1r4kQ8fijnoquXkw2Cyojj5J6mli9vZzZ1NlgM JxecKUuOo0mm7MIDCFRvLjZcU04Gi+NkhBFp0P+igV/LCWfIyk19ff2TuXGCB57s+75ITdmQ To5P1o4TMTyCnAO1Vk4aEiei4z7l5CSTk83ri+EEpVtn6XZvUaGsASdyuJWJlFO5dvuE5wRp OeG2KqmcqKCg4NANJ+fdnPtOxaAGx8LceK7znXo46ctheZaLkxu6WlJDVsOJnM8WF3rZGsyd k1ShsG13wtx4rv6TTi2cKGG+0gnPAjkJ99j17vU9zdX+5b2M6/uYk83vKh+3vrXn4up+sNfN /OEPfKHd3+n9zV4NV6e5hxWK8FGTfOy8Ia8pt+xVEzwWNee6b6xPhB33CW3pViWdPrmucntn x8mvV/eDZ93s+6TgF7xCmW+A6H4cCSMK9zYIJp7z5pTwkunEuJQ+GW/RwECOxh1hx31SSzrh 0dknA1Xo5y0n3fas283h5FTMe3zJWShzDjgvBQNsBmPnnIRKuNp0wlOGkwnB2XPGydcZnJxk czLQCP1SyqBRstvOczlB0c62+D5uyjNnTkIJlG1vDpzI4a8nVTihQV46lTjh/Wz4vQ80taQT HpWTb2iFlnLBlbVj8zl56Av3HfdOauIkBoVtTNTF66rcnCacfvKWS3CiDaxc3m+PhBj3aS3J hEfl5LtaoSUDpVy3PSvg5IIplGT6niqUWhOdzIWTvspJZ6s0Jx3P61fiRG5KcNxznNzO5OQT bU2SgVLWjs3nBO2KwXSOe+vDiSaNS/KRNSdjbJyMvaZDTgSHbFpLslVJlufd6/qHDUUDpWy3 FXDCLNnkvmmybFwvJ80995wk2whCxUNrzwnGhGR577jjBOk5eZHFyeY3Mx5WNFDKdtt5PidI Cro07C2EkyDou+dkW8PJoBwndIF73ESBkuXBPScnWnmwOZPxsO/t1MHJF75w3zSeGtfKCX4B Stqeqs1NNOkIk4mxLScUj3GA8PQ9cMUJv5M6rSXZqiS18/Fm1sM+bw2ccDLIve+MLPJw98W+ tlo5IQdl5cCz1WNQqpwkMFpywuiYkEIFONtwcl1bSwYnmzeyHnYiGChluy1M0qVn3Ed8stx9 l9HUuPbEjnIo4KrNjXXpkkty4qXzpL7nipOP9ZzEZzNEeYjVm/WwSXTquXJy6gv3zSJLtv4E oNLQPxdO4gmPHSfpBqcAjfNxtuCEd8hytcQTnkCaFQ8yH/ZwxwUnzz7Mv4+4UPj7Iku2fk4k z33V5tLFYa5QrA3sOPH4dWZp4HHOyQstJ2TVMOthhb0FpTk57xbct3tTuC+yZOvnRLJk58LJ uAwnY2EfXMdzxAm/k5qrJT6bEcjmSebDCgbK/Dg59U+E+5hPdgGJpztNl82l1HGF4jUfK068 pqj2Bq44uaerJZ7wCPLQ3bSZD3vntTo4Qf4t4b7L3oI4Ed9A5dwMek4Ca05C8XxYvtqz4ORC zwnScUIXDTMflt/8WJoTpBiy8n27N8/4fzJLdhGJ7IU3ULE5bvok+FW3tTVl5XanA5h0fl3M +VSeE97RxtcSTXgEaegcOvNhX7aCOjg5lWLMDg8WxIkw8FTmZKDlZEtbU1ZudyTpjwDJEYvd cxJNeAQRadHsh+Vc93Pk5EIKHUpdKIvgRBh4KjbHzZ74QhGKCidNFJC8ZBrTQ4n/lzs8WnFy Q1tL5LnnRWR7ELIflttbUJ4TZeOjcp8f5erhB55FcCL86lZsrq/nJPpY3dsddNL9MMJ9wjAT yFJW4YRzyPK1RFuVeBHZHsnsh+X2FpTn5LyIk1M5EhfZXbAIToSBp2JzXFXi/oAMTpIdmFLl mnjnAjkVOPlIz0lkyAbSrDjvYbnNj3PkZFcKAUldKAvhhHe1VWyOe5l8oci8zTh7NhEyvIfS pDi+TxiJKnDCOdpETm5LIkZbVXJ6JDVQ5qxPxKwavceL4YRX6VU50dcUtZB5RjHkQAlFHxtn Rs2XE2bIBtKsOLdHUgOlPCeKIauzT+4haeBZCCf8b29V4jKmipmcRFuQQk9YZ/Y0eQWFFctK nGinZJHnnmsjGqByeiQ1UObJiTwxJoG4ipOmT00KuZmlREUCXQ5lfU1hFifMblE52Y6PXIy9 eGgKUdjX5rPNMbdtOOEcshInJ6KI0cQop29TA2WenMzEyMMRAk8KKp/NgZMM7xh7O2T3h7ml M9AXYsaFLFPHS49w9dn0mIQv7cjb1wrNbRtOLjI4YZ77VMS4XF7fJgZKBU7kFWP1vv/7UMr6 1dNEbFMqNypkuyqzlc3JdjAW7MxSFvFYxwmxWgK0nUDj0XXhMJQcKgbmtg0nnKNNrEXiJLZj 8vo2MVAqcCIbspr7Tn3xg6EmkrlU+VfasPhVOel72Zx4D6IkyQY19bN+5ZnGUpOmC3HdSBue F0pQFisrR5xQz30qT+xnyevbxECZLyczaeC51EQyFyv/Sh8Wfx67FRNOkmzaFTwxbMKjJk0X 41jHl/W0zIqTd2/oa6ETnlSeGKe8vo0TGs+ZEyQ62tJMX1mVTxkmB84nRZpd8vzLo7/s+qUb Q1NTwwmFU8jb08nlBLni5Lq+lhcCJ8nBwdy+jfcWVOBkIhmyuvvkgUcT8V7cpEIskznYJ+nq bPZhsI7nVeCEaho1J5Cc9ziXk07TCScfZ3BCtyol8iSBDXL7Nh54KnCCDDg5k2bGw3x9ckx/ PFQNFAenggf6QsSxEb24juYIl7GLQwOFbihi9on19N2Kk9TRJtVCDNlAmhUX9G08M54zJ0g1 UHIqj0IvXfaOZZzmELUkeW/bSfALTwlZoXCSufI8VjgZ60xbMt8ZZ3MymC8nt7lzSIm1m9+3 kYEyb052b8oGSs5UJoprMD3AKuXIMSdKtKzEq5H6Tyael19TjmtdMUYyXCrEf5LFySTTzWPF SbpDVqqFRFVKYRoY9W00M67CiWTIau+TDJTZ53l+tliLHElB3dxEaRxoCk28Ju+PHUshhOWa cpbq6GRFTUqqibgf6nzCsiFbjZN7+lqIIRvI5klB30bHAufNyZm0xBMMDzIrv+QOl16KCqU6 JxMtAh1JC3S83JrydsbJnIz1S8j2m/mtOZlkc3KSOllumPVtNDOeNyeygRJcZpuoCUKkJlGh uM9eEA0WW0hKrbOdV1PeFhFSf6AMO47cgVacoCzTg3juC5z7at+ygacaJ4Pi+yTXfTCTB540 NpQQ/EJUKM6z5vDqI1A+KbMjW3K+Zm2ttj9s6I4TlHKStais9i2bGVfhRDJk9fdJBkqA5IEn TIcdIdacoFCcZGtTVEWomhAhl8JaqWkiLPMqnAxELAOHbmM7TpKQBXJTn90u2vSm9i077jV3 Ti5EAyWIzvFoKk8BCpCsUJxkCW3KhTqaoYF+llFTmMcJ+aGazMk2aMa2C04SCOSmsCGbvylf 17d04Jk7J5KBEqShUKTKuQGJ1cQrFDfZqQdIjVIj10QVSuaJsbzm6OKw4q9xs7xgx0mmqxUb srmHBrV9SweeSpyIW+4z7hMNlECIEspXfikHheQVigtOJvKQ4ml/5TteSU6wvlKTr1QP/laC k6+zOJm1j3IPq2v7ls54KnFybsKJaKAEfFA/oXLObglEd4ojTuQhZaz/lSeGRamTymNPkyyh ejDJUpxkLFJgQzYv6FJG35KBZ/6ciAZKgOSBJwlG/ESuiQs764QTalpyUWoyojTizzNqyt/M hMc1bplgq5SYYyecJKOK0tRnt/OCQmb07fNWUAMnooESIHngiXNiqsHNOYvFzWZr8vJCeUJi kTE7P0IGng2pwc0rB0Uvw8lFJidftvOCEWf1beu1apyIhmzWfYKBEiB54Alj5aHWlESJrMTJ tNc7OEm0eppdKSsbSmbGbHFarN1BqYwfjpYr7TjJ3oL0op2TLCGzbw9phq/XRXbMkn5ZcCIY KIFosaaV80omrinVMaU4oTuyD75Kdz5N2JDCXPDZ2do6GZmQwwJOOs1EP+elbsrnZGuunMza bdk8Mck1XwsngoESiONJUkj4LFBcKuX0SY+7DhgBWFXQDfDjnKzDJBNyqMn4VBTBi2xL6Ehj mqNlbUtOYg7Upign+iSCOX17R+Tkf7eiy5QTYct9Zo/wBkogTW3iQoKOCVIX7VEVToaMkJNk w2XoYVXR2abfoBxOmrSQPSfboSdObysnHyzHyUfXszk5knJqmPTtc56Tl62WLSeCIZvZI7yB EihQhIp5wtUUj0blOLlM99pGG1/6XjNkB36DPE68UJdBrtMs4mQrWh4SQyXZcTJwwMnHm9mc vC2ZJ5achK3WvDjhDZRAGWRCxTzhaorxKcfJlDsxNqXAsAO/HU+JKiFxos1IKR2nyN5p2/dK T8vk5MjlOPk6h5PbUq5JO06oqbJja5+YccLvQQlknxorNM1IShonUCjHyYzfuU/zno7VMBMW nGybcaKESrLgRL9NxpaTeN6rs2PbknlizEl87djbsYIhm90jnIESKNZIqIxEfE0RUaX1Cae4 CDMxJ4MSnBRGto456fDV27p5HHFyL2te3G6fiOaJJSc7AzQ3TrhNsoEyuwkVy5avKbJkS9ux R2JV2ETteHLOAY0dq+dkUMQJPdoxzh3UymynsuYk1hgaPxs2UD7aRKU5GQjz4rtuOeEMlADJ A0+omCdCTewnpTi5lM53YIUyxvOdwiTHY3J0Qi00LsqoQIITKMdzbDnpew44QVmcYEzat0Xz xHq+w3GyY8oJPzHO7hHOQAmQPPCEinki1MQs2TKcYOtkdiByczKO/Se5nJCjE2qhfrOIExSo OdxcbLsrwcmNbE7afGa4apy0AkNOeEM2p0dSAyUuJC7dSJtmA+FtPynJCTFcPxfBeRIivatV qifUzYs7WwXvm+xTkiMfWHMSWUEVOXk3MwTO77Z/aXNgy0lWISGlhgNOdt+QC4lLN9JeSKEm +rMSz0KPdgSSvWJckyakQKmMTyW2Z7rg5OPsUEntX7qOXHFSnGwy4WRgUnlqoOiXbqS91YE4 WhyVepZjNVwtqcqwJuXMXjApSLnliBOk3fFvy0nkQNE19eW/ueGMk0lhEsH4I86QzeXkkVwo sVxDxTyRaiIl7Z+F5cKVCuHPDGsKlUmRPN2ZFydseKvMSebprBfte844kbIcV+YkjYMSyJ5W Ukja4aZogZMSzzLsnaiFcEOmNckDTzAulZHSxXbvEpxEDhRdU+P2kTtOXhYlh0s4+dCo8iQO SiDap6yQfOo8kAyNJ/bPMtWmccGKy7QmGYug06yHk7HngJNJNicfJanRHXBSmBwu/ogzZPMq T5YCA8GoZIVmcriTQHaX2T8LUydKod5j05rkGU+gWLZz42RQnROUHUJ485+85ZATPveKA04S Q5ZfujmKCskneipogfSWJ9pCxz3jmuT5bVEqalecMMuoMif6kOTX0W9v/od2oTy3jYV+WZD0 K+VkYNIjyV6lQHCPRltEHitzi31RCxzYchIrK5UTTbAmfU3CwLOF9rxOPZxMdCcSrTlhDhSl qc3r39/8K8lAUeWZtc2Fbr1mxAlnyOb2SGzIyks32hf3QIqsctn7B7sXEKsTpdClOSfCwOMN Ol5NdixywklGKozNzc3rSDJQVHmS5OkGQj9vOeUkXgoUlm6wDXGpi+7YlTiZ9f7U7gUkXjy5 0FTXXEZN/OYDsgOpLk6owVyVk68zOXk1SoiQI8+Xsqmbm/TrrhEn6QpPbo/EBkog/HIf0L3O TxRM5FDXxz2rFzAVIh+IQ5gmmGRGTfzAo4u+Ny9O+p4TTgYZnGzeeNEukKfdvm0uNJdtMo+T 1JDN7ZE4oJ/oksfvTB0HuionUzVMZF5z6aKAUmioiTiZURO/3ahOTsYuOGEOFC0nr07FYUXH Sdtc6PxkTracxAZKII4nuqDCGk6UYBi5zU3lE+2igXJkWhPnMamTE+r4rcrJRJ/6j9gnA8lA 0W9mMhY6P5lT8lEaRbaAkzc1haa6oMLnGk4uzd8ur07UQlPVPMmsiQu/WCcnE/F4azlOUCYn +Jk+e6uQk7fNhU5nPHmcIENOvvC1hb76e2VWrNMnoRp3NrO5qXpSGUmzccOa0oHH87b6dXGC NJE17DmhR3g0nHwTxZl4MuWhm5nMhc5N0mPNyamf9eKOZHWy/77KybESTzSzuWEvr9DQwtJJ 0UiP5tTByZYDTj66rueEHrQT1IUa/KKtGihlk/SESDFQ8nsk8rRpXtyJrE5QcK5wooR1y2xu qj1ZmI5gR+avMnWhpEf9auCE2EWVOaETY6Wpd6/TQrmcJMF0TIVOBh4XnESGbKEEWJ1oCw17 hi9g2Kv2lvhCSVR8EmZ2Uhcnfc8JJwOdPvlmwBwkOfK0b1sKfdgy4SQxZAsqZ0uBhRJgdaIt pEyNM2oSy1XkJIk7zIUimD8nYxec0Imx3NTF5r0gUhmZ8rxo22aFTQaeXE6QISfMQCmSgKgT fSF5apxRk6h3qmakjE76dDxUIyehGtHJnhM6MZabwoMRK8QPPHIQ/La10DlJenhOPjTqEeZp K5KAqBN9ofxNb3FNl6LaqcpJSJ33oRiib96cTFxwgnScYOOWFeJnxtK2YiGphpnQhzsmnMQG SlHl1EApKETVSUah3oHBC5DcI5Uz3HY8r7nniaFh580JmRhX54SsGIeKeRIV4mfGuUm/jIR+ 2Rq45OTN4kJUnWSqiqPCF3BppHQsXuXEi07k1MrJlgNOPlY5ITZLkGoNrTzt2yWEzk6+wn8U GShFlT/0CwsxdZJVqHdQ9ALkNBsOMmaPo1PrdXLSaTrghEyMQ8U8iQtxjrT8JMdGQmcnXynB yWkxJ0ydZBW6zAhqkBY6LthBiepJv171vr7ngBMSsyBEylAUIHngCRV1Yi10dvIVUQsY9Qj1 tAX5I1g+cYK20KU3VZzyq8nJ2AUnZCt1qJgnSSzNdOAJpUlxGaEzk6+U4IQaskGVmZOgUDSF hubO/aXmBE+Mq3NCqAgV8yQplHrmQ2lSXEbozOQrovW5b1Q5OT2aV6jYs8vrC41L3mKxcKk5 mTjh5N1XpaaoKz8QDBFJnheRlrEW+mUrcMcJMVByChnsULhUgxFzl8WWgeXmBCkRbMtw8vGm 1BRdQk4KJQNPqKiTEkLTgaeIk/OuUeXE05ZTqGuw46mXs7Xk2G7T21JzsuWAk68lTtjWpUBw lIjyxOqkhNDvtYw42TepnJwezS50brIj+zJ7q9pUs7NkVTnpNB1wgs2RUJ4AcYWmMRShok5K CE3XeIo4QWacEE9bdqGu0YmxoZj0Sxh1/mFtOOl7DjjB+iOUxiGhUExFqKiTMkKTzQWFnJx3 jSp/eDO70LnZifZUayhHzJ+Ea8PJ2AUnaPNGKP5TLBTNgVN50ilQCaHJ5gIDTgYmlWNDNqvQ pGsWcSfNgB0oo876cBJ6ew44+eh6KM+KhULttwR5uFM7JYQmA08hJyhzN4Dsacsq1O0a9u0s js0XiJiUCn6xrJxMnHDy9WYoz4qFQtE4E8aet7cqCX1nx4CT865R5f6tjELnRhkVIlP2QCk0 o6dy1ocT5DWtOGloaznb/K48KxYLsYEmjP9xUkno562BCSf7JpXvvqEvdN7tmvftUAltMhv2 DtAV5mTUyNAn35BnxWKhF3Q158UJG3VuVxTaKPlK9/darZ39gsqf/4z/rzSFunjUGZj3LVYe j2f8wZ8IkzXihORT6Jtz0sji5Dr/j4FaiJ6/+PJtikm7qtCHJpycd1s73UJOftr31ULPlPM6 BWJiY+RzLhzGLA4nvD6ceB1v4hlzMkJZnHCRYqNIodKBTAIKZUU8AVhK6Kwgs4dRKOtfpYW6 P+wacfKdfcloJcf/PrTr22N23pS53L5Kok6vESeeNzbnBGVzkuQBTHIfiIVe0LM6X8oHAJ1y Il4/2zXg5Gd8rFDiaz/BpGvbtwyUE2atJMHJ14oTz5KTcE+5vk9OnSff72mv32iz65f3Kl/v EQy+JXyk4YS87t9r5V87GBP/O13lspfpmM/otrd2F+WE/+B+WX0SK5TEVJELfUkxedsB3Ko+ eSnaJyRd3I4BJ+/8iHHC/CXcVeJ38Csx8R/okwxO7glONp08msPEbjiZ6JJ+Pd8p4uQdXGAX c7LPGyalOYly/2GLFq0lJ3uOOImskjSVilxopjlMXIGT5Kzx5I42OdxzqlEyK59QHn4Y2bHi jLocJ+rB9HXipBn2XXDyjWiWc5Fm8JILUUv2xB0nESiUkh0dJxpQ0uBcTG08b/2U/45i7Jbj ZNpDa8xJEE4ccPJq+DUbb97dRLmcvO2QEz7zl5YTOuVRK59Eg8uAFPaHLVsAAASsSURBVPpp vZ+thJizx2vMCTmX0a/MyQTXQsInYcXyzdp6JBlu7ubcJ82Nw8RgHSzNi1sNvz1ysa+A1ELn PJubdfbIHd5MycizIVqlYaRLPlxLBFaCExq5j0/gVXOPZN2nOkdE7xtwUjMnFxiT76Gl40QB ZbC2CKwGJwsulHffs5iR9UYAOKnICRQCTgCB5eWkIX8w2lA+2lArCjWFGoU1jUwKaZproPtS sRF+2IZBIbmuBu42TaFGYU2K6CMUKJWH0tPgf8qFNjZCfGtxIU1N0n34nvvifbhQqNSE/yso ZMLJSHlL+GHlMihoGNwXFNeE0H2T5mQIcWMNuZNQKImgLTSSfhFwoUC6b8OwOekT/NF9pfJQ ug//UyqEf/wK2kDFhdSaAvE+8mj35V+C0UipqSH9YmgKGXDSaKiqQn27ZTlBbjhpKC9uRAo1 5EKBWkh6lQ2Fk1FGc0ipaSR/dF+pXOYEKQjg65WR8sSBWggpNUmcIJUTKpXmvahPY80JKsnJ Kw1V6Zhw0ijDCVJ/wbXjTqAphOQhJWgoQwrSNIeKmlM5QYacoJKcKBCov+RaTkaoJk40Fb2i MT2UqlXTw8QcGqnKqjwnI9U+aWhMD6W5YnNIa5805N/58pzI/aLjRDH3RiPlXWk4KWGf6Dhp FOuTUdgoNmI2NMSZGDEbr5TmpFGsT+4jjT6RC21oiEMG+mS0MVKHBqk9xdJBiolKCskfNYKG XEjpFdQYNZTHU95Lw40+GaEynGgKNUpyUn7cGaEynGgKNUpygpT7dIVG6pDdQIU1KZzoFOhI N9Ci/EIlOXnFgJMNzVTZhJPGfDlpGHAii27KSaMMJw11UqTOnDIAV2qSRpkRUjhpqBM8derQ cMPJKEQG82KTcackJxmGpQEn9xEy+PUyGXfKctLQvSVpWqrMnNRfsQaSLWItFEgtNFKak3tF LVSOE42qMPSzGXjsVE50frZXSvrZNKrC0M9m0JzmF0PnZ5P7MpBtxo1XFH/ZhqQqSCGpX0hN EhT4nvtKIcVE3ZAnz7pCBpyA3x789sAJcAKcQCHgBDgBToAT4AQ4AU6AE+AEOAFOgBPgBDgB ToAT4AQ4AU6AE+AEOAFOFlVobhdwApwAJ8AJcAKcACfACXACnAAnwAlwApwscaGNDau3rm5n z/geOFmrQiPdGasc5WDwCXCyhoUaBm8aOLnynIwYK+SgzgY9fzYaNRob5N3SI+fki/6MvuuN Bv2msdGIf5aWa5D/j+h5qejnwMnacTJC7A/hhMZEaERHzhvxz5jeYWcpN1D8M64cubHBjq5H PwdO1o6TBhuAkmBIoyiKyYh9Hp1QbySfRD+jkTC47xujuBYEnAAnKicEBuDkCnKysbERc7Kx EZklMiesDGOCmCds/NpoACdXSZ8gTp/EykTWJ0gdd5LwOsDJGs6Li8adDE5GwMnV8rOl852N UYQEi56lne9EHCTzIfqV2CfAyRr77SP/CbZGY7M0Akj2n3CcxP4TFhoG7JMrUmhuF3ACnAAn wAlwApwAJ8AJcAKcACfACXACnAAnwMmaFBqYfDQpUQg4gXPoCM6hQyHgBDgBToAT4AQ4WUVO /j8cCcF+UZk7IAAAAABJRU5ErkJggg== --=_north-23478-1343140022-0001-2 Content-Type: text/plain; charset=windows-1252; name="query.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="query.txt" Cm15c3FsPiBzZWxlY3QgY291bnQoKikgZnJvbSBzcGYgd2hlcmUgZGF0YSBybGlrZSAndj1z cGYxIC4qIHB0clsgOl0nOworLS0tLS0tLS0tLSsKfCBjb3VudCgqKSB8CistLS0tLS0tLS0t Kwp8ICAgIDQxODA5IHwKKy0tLS0tLS0tLS0rCjEgcm93IGluIHNldCAoMS42MCBzZWMpCgpt eXNxbD4gc2VsZWN0IGNvdW50KCopIGZyb20gc3BmIHdoZXJlIGRhdGEgcmxpa2UgJ3Y9c3Bm MSAuKiBwdHJbIDpdLiogcHRyWyA6XSc7CistLS0tLS0tLS0tKwp8IGNvdW50KCopIHwKKy0t LS0tLS0tLS0rCnwgICAgICA0MTkgfAorLS0tLS0tLS0tLSsKMSByb3cgaW4gc2V0ICgyLjY1 IHNlYykKCm15c3FsPiBzZWxlY3QgY291bnQoKikgZnJvbSBzcGYgd2hlcmUgZGF0YSBybGlr ZSAndj1zcGYxIC4qIHB0clsgOl0uKiBwdHJbIDpdLiogcHRyWyA6XSc7CistLS0tLS0tLS0t Kwp8IGNvdW50KCopIHwKKy0tLS0tLS0tLS0rCnwgICAgICAxMzggfAorLS0tLS0tLS0tLSsK MSByb3cgaW4gc2V0ICgzLjMzIHNlYykKCmV0Yy4gZXRjLiBldGMuCgoKCgoKbXlzcWw+IHNl bGVjdCBkb21haW4sIGRhdGEgZnJvbSBzcGYgd2hlcmUgZGF0YSBybGlrZSAndj1zcGYxIC4q IHB0clsgOl0uKiBwdHJbIDpdLiogcHRyWyA6XS4qIHB0clsgOl0uKiBwdHJbIDpdLiogcHRy WyA6XS4qIHB0clsgOl0uKiBwdHJbIDpdJzsKKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwp8IGRvbWFpbiAgICAgICAgICAgfCBkYXRhICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CistLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsKfCBtb25hcmNoaW5jLmNvbSAgIHwgdj1zcGYxIGEgcHRyIG14Om1haWwubW9uYXJj aGluYy5jb20gcHRyOndvb2RwcmVjaXNpb24uY29tIHB0cjpidXlyaXRlZXF1aXBlbnQuY29t IHB0cjptdWxsaWdhbi1pc2xhbmQuY29tIHB0cjptdWxsaWdhbnNpc2xhbmQuY29tIHB0cjpw YXJhcmVzdC5jb20gcHRyOnBhcmFtb3VudHJlc3RhdXRhbnQuY29tIHB0cjpwbWluZHVzdHJp ZXMubmV0IHB0cjptb25hcmNoaW5jLmNvbSBwdHI6b25lY29tbXVuaWNhdGlvbnMubmV0IHB0 cjpvbmVjb21tdW5pY2F0aW9ucy5jb20gcHRyOmNveG1haWwuY29tIC1hbGwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAp8 IGNoYy5lZHUgICAgICAgICAgfCB2PXNwZjEgaXA0OjY2LjcuMTMzLjIyMiBpcDQ6NjYuNy4x MzMuMTk1IHB0cjplczAxLmNoYy5lZHUgcHRyOm1haWwuY2hjLmVkdSBwdHI6ZXMwMi5jaGMu ZWR1IHB0cjplczAzLmNoYy5lZHUgcHRyOnJlcGVhdC5jaGMuZWR1IHB0cjpjaGN0ZXJtLmNo Yy5lZHUgcHRyOm15LmNoYy5lZHUgcHRyOnBhdDIuY2hjLmVkdSBwdHI6cmVwZWF0ZXIuY2hj LmVkdSBwdHI6cmVwZWF0cy5jaGMuZWR1IGlwNDo2Ni43LjEzMy4yMDAgaXA0OjY2LjcuMTMz LjIwNiBpcDQ6NjYuNy4xMzMuMjA4IGlwNDo2Ni43LjEzMy4yMDkgaXA0OjY2LjcuMTMzLjIx MyBpcDQ6NjYuNy4xMzMuMjEyIGluY2x1ZGU6dGFyZ2V0eC5jb20gaW5jbHVkZTpibGFja2Jv YXJkLmNvbSBpbmNsdWRlOm5pbmcuY29tIGluY2x1ZGU6d2MwOS5uZXQgaW5jbHVkZTpzcGYu cG9zdGluaS5jb20gaW5jbHVkZTptaC5ibGFja2JvYXJkLmNvbSAgfmFsbCB8CnwgYmFrZXJk aXN0LmNvbSAgICB8IHY9c3BmMSBhIG14IHB0ciBhOmFjcmdyb3VwLmNvbSBhOmNvYXN0bGlu ZWRpc3RyaWJ1dGlvbi5jb20gcHRyOmFjcmdyb3VwLmNvbSBwdHI6Y29hc3RsaW5lZGlzdHJp YnV0aW9uLmNvbSBwdHI6ZWFzdC53YXRzY28uY29tIHB0cjpoZWF0aW5nY29ycG9yYXRlZC5j b20gcHRyOmhvbWFucy5jb20gcHRyOnRyYWRld2luZHNodmFjLm5ldCBwdHI6d2VhdGhlcnRy b2wuY29tIGlwNDo2OC42NC4zNC4xOTcgaXA0OjY1LjEgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKfCBiZWNrY2hyeXNsZXIu Y29tIHwgdj1zcGYxIG14IHB0ciBwdHI6Y2hlY2tiZWNrLmNvbSBwdHI6YmVja25pc3Nhbi5j b20gcHRyOmZyc3JlcG8uY29tIHB0cjpiZWNrbWFpbHNlcnZlci5jb20gcHRyOmxvc3Njb250 cm9sc3VydmV5cy5jb20gcHRyOmJlY2ttaXRzdWJpc2hpLmNvbSBwdHI6ZXpvYXNpcy5jb20g cHRyOmphbmRid2hvbGVzYWxlLmNvbSBteDpiZWNrbWFpbC5iZWNrY2hyeXNsZXIuY29tIGlu Y2x1ZGU6Y2xpZW50LmRlYWxlci5jb20gbXg6Y2hlY2tiZWNrLmNvbSBteDpiICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAorLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCjQgcm93cyBpbiBzZXQgKDYuOTUgc2VjKQoKZXRj LiBldGMuIGV0Yy4KCmV0Yy4gZXRjLiBldGMuCgoKCgpteXNxbD4gc2VsZWN0IGRvbWFpbiwg ZGF0YSBmcm9tIHNwZiB3aGVyZSBkYXRhIHJsaWtlICd2PXNwZjEgLiogaW5jbHVkZVsgOl0u KiBpbmNsdWRlWyA6XS4qIGluY2x1ZGVbIDpdLiogaW5jbHVkZVsgOl0uKiBpbmNsdWRlWyA6 XS4qIGluY2x1ZGVbIDpdLiogaW5jbHVkZVsgOl0uKiBpbmNsdWRlWyA6XS4qIGluY2x1ZGVb IDpdLiogaW5jbHVkZVsgOl0uKiBpbmNsdWRlWyA6XS4qIGluY2x1ZGVbIDpdLiogaW5jbHVk ZVsgOl0uKiBpbmNsdWRlWyA6XSc7CistLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwp8IGRvbWFpbiAgICAgICAgICAgICB8IGRhdGEgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rCnwga3VsbHlzdXBwbHkuY29tICAgIHwgdj1zcGYxIG14IGluY2x1 ZGU6ZHJpbmtpbmdmb3VudGFpbmRvY3Rvci5jb20gaW5jbHVkZTpzbG9hbnBsdW1iaW5ncGFy dHMuY29tIGluY2x1ZGU6enVybnByb2R1Y3RzLmNvbSBpbmNsdWRlOndhdGVybGVzc3VyaW5h bGNhcnRyaWRnZXMuY29tIGluY2x1ZGU6b3V0ZG9vcmRyaW5raW5nZm91bnRhaW5zLmNvbSBp bmNsdWRlOnNwb3J0c2JvdHRsZWZpbGxlcnMuY29tIGluY2x1ZGU6ZXlld2FzaGVxdWlwbWVu dC5jb20gaW5jbHVkZTp3YXRlcmZpbHRlcnNvbmx5LmNvbSBpbmNsdWRlOmhhd3NwbHVtYmlu Z3Byb2R1Y3RzLmNvbSBpbmNsdWRlOmhhbHNleXRheWxvcnByb2R1Y3RzLmNvbSBpbmNsdWRl OmVsa2F5Y29tbWVyY2lhbC5jb20gaW5jbHVkZTpzcGVha21hbnBsdW1iaW5ncHJvZHVjdHMu Y29tIGluY2x1ZGU6YnJhZGxleXBsdW1iaW5ncGFydHMuY29tIGluY2x1ZGU6ZmlzaGVycGx1 bWJpbmdwcm9kdWN0cy5jb20gaW5jbHVkZTpvYXNpc3BsdW1iaW5ncHJvZHVjdHMuY29tIGlu Y2x1ZGU6a3VsbHkgfAp8IHByb2FjdGlvbm1lZGlhLmNvbSB8IHY9c3BmMSBteCBpbmNsdWRl OnNtdHAuc2VjdXJlc2VydmVyLm5ldCBpbmNsdWRlOjcwLjg2LjYuMiBpbmNsdWRlOjcwLjg2 LjYuMyBpbmNsdWRlOjcwLjg2LjYuNCBpbmNsdWRlOjcwLjg2LjYuNSBpbmNsdWRlOjcwLjg2 LjYuNiBpbmNsdWRlOjcwLjg2LjYuNyBpbmNsdWRlOjcwLjg2LjYuOCBpbmNsdWRlOjcwLjg2 LjYuOSBpbmNsdWRlOjcwLjg2LjYuMTAgaW5jbHVkZTo5OC4xOTEuOTcuNSBpbmNsdWRlOjcw Ljg1LjE1Ny44MiBpbmNsdWRlOjIwOS4yNTMuMzguMTgwIGluY2x1ZGU6NjcuNTEuMTc4Ljk5 IH5hbGwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwKKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rCjIgcm93cyBpbiBzZXQgKDEzLjQ5IHNlYykKCgoKCgpteXNxbD4gc2VsZWN0 IGRvbWFpbiwgZGF0YSBmcm9tIHNwZiB3aGVyZSBkYXRhIHJsaWtlICd2PXNwZjEgLiogbXhb IDpdLiogbXhbIDpdLiogbXhbIDpdLiogbXhbIDpdLiogbXhbIDpdLiogbXhbIDpdLiogbXhb IDpdLiogbXhbIDpdLiogbXhbIDpdLiogbXhbIDpdLiogbXhbIDpdJzsKKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwp8IGRvbWFpbiAgICAgICAg ICAgICAgIHwgZGF0YSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CistLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKfCBzb3NidXp6LmNvbSAgICAgICAgICB8 IHY9c3BmMSBhIG14IHB0ciBteDptYWlsMS5zb3NidXp6LmNvbSBteDptYWlsbGIuc29zYnV6 ei5jb20gbXg6bWFpbHByZC5zb3NidXp6LmNvbSBteDptYWlsMi5zb3NidXp6LmNvbSBteDpt YWlsMy5zb3NidXp6LmNvbSBteDptYWlsNC5zb3NidXp6LmNvbSBteDptYWlsNS5zb3NidXp6 LmNvbSBteDptYWlsNi5zb3NidXp6LmNvbSBteDptYWlsNy5zb3NidXp6LmNvbSBteDpzb3Ni dXp6LmNvbSArYWxsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAp8IHBhdWxzYWNlaGFyZHdhcmUuY29tIHwgdj1z cGYxIGEgbXggaXA0OjIxNi4yNy4yMDQuNzAgaXA0OjIxNi4yNy4yMDQuNjkgYTptYWlsMS50 cmlhZGluZXQuY29tIG14OmV4Y2hhbmdlLnBhdWxzYWNlaGFyZHdhcmUuY29tIG14Om1haWwx LnRyaWFkaW5ldC5jb20gYTptYWlsMS50cmlhZGluZXQubmV0IGE6bWFpbDIudHJpYWRpbmV0 LmNvbSBhOm1haWwyLnRyaWFkaW5ldC5uZXQgYTpnYTEudHJpYWRpbmV0LmNvbSBhOmdhMi50 cmlhZGluZXQuY29tIGE6bWFpbHN0b3JlMS5zZWN1cmVzZXJ2ZXIubmV0IG14Om1haWwxLnRy aWFkaW5ldC5uZXQgbXg6bWFpbDIudHJpYWRpbmV0LmNvbSBteDptYWlsMS50cmlhZGluZXQu bmV0IG14Om1haWwyLnRyaWFkaW5ldC5jb20gbXg6bWFpbDIudHJpYWRpbmV0Lm5ldCBteDpn YTEudHJpYWRpbmV0LmNvbSBteDpnYTIudHJpYWRpbmV0LmNvbSBteDptYWlsc3RvcmUxLnNl Y3VyZXNlcnZlci5uZXQgP2FsbCB8CnwgdXVpbmMuY29tICAgICAgICAgICAgfCB2PXNwZjEg YSBteCBpcDQ6NzIuNTIuMTMxLjcyIG14IGlwNDo2OC4yMzAuMjQxLjIxNSBteCBpcDQ6Njgu MjMwLjI0MS4yMTYgbXggaXA0OjIwNi4yMjUuMTY0LjIxIG14Omluc3VyZXNvY2tldC5jb20g bXg6YWdlbmN5d29ya3MuY29tIG14OnJlbGF5LmFnZW5jeXdvcmtzLmNvbSBteDpteXdlYm1h aWxub3cuY29tIG14IGlwNDoyMTYuMjEuMjQ3LjIxIG14IGlwNDo2OC4yMzAuMjQxLjIxMyAg bXg6a2Nhcmxzb24uc2VydmVyZGF0YS5uZXQgLWFsbCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKfCBhbWdlbi5jb20gICAgICAgICAgICB8IHY9c3BmMSBhIG14 IHB0ciBteDpteDEuYW1nZW4uY29tIG14Om14Mi5hbWdlbi5jb20gbXg6bXgzLmFtZ2VuLmNv bSBteDpteDQuYW1nZW4uY29tIG14Om14MDEuYW1nZW4uY29tIG14Om14MDIuYW1nZW4uY29t IG14Om14MDMuYW1nZW4uY29tIG14Om14MDQuYW1nZW4uY29tIG14Om14MDUuYW1nZW4uY29t IG14Om14MDYuYW1nZW4uY29tIG14Om14MC5hbWdlbi5zYXZ2aXMubmV0IG14Om14MS5hbWdl bi5zYXZ2aXMubmV0IC1hbGwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAp8IGJzaWJyb2tlci5jb20gICAgICAgIHwgdj1zcGYxIGEgbXggaXA0 OjY4LjIzMC4yNDEuMjE2IG14OnJlbGF5LmFnZW5jeXdvcmtzLmNvbSBteCBpcDQ6NzIuNTIu MTMxLjcyIG14IGlwNDoyMTYuMjEuMjQ3LjIxIG14IGlwNDoyMDYuMjI1LjE2NC4yMSBteDpp bnN1cmVzb2NrZXQuY29tIG14OiouYXAybWFpbC5jb20gbXg6YWdlbmN5d29ya3MuY29tIG14 Om15d2VibWFpbG5vdy5jb20gbXggaXA0OjIxNi4yMS4yNDEuMjEgbXg6ZGFvdXN0MS5zZXJ2 ZXJkYXRhLm5ldCAtYWxsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CnwgY2Fuc2xpbS5uZXQgICAgICAgICAgfCB2PXNwZjEgYSBteCBwdHIgbXg6 bWFpbC5jYW5zbGltLm5ldCBteDptYWlsZXIuY2Fuc2xpbS5uZXQgbXg6bWFpbDIuY2Fuc2xp bS5uZXQgbXg6c210cDIuY2Fuc2xpbS5uZXQgbXg6c210cDMuY2Fuc2xpbS5uZXQgIG14OkFT UE1YLkwuR09PR0xFLkNPTSBteDpBTFQxLkFTUE1YLkwuR09PR0xFLkNPTSBteDpBTFQyLkFT UE1YLkwuR09PR0xFLkNPTSBteDpBU1BNWDIuR09PR0xFTUFJTC5DT00gbXg6QVNQTVgzLkdP T0dMRU1BSUwuQ09NfmFsbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKfCBiaXNpbHF1ZS5jb20gICAgICAgICB8IHY9c3BmMSBteCBpcDQ6ODEuOTAuNDku MTQ2IHB0cjptYWlsLmJpc2lscXVlLmNvbSBteDptYWlsLmJpc2lscXVlLmNvbSBpcDQ6NjIu MjguNjAuNzYgbXg6YmlibG9jby5wdCBteDpiaS1ibG9jby5wdCBteDpiaWJyaWdodC5jb20g bXg6YmktYnJpZ2h0LmNvbSBteDpiaWJyaWdodC5wdCBteDpiaS1icmlnaHQucHQgbXg6Ymlq b3kucHQgbXg6Ymktam95LnB0IG14OnVrLmJpc2lscXVlLmNvbSBteDpiaXNpbHF1ZS5jb20g K2FsbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCjcg cm93cyBpbiBzZXQgKDcuNzYgc2VjKQoKZXRjLiBldGMuIGV0Yy4KCmV0Yy4gZXRjLiBldGMu CgoKCgpteXNxbD4gc2VsZWN0IGRvbWFpbiwgZGF0YSBmcm9tIHNwZiB3aGVyZSBkYXRhIHJs aWtlICd2PXNwZjEgLiogZXhpc3RzWyA6XS4qIGV4aXN0c1sgOl0uKiBleGlzdHNbIDpdLiog ZXhpc3RzWyA6XSc7CistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKfCBkb21h aW4gICAgICAgICAgICAgICAgICAgICAgICAgICB8IGRhdGEgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rCnwgY291bnRyeWNsdWIud3Jucy5jb20gICAgICAgICAgICAgfCB2PXNwZjEg aXA0OjIwOS4yMDguMTQzLjQwLzI3IGlwNDoyMDguOTUuMTMzLjAvMjQgZXhpc3RzOnRyaXRv bmxveWFsdHkuY29tIGV4aXN0czpib3VuY2UudHJpdG9ubG95YWx0eS5jb20gZXhpc3RzOmVu dGljZW50LmNvbSBleGlzdHM6bGlzdGVuZXJuZXR3b3JrLmNvbSAtYWxsIHwKfCBrcmxkLWFt Lmxpc3RlbmVybmV0d29yay5jb20gICAgICB8IHY9c3BmMSBpcDQ6MjA5LjIwOC4xNDMuNDAv MjcgaXA0OjIwOC45NS4xMzMuMC8yNCBleGlzdHM6dHJpdG9ubG95YWx0eS5jb20gZXhpc3Rz OmJvdW5jZS50cml0b25sb3lhbHR5LmNvbSBleGlzdHM6ZW50aWNlbnQuY29tIGV4aXN0czps aXN0ZW5lcm5ldHdvcmsuY29tIC1hbGwgfAp8IHZpcGNsdWIuOTQ3dGhld2F2ZS5jb20gICAg ICAgICAgIHwgdj1zcGYxIGlwNDoyMDkuMjA4LjE0My40MC8yNyBpcDQ6MjA4Ljk1LjEzMy4w LzI0IGV4aXN0czp0cml0b25sb3lhbHR5LmNvbSBleGlzdHM6Ym91bmNlLnRyaXRvbmxveWFs dHkuY29tIGV4aXN0czplbnRpY2VudC5jb20gZXhpc3RzOmxpc3RlbmVybmV0d29yay5jb20g LWFsbCB8CnwgYm9ic2ZyaWVuZHMuYm9iOTMzLmNvbSAgICAgICAgICAgfCB2PXNwZjEgaXA0 OjIwOS4yMDguMTQzLjQwLzI3IGlwNDoyMDguOTUuMTMzLjAvMjQgZXhpc3RzOnRyaXRvbmxv eWFsdHkuY29tIGV4aXN0czpib3VuY2UudHJpdG9ubG95YWx0eS5jb20gZXhpc3RzOmVudGlj ZW50LmNvbSBleGlzdHM6bGlzdGVuZXJuZXR3b3JrLmNvbSAtYWxsIHwKfCBjbHViLmtlejk5 OS5jb20gICAgICAgICAgICAgICAgICB8IHY9c3BmMSBpcDQ6MjA5LjIwOC4xNDMuNDAvMjcg aXA0OjIwOC45NS4xMzMuMC8yNCBleGlzdHM6dHJpdG9ubG95YWx0eS5jb20gZXhpc3RzOmJv dW5jZS50cml0b25sb3lhbHR5LmNvbSBleGlzdHM6ZW50aWNlbnQuY29tIGV4aXN0czpsaXN0 ZW5lcm5ldHdvcmsuY29tIC1hbGwgfAp8IGNsdWJ5cmV3YXJkcy53bmN5LmNvbSAgICAgICAg ICAgIHwgdj1zcGYxIGlwNDoyMDkuMjA4LjE0My40MC8yNyBpcDQ6MjA4Ljk1LjEzMy4wLzI0 IGV4aXN0czp0cml0b25sb3lhbHR5LmNvbSBleGlzdHM6Ym91bmNlLnRyaXRvbmxveWFsdHku Y29tIGV4aXN0czplbnRpY2VudC5jb20gZXhpc3RzOmxpc3RlbmVybmV0d29yay5jb20gLWFs bCB8CnwgY2hpY2Fnb3BvaW50cy5jaGljYWdvdHJpYnVuZS5jb20gfCB2PXNwZjEgaXA0OjIw OS4yMDguMTQzLjQwLzI3IGlwNDoyMDguOTUuMTMzLjAvMjQgZXhpc3RzOnRyaXRvbmxveWFs dHkuY29tIGV4aXN0czpib3VuY2UudHJpdG9ubG95YWx0eS5jb20gZXhpc3RzOmVudGljZW50 LmNvbSBleGlzdHM6bGlzdGVuZXJuZXR3b3JrLmNvbSAtYWxsIHwKfCByZXdhcmRzLnRoZWZp c2hhdGxhbnRhLmNvbSAgICAgICB8IHY9c3BmMSBpcDQ6MjA5LjIwOC4xNDMuNDAvMjcgaXA0 OjIwOC45NS4xMzMuMC8yNCBleGlzdHM6dHJpdG9ubG95YWx0eS5jb20gZXhpc3RzOmJvdW5j ZS50cml0b25sb3lhbHR5LmNvbSBleGlzdHM6ZW50aWNlbnQuY29tIGV4aXN0czpsaXN0ZW5l cm5ldHdvcmsuY29tIC1hbGwgfAp8IGJ1enpwb2ludHMuc2FjYmVlLmNvbSAgICAgICAgICAg IHwgdj1zcGYxIGlwNDoyMDkuMjA4LjE0My40MC8yNyBpcDQ6MjA4Ljk1LjEzMy4wLzI0IGV4 aXN0czp0cml0b25sb3lhbHR5LmNvbSBleGlzdHM6Ym91bmNlLnRyaXRvbmxveWFsdHkuY29t IGV4aXN0czplbnRpY2VudC5jb20gZXhpc3RzOmxpc3RlbmVybmV0d29yay5jb20gLWFsbCB8 CnwgcmV3YXJkcy5xMTA0My5jb20gICAgICAgICAgICAgICAgfCB2PXNwZjEgaXA0OjIwOS4y MDguMTQzLjQwLzI3IGlwNDoyMDguOTUuMTMzLjAvMjQgZXhpc3RzOnRyaXRvbmxveWFsdHku Y29tIGV4aXN0czpib3VuY2UudHJpdG9ubG95YWx0eS5jb20gZXhpc3RzOmVudGljZW50LmNv bSBleGlzdHM6bGlzdGVuZXJuZXR3b3JrLmNvbSAtYWxsIHwKKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKwoxMCByb3dzIGluIHNldCAoNC41NyBzZWMpCgoKCgoKCg== --=_north-23478-1343140022-0001-2-- From vesely@tana.it Tue Jul 24 08:13:44 2012 Return-Path: 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 6EAE721F86A4 for ; Tue, 24 Jul 2012 08:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 AOf+JYRSFniy for ; Tue, 24 Jul 2012 08:13:43 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A7FBF21F869F for ; Tue, 24 Jul 2012 08:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1343142811; bh=EEoZGxwPcECbDxPq32EI1th1Wi7V1Cwcng8Kg4SPLWY=; l=1749; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=mATBkYO6POVqPaicJVu1v5lk1rG3VK0xwmmhhhcmdin3YDrXljTukG0aMVcOY+Ia4 3fKcJ2W7y8QJntzdQwY/awkJon9uNDInxF13fsyFzrbHji/UaWJssaWwVSMTmuo6j3 KIYv9riZrNiq/1Bmggcle+STpz03tpnEQkByMxns= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 24 Jul 2012 17:13:31 +0200 id 00000000005DC04C.00000000500EBB9B.000066FF Message-ID: <500EBB9A.9050303@tana.it> Date: Tue, 24 Jul 2012 17:13:30 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <500D16E0.3090607@tana.it> <500E533F.9050002@isdg.net> In-Reply-To: <500E533F.9050002@isdg.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 15:13:44 -0000 On Tue 24/Jul/2012 09:48:15 +0200 Hector Santos wrote: > > The PTR "Slowness" issue IME has become a "thing of the past' with > faster hardware, high speed connectivity, better DNS databases, better > DNS setups, records, automated caching and/or record assignments, > temporary or otherwise makes the rDNS more feasible today and probably > this is reflective in the greater amount of application enabling it, > like many MTAs now requiring clients to have a PTR record. For me, > this was a real case where we did follow the market trend, the market > leaders because the overhead was there for the customer base we > served. I pay very careful attention to optimizing our product because > it pays in the long run to have a high QA out of the box with little > support overhead, and in the two years since we implemented rDNS for > our customer Anti-Spam scripts, I haven't heard one complaint yet. It is not so much the performance as the effectiveness and reliability of the results. No doubt, some domains are able to use PTR in a reasonable way. However, rDNS is already a "derived" datum, in the sense that it should be set after the corresponding DNS entries. Errors may remain unnoticed for a long time. As a third-hand tool, PTR can give a false sense of soundness. In addition, SERVFAIL cases seem to be more frequent when using PTR, possibly because secondary servers are not set up equally well for rDNS, if those zones are delegated at all. It is true that EXISTS and IP6 are even less used than PTR, but if I were to strike mechanisms from the spec --in order to simplify it-- I'd choose PTR and MX: They seem to be more suitable for heuristic reasoning than for conveying precise policy statements. From hsantos@isdg.net Tue Jul 24 09:40:49 2012 Return-Path: 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 F422911E808E for ; Tue, 24 Jul 2012 09:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.194 X-Spam-Level: X-Spam-Status: No, score=-102.194 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 rbJ+cf+h-oP3 for ; Tue, 24 Jul 2012 09:40:47 -0700 (PDT) Received: from mail.catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B4EB511E8088 for ; Tue, 24 Jul 2012 09:40:35 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4094; t=1343148023; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=qFPFLssm7Vq6hPano9FtV7Y15yc=; b=M/+qI+IailV3gh2tEXiX E+iI73ZCLH7uiNzhFeq1v+ICmW04hQ5bXkeMJm589Pn3HD6pkmvM0kU5S8ZM6NCC nfCn5F0VrcCP0ADXPMf7b4+HWB8YRM70LfMm7cfMabPXm6Hvv2GYHRCk/CoIHWw+ JPMkxFV1UxCQ3EW5l8dLxzY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 24 Jul 2012 12:40:23 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3464815863.22778.4724; Tue, 24 Jul 2012 12:40:21 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4094; t=1343147880; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=7JnlYNH U8BYH8B5+jDfH3l8I1/EiZYoZC/nEc0ONPBU=; b=FxbkdoIa5zQrxlYukSGnt3I BKmD5SjljQvGcXPl8bhSWRMap4ozVYp4C1ji6oPQqR2ONePSvmwjUmnovP4xXo02 jSEFwrUUkvbFwGDciiK6Bqo8TH5GxTPL3xkaRoOJ2cM1OoZe/w1J/PG8UXlOV/Iy J/1ZF5QjNzUe4829lyNc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 24 Jul 2012 12:38:00 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4063646410.9.7008; Tue, 24 Jul 2012 12:38:00 -0400 Message-ID: <500ECFF4.50509@isdg.net> Date: Tue, 24 Jul 2012 12:40:20 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alessandro Vesely References: <6.2.5.6.2.20120718130921.0a394300@elandsys.com> <5007322E.9080009@Commerco.Net> <500D16E0.3090607@tana.it> <500E533F.9050002@isdg.net> <500EBB9A.9050303@tana.it> In-Reply-To: <500EBB9A.9050303@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] A standards track document defining SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 16:40:49 -0000 Hi, this is probably all true, no reason to doubt it, but unless there is an real cost impact/problem analysis to warrant deprecation, we are simply speculating about something we may or may not still believe is a problem today as it was more sure of yesteryears. Consider, this change was done on assumption, not based on any report of a real measured problem existing costing anyone a problem or even the costing the network. We are making an intelligence engineering guess since it is "overhead" therefore its a problem, and we were wrong that it wasn't in use, therefore its open for deprecation. Thats a big impact. Consider, we all knew about the cost of PTR and yet, I don't see any resistance or barriers to usage. As you noted, it was mentioned in the old draft, yet, it still happen. In other words, if we had annual data collection, if this old recommendation was followed, then we would expect the usage of PTR to be on a down curve, and not only for SPF but for MTAs and other applications - less applied usage. In fact, I submit we are seeing the opposite - an annual increase usage (at the more applied usage level). I call it becoming more feasible today. Look, we can say the same for some many things that the purist will tell ya is high overhead, for example XML, Javascripting, etc. XML today is viewed as a "Language" for god sake by application developers, and it took a while but even system level developers have given in. It all has to do with the increase speed and throughput of processing allowing its "productivity" value to be realized and feasible to use. Would many even consider using XML in years past for XYZ applications? I say no. Today, Yes. People don't even sweat it. Same with JSON, same with depending on interpretative languages as opposed to compiled or even p-code, why? Well, interpretative feeds into dynamic thinking, artificial intelligence creatively, code creating code, etc. Ok with JIT, pcode, but not as dynamic if compiled code/data was done for the purpose of obtaining high speed. Its a balance of size vs speed. -- HLS Alessandro Vesely wrote: > On Tue 24/Jul/2012 09:48:15 +0200 Hector Santos wrote: >> The PTR "Slowness" issue IME has become a "thing of the past' with >> faster hardware, high speed connectivity, better DNS databases, better >> DNS setups, records, automated caching and/or record assignments, >> temporary or otherwise makes the rDNS more feasible today and probably >> this is reflective in the greater amount of application enabling it, >> like many MTAs now requiring clients to have a PTR record. For me, >> this was a real case where we did follow the market trend, the market >> leaders because the overhead was there for the customer base we >> served. I pay very careful attention to optimizing our product because >> it pays in the long run to have a high QA out of the box with little >> support overhead, and in the two years since we implemented rDNS for >> our customer Anti-Spam scripts, I haven't heard one complaint yet. > > It is not so much the performance as the effectiveness and reliability > of the results. No doubt, some domains are able to use PTR in a > reasonable way. However, rDNS is already a "derived" datum, in the > sense that it should be set after the corresponding DNS entries. > Errors may remain unnoticed for a long time. As a third-hand tool, > PTR can give a false sense of soundness. > > In addition, SERVFAIL cases seem to be more frequent when using PTR, > possibly because secondary servers are not set up equally well for > rDNS, if those zones are delegated at all. > > It is true that EXISTS and IP6 are even less used than PTR, but if I > were to strike mechanisms from the spec --in order to simplify it-- > I'd choose PTR and MX: They seem to be more suitable for heuristic > reasoning than for conveying precise policy statements. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From prvs=548cb204d=fmartin@linkedin.com Thu Jul 26 17:14:51 2012 Return-Path: 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 5C1BF11E80C6 for ; Thu, 26 Jul 2012 17:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 Q2w8Mis1LmtE for ; Thu, 26 Jul 2012 17:14:50 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id BBA2011E80BF for ; Thu, 26 Jul 2012 17:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim; t=1343348090; x=1374884090; h=from:to:subject:date:message-id:mime-version; bh=tcJ4ZI9K2gwzNVLWKQaA0zxofIN+lqqTL/u75FbW94Q=; b=LK8z3JhSWz7h0SQuEq1XXlexbXSmYCmMxGtKyAUzdlyuQd7L8SaEG3Uq kAADWjLsLCKy0xjdIQ7VLArZvCUxxxDaOE1cJ9NmSLDEx/FJy2LlmION9 LEsPaJCOIiorWRg; X-IronPort-AV: E=Sophos;i="4.77,662,1336374000"; d="scan'208,217";a="20076870" Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.01.0355.002; Thu, 26 Jul 2012 17:14:28 -0700 From: Franck Martin To: "spfbis@ietf.org" Thread-Topic: SPF and empty mail from envelope spec is unclear. Thread-Index: AQHNa4zJSInjtc1rf0KkMKN4sD5TeQ== Date: Fri, 27 Jul 2012 00:14:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: multipart/alternative; boundary="_000_CC372B8523551fmartinlinkedincom_" MIME-Version: 1.0 Subject: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 00:14:51 -0000 --_000_CC372B8523551fmartinlinkedincom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, This may be something, you have discussed before, but I'll jump in, instead= of reading the archives=85 I'm looking at the current spec, and I'm not sure it is clear to use the do= main in the HELO/EHLO string when the mail from: is empty (bounce). I think this part should be made clearer, and may be help define what is th= e domain inside the HELO/EHLO string. Is this defined as localhost.domain? = Or is it left to the SPF implementation to figure it out and look for an SP= F record for each portion of the string: a.b.c.d then b.c.d then c.d =85 --_000_CC372B8523551fmartinlinkedincom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

This may be something, you have discussed before, but I'll jump in, in= stead of reading the archives=85

I'm looking at the current spec, and I'm not sure it is clear to use t= he domain in the HELO/EHLO string when the mail from: is empty (bounce).

I think this part should be made clearer, and may be help define what = is the domain inside the HELO/EHLO string. Is this defined as localhost.dom= ain? Or is it left to the SPF implementation to figure it out and look for = an SPF record for each portion of the string: a.b.c.d then b.c.d then c.d =85
--_000_CC372B8523551fmartinlinkedincom_-- From spf2@kitterman.com Thu Jul 26 22:53:45 2012 Return-Path: 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 AA55C11E80A2 for ; Thu, 26 Jul 2012 22:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] 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 hS9bz7bSZOoU for ; Thu, 26 Jul 2012 22:53:45 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 28D1C11E8073 for ; Thu, 26 Jul 2012 22:53:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D504220E40FF; Fri, 27 Jul 2012 01:53:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343368423; bh=TA4jopEymF+D8GBRtsBzEc1NL3/uclLFmrBIwO3Tj2k=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lBrhWvD60NYHfuOInfSSw6f9WmnjvOEeFdA7xPvoJHf82lC+VLFLeiWwdiRgqa5wi F5qZCqvABIAC92YCwU7ANgIrTQHcrPO0py+x+b8NEqQcX/QZRLzLUhPTdIP1VPncRH tqS03yY8pplNYg/C/zEwGyBk0EGvWd1yYhDgB28I= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B40B320E403E; Fri, 27 Jul 2012 01:53:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 27 Jul 2012 01:53:42 -0400 Message-ID: <1358167.AAxpsuSkXD@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 05:53:45 -0000 On Friday, July 27, 2012 12:14:27 AM Franck Martin wrote: > Hi, >=20 > This may be something, you have discussed before, but I'll jump in, i= nstead > of reading the archives=E2=80=A6 >=20 > I'm looking at the current spec, and I'm not sure it is clear to use = the > domain in the HELO/EHLO string when the mail from: is empty (bounce).= >=20 > I think this part should be made clearer, and may be help define what= is the > domain inside the HELO/EHLO string. Is this defined as localhost.doma= in? Or > is it left to the SPF implementation to figure it out and look for an= SPF > record for each portion of the string: a.b.c.d then b.c.d then c.d =E2= =80=A6 It's the domain used by the connection SMTP client as their HELO/EHLO n= ame. =20 Isn't that sufficiently defined in RFC 5321? There is no walk up the d= omain=20 tree. That was tried pre-RFC 4408 and it turned out to have a number o= f=20 operational problems and was abandoned. I'm not sure what's unclear, so perhaps you could propose text? Scott K From hsantos@isdg.net Fri Jul 27 20:47:19 2012 Return-Path: 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 EE6F711E814F for ; Fri, 27 Jul 2012 20:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.641 X-Spam-Level: X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 sXSB5RZga2Aj for ; Fri, 27 Jul 2012 20:47:19 -0700 (PDT) Received: from dkim.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E5B9811E8142 for ; Fri, 27 Jul 2012 20:47:18 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3661; t=1343447234; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=MOgrpZ0IiAUUAlQP79OoYm9aBWc=; b=TSs5Ve/GXyBZdX8qmLx9 gsI2Q+ei9BJvoJzqCchAp+rZd3g8fXBnXDeRk8+U6Jj3nCBAcAJ9v9c+CWbERzef MVRq3rKiwoclFa3at8LEX1ipAfaMXNc0fhnbom+GMc1F1Sie6gCcNNiS15uhc+Ae HTvA634w5bYYKT3H8kzxlIc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 27 Jul 2012 23:47:14 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3764024595.639.3128; Fri, 27 Jul 2012 23:47:13 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3661; t=1343447087; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=yWcOiAG DV0vXphqaqdCqG7ojGPyjATSdRbmnPevaryY=; b=K+ArT620eEIv5imXMJD7qnp sW0nee0+5rEZeXXnya/+FYlfp22gPaukWbLz9SbxaeXmXbrHdFlPTv4h/2JPaEPl HQt2b8rwtPvj7HLHnE9AF+SeHiCdC0ukh98/R/bYvTaZ8AH+kXH2GaAQ6o1A8TMk A1qcRwZuNAGZu5ANJ03g= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 27 Jul 2012 23:44:47 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 67885630.9.3468; Fri, 27 Jul 2012 23:44:46 -0400 Message-ID: <501360B4.408@isdg.net> Date: Fri, 27 Jul 2012 23:47:00 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <1358167.AAxpsuSkXD@scott-latitude-e6320> In-Reply-To: <1358167.AAxpsuSkXD@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 03:47:20 -0000 Maybe some clarification is required for Section 2.1 in the form of what is the HELO identity in relationship to the IP and perhaps why SPF may be applicable. Of course, it can point to RFC5321 but maybe a sentence can save the reader some time since SPF is a protocol that attempts to raise the bar for the domain::IP association. Something as simple: For SMTP compliant clients, the HELO identity MUST be the public domain name of the computer (machine) sending starting the SMTP session. This domain MUST match the IP address of the connecting machine. While RFC5321 has a protocol requirement for a valid public domain name, and if the client can not provide a valid public domain, it MUST use squared bracketed IP literal. Unfortunately, there is a history of invalid values. It could be a valid private domain name or even a NETBIOS computer name resolvable locally, however, it is invalid public identity hence the unreliability of performing reverse DNS lookups (PTR) and domain::IP matching attempts. SPF attempts to raise the bar by providing a policy to associate the IP with the HELO identity verifying the machine sending the machine. However, since of the unreliability for a proper public value, performing an SPF check on the HELO identity SHOULD remain optional at the deployment level. You get the idea. Note: I wonder when a SPF(HELO) check is a valid, whether a rDNS is also valid. I don't know off hand if that would be always the case, but if the argument is made a PTR is not enforced, then SPF may be viewed as a (unenforced) replacement rule. So this could be a discussion on an implementation "suggestion" for the advocation of PTR deprecation: SMTP receivers may wish to consider not enforcing PTR requirement and instead check the SPF HELO identity policy. And what makes this a technical consideration on its merit is the suggestion the TXT lookup is less expensive than a PTR. PS: RFC1001 has this for a reference (no official RFC for NETBIOS) and footnote: NetBIOS defines a software interface not a protocol. There is no "official" NetBIOS service standard. In practice, however, the IBM PC-Network version is used as a reference. That version is described in the IBM document 6322916, "Technical Reference PC Network"[2]. [2] IBM Corp., "IBM PC Network Technical Reference Manual", No. 6322916, First Edition, September 1984. Scott Kitterman wrote: > On Friday, July 27, 2012 12:14:27 AM Franck Martin wrote: >> Hi, >> >> This may be something, you have discussed before, but I'll jump in, instead >> of reading the archives… >> >> I'm looking at the current spec, and I'm not sure it is clear to use the >> domain in the HELO/EHLO string when the mail from: is empty (bounce). >> >> I think this part should be made clearer, and may be help define what is the >> domain inside the HELO/EHLO string. Is this defined as localhost.domain? Or >> is it left to the SPF implementation to figure it out and look for an SPF >> record for each portion of the string: a.b.c.d then b.c.d then c.d … > > It's the domain used by the connection SMTP client as their HELO/EHLO name. > Isn't that sufficiently defined in RFC 5321? There is no walk up the domain > tree. That was tried pre-RFC 4408 and it turned out to have a number of > operational problems and was abandoned. > > I'm not sure what's unclear, so perhaps you could propose text? > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- HLS From prvs=5494ace59=fmartin@linkedin.com Sat Jul 28 00:17:58 2012 Return-Path: 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 EDDB911E808C for ; Sat, 28 Jul 2012 00:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 Bt3AC3z+UJfa for ; Sat, 28 Jul 2012 00:17:58 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 40B3511E8073 for ; Sat, 28 Jul 2012 00:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim; t=1343459878; x=1374995878; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tvENJ3SkDffZBQItLU1aECW5oju7iL6qtAudpe8EKeA=; b=T7BV+H9qR7SE2ksKmuKalXudj1pMHDUrlEnsptp0P+UxfotOcoG4NSXN oAsq/smRMFQYPqvoVIeIYFuKqw+iUkDrjkIg+cVI6gQPtRXdeQn2w4Ced uZm0TXJYfbEolP1; X-IronPort-AV: E=Sophos;i="4.77,670,1336374000"; d="scan'208";a="20198352" Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.01.0355.002; Sat, 28 Jul 2012 00:17:36 -0700 From: Franck Martin To: Scott Kitterman Thread-Topic: [spfbis] SPF and empty mail from envelope spec is unclear. Thread-Index: AQHNa4zJSInjtc1rf0KkMKN4sD5TeZc9FpkAgAGp3YA= Date: Sat, 28 Jul 2012 07:17:35 +0000 Message-ID: <17A84E12-81F0-4ECF-8185-CF87856C5C8B@linkedin.com> References: <1358167.AAxpsuSkXD@scott-latitude-e6320> In-Reply-To: <1358167.AAxpsuSkXD@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3ABE9749173AA948BCC8FA54280F67F6@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 07:17:59 -0000 I see... from experience when it is not broken what I have seen is that the helo doe= s not contain a domain but the fully qualified hostname of the client: host= name.domain It could then difficult to find the domain from that. I'm not sure, any SMTP implementation respect this RFC. May be someone as s= ome data? On Jul 26, 2012, at 10:53 PM, Scott Kitterman wrote: > On Friday, July 27, 2012 12:14:27 AM Franck Martin wrote: >> Hi, >>=20 >> This may be something, you have discussed before, but I'll jump in, inst= ead >> of reading the archives=85 >>=20 >> I'm looking at the current spec, and I'm not sure it is clear to use the >> domain in the HELO/EHLO string when the mail from: is empty (bounce). >>=20 >> I think this part should be made clearer, and may be help define what is= the >> domain inside the HELO/EHLO string. Is this defined as localhost.domain?= Or >> is it left to the SPF implementation to figure it out and look for an SP= F >> record for each portion of the string: a.b.c.d then b.c.d then c.d =85 >=20 > It's the domain used by the connection SMTP client as their HELO/EHLO nam= e. =20 > Isn't that sufficiently defined in RFC 5321? There is no walk up the dom= ain=20 > tree. That was tried pre-RFC 4408 and it turned out to have a number of= =20 > operational problems and was abandoned. >=20 > I'm not sure what's unclear, so perhaps you could propose text? >=20 > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Sat Jul 28 00:20:08 2012 Return-Path: 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 64CF711E808C for ; Sat, 28 Jul 2012 00:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] 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 QGRzgSYq2j9A for ; Sat, 28 Jul 2012 00:20:07 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7DB11E8073 for ; Sat, 28 Jul 2012 00:20:07 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5315320E40FF; Sat, 28 Jul 2012 03:20:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343460006; bh=0sEPt5bLk/4l35aFvNATOdNcTVKZie8wXXMtjT+vNus=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aAhZCJt0yjErBwzn4RfTsCp8arRtSs/dC7YkTpLo473iBlv4MLKORS1BVbkMmkUs+ rfY4jYlRGmII4pH9dqPpavRUsN75FDIU5HDm5wWbcRy7xZ5nHa9jY3cdoGr6Nc70Lp q2TRyna2EKSFqMkdZArzn7R7Ovkxby0AicXhtC+A= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3997720E4064; Sat, 28 Jul 2012 03:20:06 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 28 Jul 2012 03:20:05 -0400 Message-ID: <2251090.tmuqHQDhjH@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <17A84E12-81F0-4ECF-8185-CF87856C5C8B@linkedin.com> References: <1358167.AAxpsuSkXD@scott-latitude-e6320> <17A84E12-81F0-4ECF-8185-CF87856C5C8B@linkedin.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 07:20:08 -0000 I guess I was speaking imprecisely. fully qualified hostname of the cl= ient:=20 hostname.domain is exactly what you use. =20 Scott K On Saturday, July 28, 2012 07:17:35 AM Franck Martin wrote: > I see... >=20 > from experience when it is not broken what I have seen is that the he= lo does > not contain a domain but the fully qualified hostname of the client: > hostname.domain >=20 > It could then difficult to find the domain from that. >=20 > I'm not sure, any SMTP implementation respect this RFC. May be someon= e as > some data? > On Jul 26, 2012, at 10:53 PM, Scott Kitterman wrote: > > On Friday, July 27, 2012 12:14:27 AM Franck Martin wrote: > >> Hi, > >>=20 > >> This may be something, you have discussed before, but I'll jump in= , > >> instead > >> of reading the archives=E2=80=A6 > >>=20 > >> I'm looking at the current spec, and I'm not sure it is clear to u= se the > >> domain in the HELO/EHLO string when the mail from: is empty (bounc= e). > >>=20 > >> I think this part should be made clearer, and may be help define w= hat is > >> the domain inside the HELO/EHLO string. Is this defined as > >> localhost.domain? Or is it left to the SPF implementation to figur= e it > >> out and look for an SPF record for each portion of the string: a.b= .c.d > >> then b.c.d then c.d =E2=80=A6>=20 > > It's the domain used by the connection SMTP client as their HELO/EH= LO > > name. > > Isn't that sufficiently defined in RFC 5321? There is no walk up t= he > > domain tree. That was tried pre-RFC 4408 and it turned out to have= a > > number of operational problems and was abandoned. > >=20 > > I'm not sure what's unclear, so perhaps you could propose text? > >=20 > > Scott K > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis >=20 > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From hsantos@isdg.net Sat Jul 28 05:30:19 2012 Return-Path: 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 B653E21F8464 for ; Sat, 28 Jul 2012 05:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.639 X-Spam-Level: X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 BRgAznYn9kP4 for ; Sat, 28 Jul 2012 05:30:18 -0700 (PDT) Received: from secure.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A899A21F8460 for ; Sat, 28 Jul 2012 05:30:17 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2266; t=1343478610; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=f13YRUREweRQGc4nU700YCz0Tt0=; b=wjk6WNTaPOoiPE7WfL3Y zFbs7g0u3EU+pEau1Nuj+gOGMtdqKltbv3SxFQJrapVnB4akkeR39vvD5vPYRi4Y zbgHHcbKDEUDj/6eNW5dAPK+/gHK0Z+7a15wy3/i2yZY6S/v/brcOJkCQm0NT22A 3NjTr1TABldoyQUELKD58qk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 28 Jul 2012 08:30:10 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3795400046.1571.5784; Sat, 28 Jul 2012 08:30:09 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2266; t=1343478464; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=bsDTYNR n9pchtfFbW3Zew3PVjMHUzL3boNbDyGVN9po=; b=YucEMd97EhxBarsKXXNVjHa iipN4Aqz9piosHHtwHipDldQip/0VksmG6l6SZwFjeb4e7itt6/zHrhlSp82F4v4 8c8o6MFpjfroIETDFauD7Dy4dKn62DKmjCZleW7kp5WWYzT8oq23rJ5Ge0Ncaoce xWl9DlSo3rcDnfSvzvD4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 28 Jul 2012 08:27:44 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 99261802.9.6148; Sat, 28 Jul 2012 08:27:43 -0400 Message-ID: <5013DB51.3070906@isdg.net> Date: Sat, 28 Jul 2012 08:30:09 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <1358167.AAxpsuSkXD@scott-latitude-e6320> <17A84E12-81F0-4ECF-8185-CF87856C5C8B@linkedin.com> <2251090.tmuqHQDhjH@scott-latitude-e6320> In-Reply-To: <2251090.tmuqHQDhjH@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 12:30:19 -0000 And more to the precision - a public FQHN. FQDN is also a common acronym. Makes no use if its private. Scott Kitterman wrote: > I guess I was speaking imprecisely. fully qualified hostname of the client: > hostname.domain is exactly what you use. > > Scott K > > On Saturday, July 28, 2012 07:17:35 AM Franck Martin wrote: >> I see... >> >> from experience when it is not broken what I have seen is that the helo does >> not contain a domain but the fully qualified hostname of the client: >> hostname.domain >> >> It could then difficult to find the domain from that. >> >> I'm not sure, any SMTP implementation respect this RFC. May be someone as >> some data? >> On Jul 26, 2012, at 10:53 PM, Scott Kitterman wrote: >>> On Friday, July 27, 2012 12:14:27 AM Franck Martin wrote: >>>> Hi, >>>> >>>> This may be something, you have discussed before, but I'll jump in, >>>> instead >>>> of reading the archives… >>>> >>>> I'm looking at the current spec, and I'm not sure it is clear to use the >>>> domain in the HELO/EHLO string when the mail from: is empty (bounce). >>>> >>>> I think this part should be made clearer, and may be help define what is >>>> the domain inside the HELO/EHLO string. Is this defined as >>>> localhost.domain? Or is it left to the SPF implementation to figure it >>>> out and look for an SPF record for each portion of the string: a.b.c.d >>>> then b.c.d then c.d …> >>> It's the domain used by the connection SMTP client as their HELO/EHLO >>> name. >>> Isn't that sufficiently defined in RFC 5321? There is no walk up the >>> domain tree. That was tried pre-RFC 4408 and it turned out to have a >>> number of operational problems and was abandoned. >>> >>> I'm not sure what's unclear, so perhaps you could propose text? >>> >>> Scott K >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- HLS From W.Doust@racingvictoria.net.au Sun Jul 29 18:36:58 2012 Return-Path: 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 1430B11E80D7 for ; Sun, 29 Jul 2012 18:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] 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 tmFzf2NlpnaE for ; Sun, 29 Jul 2012 18:36:55 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id D124F21F860B for ; Sun, 29 Jul 2012 18:36:52 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 9558) id ; Mon, 30 Jul 2012 11:36:49 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD6DF3.C294092C" Date: Mon, 30 Jul 2012 11:36:32 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1t87+TgTlbqLyaQgCnLx5BoO7zQg== From: "Wayne Doust" To: Subject: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 01:36:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD6DF3.C294092C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have to deal with SPF failures (and explaining the reasons why) on an almost daily basis. Aside from forwarding issues, the next biggest cause of SPF failure I encounter is problems with parsing the SPF record. Sometimes it is a problem with MY record that cannot be parsed, other times it is a problem with the sender's record. From what I have gathered so far, usually the issue arises with dealing with listing entire subnets within the SPF record. Fixing such an issue requires (generally) some level of communication between IT departments. In my experience, the success of this effort is inversely proportional to the size of their IT Department. In a recent case I dealt with a very large ISP in Australia that spent two weeks treating me like a bozo before they finally admitted they had a problem with their Cisco Ironport setup. =20 If possible, I think the SPF specification should recommend a parsing failure should default to an SPF of NEUTRAL rather than a FAIL or SOFTFAIL as is usually the case. In most cases I deal with the remote sysadmin has simply implemented some off-the-shelf solution and ticked the SPF "box" and that's the end of the story. Most have no way of dealing with the issue other than whitelisting the entire domain - something that to me defeats the entire purpose of SPF. =20 If a site HAS published SPF and a broken 3rd party mail filter cannot parse the record, the domain is effectively penalised and in a worse situation than had they published no record at all. At the very worst the fallback position should be to perform rDNS checks and rely on that. =20 Regards, =20 Wayne Doust *************************************************************************= ******************************* Disclaimer: This email message and any attachments are confidential. =20 The information contained in this email message and any attachments may b= e=20 confidential information. If you are not the intended recipient, any use,= =20interference with,=20 disclosure or copying of this material is unauthorised and prohibited. This email and any attachments are also subject to copyright. =20 No part of them may be reproduced, adapted or transmitted without the wri= tten permission of the copyright owner. If you have received this email in error please immediately advise the se= nder=20 by return email and delete the message from your system.=20 Although this email has been checked for viruses and other defects, no re= sponsibility=20 can be accepted for any loss or damage arising from its receipt or use. Racing Victoria Limited respects your privacy. Our privacy policy can be = accessed=20 from our web site: "http://www.racingvictoria.net.au" *************************************************************************= ******************************* ------_=_NextPart_001_01CD6DF3.C294092C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have to de= al with SPF failures (and explaining the reasons why) on an almost daily = basis. Aside from forwarding issues, the next biggest cause of SPF failur= e I encounter is problems with parsing the SPF record. Sometimes it is a = problem with MY record that cannot be parsed, other times it is a problem= =20with the sender’s record. From what I have gathered so far, usua= lly the issue arises with dealing with listing entire subnets within the = SPF record. Fixing such an issue requires (generally) some level of commu= nication between IT departments. In my experience, the success of this ef= fort is inversely proportional to the size of their IT Department. In a r= ecent case I dealt with a very large ISP in Australia that spent two week= s treating me like a bozo before they finally admitted they had a problem= =20with their Cisco Ironport setup.

 

If possible, I think the SPF spec= ification should recommend a parsing failure should default to an SPF of = NEUTRAL rather than a FAIL or SOFTFAIL as is usually the case. In most ca= ses I deal with the remote sysadmin has simply implemented some off-the-s= helf solution and ticked the SPF “box” and that’s the e= nd of the story. Most have no way of dealing with the issue other than wh= itelisting the entire domain – something that to me defeats the ent= ire purpose of SPF.

 <= /p>

If a site HAS published SPF and a broken 3rd= party mail filter cannot parse the record, the domain is effective= ly penalised and in a worse situation than had they published no record a= t all. At the very worst the fallback position should be to perform rDNS = checks and rely on that.

 

Regards,

=  

Wayne Doust


Attention:
**********************= *************************************************************************= *********=20 Disclaimer: This email message and any attachments are confidential. The = information contained in this email message and any attachments may be=20 confidential information. If you are not the intended recipient, any use,= =20 interference with, disclosure or copying of this material is unauthorised= =20and=20 prohibited. This email and any attachments are also subject to copyright.= =20No=20 part of them may be reproduced, adapted or transmitted without the writte= n=20 permission of the copyright owner. If you have received this email in err= or=20 please immediately advise the sender by return email and delete the messa= ge from=20 your system. Although this email has been checked for viruses and other d= efects,=20 no responsibility can be accepted for any loss or damage arising from its= =20 receipt or use. Racing Victoria Limited respects your privacy. Our privac= y=20 policy can be accessed from our web site: "http://www.racingvictoria.net.= au"=20 *************************************************************************= *******************************

Thank = You.

------_=_NextPart_001_01CD6DF3.C294092C-- From superuser@gmail.com Sun Jul 29 19:28:41 2012 Return-Path: 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 5191011E80F8 for ; Sun, 29 Jul 2012 19:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.671 X-Spam-Level: X-Spam-Status: No, score=-3.671 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 i7lNZACeYfu8 for ; Sun, 29 Jul 2012 19:28:40 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27E3511E8088 for ; Sun, 29 Jul 2012 19:28:39 -0700 (PDT) Received: by lagv3 with SMTP id v3so3244673lag.31 for ; Sun, 29 Jul 2012 19:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JM1IYq+7nW02Ej0XJUKj3M0N/uCo74osuD81KnHxiPk=; b=1BEY9QgkvOaCyQuHUXcYBVa9Wdu6MpcQVTdtd5ZceLgFrDCKE0UHGHp2mPddWA/re5 F5WKXJ9StlGpYnTkM8/GTmq8Z4TLBL4cjDx3ajS519VGFHHtdEYc2QZQlAB2p0/sLEcv 8JtQpkNWvF5bplvztvLiqNVNACE+UMugD4/4whUuGW+QPbKI321IhenaNEk9IqQXEoa8 I2YhqyfuA2qxCNeDxVfEAxRLN6wZnA9PGqJkCuJOgaPWRTlgtom3dCx5aCj8c7ugak9U f0Z5qQbFC/EB5Zb0A/TmlczGUmLd+I7fw0KWiUh/xXb2pJ8H/m9MIVn4MyWxpLIN2uUX lEnA== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr9791236lab.40.1343615318899; Sun, 29 Jul 2012 19:28:38 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sun, 29 Jul 2012 19:28:38 -0700 (PDT) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> Date: Sun, 29 Jul 2012 19:28:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: Wayne Doust Content-Type: multipart/alternative; boundary=f46d040838d3cc3d4d04c602d1c6 Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 02:28:41 -0000 --f46d040838d3cc3d4d04c602d1c6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Jul 29, 2012 at 6:36 PM, Wayne Doust wrote: > I have to deal with SPF failures (and explaining the reasons why) on an > almost daily basis. Aside from forwarding issues, the next biggest cause = of > SPF failure I encounter is problems with parsing the SPF record. Sometime= s > it is a problem with MY record that cannot be parsed, other times it is a > problem with the sender=92s record. From what I have gathered so far, usu= ally > the issue arises with dealing with listing entire subnets within the SPF > record. Fixing such an issue requires (generally) some level of > communication between IT departments. In my experience, the success of th= is > effort is inversely proportional to the size of their IT Department. In a > recent case I dealt with a very large ISP in Australia that spent two wee= ks > treating me like a bozo before they finally admitted they had a problem > with their Cisco Ironport setup. > I'm confused a bit here. Listing an entire subnet isn't by itself a syntax error or parsing problem, is it? It's a matter of having too broad of an authorization, correct? > **** > > ** ** > > If possible, I think the SPF specification should recommend a parsing > failure should default to an SPF of NEUTRAL rather than a FAIL or SOFTFAI= L > as is usually the case. In most cases I deal with the remote sysadmin has > simply implemented some off-the-shelf solution and ticked the SPF =93box= =94 and > that=92s the end of the story. Most have no way of dealing with the issue > other than whitelisting the entire domain =96 something that to me defeat= s > the entire purpose of SPF.**** > > ** ** > > If a site HAS published SPF and a broken 3rd party mail filter cannot > parse the record, the domain is effectively penalised and in a worse > situation than had they published no record at all. At the very worst the > fallback position should be to perform rDNS checks and rely on that. > How a filter actually responds to a softfail or fail isn't specified by either version of the document. (Or neutral, for that matter.) Essentially the filter has made an unfortunate decision. If RFC4408bis doesn't adequately warn of "use cases" such as these, I agree that we should consider mentioning them. -MSK --f46d040838d3cc3d4d04c602d1c6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Jul 29, 2012 at 6:36 PM, Wayne Doust <W.Doust@racingv= ictoria.net.au> wrote:

I have to deal with SPF failures (and explaining the reasons why) on an= almost daily basis. Aside from forwarding issues, the next biggest cause o= f SPF failure I encounter is problems with parsing the SPF record. Sometime= s it is a problem with MY record that cannot be parsed, other times it is a= problem with the sender=92s record. From what I have gathered so far, usua= lly the issue arises with dealing with listing entire subnets within the SP= F record. Fixing such an issue requires (generally) some level of communica= tion between IT departments. In my experience, the success of this effort i= s inversely proportional to the size of their IT Department. In a recent ca= se I dealt with a very large ISP in Australia that spent two weeks treating= me like a bozo before they finally admitted they had a problem with their = Cisco Ironport setup.


I'm confused a bit here.=A0 Listing a= n entire subnet isn't by itself a syntax error or parsing problem, is i= t?=A0 It's a matter of having too broad of an authorization, correct? =A0

=A0

If possible, I think the SPF sp= ecification should recommend a parsing failure should default to an SPF of = NEUTRAL rather than a FAIL or SOFTFAIL as is usually the case. In most case= s I deal with the remote sysadmin has simply implemented some off-the-shelf= solution and ticked the SPF =93box=94 and that=92s the end of the story. M= ost have no way of dealing with the issue other than whitelisting the entir= e domain =96 something that to me defeats the entire purpose of SPF.=

=A0

If a sit= e HAS published SPF and a broken 3rd party mail filter cannot pa= rse the record, the domain is effectively penalised and in a worse situatio= n than had they published no record at all. At the very worst the fallback = position should be to perform rDNS checks and rely on that.


How a filter actually responds to a softf= ail or fail isn't specified by either version of the document.=A0 (Or n= eutral, for that matter.)=A0 Essentially the filter has made an unfortunate= decision.=A0 If RFC4408bis doesn't adequately warn of "use cases&= quot; such as these, I agree that we should consider mentioning them.

-MSK

--f46d040838d3cc3d4d04c602d1c6-- From SRS0=6S/5U=F7==stuart@gathman.org Sun Jul 29 19:30:05 2012 Return-Path: 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 75BA621F84CE for ; Sun, 29 Jul 2012 19:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 V7A5sIDmcTaG for ; Sun, 29 Jul 2012 19:30:04 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id EFC2E21F848F for ; Sun, 29 Jul 2012 19:30:03 -0700 (PDT) Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=72.209.196.211 (fairfax.gathman.org); auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q6U2U0LA007831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 29 Jul 2012 22:30:01 -0400 Message-ID: <5015F1A7.50000@gathman.org> Date: Sun, 29 Jul 2012 22:29:59 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> Content-Type: multipart/alternative; boundary="------------040804080400080509000707" Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 02:40:11 -0000 This is a multi-part message in MIME format. --------------040804080400080509000707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Long ago, Nostradamus foresaw that on 07/29/2012 09:36 PM, Wayne Doust would write: > > If possible, I think the SPF specification should recommend a parsing > failure should default to an SPF of NEUTRAL rather than a FAIL or > SOFTFAIL as is usually the case. In most cases I deal with the remote > sysadmin has simply implemented some off-the-shelf solution and ticked > the SPF "box" and that's the end of the story. Most have no way of > dealing with the issue other than whitelisting the entire domain -- > something that to me defeats the entire purpose of SPF. > > > The SPF specification *mandates* a result of PERMERROR (not fail or softfail) for parsing failures. It already recommends treating PermError like neutral. Such recommendations are irrelevant anyway, since you are expecting people who aren't following the spec in the first place to heed them. In relaxed mode, pyspf applies heuristics to PermError (translating common errors like A:1.2.3.4 to IP4:1.2.3.4) and then (in addition) returns the heuristic result as a "best guess" for local policy purposes. When the "best guess" is a "pass", my policy is to then send an automatic DSN with the diagnostic for the PermError. --------------040804080400080509000707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Long ago, Nostradamus foresaw that on 07/29/2012 09:36 PM, Wayne Doust would write:

If possible, I think the SPF specification should recommend a parsing failure should default to an SPF of NEUTRAL rather than a FAIL or SOFTFAIL as is usually the case. In most cases I deal with the remote sysadmin has simply implemented some off-the-shelf solution and ticked the SPF “box” and that’s the end of the story. Most have no way of dealing with the issue other than whitelisting the entire domain – something that to me defeats the entire purpose of SPF.

 

The SPF specification *mandates* a result of PERMERROR (not fail or softfail) for parsing failures.  It already recommends treating PermError like neutral.  

Such recommendations are irrelevant anyway, since you are expecting people who aren't following the spec in the first place to heed them.  In relaxed mode, pyspf applies heuristics to PermError (translating common errors like A:1.2.3.4 to IP4:1.2.3.4) and then (in addition) returns the heuristic result as a "best guess" for local policy purposes.   When the "best guess" is a "pass", my policy is to then send an automatic DSN with the diagnostic for the PermError.

--------------040804080400080509000707-- From SRS0=6S/5U=F7==stuart@gathman.org Sun Jul 29 19:39:49 2012 Return-Path: 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 D2EF211E8107 for ; Sun, 29 Jul 2012 19:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] 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 YJwQhYERdxn6 for ; Sun, 29 Jul 2012 19:39:49 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 415F511E8104 for ; Sun, 29 Jul 2012 19:39:49 -0700 (PDT) Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=72.209.196.211 (fairfax.gathman.org); auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart Received: from melissa.gathman.org (fairfax.gathman.org [72.209.196.211]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q6U2dl0N008000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 29 Jul 2012 22:39:48 -0400 Message-ID: <5015F3F3.4010304@gathman.org> Date: Sun, 29 Jul 2012 22:39:47 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <1358167.AAxpsuSkXD@scott-latitude-e6320> <501360B4.408@isdg.net> In-Reply-To: <501360B4.408@isdg.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 02:40:16 -0000 Long ago, Nostradamus foresaw that on 07/27/2012 11:47 PM, Hector Santos would write: > > SMTP receivers may wish to consider not enforcing PTR requirement > and instead > check the SPF HELO identity policy. For checking the identity of an SMTP connection with valid HELO that matches the IP, there is no need for SPF or PTR. The matching HELO establishes that the owner of the HELO domain is responsible for the sending MTA. Where checking SPF HELO comes in is rejecting *unauthorized* connections, and in authorizing connections where an SPF record is simpler than assigning a unique HELO to each IP used by MTAs (e.g. large MTA farms). From hsantos@isdg.net Sun Jul 29 21:37:31 2012 Return-Path: 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 D07FE11E8117 for ; Sun, 29 Jul 2012 21:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 fxAgQXZuJSm0 for ; Sun, 29 Jul 2012 21:37:30 -0700 (PDT) Received: from ftp.catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDEA11E8098 for ; Sun, 29 Jul 2012 21:37:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2813; t=1343623043; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=BG0b/QlHlRwtwpwSzX1s5fshTQs=; b=l2HV6yHnXyJrhtnMYigS z6lTV1G38BknAoqTzOlXR4YvHGW6q2EGajbtsrLT0813Jo7I4hTwfdiVM4K/ae9I Vhs9vYYGXCftLC7PviCGFBjnnDWZ8G06AH8GTJbNPHRdTg/VWf7i6WAaYhS+zHsQ LsKUYUCefo9IXVkg8mxV3ys= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 30 Jul 2012 00:37:23 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3939831310.2529.4616; Mon, 30 Jul 2012 00:37:22 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2813; t=1343622893; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bfo3ygD EsA6eEKWVnAh9HSqdaQFcZRk3W8bjFK65cM8=; b=T8y6wO3OB28axGYMZlc3dWc MhPAf0OGIullyBfN9TIThUWbzhCzYrdRRNxBvcTDza8WEil0RsZIZwCTgOVAXgz7 Nj1//bjFfotFD2bFjEX3iWQq1nV6MzuNvx6ZDCTw0uhyGjcCqau/B0Y3+DguOoyk IkpQquSfzOnEM2ZjTOls= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 30 Jul 2012 00:34:53 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 243690552.9.8040; Mon, 30 Jul 2012 00:34:51 -0400 Message-ID: <50160F83.4040806@isdg.net> Date: Mon, 30 Jul 2012 00:37:23 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 04:37:32 -0000 Murray S. Kucherawy wrote: >> >> If a site HAS published SPF and a broken 3rd party mail filter cannot >> parse the record, the domain is effectively penalised and in a worse >> situation than had they published no record at all. At the very worst the >> fallback position should be to perform rDNS checks and rely on that. >> > > How a filter actually responds to a softfail or fail isn't specified by > either version of the document. (Or neutral, for that matter.) -1, SPF is very clear about FAIL. Lets be very clear for protocol developers between the deterministic and reputation world and the battles over the year. SPF always offered a clear avenue for rejection of what was deemed BAD mail. It is was essential reason for its existence after the 2003 SORBIG attack that hurt everyone with a dual blitz attack: - Blitz #1 - spoof the return path address - cross fingers server accepted RCPT. Bad guys targeted accept always servers which were dominate in years past. - Blitz #2 - If accepted mail was not deliverable, cross fingers server bounced mail to spoofed return path address. That is why SPF existed and LMAP like protocols were started and a resultant FAIL was deemed rejected mail - and expected by the publishing domain. Otherwise don't use -ALL It is written in 4408 very clearly. In the abstract, with its theme sentence regarding the problem - FORGERY. In section 1.0 Furthermore, if a claimed identity fails verification, local policy can take stronger action against such E-Mail, such as rejecting it. In section 2.4 Although invalid, malformed, or non-existent domains cause SPF checks to return "None" because no SPF record can be found, it has long been the policy of many MTAs to reject E-Mail from such domains, especially in the case of invalid "MAIL FROM". [5321 even provide insights for requiring and rejection invalid mail froms] In section 2.5.4. Fail A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking software can choose to mark the mail based on this or to reject the mail outright. We seriously need to halt the continued misconception and attempts to instill false understandings of SPF, that it was never about rejecting (SPF detected) forged mail, especially with the exclusive domain policies using -ALL (FAIL). It was what SPF was all about very much different than other watered down low/no payoff prototols such as DKIM remodeled with POLICY removed and reshaped for non-persistent, non-consistent modeling on reputation, leaving very little payoff but to processing and use heuristic. SPF is not DKIM. It has a strong deterministic framework - by design. Its not DKIM. Thanks -- HLS From hsantos@isdg.net Sun Jul 29 21:49:11 2012 Return-Path: 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 D7EFE11E810F for ; Sun, 29 Jul 2012 21:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 d3FLko-jLuCH for ; Sun, 29 Jul 2012 21:49:10 -0700 (PDT) Received: from ftp.catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6201911E808D for ; Sun, 29 Jul 2012 21:49:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2782; t=1343623743; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=PqNUlABmCCsnSDnxEMb+TnUtDSI=; b=PfCUYjiH05C3E/TflUQs Zorg4G21+kuVOwnKZ0yMVaEb65rJDDP6joczW89yHmSvcwVYgO/NApvVtwaIFKWn igFEzjiEVPIm2OUA7wL6NUpvDK2FUesNrLHk21qqWR60YZTbXeVg0VwrnGXaYVRv b+3gBQVJmQ5+Tl4iKf7Yxi0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 30 Jul 2012 00:49:03 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3940531707.2529.828; Mon, 30 Jul 2012 00:49:03 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2782; t=1343623594; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=nFhBneo HSk36GA6RkywfGJENcT1v6LL/vjc4gT+A1lQ=; b=mGtY6qIzKBtP6FXkdDguKwB 2XUNv0SAO90cvByOBCtbK1FlhbDF2HDJOl0oWZoXZ+9j37nzz6lZcclf203OwgqX lr5s6RWItc5gEytdW5bji9cqPJsMjw47AxWGaSTYT7gb3WWj++uR5fJo1CNPIxLN tDIOg5fdvk5Zt2pr5Si8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 30 Jul 2012 00:46:34 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 244392005.9.4928; Mon, 30 Jul 2012 00:46:33 -0400 Message-ID: <5016123F.1090803@isdg.net> Date: Mon, 30 Jul 2012 00:49:03 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Wayne Doust References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 04:49:12 -0000 Wayne, Our input is: The best way to do with this is to track failure, treat as none, but don't tolerant it after X period and then determine if its requires rejection. If its a "Good Guy" then in most support cases, if they don't wish to fix their problem or are presently in denial, you have no choice but to white list them so that it doesn't add to your processing or support overhead. If a bad guy, then its easy - block them. For us, SPF is just one of a suite of testing. For an processing error, its treated as NONE - like it never existence, i.e. indeterminate, no result. I don't think a good system can fallback to FAIL/SOFTFAIL if A) the domain did not declare it or b) without some form of analysis of the sender at some point. In the automated world, the risk is too high for false positives (thats not to suggest there is a high occurrence of bad SPF policy statements). But the FAIL-SAFE is better until one can see if its an abusive system, then adding a block for it is par for the course. -- HLS Wayne Doust wrote: > I have to deal with SPF failures (and explaining the reasons why) on an > almost daily basis. Aside from forwarding issues, the next biggest cause > of SPF failure I encounter is problems with parsing the SPF record. > Sometimes it is a problem with MY record that cannot be parsed, other > times it is a problem with the sender's record. From what I have > gathered so far, usually the issue arises with dealing with listing > entire subnets within the SPF record. Fixing such an issue requires > (generally) some level of communication between IT departments. In my > experience, the success of this effort is inversely proportional to the > size of their IT Department. In a recent case I dealt with a very large > ISP in Australia that spent two weeks treating me like a bozo before > they finally admitted they had a problem with their Cisco Ironport > setup. > > > > If possible, I think the SPF specification should recommend a parsing > failure should default to an SPF of NEUTRAL rather than a FAIL or > SOFTFAIL as is usually the case. In most cases I deal with the remote > sysadmin has simply implemented some off-the-shelf solution and ticked > the SPF "box" and that's the end of the story. Most have no way of > dealing with the issue other than whitelisting the entire domain - > something that to me defeats the entire purpose of SPF. > > > > If a site HAS published SPF and a broken 3rd party mail filter cannot > parse the record, the domain is effectively penalised and in a worse > situation than had they published no record at all. At the very worst > the fallback position should be to perform rDNS checks and rely on that. > > Regards, > > Wayne Doust From W.Doust@racingvictoria.net.au Sun Jul 29 22:03:04 2012 Return-Path: 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 8F73511E808D for ; Sun, 29 Jul 2012 22:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.057 X-Spam-Level: X-Spam-Status: No, score=0.057 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] 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 ddBulTi-1QW9 for ; Sun, 29 Jul 2012 22:03:02 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id D3A6511E8098 for ; Sun, 29 Jul 2012 22:02:59 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 9558) id ; Mon, 30 Jul 2012 15:02:56 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD6E10.764E6C6C" Date: Mon, 30 Jul 2012 15:02:00 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279DD@XCHANGE.rvl.internal> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1t+wvMdzITNt4USMqzwg1rwVwz0QAFA+Zw References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> From: "Wayne Doust" To: "Murray S. Kucherawy" Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 05:03:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD6E10.764E6C6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable | I'm confused a bit here. Listing an entire subnet isn't by itself a syntax error or parsing problem, is it? It's a matter of having too broad of an authorization, correct? =20 Most of the parsing failures I've encountered do seem to be failing on either IP4 or IP6 subnets. Certainly for the record I'm responsible for, that seems to be the case. Nearly always it is due to some out-of-the-box email filter that is the problem and I'm greeted with "Ha! We use XYZ email filter! It must be YOUR problem." =20 | How a filter actually responds to a softfail or fail isn't specified by either version of the document. (Or neutral, for that matter.) Essentially the filter has made an unfortunate decision. If RFC4408bis doesn't adequately warn of "use cases" such as these, I agree that we should consider mentioning them. This is essentially what I'm advocating: =20 A STRICT check should REQUIRE an SPF PASS. A MODERATE check should REQUIRE an SPF PASS, NEUTRAL or NONE, but ALSO permit a PERMERROR or TEMPERROR. This means a Moderate check should ONLY Fail on an SPF FAIL or SPF SOFTFAIL. A RELAXED check should ONLY Fail on an SPF FAIL. =20 *************************************************************************= ******************************* Disclaimer: This email message and any attachments are confidential. =20 The information contained in this email message and any attachments may b= e=20 confidential information. If you are not the intended recipient, any use,= =20interference with,=20 disclosure or copying of this material is unauthorised and prohibited. This email and any attachments are also subject to copyright. =20 No part of them may be reproduced, adapted or transmitted without the wri= tten permission of the copyright owner. If you have received this email in error please immediately advise the se= nder=20 by return email and delete the message from your system.=20 Although this email has been checked for viruses and other defects, no re= sponsibility=20 can be accepted for any loss or damage arising from its receipt or use. Racing Victoria Limited respects your privacy. Our privacy policy can be = accessed=20 from our web site: "http://www.racingvictoria.net.au" *************************************************************************= ******************************* ------_=_NextPart_001_01CD6E10.764E6C6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

| I'm confused a bit here.  L= isting an entire subnet isn't by itself a syntax error or parsing problem= , is it?  It's a matter of having too broad of an authorization, cor= rect?
 

Most of the parsing failures I’ve encountered do= =20seem to be failing on either IP4 or IP6 subnets. Certainly for the rec= ord I’m responsible for, that seems to be the case. Nearly always i= t is due to some out-of-the-box email filter that is the problem and I= 217;m greeted with “Ha! We use XYZ email filter! It must be YOUR pr= oblem.”

&nb= sp;


| How a filter actually responds to a softfail or fail isn't spe= cified by either version of the document.  (Or neutral, for that mat= ter.)  Essentially the filter has made an unfortunate decision. = ; If RFC4408bis doesn't adequately w= arn of "use cases" such as these, I agree that we should consid= er mentioning them.

T= his is essentially what I’m advocating:

 

= A STRICT check should REQUIRE an SPF PASS.

=

A MODERATE check should REQUIRE an SPF PASS= , NEUTRAL or NONE, but ALSO permit a PERMERROR or TEMPERROR. This means a= =20Moderate check should ONLY Fail on an SPF FAIL or SPF SOFTFAIL.

A RELAXED check should ONLY = Fail on an SPF FAIL.

 


Attention:
**********************= *************************************************************************= *********=20 Disclaimer: This email message and any attachments are confidential. The = information contained in this email message and any attachments may be=20 confidential information. If you are not the intended recipient, any use,= =20 interference with, disclosure or copying of this material is unauthorised= =20and=20 prohibited. This email and any attachments are also subject to copyright.= =20No=20 part of them may be reproduced, adapted or transmitted without the writte= n=20 permission of the copyright owner. If you have received this email in err= or=20 please immediately advise the sender by return email and delete the messa= ge from=20 your system. Although this email has been checked for viruses and other d= efects,=20 no responsibility can be accepted for any loss or damage arising from its= =20 receipt or use. Racing Victoria Limited respects your privacy. Our privac= y=20 policy can be accessed from our web site: "http://www.racingvictoria.net.= au"=20 *************************************************************************= *******************************

Thank = You.

------_=_NextPart_001_01CD6E10.764E6C6C-- From W.Doust@racingvictoria.net.au Sun Jul 29 22:12:39 2012 Return-Path: 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 C676611E812C for ; Sun, 29 Jul 2012 22:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 6CNZCsQEc2sN for ; Sun, 29 Jul 2012 22:12:39 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id AC06311E8127 for ; Sun, 29 Jul 2012 22:12:38 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 9558) id ; Mon, 30 Jul 2012 15:12:37 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 30 Jul 2012 15:11:39 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279E0@XCHANGE.rvl.internal> In-Reply-To: <5016123F.1090803@isdg.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1uDqyPLQ5Iy/2KR5CAMFakQExWogAAkJaw References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <5016123F.1090803@isdg.net> From: "Wayne Doust" To: "Hector Santos" Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 05:12:40 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEhlY3RvciBTYW50b3MgW21haWx0bzpo c2FudG9zQGlzZGcubmV0XSANClNlbnQ6IE1vbmRheSwgMzAgSnVseSAyMDEyIDI6NDkgUE0NClRv OiBXYXluZSBEb3VzdA0KQ2M6IHNwZmJpc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzcGZiaXNd IFNQRiBwYXJzaW5nIGZhaWx1cmUgc2hvdWxkIGRlZmF1bHQgdG8gU1BGIE5FVVRSQUwNCg0KSWYg aXRzIGEgIkdvb2QgR3V5IiB0aGVuIGluIG1vc3Qgc3VwcG9ydCBjYXNlcywgaWYgdGhleSBkb24n dCB3aXNoIHRvIGZpeCB0aGVpciBwcm9ibGVtIG9yIGFyZSBwcmVzZW50bHkgaW4gZGVuaWFsLCB5 b3UgaGF2ZSBubyBjaG9pY2UgYnV0IHRvIHdoaXRlIGxpc3QgdGhlbSBzbyB0aGF0IGl0IGRvZXNu J3QgYWRkIHRvIHlvdXIgcHJvY2Vzc2luZyBvciBzdXBwb3J0IG92ZXJoZWFkLiAgSWYgYSBiYWQg Z3V5LCB0aGVuIGl0cyBlYXN5IC0gYmxvY2sgdGhlbS4NCg0KRm9yIHVzLCBTUEYgaXMganVzdCBv bmUgb2YgYSBzdWl0ZSBvZiB0ZXN0aW5nLiBGb3IgYW4gcHJvY2Vzc2luZyBlcnJvciwgaXRzIHRy ZWF0ZWQgYXMgTk9ORSAtIGxpa2UgaXQgbmV2ZXIgZXhpc3RlbmNlLCBpLmUuIA0KaW5kZXRlcm1p bmF0ZSwgbm8gcmVzdWx0LiAgSSBkb24ndCB0aGluayBhIGdvb2Qgc3lzdGVtIGNhbiBmYWxsYmFj ayB0byBGQUlML1NPRlRGQUlMIGlmIEEpIHRoZSBkb21haW4gZGlkIG5vdCBkZWNsYXJlIGl0IG9y IGIpIHdpdGhvdXQgc29tZSBmb3JtIG9mIGFuYWx5c2lzIG9mIHRoZSBzZW5kZXIgYXQgc29tZSBw b2ludC4gSW4gdGhlIGF1dG9tYXRlZCB3b3JsZCwgdGhlIHJpc2sgaXMgdG9vIGhpZ2ggZm9yIGZh bHNlIHBvc2l0aXZlcyAodGhhdHMgbm90IHRvIHN1Z2dlc3QgdGhlcmUgaXMgYSBoaWdoIG9jY3Vy cmVuY2Ugb2YgYmFkIFNQRiBwb2xpY3kgc3RhdGVtZW50cykuICBCdXQgdGhlIEZBSUwtU0FGRSBp cyBiZXR0ZXIgdW50aWwgb25lIGNhbiBzZWUgaWYgaXRzIGFuIGFidXNpdmUgc3lzdGVtLCB0aGVu IGFkZGluZyBhIGJsb2NrIGZvciBpdCBpcyBwYXIgZm9yIHRoZSBjb3Vyc2UuDQotLQ0KDQpQbGVh c2UgYWxsb3cgbWUgdG8gcGFpbnQgdGhlIHBpY3R1cmUgZnJvbSBTeXNhZG1pbiBvZiBhbiBTTUUg KGxpa2UgbWUpIGJlaW5nIGNhbGxlZCBieSBhIHVzZXI6DQoNCjEpIElmIGEgdXNlciBjYW4ndCBy ZWNlaXZlIGVtYWlsIGZyb20gYSB0aGlyZCBwYXJ0eSAtIGl0J3MgTVkgZmF1bHQuICJUaGV5IGNh biBzZW5kIGVtYWlsIHRvIEVWRVJZT05FIGVsc2UhIg0KMikgSWYgYSB1c2VyIGNhbid0IHNlbmQg ZW1haWwgdG8gYSB0aGlyZCBwYXJ0eSAtIGl0J3MgTVkgZmF1bHQuICJUaGV5IGNhbiByZWNlaXZl IGVtYWlsIGZyb20gRVZFUllPTkUgZWxzZSEiDQoNCklmICMxIGhhcHBlbnMsIHRoYXQncyBlYXN5 OiBJIHdoaXRlbGlzdCB0aGUgcmVtb3RlIHVzZXIuIEluIGZhY3QsIEkgbm93IGF1dG8td2hpdGVs aXN0IEFMTCBvdXRnb2luZyByZWNpcGllbnQgZW1haWwgYWRkcmVzc2VzLg0KSWYgIzIgaGFwcGVu cywgdGhlcmUncyBub3QgbXVjaCBJIGNhbiBkbyBvdGhlciB0aGFuIGF0dGVtcHQgdG8gY29udGFj dCB0aGUgcmVtb3RlIElUIERlcGFydG1lbnQuIFNvbWV0aGluZyBJIGRvIGFsbCB0b28gb2Z0ZW4u DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpEaXNj bGFpbWVyOiBUaGlzIGVtYWlsIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlk ZW50aWFsLiAgIA0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGVtYWlsIG1lc3Nh Z2UgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgYmUgDQpjb25maWRlbnRpYWwgaW5mb3JtYXRpb24u IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSB1c2UsIGludGVyZmVy ZW5jZSB3aXRoLCANCmRpc2Nsb3N1cmUgb3IgY29weWluZyBvZiB0aGlzIG1hdGVyaWFsIGlzIHVu YXV0aG9yaXNlZCBhbmQgcHJvaGliaXRlZC4NClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgYWxzbyBzdWJqZWN0IHRvIGNvcHlyaWdodC4gIA0KTm8gcGFydCBvZiB0aGVtIG1heSBi ZSByZXByb2R1Y2VkLCBhZGFwdGVkIG9yIHRyYW5zbWl0dGVkIHdpdGhvdXQgdGhlIHdyaXR0ZW4N CnBlcm1pc3Npb24gb2YgdGhlIGNvcHlyaWdodCBvd25lci4NCklmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIGltbWVkaWF0ZWx5IGFkdmlzZSB0aGUgc2VuZGVy IA0KYnkgcmV0dXJuIGVtYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgZnJvbSB5b3VyIHN5c3Rl bS4gDQpBbHRob3VnaCB0aGlzIGVtYWlsIGhhcyBiZWVuIGNoZWNrZWQgZm9yIHZpcnVzZXMgYW5k IG90aGVyIGRlZmVjdHMsIG5vIHJlc3BvbnNpYmlsaXR5IA0KY2FuIGJlIGFjY2VwdGVkIGZvciBh bnkgbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIGl0cyByZWNlaXB0IG9yIHVzZS4NClJhY2lu ZyBWaWN0b3JpYSBMaW1pdGVkIHJlc3BlY3RzIHlvdXIgcHJpdmFjeS4gT3VyIHByaXZhY3kgcG9s aWN5IGNhbiBiZSBhY2Nlc3NlZCANCmZyb20gb3VyIHdlYiBzaXRlOiAiaHR0cDovL3d3dy5yYWNp bmd2aWN0b3JpYS5uZXQuYXUiDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0K From superuser@gmail.com Mon Jul 30 00:02:20 2012 Return-Path: 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 CC5BE11E811C for ; Mon, 30 Jul 2012 00:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 oC1hSyDzmx-L for ; Mon, 30 Jul 2012 00:02:19 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCE111E8114 for ; Mon, 30 Jul 2012 00:02:19 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3441621lbb.31 for ; Mon, 30 Jul 2012 00:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wFNN3ztXL+/jh2v9KA4j1Un86P3RNhSRYC7U4PSl1c8=; b=UVRTqYvfn9kEQ2t26tZ0L/UMWOZZTqKIU6riYovV4P7W4Au28/A7HVVM3q/7cLs8N7 od6g4Lq2ZbW8KwiwQSM7x5lI+1UBvO6qVENurtw6TS5+EYtpthepw0R1ZLHVhWGUYyDf Vewo8uc1ffu1k66xqjPShrAGzDHPy/8AZ2x3Nq9wsraXTQb+MOr96LQKxduAbnY0gDXu A2HYFHDUML40Mv0rtrANVbGV32C7U6D/qcYLMLkffJeIM/KNj1hQboc0AS59Ylz8pTjm dGkaxEQunZ47bflCpvONhxj8h/n1At82EdKfrbevWr2Z8MQe0KBtlh80/DoJV64+n+I9 ca6g== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr10691611lab.9.1343631738168; Mon, 30 Jul 2012 00:02:18 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 30 Jul 2012 00:02:18 -0700 (PDT) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279DD@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <0D2A0D5F64179F4F9556D3DEDE39F9AF010279DD@XCHANGE.rvl.internal> Date: Mon, 30 Jul 2012 00:02:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Wayne Doust Content-Type: multipart/alternative; boundary=e89a8f22c41176660a04c606a481 Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 07:02:20 -0000 --e89a8f22c41176660a04c606a481 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Jul 29, 2012 at 10:02 PM, Wayne Doust wrote: > > | I'm confused a bit here. Listing an entire subnet isn't by itself a > syntax error or parsing problem, is it? It's a matter of having too broa= d > of an authorization, correct? > **** > > Most of the parsing failures I=92ve encountered do seem to be failing on > either IP4 or IP6 subnets. Certainly for the record I=92m responsible for= , > that seems to be the case. Nearly always it is due to some out-of-the-box > email filter that is the problem and I=92m greeted with =93Ha! We use XYZ= email > filter! It must be YOUR problem.=94 > So you really are talking about syntax errors here. Section 2.5.8 of RFC4408 seems to be pretty clear that this should result in a "permerror", not "neutral", "none", or "softfail". A filter that yields one of the latter results when it encounters a syntax error in the DNS record is plainly broken. > **** > > > | How a filter actually responds to a softfail or fail isn't specified by > either version of the document. (Or neutral, for that matter.) > Essentially the filter has made an unfortunate decision. If RFC4408bis > doesn't adequately warn of "use cases" such as these, I agree that we > should consider mentioning them. > > **** > > This is essentially what I=92m advocating:**** > > ** ** > > A STRICT check should REQUIRE an SPF PASS.**** > > A MODERATE check should REQUIRE an SPF PASS, NEUTRAL or NONE, but ALSO > permit a PERMERROR or TEMPERROR. This means a Moderate check should ONLY > Fail on an SPF FAIL or SPF SOFTFAIL.**** > > A RELAXED check should ONLY Fail on an SPF FAIL.**** > > > > I don't think we have specific definitions of STRICT, MODERATE, or RELAXED the way you're using them here, so we can't really say anything like what you're saying in a normative sense. If we did, we'd also have to include some guidance about when each of those modes would be appropriate to apply. I think it's far simpler to leave that in the hands of the (educated, one would hope) reader. Why, for example, would I not want a STRICT check if I have users to defend? Essentially, RFC4408 leaves it in the hands of implementers to decide what to do with any given result. In particular, "fail" does not actually require rejection of a message: 2.5.4 . Fail A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking software can choose to mark the mail based on this or to reject the mail outright. It then proceeds to say "If you're going to reject, here's how we think you should go about it." But none of that is required in either RFC4408 or its planned successor. If you post a syntactically valid SPF record and someone's broken filter rejects your mail anyway, and that recipient is daft enough to stand by that filter, I imagine there's not much a spec writer could do to change that person's mind. -MSK --e89a8f22c41176660a04c606a481 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Jul 29, 2012 at 10:02 PM, Wayne Doust <W.Doust@racingv= ictoria.net.au> wrote:


| = I'm confused a bit here.=A0 Listing an entire subnet isn't by itsel= f a syntax error or parsing problem, is it?=A0 It's a matter of having = too broad of an authorization, correct?
=A0

Most of the parsing failures I=92ve encountered do seem to = be failing on either IP4 or IP6 subnets. Certainly for the record I=92m res= ponsible for, that seems to be the case. Nearly always it is due to some ou= t-of-the-box email filter that is the problem and I=92m greeted with =93Ha!= We use XYZ email filter! It must be YOUR problem.=94


So you really are talking abo= ut syntax errors here.

Section 2.5.8 of RFC4408 seems to be pretty c= lear that this should result in a "permerror", not "neutral&= quot;, "none", or "softfail".=A0 A filter that yields o= ne of the latter results when it encounters a syntax error in the DNS recor= d is plainly broken.
=A0

=
| How a filter actually responds t= o a softfail or fail isn't specified by either version of the document.= =A0 (Or neutral, for that matter.)=A0 Essentially the filter has made an un= fortunate decision.=A0 If RFC4408bis doesn't adequately warn of "use cases" such as these, I agree = that we should consider mentioning them.

This is essentially what I=92m advocating:

=A0

A STRICT check should REQUIRE an SPF PASS.=

A MODERATE check should R= EQUIRE an SPF PASS, NEUTRAL or NONE, but ALSO permit a PERMERROR or TEMPERR= OR. This means a Moderate check should ONLY Fail on an SPF FAIL or SPF SOFT= FAIL.

A RELAXED check should ON= LY Fail on an SPF FAIL.




I = don't think we have specific definitions of STRICT, MODERATE, or RELAXE= D the way you're using them here, so we can't really say anything l= ike what you're saying in a normative sense.=A0 If we did, we'd als= o have to include some guidance about when each of those modes would be app= ropriate to apply.=A0 I think it's far simpler to leave that in the han= ds of the (educated, one would hope) reader.=A0 Why, for example, would I n= ot want a STRICT check if I have users to defend?

Essentially, RFC4408 leaves it in the hands of implementers to decide w= hat to do with any given result.=A0 In particular, "fail" does no= t actually require rejection of a message:


2.5.4.  Fail


   A "Fail" result is an explicit statement that the client is no=
t
   authorized to use the domain in the given identity.  The checking
   software can choose to mark the mail based on this or to reject the
   mail outright.

It then proceeds to say "If you're goin= g to reject, here's how we think you should go about it."=A0 But n= one of that is required in either RFC4408 or its planned successor.

If you post a syntactically valid SPF record and someone's broken filte= r rejects your mail anyway, and that recipient is daft enough to stand by t= hat filter, I imagine there's not much a spec writer could do to change= that person's mind.

-MSK

--e89a8f22c41176660a04c606a481-- From hsantos@isdg.net Mon Jul 30 01:04:22 2012 Return-Path: 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 386DC21F86C3 for ; Mon, 30 Jul 2012 01:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 EWgBAGVKggCm for ; Mon, 30 Jul 2012 01:04:19 -0700 (PDT) Received: from pop3.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4596221F86BA for ; Mon, 30 Jul 2012 01:04:18 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2282; t=1343635454; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=swZXNF4XhjRWMqQqA2NmILqs24U=; b=s81/WGr1KYF/qmz8GfgL JJKQYrkE6Bj8RpMMnAfmCp1E4E4R/Y92Q8rDIKIjhH6SJSJMg2oXGm3TSQKJSB2j je2xDDypF4tRLD77nxv+n4qQfb7q2iuiFH169KxCX8yUIHxine+1VzvM64EkMWWB KY+67TKd7PssnmY68nVHI6M= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 30 Jul 2012 04:04:14 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3952242001.3333.5088; Mon, 30 Jul 2012 04:04:13 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2282; t=1343635304; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+vfSvwh 9qjAO3szT3bODReVZoAt7pVUM+8y0XuuTTjs=; b=C5jz0uNvDOj8CMFpnon9JiS Pv7yTlRtxkwU2TMmfFPZoBCMGH6xnWFQYRXtSWySdPxz1uEHWC82HJDcosPNir3c TcUptrC+0v7pLKOcFL2W1YrnzbzOwhO7UHc2FL2ByZEPMgkJwlIiywqmZ6aMMXEj 1iWZvj96McAIdivXiR3c= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 30 Jul 2012 04:01:44 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 256101895.9.5692; Mon, 30 Jul 2012 04:01:43 -0400 Message-ID: <50163FFE.3090109@isdg.net> Date: Mon, 30 Jul 2012 04:04:14 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Wayne Doust References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <0D2A0D5F64179F4F9556D3DEDE39F9AF010279DD@XCHANGE.rvl.internal> In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279DD@XCHANGE.rvl.internal> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 08:04:22 -0000 Wayne Doust wrote: > A STRICT check should REQUIRE an SPF PASS. > > A MODERATE check should REQUIRE an SPF PASS, NEUTRAL or NONE, but ALSO > permit a PERMERROR or TEMPERROR. This means a Moderate check should ONLY > Fail on an SPF FAIL or SPF SOFTFAIL. > > A RELAXED check should ONLY Fail on an SPF FAIL. I think I partly follow your point now. If the DOMAIN publishes exclusive policies for hard failures, then an error processing should fallback to a a FAIL SPF result. That may have reasoning logic to consider. However, not sure what STRICT, MODERATE, RELAXED means or where you are going with this but there is only one form of SPF checking - the correct one. Everyone MUST follow the same protocol and expectations for proper processing. Sounds to me that there is also a programming issue where complexity has become a worth factor. What happens now is that it breakdowns to this: FORMS OF CHECKING: STRICT - complete 100% correct and support of all SPF features. MODERATE - partial < 100% correct and support of SPF features. RELAXED - Less than MODERATE support of SPF features. I don't think we want to go there - 100% support if expected others the SPF receiver is not complaint and it worst, it will water down, weaken SPF publishing of statements dependent on subjective design viewpoint of "Software Complexity." There MUST be one design expectation - ALL or nothing, unless of course there is an existing OPTION for not supporting. But it has to be written what is OPTIONAL or not. Anyway, You're talking about an invalid SPF policy - thats not your fault. Passing the buck isn't going to help your user who can care less. QA/Customer Support 101 - the customer is always right. IMTO, the best you can do is monitor, track whether the 3rd party is a good or bad guy. The same issue can be applied to other issues already on the tracker concerning any kind temporary, permanent or perpetual error - does the receiver have a right to take action at some point? When does a temporary but perpetual errors become permanent to avoid the overhead, the redundant invalid SPF policy processing? These are implementation specific suggestions, although I believe it should be considered for a protocol. -- HLS From me@junc.org Mon Jul 30 12:26:05 2012 Return-Path: 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 D172111E81BE for ; Mon, 30 Jul 2012 12:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.691 X-Spam-Level: X-Spam-Status: No, score=-8.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_HI=-8] 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 oldYP93Q9zYq for ; Mon, 30 Jul 2012 12:26:05 -0700 (PDT) Received: from home.junc.org (home.junc.org [2.104.223.10]) by ietfa.amsl.com (Postfix) with ESMTP id E45D611E808D for ; Mon, 30 Jul 2012 12:26:04 -0700 (PDT) Received: from localhost (localhost.junc.org [127.0.0.1]) by home.junc.org (Postfix) with SMTP id 0D8EB25C196 for ; Mon, 30 Jul 2012 21:32:53 +0200 (CEST) Received: from localhost.junc.org (localhost.junc.org [127.0.0.1]) by localhost.junc.org (Postfix) with ESMTP id C5BAE25C1F2 for ; Mon, 30 Jul 2012 21:32:52 +0200 (CEST) Received: from localhost.junc.org ([127.0.0.1]) by localhost.junc.org (localhost.junc.org [127.0.0.1]) (amavisd-new, port 10586) with ESMTP id 9dV99aJLvQGp for ; Mon, 30 Jul 2012 21:32:50 +0200 (CEST) Received: from localhost.junc.org (localhost.junc.org [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: me@junc.org) by home.junc.org (Postfix) with ESMTPSA id B610B25C196 for ; Mon, 30 Jul 2012 21:32:50 +0200 (CEST) X-DKIM: OpenDKIM Filter v2.6.7 home.junc.org B610B25C196 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=junc.org; s=mail; t=1343676770; x=1343680370; bh=s06PYwLj4+TcIcKyi22qYYi8B9NqlYedewq750KfakI=; l=112; h=Date:From:To:Subject:In-Reply-To:References; b=sm6c/osezJBWR+OvHvPRX86h5ldyy5IrzX4C766TJC3MyR5+hYiNj/QNDRXsWP7h/ b6YTA9R25IhpE55+re3Nk6DvwqByZ7N6S8CtN+qtEFnif1zKBTulHPgNo9dzD4Wb0N 8UHmWtecZShNLvwl1sXE7DiuVLQrV43aLEV4yfpY= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 30 Jul 2012 21:32:50 +0200 From: Benny Pedersen To: In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> Message-ID: X-Sender: me@junc.org User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 19:26:05 -0000 Den 2012-07-30 03:36, Wayne Doust skrev: > Our privacy policy can be accessed from our web our maillist :/ From prvs=5512d402d=fmartin@linkedin.com Mon Jul 30 12:53:34 2012 Return-Path: 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 7D94911E81E5 for ; Mon, 30 Jul 2012 12:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 c2V5pDdklKZm for ; Mon, 30 Jul 2012 12:53:33 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id B26AE11E81E4 for ; Mon, 30 Jul 2012 12:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim; t=1343678013; x=1375214013; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=dKoJzuNm0OyOo9qCmeG5LzA3sw5hDKy/TWLlipRz2sA=; b=goViloiI9IoNJMsdU+5oQMb2dcjee3RRXKb4285pnSj8jv+UbyzDJNXy sbNJEDJyWk1L6FMvkYnhFubU7CkyC4RwyLIchWWzAAikhIE1y9zCnEDHZ jF3txTXLTJZb6FG; X-IronPort-AV: E=Sophos;i="4.77,681,1336374000"; d="scan'208";a="22040316" Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.01.0355.002; Mon, 30 Jul 2012 12:53:11 -0700 From: Franck Martin To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] SPF and empty mail from envelope spec is unclear. Thread-Index: AQHNa4zJSInjtc1rf0KkMKN4sD5TeZc9FpkAgAGp3YCAAACbgIADgc8A Date: Mon, 30 Jul 2012 19:53:10 +0000 Message-ID: In-Reply-To: <2251090.tmuqHQDhjH@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="Windows-1252" Content-ID: <160354988358F74BBE9B45CDC1B4B8E4@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 19:53:34 -0000 Digging more in this issue, I'm keen on proposing some text, but also looking at my anecdotal operational experience, isn't it something that should go on the deprecated list, due to lack of correct implementation? On 7/28/12 12:20 AM, "Scott Kitterman" wrote: >I guess I was speaking imprecisely. fully qualified hostname of the >client:=20 >hostname.domain is exactly what you use. > >Scott K > >On Saturday, July 28, 2012 07:17:35 AM Franck Martin wrote: >> I see... >>=20 >> from experience when it is not broken what I have seen is that the helo >>does >> not contain a domain but the fully qualified hostname of the client: >> hostname.domain >>=20 >> It could then difficult to find the domain from that. >>=20 >> I'm not sure, any SMTP implementation respect this RFC. May be someone >>as >> some data? >> On Jul 26, 2012, at 10:53 PM, Scott Kitterman wrote: >> > On Friday, July 27, 2012 12:14:27 AM Franck Martin wrote: >> >> Hi, >> >>=20 >> >> This may be something, you have discussed before, but I'll jump in, >> >> instead >> >> of reading the archives=8A >> >>=20 >> >> I'm looking at the current spec, and I'm not sure it is clear to use >>the >> >> domain in the HELO/EHLO string when the mail from: is empty (bounce). >> >>=20 >> >> I think this part should be made clearer, and may be help define >>what is >> >> the domain inside the HELO/EHLO string. Is this defined as >> >> localhost.domain? Or is it left to the SPF implementation to figure >>it >> >> out and look for an SPF record for each portion of the string: >>a.b.c.d >> >> then b.c.d then c.d =8A> >> > It's the domain used by the connection SMTP client as their HELO/EHLO >> > name. >> > Isn't that sufficiently defined in RFC 5321? There is no walk up the >> > domain tree. That was tried pre-RFC 4408 and it turned out to have a >> > number of operational problems and was abandoned. >> >=20 >> > I'm not sure what's unclear, so perhaps you could propose text? >> >=20 >> > Scott K >> > _______________________________________________ >> > spfbis mailing list >> > spfbis@ietf.org >> > https://www.ietf.org/mailman/listinfo/spfbis >>=20 >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Mon Jul 30 13:25:15 2012 Return-Path: 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 EC2FE11E8151 for ; Mon, 30 Jul 2012 13:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] 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 jRJoGjpuTkbb for ; Mon, 30 Jul 2012 13:25:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6DA11E8126 for ; Mon, 30 Jul 2012 13:25:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A241D20E4134; Mon, 30 Jul 2012 16:25:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343679902; bh=0+kDXmrbAkofAKSy4bUMRFogLn/YukSTpb4kKwzE0AA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bc+l16usFcUG4FWcitoBv4Uyaa98pn9pnSL6P2pNoE/hqviQmXbj0cPh+p8my3eKm 4nweGX7vbq1uAbrmEO163iqhEc+uQfCHmcFWsiwSE+mGjTa47XrPKDRqmPtLSTzPLk 5Ujf/zPJmObuXp1KgCyzbQPoEbxH4tBDoD4S4awg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 82CCD20E4095; Mon, 30 Jul 2012 16:25:02 -0400 (EDT) From: Scott Kitterman To: "spfbis@ietf.org" Date: Mon, 30 Jul 2012 16:25:01 -0400 Message-ID: <3404145.iU5CY3iOGV@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:25:15 -0000 I'm not sure what you mean. At least all open source libraries of whic= h I'm=20 aware implement this correctly. It's certainly not unused. Scott K On Monday, July 30, 2012 07:53:10 PM Franck Martin wrote: > Digging more in this issue, I'm keen on proposing some text, but also= > looking at my anecdotal operational experience, isn't it something th= at > should go on the deprecated list, due to lack of correct implementati= on? >=20 > On 7/28/12 12:20 AM, "Scott Kitterman" wrote: > >I guess I was speaking imprecisely. fully qualified hostname of the= > >client: > >hostname.domain is exactly what you use. > > > >Scott K > > > >On Saturday, July 28, 2012 07:17:35 AM Franck Martin wrote: > >> I see... > >>=20 > >> from experience when it is not broken what I have seen is that the= helo > >> > >>does > >> > >> not contain a domain but the fully qualified hostname of the clien= t: > >> hostname.domain > >>=20 > >> It could then difficult to find the domain from that. > >>=20 > >> I'm not sure, any SMTP implementation respect this RFC. May be som= eone > >> > >>as > >> > >> some data? > >>=20 > >> On Jul 26, 2012, at 10:53 PM, Scott Kitterman wrote: > >> > On Friday, July 27, 2012 12:14:27 AM Franck Martin wrote: > >> >> Hi, > >> >>=20 > >> >> This may be something, you have discussed before, but I'll jump= in, > >> >> instead > >> >> of reading the archives=C5=A0 > >> >>=20 > >> >> I'm looking at the current spec, and I'm not sure it is clear t= o use > >> > >>the > >> > >> >> domain in the HELO/EHLO string when the mail from: is empty (bo= unce). > >> >>=20 > >> >> I think this part should be made clearer, and may be help defin= e > >> > >>what is > >> > >> >> the domain inside the HELO/EHLO string. Is this defined as > >> >> localhost.domain? Or is it left to the SPF implementation to fi= gure > >> > >>it > >> > >> >> out and look for an SPF record for each portion of the string: > >>a.b.c.d > >> > >> >> then b.c.d then c.d =C5=A0> > >> >=20 > >> > It's the domain used by the connection SMTP client as their HELO= /EHLO > >> > name. > >> > Isn't that sufficiently defined in RFC 5321? There is no walk u= p the > >> > domain tree. That was tried pre-RFC 4408 and it turned out to h= ave a > >> > number of operational problems and was abandoned. > >> >=20 > >> > I'm not sure what's unclear, so perhaps you could propose text? > >> >=20 > >> > Scott K > >> > _______________________________________________ > >> > spfbis mailing list > >> > spfbis@ietf.org > >> > https://www.ietf.org/mailman/listinfo/spfbis > >>=20 > >> _______________________________________________ > >> spfbis mailing list > >> spfbis@ietf.org > >> https://www.ietf.org/mailman/listinfo/spfbis > > > >_______________________________________________ > >spfbis mailing list > >spfbis@ietf.org > >https://www.ietf.org/mailman/listinfo/spfbis From prvs=5512d402d=fmartin@linkedin.com Mon Jul 30 13:47:10 2012 Return-Path: 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 992BB11E8155 for ; Mon, 30 Jul 2012 13:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 GENKFVRAJING for ; Mon, 30 Jul 2012 13:47:09 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id AF59F11E818E for ; Mon, 30 Jul 2012 13:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim; t=1343681229; x=1375217229; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=8APlMmW5ba9J6czzmwRBP6qa30Y3A+eWnbYnI4rHVP8=; b=P17HTn86L6ODXmsB7ythuspeGZH2nnBvechIFElHIGI0OEk20N/Da/HA +QBI5/CvPmXrZb+UTygr7lkG8YlX9o6F0iGOkgxTNThW/tSGNgueQqXjQ 7Vv1whvZl0d9vsr; X-IronPort-AV: E=Sophos;i="4.77,681,1336374000"; d="scan'208";a="22044689" Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.01.0355.002; Mon, 30 Jul 2012 13:46:46 -0700 From: Franck Martin To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] SPF and empty mail from envelope spec is unclear. Thread-Index: AQHNa4zJSInjtc1rf0KkMKN4sD5TeZc9FpkAgAGp3YCAAACbgIADgc8AgAB+KYD//5DPgA== Date: Mon, 30 Jul 2012 20:46:46 +0000 Message-ID: In-Reply-To: <3404145.iU5CY3iOGV@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D99E2197B1F9E40A470FB9311A37B1F@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:47:10 -0000 What I mean, is who present a correct helo string associated with a SPF record, so the SPF validation can work for a bounce? Is that part widely implemented? On 7/30/12 1:25 PM, "Scott Kitterman" wrote: >I'm not sure what you mean. At least all open source libraries of which >I'm=20 >aware implement this correctly. It's certainly not unused. > >Scott K > >On Monday, July 30, 2012 07:53:10 PM Franck Martin wrote: >> Digging more in this issue, I'm keen on proposing some text, but also >> looking at my anecdotal operational experience, isn't it something that >> should go on the deprecated list, due to lack of correct implementation? >>=20 >> On 7/28/12 12:20 AM, "Scott Kitterman" wrote: >> >I guess I was speaking imprecisely. fully qualified hostname of the >> >client: >> >hostname.domain is exactly what you use. >> > From spf2@kitterman.com Mon Jul 30 13:58:26 2012 Return-Path: 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 00C1011E81B4 for ; Mon, 30 Jul 2012 13:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] 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 qccEBL4Hmydf for ; Mon, 30 Jul 2012 13:58:25 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5117B11E818E for ; Mon, 30 Jul 2012 13:58:25 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 83FED20E4095; Mon, 30 Jul 2012 16:58:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343681904; bh=SVnc6SJoUm5n0uE3dhrUC4NukUiJpHT5Ub/gfUr3Osc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=p71e/dS8TnnNWLOgAdKRijuB9RNp6gRwy7uxd1JpdVP7gyMrQ4XPQvRmDOS+B95NO Ivs2kEYIWeFbx8WkB+1x33ikNdzhHRru2CyywKiU29raoBTs0P2/ma46bealitVE3v k7xJFqYVaQxL9fFpleMPTElC1tCDEhoFByBoyxds= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6567E20E408E; Mon, 30 Jul 2012 16:58:24 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 30 Jul 2012 16:58:23 -0400 Message-ID: <671843375.Vxg8nyqboN@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:58:26 -0000 Yes. Scott K On Monday, July 30, 2012 08:46:46 PM Franck Martin wrote: > What I mean, is who present a correct helo string associated with a SPF > record, so the SPF validation can work for a bounce? Is that part widely > implemented? > > On 7/30/12 1:25 PM, "Scott Kitterman" wrote: > >I'm not sure what you mean. At least all open source libraries of which > >I'm > >aware implement this correctly. It's certainly not unused. > > > >Scott K > > > >On Monday, July 30, 2012 07:53:10 PM Franck Martin wrote: > >> Digging more in this issue, I'm keen on proposing some text, but also > >> looking at my anecdotal operational experience, isn't it something that > >> should go on the deprecated list, due to lack of correct implementation? > >> > >> On 7/28/12 12:20 AM, "Scott Kitterman" wrote: > >> >I guess I was speaking imprecisely. fully qualified hostname of the > >> >client: > >> >hostname.domain is exactly what you use. > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From prvs=5512d402d=fmartin@linkedin.com Mon Jul 30 15:16:28 2012 Return-Path: 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 CE80511E81FC for ; Mon, 30 Jul 2012 15:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] 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 YwFLxVbi2FeX for ; Mon, 30 Jul 2012 15:16:28 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 25EC511E81EB for ; Mon, 30 Jul 2012 15:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim; t=1343686588; x=1375222588; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=T8E+HEV9mXBPKvGTIk4i3lbbDZh4HIZxlE7K4Xm5MNs=; b=OZTwC3tInoI269wXDDhA8oJ6Idb7vS3fLBlx6uE6A1sYGndUGq4mASX2 s3RzTQOkPxGMUeqoV96Ao1r95dme4HuoRXnyuOBBgkQPmD/XRMvSFLYIw W6t9d4jvu4wNQcG; X-IronPort-AV: E=Sophos;i="4.77,681,1336374000"; d="scan'208";a="22052142" Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.01.0355.002; Mon, 30 Jul 2012 15:16:05 -0700 From: Franck Martin To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] SPF and empty mail from envelope spec is unclear. Thread-Index: AQHNa4zJSInjtc1rf0KkMKN4sD5TeZc9FpkAgAGp3YCAAACbgIADgc8AgAB+KYD//5DPgIAAeISA//+gb4A= Date: Mon, 30 Jul 2012 22:16:05 +0000 Message-ID: In-Reply-To: <671843375.Vxg8nyqboN@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="us-ascii" Content-ID: <889A17D81A68E6429172B8855A355330@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:16:28 -0000 Thanks.=20 I'm confused because I see often host.domain where domain is the one with the SPF record. Based on http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ An added section under 9.1 could be useful 9.1.3 Bounces As explained in 2.2, [RFC5321] allows the reverse-path to be null, which is typical of some Delivery Status Notification [RFC3464], commonly called email bounces. In this case the only entity available for performing an SPF check is the HELO identity defined in 1.1. Administrators MUST(SHOULD?) ensure that this identity is set correctly and has an appropriate SPF record. It is common to have the HELO identity set to hostname instead of domain. Administrators SHOULD consider publishing an SPF for *.domain (wildcard domains) in that case. Feel free to rewrite, which I'm sure you will. On 7/30/12 1:58 PM, "Scott Kitterman" wrote: >Yes. > >Scott K > >On Monday, July 30, 2012 08:46:46 PM Franck Martin wrote: >> What I mean, is who present a correct helo string associated with a SPF >> record, so the SPF validation can work for a bounce? Is that part widely >> implemented? >>=20 >> On 7/30/12 1:25 PM, "Scott Kitterman" wrote: >> >I'm not sure what you mean. At least all open source libraries of >>which >> >I'm >> >aware implement this correctly. It's certainly not unused. >> > >> >Scott K >> > >> >On Monday, July 30, 2012 07:53:10 PM Franck Martin wrote: >> >> Digging more in this issue, I'm keen on proposing some text, but also >> >> looking at my anecdotal operational experience, isn't it something >>that >> >> should go on the deprecated list, due to lack of correct >>implementation? >> >>=20 >> >> On 7/28/12 12:20 AM, "Scott Kitterman" wrote: >> >> >I guess I was speaking imprecisely. fully qualified hostname of the >> >> >client: >> >> >hostname.domain is exactly what you use. >>=20 >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From derek.diget+spfbis@wmich.edu Mon Jul 30 17:48:55 2012 Return-Path: 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 CA9D711E80BF for ; Mon, 30 Jul 2012 17:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 04SaLkssscfL for ; Mon, 30 Jul 2012 17:48:55 -0700 (PDT) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by ietfa.amsl.com (Postfix) with ESMTP id 25A5B11E80BA for ; Mon, 30 Jul 2012 17:48:55 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/Plain; charset=US-ASCII Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0M7Z009WDTCELL30@mta01.service.private> for spfbis@ietf.org; Mon, 30 Jul 2012 17:36:15 -0400 (EDT) X-WMU-Spam: Gauge=X, Probability=10% on Mon Jul 30 17:36:15 2012, Report=' WMU_MSA_SMTP+ 0, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1200_1299 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NS ' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.30.212118 - Mon Jul 30 17:36:14 2012 Date: Mon, 30 Jul 2012 17:36:14 -0400 (EDT) From: Derek Diget X-X-Sender: diget@spaz.oit.wmich.edu To: spfbis@ietf.org In-reply-to: <5015F1A7.50000@gathman.org> Message-id: References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <5015F1A7.50000@gathman.org> Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:48:55 -0000 On Jul 29, 2012 at 22:29 -0400, Stuart Gathman wrote: =>Long ago, Nostradamus foresaw that on 07/29/2012 09:36 PM, Wayne Doust =>would write: =>> =>> If possible, I think the SPF specification should recommend a parsing =>> failure should default to an SPF of NEUTRAL rather than a FAIL or =>> SOFTFAIL as is usually the case. In most cases I deal with the remote =>> sysadmin has simply implemented some off-the-shelf solution and ticked =>> the SPF "box" and that's the end of the story. Most have no way of =>> dealing with the issue other than whitelisting the entire domain -- =>> something that to me defeats the entire purpose of SPF. =>> =>The SPF specification *mandates* a result of PERMERROR (not fail or =>softfail) for parsing failures. It already recommends treating =>PermError like neutral. Can you point me in the direction where RFC4408 says that? I don't see it in section 2.5.7 nor anywhere else in the doc. Thanks. -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** From W.Doust@racingvictoria.net.au Mon Jul 30 21:57:50 2012 Return-Path: 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 8F60D21F8589 for ; Mon, 30 Jul 2012 21:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_05=-1.11, EXTRA_MPART_TYPE=1, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] 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 VS2UnrylsxhN for ; Mon, 30 Jul 2012 21:57:49 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8C23821F8578 for ; Mon, 30 Jul 2012 21:57:46 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 9558) id ; Tue, 31 Jul 2012 14:57:43 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CD6ED9.041EE44C" Date: Tue, 31 Jul 2012 14:57:36 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027AA6@XCHANGE.rvl.internal> In-Reply-To: <50163FFE.3090109@isdg.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [spfbis] SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1uKe6hOHz2J6HVSHeYqmtu7hUh1wApq+7Q References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <0D2A0D5F64179F4F9556D3DEDE39F9AF010279DD@XCHANGE.rvl.internal> <50163FFE.3090109@isdg.net> From: "Wayne Doust" To: "Hector Santos" Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 04:57:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD6ED9.041EE44C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CD6ED9.041EE44C" ------_=_NextPart_002_01CD6ED9.041EE44C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IA0KDQo+IElmIHRoZSBET01BSU4gcHVibGlzaGVzIGV4Y2x1c2l2ZSBwb2xpY2llcyBmb3IgaGFy ZCBmYWlsdXJlcywgdGhlbiBhbiBlcnJvciBwcm9jZXNzaW5nIHNob3VsZCBmYWxsYmFjayB0byBh IGEgRkFJTCBTUEYgcmVzdWx0Lg0KDQoNCkNsb3NlLCBidXQgbm90IHF1aXRlLg0KDQogDQoNClRo ZSAoZ2VuZXJhbGx5IHJlYXNvbmFibGUpIGFzc3VtcHRpb24gZm9yIGEgUEVSTUVSUk9SIGlzIGFu IGVycm9yIGluIHRoZSBzeW50YXggb2YgYW4gU1BGIHJlY29yZC4gSG93ZXZlciwgSSAqa25vdyog dGhhdCBteSBTUEYgcmVjb3JkIGlzIHN5bnRhY3RpY2FsbHkgY29ycmVjdCwgaG93ZXZlciBJIHN0 aWxsIGdldCBtYWlsIHJlamVjdGVkIGJlY2F1c2Ugb2YgUEVSTUVSUk9SLiBBbmQgSSBkb24ndCBt ZWFuIGZyb20gc21hbGwgc2l0ZXMuIEkndmUgaGFkIHByb2JsZW1zIHdpdGggbGFyZ2UgSVNQcywg YSBnb3Zlcm5tZW50IGRlcGFydG1lbnQgYW5kIEF1c3RyYWxpYSBQb3N0IHJlamVjdCBlbWFpbCB3 aXRoIGEgNDV4IG9uIHRoZSBiYXNpcyBvZiBhIFBFUk1FUlJPUi4NCg0KIA0KDQo+VGhhdCBtYXkg aGF2ZSByZWFzb25pbmcgbG9naWMgdG8gY29uc2lkZXIuIEhvd2V2ZXIsIG5vdCBzdXJlIHdoYXQg U1RSSUNULCBNT0RFUkFURSwgUkVMQVhFRCBtZWFucyBvciB3aGVyZSB5b3UgYXJlIGdvaW5nIHdp dGggdGhpcyANCg0KPmJ1dCB0aGVyZSBpcyBvbmx5IG9uZSBmb3JtIG9mIFNQRiBjaGVja2luZyAt IHRoZSBjb3JyZWN0IG9uZS4gRXZlcnlvbmUgTVVTVCBmb2xsb3cgdGhlIHNhbWUgcHJvdG9jb2wg YW5kIGV4cGVjdGF0aW9ucyBmb3IgcHJvcGVyIHByb2Nlc3NpbmcuDQoNCiANCg0KSSBhZ3JlZS4g SG93ZXZlciBwZXJoYXBzIHRoZSBzcGVjaWZpY2F0aW9uIGNhbiBnbyBiZXlvbmQgdGhlIGltbWVk aWF0ZSBjYXRlZ29yaWVzIHRvIHJlY29tbWVuZGluZyBob3cgdG8gZGVhbCB3aXRoIGVhY2ggb2Yg dGhlIHJlc3VsdHMgdW5kZXIgZGlmZmVyZW50IGNvbmRpdGlvbnMuDQoNCiANCg0KIA0KDQo+ICAg U1RSSUNUICAgLSBjb21wbGV0ZSAxMDAlIGNvcnJlY3QgYW5kIHN1cHBvcnQgb2YgYWxsIFNQRiBm ZWF0dXJlcy4NCg0KPiAgIE1PREVSQVRFIC0gcGFydGlhbCA8IDEwMCUgY29ycmVjdCBhbmQgc3Vw cG9ydCBvZiBTUEYgZmVhdHVyZXMuDQoNCj4gICBSRUxBWEVEICAtIExlc3MgdGhhbiBNT0RFUkFU RSBzdXBwb3J0IG9mIFNQRiBmZWF0dXJlcy4NCg0KPiANCg0KPiBJIGRvbid0IHRoaW5rIHdlIHdh bnQgdG8gZ28gdGhlcmUgLSAxMDAlIHN1cHBvcnQgaWYgZXhwZWN0ZWQgb3RoZXJzIHRoZSBTUEYg cmVjZWl2ZXIgaXMgbm90IGNvbXBsYWludCBhbmQgaXQgd29yc3QsIGl0IHdpbGwgd2F0ZXIgZG93 biwgd2Vha2VuIFNQRiBwdWJsaXNoaW5nIG9mIHN0YXRlbWVudHMgZGVwZW5kZW50IG9uIHN1Ympl Y3RpdmUgZGVzaWduIA0KDQogDQoNCkkgdGhpbmsgd2UgYWxyZWFkeSBBUkUgdGhlcmUuIE5vdCBl dmVyeW9uZSBpbXBsZW1lbnRzIHB5U1BGLiBNb3N0IGltcGxlbWVudG9ycyBleHBvc3VyZSB0byBT UEYgaXMgdmlhIGEgR1VJIHRoYXQgaGFzIHN0dWZmIGxpa2UgdGhpczoNCg0KIA0KDQogDQoNCiAN Cg0KIA0KDQogDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNCkRpc2NsYWltZXI6IFRoaXMgZW1haWwgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwuICAgDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg ZW1haWwgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBiZSANCmNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbi4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IHVz ZSwgaW50ZXJmZXJlbmNlIHdpdGgsIA0KZGlzY2xvc3VyZSBvciBjb3B5aW5nIG9mIHRoaXMgbWF0 ZXJpYWwgaXMgdW5hdXRob3Jpc2VkIGFuZCBwcm9oaWJpdGVkLg0KVGhpcyBlbWFpbCBhbmQgYW55 IGF0dGFjaG1lbnRzIGFyZSBhbHNvIHN1YmplY3QgdG8gY29weXJpZ2h0LiAgDQpObyBwYXJ0IG9m IHRoZW0gbWF5IGJlIHJlcHJvZHVjZWQsIGFkYXB0ZWQgb3IgdHJhbnNtaXR0ZWQgd2l0aG91dCB0 aGUgd3JpdHRlbg0KcGVybWlzc2lvbiBvZiB0aGUgY29weXJpZ2h0IG93bmVyLg0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2UgaW1tZWRpYXRlbHkgYWR2aXNl IHRoZSBzZW5kZXIgDQpieSByZXR1cm4gZW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBmcm9t IHlvdXIgc3lzdGVtLiANCkFsdGhvdWdoIHRoaXMgZW1haWwgaGFzIGJlZW4gY2hlY2tlZCBmb3Ig dmlydXNlcyBhbmQgb3RoZXIgZGVmZWN0cywgbm8gcmVzcG9uc2liaWxpdHkgDQpjYW4gYmUgYWNj ZXB0ZWQgZm9yIGFueSBsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gaXRzIHJlY2VpcHQgb3Ig dXNlLg0KUmFjaW5nIFZpY3RvcmlhIExpbWl0ZWQgcmVzcGVjdHMgeW91ciBwcml2YWN5LiBPdXIg cHJpdmFjeSBwb2xpY3kgY2FuIGJlIGFjY2Vzc2VkIA0KZnJvbSBvdXIgd2ViIHNpdGU6ICJodHRw Oi8vd3d3LnJhY2luZ3ZpY3RvcmlhLm5ldC5hdSINCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQo= ------_=_NextPart_002_01CD6ED9.041EE44C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYg OSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFp blRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZh bWlseTpDb25zb2xhczt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5Q bGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjIwNTAiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRp diBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IElmIHRoZSBET01BSU4gcHVibGlzaGVz IGV4Y2x1c2l2ZSBwb2xpY2llcyBmb3IgaGFyZCBmYWlsdXJlcywgdGhlbiBhbiBlcnJvciBwcm9j ZXNzaW5nIHNob3VsZCBmYWxsYmFjayB0byBhIGEgRkFJTCBTUEYgcmVzdWx0LjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48YnI+Q2xvc2UsIGJ1dCBub3QgcXVpdGUuPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD5UaGUgKGdlbmVyYWxseSByZWFzb25hYmxlKSBhc3N1bXB0aW9uIGZv ciBhIFBFUk1FUlJPUiBpcyBhbiBlcnJvciBpbiB0aGUgc3ludGF4IG9mIGFuIFNQRiByZWNvcmQu IEhvd2V2ZXIsIEkgKmtub3cqIHRoYXQgbXkgU1BGIHJlY29yZCBpcyBzeW50YWN0aWNhbGx5IGNv cnJlY3QsIGhvd2V2ZXIgSSBzdGlsbCBnZXQgbWFpbCByZWplY3RlZCBiZWNhdXNlIG9mIFBFUk1F UlJPUi4gQW5kIEkgZG9uJ3QgbWVhbiBmcm9tIHNtYWxsIHNpdGVzLiBJJ3ZlIGhhZCBwcm9ibGVt cyB3aXRoIGxhcmdlIElTUHMsIGEgZ292ZXJubWVudCBkZXBhcnRtZW50IGFuZCBBdXN0cmFsaWEg UG9zdCByZWplY3QgZW1haWwgd2l0aCBhIDQ1eCBvbiB0aGUgYmFzaXMgb2YgYSBQRVJNRVJST1Iu PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7VGhhdCBtYXkgaGF2ZSByZWFzb25pbmcgbG9naWMgdG8gY29uc2lkZXIuIEhvd2V2ZXIsIG5v dCBzdXJlIHdoYXQgU1RSSUNULCBNT0RFUkFURSwgUkVMQVhFRCBtZWFucyBvciB3aGVyZSB5b3Ug YXJlIGdvaW5nIHdpdGggdGhpcyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0O2J1dCB0aGVyZSBpcyBvbmx5IG9uZSBmb3JtIG9mIFNQRiBjaGVja2luZyAtIHRoZSBjb3Jy ZWN0IG9uZS4gRXZlcnlvbmUgTVVTVCBmb2xsb3cgdGhlIHNhbWUgcHJvdG9jb2wgYW5kIGV4cGVj dGF0aW9ucyBmb3IgcHJvcGVyIHByb2Nlc3NpbmcuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPkkgYWdyZWUuIEhvd2V2ZXIgcGVyaGFwcyB0aGUgc3BlY2lm aWNhdGlvbiBjYW4gZ28gYmV5b25kIHRoZSBpbW1lZGlhdGUgY2F0ZWdvcmllcyB0byByZWNvbW1l bmRpbmcgaG93IHRvIGRlYWwgd2l0aCBlYWNoIG9mIHRoZSByZXN1bHRzIHVuZGVyIGRpZmZlcmVu dCBjb25kaXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7wqDCoCBTVFJJQ1TCoMKgIC0gY29tcGxldGUgMTAwJSBjb3JyZWN0IGFuZCBzdXBw b3J0IG9mIGFsbCBTUEYgZmVhdHVyZXMuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDvCoMKgIE1PREVSQVRFIC0gcGFydGlhbCAmbHQ7IDEwMCUgY29ycmVjdCBhbmQgc3Vw cG9ydCBvZiBTUEYgZmVhdHVyZXMuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDvCoMKgIFJFTEFYRUTCoCAtIExlc3MgdGhhbiBNT0RFUkFURSBzdXBwb3J0IG9mIFNQRiBm ZWF0dXJlcy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZndDsgPC9zcGFuPkkgZG9uJ3QgdGhpbmsgd2Ugd2FudCB0byBnbyB0aGVyZSAtIDEwMCUg c3VwcG9ydCBpZiBleHBlY3RlZCBvdGhlcnMgdGhlIFNQRiByZWNlaXZlciBpcyBub3QgY29tcGxh aW50IGFuZCBpdCB3b3JzdCwgaXQgd2lsbCB3YXRlciBkb3duLCB3ZWFrZW4gU1BGIHB1Ymxpc2hp bmcgb2Ygc3RhdGVtZW50cyBkZXBlbmRlbnQgb24gc3ViamVjdGl2ZSBkZXNpZ24gPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPkkgdGhpbmsgd2UgYWxyZWFkeSBBUkUgdGhlcmUuIE5vdCBldmVyeW9u ZSBpbXBsZW1lbnRzIHB5U1BGLiBNb3N0IGltcGxlbWVudG9ycyBleHBvc3VyZSB0byBTUEYgaXMg dmlhIGEgR1VJIHRoYXQgaGFzIHN0dWZmIGxpa2UgdGhpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxpbWcgd2lkdGg9MzU3IGhlaWdodD0zMjYgaWQ9IlBpY3R1cmVfeDAwMjBfMSIg c3JjPSJjaWQ6aW1hZ2UwMDEucG5nQDAxQ0Q2RjJDLkQyQjMxQkQwIj48L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+DQo8RElWPjxGT05UIHNpemU9MiBm YWNlPUFyaWFsPg0KPEhSPg0KPEZPTlQgDQpjb2xvcj0jODA4MDgwPjxTVFJPTkc+PEJSPkF0dGVu dGlvbjo8L1NUUk9ORz48QlI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKiogDQpEaXNjbGFpbWVyOiBUaGlzIGVtYWlsIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsLiBUaGUgDQppbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBlbWFpbCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGJlIA0KY29uZmlkZW50aWFs IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkg dXNlLCANCmludGVyZmVyZW5jZSB3aXRoLCBkaXNjbG9zdXJlIG9yIGNvcHlpbmcgb2YgdGhpcyBt YXRlcmlhbCBpcyB1bmF1dGhvcmlzZWQgYW5kIA0KcHJvaGliaXRlZC4gVGhpcyBlbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGFyZSBhbHNvIHN1YmplY3QgdG8gY29weXJpZ2h0LiBObyANCnBhcnQg b2YgdGhlbSBtYXkgYmUgcmVwcm9kdWNlZCwgYWRhcHRlZCBvciB0cmFuc21pdHRlZCB3aXRob3V0 IHRoZSB3cml0dGVuIA0KcGVybWlzc2lvbiBvZiB0aGUgY29weXJpZ2h0IG93bmVyLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIA0KcGxlYXNlIGltbWVkaWF0ZWx5IGFk dmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGZy b20gDQp5b3VyIHN5c3RlbS4gQWx0aG91Z2ggdGhpcyBlbWFpbCBoYXMgYmVlbiBjaGVja2VkIGZv ciB2aXJ1c2VzIGFuZCBvdGhlciBkZWZlY3RzLCANCm5vIHJlc3BvbnNpYmlsaXR5IGNhbiBiZSBh Y2NlcHRlZCBmb3IgYW55IGxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSBpdHMgDQpyZWNlaXB0 IG9yIHVzZS4gUmFjaW5nIFZpY3RvcmlhIExpbWl0ZWQgcmVzcGVjdHMgeW91ciBwcml2YWN5LiBP dXIgcHJpdmFjeSANCnBvbGljeSBjYW4gYmUgYWNjZXNzZWQgZnJvbSBvdXIgd2ViIHNpdGU6ICJo dHRwOi8vd3d3LnJhY2luZ3ZpY3RvcmlhLm5ldC5hdSIgDQoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8UD48Rk9OVCBm YWNlPUFyaWFsPjxGT05UIHNpemU9Mj48Rk9OVCBjb2xvcj0jODA4MDgwPjxTVFJPTkc+VGhhbmsg DQpZb3UuPC9TVFJPTkc+PEJSPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvUD48Rk9OVCBzaXplPTIg ZmFjZT1BcmlhbD48QlI+DQo8SFI+DQo8L0ZPTlQ+DQo8UD48L1A+DQo8L2JvZHk+PC9odG1sPg== ------_=_NextPart_002_01CD6ED9.041EE44C-- ------_=_NextPart_001_01CD6ED9.041EE44C Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.png Content-Location: image001.png iVBORw0KGgoAAAANSUhEUgAAAWUAAAFGCAIAAAA93xl0AAAAA3NCSVQFBQUYJt5DAAAAAXNSR0IA rs4c6QAAIKhJREFUeF7tnSHXHTeShuM9SwIDAzfMZjEc6I/NssxPGGoYFmy2MHR+woTtsDEc6DCb ZeHAQA/7VnaNy+WSWi2ppW519+Nzj8/9+kql0lPq95bU3bpP3r598xX/IAABCKwRePnyxydBL54+ /X6tJJ9DAAK3JvDq1avXr1//Wy/evfv11jDoPAQgkCXwyy9/+0Ivnv/3XyAGAQhAICbw5n//LHrx H9CBAAQgUEjg83yE/KIQGcUgcF4C73/7udz5h4eHf/zf01Ce/KIcGiUhcCkCYbGy5BUWOONub5qP BK2qkqvt1PdvcbvPWIDAZQh4vZATUl+9+tndrAqHUxAEpVfIsHN5As+ePQ8v2834iIOQzi++/u5l eIWiXdIHMSI21fLGYCzZ6WV/o3tUh8D8BOReTZUMeZO/gbN0PmK/t5Pf4Q1ZSVxlKQ2J852ltCL2 c+lIFymcf0zgIQQyBFQySsQi2CnVizx0m0EUZiWZKi67cSWTnsRpRbl9xhME7kxAE4qSR0PSeqHf yTIrKfzH2kEhKIpBYB4Cbj6Sd2xx/aKhP31XKBocoAoEIFBFQKchbi1jycjifKTjemdVBygMAQjs Q8CtWZRIRm79wkqGvk8uE9pP41lJ8lNnMDPxKW/aUi63v09saAUCsxEIAuHWLOIjzmfuB58tiPgD gYEEwtd54cPo8oCZux8cvRgYG0xDYDYCQS+SN3on/UQvZgsf/kBgVwJ/+K93Ve2RX1ThojAEIMDz qYwBCECgngD78dUzowYE7kfA78d3+V1//7UU48UPSgdFo4EvqzUayfr4foBRb/J9KaW4XLV3axXW Pi9ydQ9owZFWX+vq1UfnXynPvv/2HfvxFY0eCkEAAkqgz/NmAIUABO5AAL24Q5TpIwT6EEAv+nDE CgTuQAC9uEOU6SME+hBAL/pwxAoE7kAAvbhDlOkjBPoQQC/6cMQKBO5AAL24Q5TpIwT6EBiiF08+ /uvj4BgrXz95El4Ntr/++om8GuqOq/LtN0/Ca5x9LENACLTohZWDpfdn4ftBOIpPfin5/v1jeNkO fvP1E/sKH8VHlg4eBeq7b5+El7bu/qzy6tl3T8KrqgqFT0qgRS9O2tVBbouI/P7+UV/akBwRpXAH 5fg8/37752N4tfnz9rfH8GqrS61zERioF5J62ImJHtGDWsAdSc5oCgu7VqyppWlIcoqhUw+XgJTn I1VDQeYUdmaRf5+cg7gqmkFI+hAnEXrEfhQXtkeemaxEOmjzC3lPxlEV+hMVbtGLx8cPXyZuhUL+ lI/kX3hvS2qBuLoVi7iio5kvbFuxzuRDEk8x3NTDaoSbjIhlnYCsxj5Z8puPqw///P0xvMKb/GKE FCspqc5I+iAZhJ2GxGmFfJovHEuGCkd4I+kGGcfqSDhjgRa90H66U7ek/8nEQZVFLOSXS0sK77ng Gq9lKAeRhvCnnX3E0xYt71IGVQSRD/lT1KR2gTOZXJTEq6EMyUUDtLNU2aQXoZPu7F3ttpTP1yop ow25wjan2O0azZIEZKQhCUoTB5WGuJhqR6aMq+VShtUYNRewOQUroM0YZ67YqBfJVL88/x9KpFbC hjqz0biKQrk6bGxxY3VmIhsBTl69US8aeqXLFvE6qE0WdD6yOqdIGrTGpYAWS95w8f5jmXi9U2YZ ejy5ZiFuhzJ2SaLtwsfvn5YtVucabpLiApH8VJct3MpFqBuvgLrCVRdN7Eon6xcN58j8VT7v38l+ fM3RqtsiTZthP75a4mug1z4vao/9+GJM7MdXNHQoBAEIWAL7zUfgDgEInJ0AenH2COI/BPYjgF7s x5qWIHB2AujF2SOI/xDYjwB6sR9rWoLA2QmgF2ePIP5DYD8C6MV+rGkJAmcngF6cPYL4D4H9CKAX +7GmJQicnQB6cfYI4j8E9iNwsF70euS8l52h4O2ufM0Nzb+v7yRPsv/h2YdNQ+R//ef+bI7CbSuO 1Yt4A7420Ek5GKERso9W+Y57qyVrNSIpB1s0wm2ul99rzz7A2hapqlrPzS7B9n2VkbgworARYKb6 QL0I53PVzjfjOlluOfPcetJIbflyT7qUDOe/7sSnT6brEVWHuEyX1quMvOm3Y/A/3rL5cBX7isID 9SLpxdLmF/FxdyS/A3Boa9WC9Uc2/pUdMWxOofmC3RHD/eZIsnxm/07dlS+0FRcLO3fKS90r2cjX lVndNaNiRHxZ1G3kZxMQ3cUzucGvnZXo+7hkSCsks9D8Qo7Ef8YJyPNPcw19k5yDuL6HMvKykxR3 pBnX5SsO1IuQXMTnvGYcdjZhMxE5bo9IDJK7ZtmDznJsU2MZZCJskyMvORgkwGUKugOwfCQvqyau vG69F09A9FcFQkNxsbBTjrx00qF7+drBZw/qtn1SJfzvjmjFkDiU7NyZ2T08TkbiU0I3+F1duYhL hrTCZhZBFORIeKlAfD7y5WJE28kZsg95qbi4I21mb1JroF7oSS7CIUDL84vtAchs5OWM56cV8W+a xeXL9wd3Tcf5RUPHM/lFfMKrOsQzlHg3LSc3oYCkFeH/t59+r6T8BwTKS5ZDCMnFm7ePmmKUV9SS ccbRYOQmVcbqRQxxaUVjxEpHL5uaXyzJShCL2q19hUwQC80vtgy4ko2CbdJR/utEq0sbQQIKf0Cg vOQWFA11Nb9g4WOV3t56oQ4tXd0YcdWjl83VqyGruEcX2HIlJe+brlyEtMImF6N7lLEvaUX4P5SR 9xtPeC6srEZzoF7Yi6m69a4etJuJ25WOuGTogxaw/Uke1AKxTf0oLFvY9c6YkSxV6E8W6XxkKb8I ycXSfEQ/SkYiJBduPhIyhXi9M3lQDeqnspBhG7ILE1U794oRu/yxVD0kF8lZRnw8PiKLFHYhU4/I Qsbq8G0ooLMPERdZyJDXRrlpcOZ0Vdjv96uvNu8S22iA/X5rT5c10GufF7XHfr8xJvb7LRo6FIIA BCyBgfMRQEMAAhcjgF5cLKB0BwIDCVxWL9z9YAMRLpuufXjkECdpFALlBE6mF72ujCYBFV4uLSxW HgNKQuAsBE6mF0OxTv7w2NC+YxwCJQTG6sXqM2DJh8rim8fd5CJzd3myRbmn499Pl326M93dgpF5 wOxD3Y+3Yyw9jWafKAuFV58903mK3nxhnzcrCRtlIHAIgbF6kXkGLPTWPVSWfEIsfj5NnzEreUrN MZUnzUQ79JEzvS9LCscPmNkjUsY9jSY3g4sKZO4Ntx+pZMTPmx0yDmgUAiUExupF+RNf4uvo8vpA qkiGPtLuZeXLbCLPMaiJyy9KuFMGAmckMFAv4mfSVwHVPiFWW946oPlFvGyx+oDZF3Y+Jhf2ofXV blIAAiclMFAvthCpvQ5SW976lrneUXUppNfV03HPjG2JCHUhEAgM1It4vxx3JPOnPo3mnk+zz5it PqUmExz7YJuG3D5yFu+U4x4w08fP3BNospCh85GQYoQjJc+eyUIG4w8CpyMwUC8Ci3i+oEeEVP7P uIAeSVZPtmg1IjkfiWOm85HPdT9tsSVHdL1T3rvJiE5PYlFwM5ew2KlN6KOl7hnT0w0pHL4wgbF6 cSJw8ZZ8J3IeVyGwD4Gp9SI5lajiUm6Bm7WqwFL4ngSm1ot7hoReQ2BaAujFtKHBMQhMRwC9mC4k OASBaQmgF9OGBscgMB0B9GK6kOAQBKYlgF5MGxocg8B0BNCL6UKCQxCYlgB6MW1ocAwC0xFAL6YL CQ5BYFoC6MW0ocExCExHAL2YLiQ4BIFpCXz+PcRffvnbtF7iGAQgcCCBH374Y9CH169f3+j3Uw/E TdMQODWBd+9+9Xpx6v7gPAQgMJSA6AXrF0MhYxwClyKAXlwqnHQGAkMJoBdD8WIcApcigF5cKpx0 BgJDCaAXQ/FiHAKXIoBeXCqcdAYCQwmgF0PxYhwClyKAXlwqnHQGAkMJoBdD8WIcApcigF5cKpx0 BgJDCaAXQ/FiHAKXIoBeXCqcdAYCQwnMohfPnj3v28/uBvu6V2itby/6WivsAsWuRKCbXoSxqK/R gMrbqj1DrOXauqN7be2P9tP2fWYOezKnrUCgj16EIfX27Rt97UBW28qP5lCs1pmdO1Lrnpbfzc8G hs2douLkBD7vl7PqaHIDrrDxTqgoeuEs6JksH9kTWwvHB+NaobCzb//U9/mK9tNkdXE+7ogcybQi FaWMvFFT+pG1bE05MvqnthgXzvvpPl2FWdivJT+teOl7NmpbPZVmK/DTTz+FHXHyXlXvlxMqBLvO qDaTHJp2+MZnaeERexLGZ4s7n/XMtMdL5Mad5EsqoN2PdSQ+25PddxKQhKBdjnsX+2nbLVG9jFw6 erXhk/JPn34/2/mAPxkCr169GqgXqzqkQ9y66HKEzEmeqWXPVffNtiQ9mfMtTlv0bLE+xFpjm04m C5prxCVjFVsVzVguk34unepLPjhlUbmX5la9SpbhtDwjAckDVs/r4ftrtU2wC2vtuVbicgppenVk FHakxI49mVfLN3gr6lDYr3IHKHk9An3WO/Ncmof7ONzJ5GJQc7quoV/ata3HCUvS1Vqzg/qL2QsT 6KMX4UzQl3z3ytiV19K3sS0jiEtqZU6VpebihtoiWm6nvCOFJWPJsMxXmdgCeewuEG46kw9oG1Vq nYhA3fWRknnOKTqfUbFT+I+TEOhFYJb1i179wQ4EIDAJgT7zkUk6U+5GyYJluTVKQuAmBG6qFzeJ Lt2EQF8C6EVfnliDwJUJoBdXji59g0BfAuhFX55Yg8CVCaAXV44ufYNAXwKj9KLtns6NfTuk0YzP cnfTUoFabzPWxFStwY20L1A9H6AtHbxqLProxeq9hlvQd6+7Tyz1oQzrf3PTSWsbyTQ7k2/Xmt3e xHYLGb3WR2bGtbIxRrNV76MXoVf6wBLoZ4vxkj873ISyQxNdaJ/Fzy6d3WKkm15kVNxlfZqMaBV3 JC5QW7KwCefzkhvuC3MpiV1qNNmKHFz10+Um6kkGUWzW1tJ2df6SzA0zCWM5JTtFKq8Vf99Y4M1j I9PNpJ/iRpwruePl/pTHZcv5PLrufw5tQLJoHaP6KJo9YssI07iKsxD/uVRLjrsmJBuKT+MqV0vc Tn5r2YOuxUzfrc/5YvlPk+HOu+E0a5VSjLdhGNhGk+Mhw39pFGU8T46opVNDm66KV0Nchp6bbca7 5RcqtO4kKfkKdV8pec2Ov3KXvpHi422MSlrcblmHrP067WVWT6ERTHo5ObNvSf2KU4YGFPqV1lB3 /yrd9ELXL1wf9LjoiNDRdSb5LtInrKWuq6IGa0vaVnqRXfLtLPZ7+dndThzc7k2MMDh6PIzweYvN bnqx6kT+2yOZuierlJcUeVp1rK3AOMuaaLQ5FteyM7Lk7KxXQ9vtnHfdsWE8nCguGtmx6xdCRLMG yR3i2cdSgXhqU1Iy36h+j4kzNnlxri6deNaHquq2+8kTI/Y8eQbmixUayZzbcYzy3VwKsfaxxKUl +FrXBs7Fzo2rfMmqjmdQxI3m5bIEwnbBHW3hpvvljMZ6GfvxUrHr2mqBk6K4ar/icLBfzkmH6ERu L61eT+TiGFdu2/FCnPutXxQ6RLEZCOgy3qoz511xWJrrjVgmX8V4lgLoxVkihZ8QOJ7AMXrRsJi8 hKrEVEmZ40Ox2YPu3exucHMXWwwM6sUgsy093LFOH71wtxhl7jiylMtr9QWyFOlxI6DQsk6eC8tv wVLeVq0z1nJt3S09OqTu5TvoqPbRi/JQzTDdncGHmJgsyJcvHJQzXyqpbeUHfQOunTuyHQUWCgl0 0wu9vOwuROm3jTjkhmZVLa0b20ymKvk8IvkFa+0kPRebcV09rt3MZE/OciZUSz2N07TMEedbeXMu ZNYZ11x+tOXhOLOrHbGjKDMk4sHmxkNhyGJ6sZ0lNwpPwhMVG3u/VgCh305OR/KM4lpaPbYTFy5s tLBisulCD7Xuqkvx/Ty2p0t2XBk5STK+5cUi42RV+OwZJTZt9SXsjnOyI0n/S7qc9D8ZWTlY3t/V yJ5IDlZd7ZZfiDTElO23R9Kbwlo2K3YCn8ztpd3V/ld92eYzc+dhxoElx+IJwiq9pfPHtZ70XI23 zTj0izeuHs9HyuHYHiW7r+dz4VeOUytbK+9Vw/hpqLJliO5ft6deJM/bhgm5DAh5xTbleP5sbGh0 qaElN1YH65IPq/67Ad3Ql/h0XVLqtt5tGab54DrLhR1Z9UcGTFXIqsIklhuqrHo+W4HOetHwTSWg a7k0VKltQsuvDrV8krJ0rlb50+ZDW61Cx5KJYWHd2mLSEdtibeslkiFexZOpKm9dzlJVd/7CnfUi /n5oyKg1fUgO99UsOl89ExKbtlgjSW3KuBHXtZaXKupxndOt+qCnkM22SmotSVhhp7YM6/LolHek sGRGMmILDsWS2yWR3YJrtro8b9YSET2lWypfpQ4QrhFJnje7RhzpBQSmIzB2PjJddzs5tOfqSSeX +5sBQn+m01tEL6YPEQ5CYBoC6MU0ocARCExPAL2YPkQ4CIFpCKAX04QCRyAwPQH0YvoQ4SAEpiGA XkwTChyBwPQE0IvpQ4SDEJiGAHoxTShwBALTE0Avpg8RDkJgGgLoxTShwBEITE9giF6EJ1j0NT0B HIQABEoJdNYLkYnX5p8cKXWHchCAwMQEeuqFKsXfzT+RjqdPv58YAq5BAAJFBHrqhTQYtMK2HP78 +ef/WfLFbhITyiztB7W0cU5RFykEAQh0ItBNLyS5cGIhTobk4t27X+MUw27lmH84mkenO4UbMxDY RKCbXmzywlTWreV0+2mbd7jd/TK7/vbyBzsQgIASOFIvknsiyibL4p/b8S3eWtoWJqgQgMBoAkfq ReibnPBLG7EyDRkdfuxDoIpAN7344Yc/vnjx4uHhIW5eFi/C/1WeURgCEJiNQDe9kI6FSyFOF5CJ 2UKOPxBoJtBTL0KKEfIISSX0pUdiFzO/uJHsj1vvsD/90Nx/KkIAAuUEhvz+iL10Sn5RHgxKQmB/ Asf//ojNLzL9t/kFV0b3Hyi0CIFaAj3nI7Vt68URfVNrgfIQgMCeBI7Uiz37SVsQgMB2AujFdoZY gMBdCKAXd4k0/YTAdgLoxXaGWIDAXQigF3eJNP2EwHYC6MV2hliAwF0IoBd3iTT9hMB2AujFdoZY gMBdCAzRC/YHv8vwoZ83I9BZL9gf/Gbjh+7ei0BPvdhnf/ClPYHvFTd6C4EjCPTUC/G/fH9w94zZ 0EfOUJkjRhdtXo1AN71o2B/8aizpDwSuTqCbXrSB0p074619k9mHTRPivcKDD1rAfSofZT5t859a ELgVgYP1Isna7gOuvyrgnnmPy4gi6BbB8U7Cupl4su6tok5nIdBG4Hi9kBSjYSvwOIOwRuJPLaD8 p20oqQWByxPophf77w9ut9txcYp/qcQVyNS9fMjpIASaCXTTC/GgbX/whuTCJQvN/ee6STM6Kt6Q QE+9qN0ffAm33QdcpCT+JbS4jLWWKe+sbZSqG44YunxnAuwPfufo03cIfHXi/cGH3rLF0IAABDYS 6DkfqXUl3h+c30+uZUh5COxJ4Ei92LOftAUBCGwngF5sZ4gFCNyFAHpxl0jTTwhsJ4BebGeIBQjc hQB6cZdI008IbCeAXmxniAUI3IUAenGXSNNPCGwngF5sZ4gFCNyFwBC9YH/wuwwf+nkzAp31gv3B bzZ+6O69CPTUi0H7g/d65LyXnXsNEHoLAUOgp16I2dr9wXnGjAEJgbMQ6KYXbfuDx7tsngUcfkLg hgS66UVHdkubayY3BJd2V7cFZzLSMUCYui2B6fQis3m3S0bi3yIo2Vj8tpGm4xDYTuBgvdCUoWRr 7+SG4Ks/XLKdERYgAAEh0E0v2vYHT26Qk9y8e3XLb+kPG38zsiEwjkA3vRAXm/cHT64vrC46iIi0 1R3HFMsQuCqBnnqxZX9wPe2XNv6Ot/zWmUimblzrqoGkXxDYgQD7g+8AmSYgMC+Bc+8PPi9XPIPA 7Qn0nI/UwkzuD15rhPIQgMBuBI7Ui906SUMQgEAXAuhFF4wYgcAtCKAXtwgznYRAFwLoRReMGIHA LQigF7cIM52EQBcC6EUXjBiBwC0IoBe3CDOdhEAXAofpxZ/+9OfQgaP+78IOIxC4G4Eh94OHO0yV Y3ioZDamQaT++te/zOYV/kDgEAJH3g9evj+4ZBaH/EMsDsFOoxcg0HM+UrU/+A4n7dLj8AdK1QVG DF24M4GeeiEcC/cHDyft6vYWgwKzg1QN8hyzEDiWQDe9cPuDP/n4T/r29On37979Gv63XT3wpCW/ OHbM0fp5CXTTC4tAlULfxICSJ228Q6ceiZOReLvw5MbitqK8P1CqzjtQ8BwCgcAQvSghG5+0Vbt7 J7cRL/w1E/KLkgBRBgIxgSF68fj4KC3pm8L8YkSE4p8dIL8YwRmbdyDQTS/c/uBBKVQsZPEi/M/6 xR2GFH28MIFueiGMyvcH33NSICmG/sQJ+cWFBzRdG0qgp15U7Q8uJ61doYx3Bs/s7r20jXgJrD2l qsQfykDgLASG3A9uL526aYhyqb0p2/2OWRXfLXWrGqIwBE5H4Mj7wQVW0Ah9LeEL+YW9Vrp071by BxM3hoT8YiNAqt+WQM/5SBXEcNK6/cGT1bVMlXFX2P44a/iI9YstMKl7ZwKH6UU4aY96mJ384s4j nr5vITBk/WKLQ9SFAAT2JHD8+sWevaUtCEBgNwKHzUd26yENQQACvQigF71IYgcC1yeAXlw/xvQQ Ar0IsN7ZiyR29ibgdlTZu/lTtffw8BCe1Ui6XLXeiV6cKuw4awjEDzGCZ0kRXr9+3UUvmI8wxiAA gVICQ/RCdgmXV6kjlIMABKYn0Fkvyn9PYHoyOAgBCHgCPfWi6vcECAUEIHA6Aj31Qjpf+HsCSiqz o2+S5lG/QnC60OJwIMCMuO8w6KYX7vcErJfJ3xOQAnbbXvcUad9+Yu0mBOK1s8Mvu1rNWnp/luh0 04uGDie3sYm3/xdZkZeqjHuf/NNWaXCPKqcjEM7GsMnbT5/+Ha4UCtB6ou9lP7pzQT5SLwpJ2RxE qsimGC49UcmQT7UW85dCzmcvJmIhyazdrunVq1fuUp27eJe8nBcfzFzyWzKoSMUH+VPfhyPBz+2t 7xm4E+iF6MKeUGjrpASSd3BpuqFnrOYgesSVsXlKQBHM2iNuTcR+tFRS7Es2Yd/bI+G4WM63fmxK 0k0v3O8J2AGX/D2B8hGp+QKqUQ6Nkm4Eyj6ycrKFEzJ8yYd/eiS8kZREj2ieonaSteRTyRTUQt6+ bUuNl7S+usflDkHvphfia/nvCYTC+ktCJf1kNbSEEmVWCbhv79XyWkBzkPDG1pJsxU55lkqWt+VK xk00m9pYsadeVP2egPhtfxZA0of4NwTclr9awBVGUDYOhbNXD8NPUobVf3HusFpFCsg3fGjF7Xof /gythwI6WVgqWdhQXMw1cdQ1l556oUADNX1porVEyu76qyJit/mNt/zV9U6RDPenGnFvmkNFxbMQ CCdtcvnQ+i+y4lZAXQfjMvaIu66hLYpkxCX1iP00gzRu3TUhdZPXXNzx7oGb7vnUeJGCxKF71K9h cOn5VPfzN7aYvi8vE8QlzC/s0oZ8L1qGNq1wJ7OWlDLWjq7rZTzU1pNNWOPJ9+JMkJtez6dOpxfX GMr0YgcCTi/cZQtxQL7zG/7Ziyn7Pzjft3X0omEAUOVqBOLTOHmtcekX9lZxxF/pq1U6FujYeke9 6Lx+0ZEXpiBQS8DeqbX96uN2C7X+2/LHtr7kOXqxJabUhcC9CKAX94o3vYXAFgKsd26hR90jCYQZ fuENF0d6OUfbXB+ZIw54cRyBly9/PK7x87XcZb9f8ovzBR6PIdCRQLh6ojeYZMzKRRbWLzqSxxQE Lk4Avbh4gOkeBDoSQC86wsQUBC5OAL24eIDpHgQ6EkAvOsLEFAQuTgC9uHiA6R4EOhJALzrCxBQE Lk4Avbh4gOkeBDoSQC86wsQUBC5OoO7+zovDoHsQuCWB8vs7K/Ti2B8+uGUc6TQEdiKwuquQ3A9e oRc7OU4zEIDAfAR4fmS+mOARBOYmwHrn3PHBOwjMRAC9mCka+AKBuQmgF3PHB+8gMBMB9GKmaOAL BOYmgF7MHR+8g8BMBNCLmaKBLxCYmwB6MXd88A4CMxFAL2aKBr5AYG4C6MXc8cE7CMxEAL2YKRr4 AoG5CfD8SGN8nj173ljzJNXevn0Te3rtZw4fHh6WftTnth3XMcDzZptO3KAXj4+Pm0zMWjmcNuFJ xCW9WH2QcdZurfgl50NGL+7ZcfSiz3gWvbjeGJLTBr1woyTkF9eLtfQxL5ROL1i/6CMfWIHAHQig F3eIMn2EQB8C6EUfjliBwB0IoBd3iPL1+3jVy1Wz9Qu9mPRcCgNFXurf0vtJO7DslnZttpNhT5Ku 72dBgV7sOUhK2wqjJ1zOlFc8kuTTUluTlbNdO28vJoO6nzvoxX6sC1tycuAk4wJiEXNwyVQyAVkq U0j1LMXivDJ4Pk9Ghl6cZSB98PPUYpEBHSdT7ojNSpTDUv51lojGKpDJKzP55p79RS/2pE1baQLJ L9U8rIYqs9FXCbDzssn7hV7MNopy/iSXM87UgZSvLnco7E7yZCusO3OxyfuFXkw3ePILFqeWjBHO n+XKQu04m7Nf6EVtHPcoL+eVvOKLCCPOuj169bEN2zU5JeyRJTdcmTyf3frSvaFMvzLjobsbGYPo xZ60K9rSvFTrWOE49ZXIOOV2R5I9dUDiPyvgTlDURVD/XOpXPB4O6QR6cQh2Gr07AXtxZPI1Thsq 9OLuA5f+H0LAplSrucM86SR6cchooVEInJIAenHKsOE0BA4hwP6djdjDnDPsr/Xq1avG+hNXY3+t ODjsr8X+nZtO2aAXL1682GRi4sqZ/fguKZESivz+nffsuA5S9GLT+Trn7TSbuvRl5eQa28uXP3Zs YkJTS/v93rbj6MWEoxSXIDA7AckvWO+cPU74B4F5CKAX88QCTyAwOwH0YvYI4R8E5iGAXswTCzyB wOwE0IvZI4R/EJiHAHoxTyzwBAKzE0AvZo8Q/kFgHgLoxTyxwBMIzE4AvZg9QvgHgXkIoBfzxAJP IDA7AfRi9gjhHwTmIfDhefZwZ/g8DuEJBCAwJ4Hw/MiTCz+UPSd0vILAeQn8P08UZexpkjoTAAAA AElFTkSuQmCC ------_=_NextPart_001_01CD6ED9.041EE44C-- From spf2@kitterman.com Mon Jul 30 22:19:30 2012 Return-Path: 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 22C1E21F8644 for ; Mon, 30 Jul 2012 22:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] 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 BDKUxZFNvZrk for ; Mon, 30 Jul 2012 22:19:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 015B811E80D5 for ; Mon, 30 Jul 2012 22:19:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C564A20E4095; Tue, 31 Jul 2012 01:19:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343711967; bh=CShbqfjSUh7B/OpZebGH9A3hdEq74ktgumu9h6tFd08=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UL2FdaEHtdrEXk07hx3N90CZmMDLgShsPgLFl6mCyTJH9PveDnSDcuZS6Pr8gl7Xt 3b5PjwsnNRpHmDvOT/Xcobo93XDANzkfAM3FvLqImjB0pH0I4jMKrjUCjOEoLAeVua NO1jfpm2ZeRUcL6Js0gRn9Zgfg7dS4IlCqcqRUoo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A6F7E20E408E; Tue, 31 Jul 2012 01:19:27 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 31 Jul 2012 01:19:26 -0400 Message-ID: <1373558.UHCXZLjJRI@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027AA6@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <50163FFE.3090109@isdg.net> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027AA6@XCHANGE.rvl.internal> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 05:19:30 -0000 On Tuesday, July 31, 2012 02:57:36 PM Wayne Doust wrote: > > If the DOMAIN publishes exclusive policies for hard failures, then an > > error processing should fallback to a a FAIL SPF result. > > > Close, but not quite. > > > > The (generally reasonable) assumption for a PERMERROR is an error in the > syntax of an SPF record. However, I *know* that my SPF record is > syntactically correct, however I still get mail rejected because of > PERMERROR. And I don't mean from small sites. I've had problems with large > ISPs, a government department and Australia Post reject email with a 45x on > the basis of a PERMERROR. Assuming racingvictoria.net.au is the correct domain, you're correct. Erroneous permerror can come from implementation errors in the receiver system. It would be interesting to know the domain/IP address that's gotten such an error recently. > >That may have reasoning logic to consider. However, not sure what STRICT, > >MODERATE, RELAXED means or where you are going with this > > > >but there is only one form of SPF checking - the correct one. Everyone MUST > >follow the same protocol and expectations for proper processing. > > I agree. However perhaps the specification can go beyond the immediate > categories to recommending how to deal with each of the results under > different conditions. > > > > > > > STRICT - complete 100% correct and support of all SPF features. > > > > > MODERATE - partial < 100% correct and support of SPF features. > > > > > RELAXED - Less than MODERATE support of SPF features. > > > > > > > > > > I don't think we want to go there - 100% support if expected others the > > SPF receiver is not complaint and it worst, it will water down, weaken > > SPF publishing of statements dependent on subjective design > > > > I think we already ARE there. Not everyone implements pySPF. Most > implementors exposure to SPF is via a GUI that has stuff like this: Nothing in the picture has anything to do with the SPF protocol. How receivers handle SPF results is entirely up to them. BTW, such a GUI with no explanation about what the options mean or the potential impacts is a complete disaster waiting to happen. It's a good sign you're using the wrong software. pySPF is nothing more than a library that implements RFC 4408, there are several. Scott K From raz@raz.cx Mon Jul 30 22:28:50 2012 Return-Path: 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 06C4C21F8549 for ; Mon, 30 Jul 2012 22:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6] 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 RGSL60E9-u2Z for ; Mon, 30 Jul 2012 22:28:49 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 16A7F21F8532 for ; Mon, 30 Jul 2012 22:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=raz.cx; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=0bdR8snuiyh+zKFCFC0hLTqlU2Csr1aTn+G+F1022r8=; b=G/aNz1fLqFFl/TYn1FFP0GPKTGZfS2Gm5RCfb70U+NB3TPo87cYHmnJgdXVSfLSz9HJXnRP23sdLYDfLET3/dT5ectsdrmDNYIWf1ArTEFg9VlFBqEK95YIeqMMLd0xfAl2Z2qrBVTameAchS4aRpJjZNbemLc0/gLZhP1ML6g4=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=180.129.119.15 Received: from [180.129.119.15] (port=57486 helo=[192.168.1.108]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Sw50f-0006je-Nw for spfbis@ietf.org; Tue, 31 Jul 2012 05:28:47 +0000 Message-ID: <50176D0B.5040202@raz.cx> Date: Tue, 31 Jul 2012 13:28:43 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "spfbis@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 05:28:50 -0000 Franck, I've read the thread, and don't understand what you're getting at. 4408 2.2 is clear, when MAIL FROM is empty (DSN/MDN/bounce), the identifier that's being assessed is postmaster@$HeloIdentity. Questions of matching organisational suffixes are not addressed by SPF (and may not make much sense; if the machine generating the bounce is a gateway for a thousand domains, which is the "correct" one for you to look at?). Perhaps another way to tackle this is to ask: why do you care about the difference between "HELO a.example.com" and "HELO example.com"? What use are you trying to make of an authenticated HELO string? - Roland On 31/07/2012 06:16, Franck Martin wrote: > Thanks. > > I'm confused because I see often host.domain where domain is the one with > the SPF record. > > Based on http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ > > An added section under 9.1 could be useful > > > 9.1.3 Bounces > As explained in 2.2, [RFC5321] allows the reverse-path to be null, which > is typical of some Delivery Status Notification [RFC3464], commonly called > email bounces. In this case the only entity available for performing an > SPF check is the HELO identity defined in 1.1. Administrators > MUST(SHOULD?) ensure that this identity is set correctly and has an > appropriate SPF record. It is common to have the HELO identity set to > hostname instead of domain. Administrators SHOULD consider publishing an > SPF for *.domain (wildcard domains) in that case. > > Feel free to rewrite, which I'm sure you will. > > On 7/30/12 1:58 PM, "Scott Kitterman" wrote: > >> Yes. >> >> Scott K >> >> On Monday, July 30, 2012 08:46:46 PM Franck Martin wrote: >>> What I mean, is who present a correct helo string associated with a SPF >>> record, so the SPF validation can work for a bounce? Is that part widely >>> implemented? >>> >>> On 7/30/12 1:25 PM, "Scott Kitterman" wrote: >>>> I'm not sure what you mean. At least all open source libraries of >>> which >>>> I'm >>>> aware implement this correctly. It's certainly not unused. >>>> >>>> Scott K >>>> >>>> On Monday, July 30, 2012 07:53:10 PM Franck Martin wrote: >>>>> Digging more in this issue, I'm keen on proposing some text, but also >>>>> looking at my anecdotal operational experience, isn't it something >>> that >>>>> should go on the deprecated list, due to lack of correct >>> implementation? >>>>> On 7/28/12 12:20 AM, "Scott Kitterman" wrote: >>>>>> I guess I was speaking imprecisely. fully qualified hostname of the >>>>>> client: >>>>>> hostname.domain is exactly what you use. >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From W.Doust@racingvictoria.net.au Mon Jul 30 23:05:23 2012 Return-Path: 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 543E621F8539 for ; Mon, 30 Jul 2012 23:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 HSIYbsjsqAq0 for ; Mon, 30 Jul 2012 23:05:22 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA8B21F8532 for ; Mon, 30 Jul 2012 23:05:21 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 9558) id ; Tue, 31 Jul 2012 16:05:17 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jul 2012 16:05:08 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027ABE@XCHANGE.rvl.internal> In-Reply-To: <1373558.UHCXZLjJRI@scott-latitude-e6320> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1u3BRvUpRUOOUuQwS17lPJvPusVwABFLWQ References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal><50163FFE.3090109@isdg.net><0D2A0D5F64179F4F9556D3DEDE39F9AF01027AA6@XCHANGE.rvl.internal> <1373558.UHCXZLjJRI@scott-latitude-e6320> From: "Wayne Doust" To: "Scott Kitterman" , Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 06:05:23 -0000 > Erroneous permerror can come from implementation errors in the receiver system. It would be interesting to know the domain/IP address=20 > that's gotten such an error recently. I can provide several. However, most of them fixed the issue with a whitelist. Next time I get a live one, I'll email you. > Nothing in the picture has anything to do with the SPF protocol. =20 If we remember that all we are doing with SPF (and other ant-spam devices) is fixing an IETF specification that started out broken (SMTP); then we must assume that it is incumbent upon us to develop a spec that assumes a worst-case scenario rather than a best-case. Implementors of email systems and mail filters will never expose mail system administrators to the nuts and bolts. That will only generate service-desk calls. They will make is as dumbed down as they can. The problem is that without guidance, vendor A's dumbing down will be different to vendor B's. Why not provide recommendations for dumbing down in the spec? That recommendation SHOULD include treating PERMERROR and TEMPERROR in same category as a NEUTRAL. It could be a "Best Practice for SPF" recommendation. > BTW, such a GUI with no explanation about what the options mean or the potential impacts is a complete disaster waiting to happen. It's a good sign you're using the wrong software. This is the GUI from MailMarshal. It is one of the "better" mail filtering tools - and possibly one of the most popular. Others are MUCH worse. Like it or not, this is the way SME's - and even larger organisations - are implementing SPF.=20 *************************************************************************= ******************************* Disclaimer: This email message and any attachments are confidential. =20 The information contained in this email message and any attachments may b= e=20 confidential information. If you are not the intended recipient, any use,= =20interference with,=20 disclosure or copying of this material is unauthorised and prohibited. This email and any attachments are also subject to copyright. =20 No part of them may be reproduced, adapted or transmitted without the wri= tten permission of the copyright owner. If you have received this email in error please immediately advise the se= nder=20 by return email and delete the message from your system.=20 Although this email has been checked for viruses and other defects, no re= sponsibility=20 can be accepted for any loss or damage arising from its receipt or use. Racing Victoria Limited respects your privacy. Our privacy policy can be = accessed=20 from our web site: "http://www.racingvictoria.net.au" *************************************************************************= ******************************* From spf2@kitterman.com Mon Jul 30 23:22:24 2012 Return-Path: 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 BE42211E80AD for ; Mon, 30 Jul 2012 23:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] 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 wZFrOHZk6OpO for ; Mon, 30 Jul 2012 23:22:24 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D950921F8610 for ; Mon, 30 Jul 2012 23:22:23 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2155320E4095; Tue, 31 Jul 2012 02:22:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343715743; bh=YkNuxyO95AGavWdgkHdCFv9ZtQDtHHDhNNTDA5HRLOo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jx9IvR9Ii/m0xfzsEzW1VHsqcnLbVdtRFKghBUIwIWtwMnxElvZs22Ltbh3rpk6xu LpiLiD+c2Rh+8IdfWbENJ2V48BybYD4nEEp67Hry/pDTFIzOgR6BuVKFpAe16M8B6J caNRr+T6Vh38G5iiO4QA9A0g1LN7vasDTtkM/02M= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 045B520E408E; Tue, 31 Jul 2012 02:22:22 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 31 Jul 2012 02:22:22 -0400 Message-ID: <3510820.QBJdz4C5b1@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027ABE@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <1373558.UHCXZLjJRI@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027ABE@XCHANGE.rvl.internal> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 06:22:25 -0000 On Tuesday, July 31, 2012 04:05:08 PM Wayne Doust wrote: ... > > Nothing in the picture has anything to do with the SPF protocol. > > If we remember that all we are doing with SPF (and other ant-spam > devices) is fixing an IETF specification that started out broken (SMTP); > then we must assume that it is incumbent upon us to develop a spec that > assumes a worst-case scenario rather than a best-case. > > Implementors of email systems and mail filters will never expose mail > system administrators to the nuts and bolts. That will only generate > service-desk calls. They will make is as dumbed down as they can. The > problem is that without guidance, vendor A's dumbing down will be > different to vendor B's. Why not provide recommendations for dumbing > down in the spec? That recommendation SHOULD include treating PERMERROR > and TEMPERROR in same category as a NEUTRAL. It could be a "Best > Practice for SPF" recommendation. I would encourage you to review the group's charter. We have a pretty tightly specified set of work we're scoped to do. IMO, independent of if this is a good idea or not, it's outside our scope. Scott K From superuser@gmail.com Tue Jul 31 00:36:51 2012 Return-Path: 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 D0DBA21F8602 for ; Tue, 31 Jul 2012 00:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.665 X-Spam-Level: X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Tvk4OtcF8stA for ; Tue, 31 Jul 2012 00:36:46 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3AC21F8604 for ; Tue, 31 Jul 2012 00:36:45 -0700 (PDT) Received: by lagv3 with SMTP id v3so4023797lag.31 for ; Tue, 31 Jul 2012 00:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BJem81cj8rGAIkWN5Db4OaovzJl42V75hmV45sjXhuM=; b=A760CTJFwC+LSVf4oS9QrC/qHtrw+2AEGSerpKcbCNAOxIf0Y/kDZ7oYvB7azoa+jV 8sq+hmJ36p5LgJs+gpm1l/lSTJTztILZP/51zf4sAYPknFAYDIYvQeDkmbuXvslcMu2Z gOkE2Z7+d4tdpYiHQlIv5p8x63TNArq3iPXpCWlwHwWnjRzYXJrFqd4AqF5ZOZptlem/ gWDYo0LG3HezZ87PqUe6C5nr5LwrSJxmc2bxALev4tvM671CqhEuVvTiK2H5qJC1UOjz seG2XcUeSZp57qj/PYr4YQYzDgt1jaK6oXO2pJFelbfhj/MGJqEb0v235uMexcEeFs6+ nR0g== MIME-Version: 1.0 Received: by 10.112.46.9 with SMTP id r9mr6307418lbm.81.1343720204244; Tue, 31 Jul 2012 00:36:44 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Tue, 31 Jul 2012 00:36:44 -0700 (PDT) In-Reply-To: <3510820.QBJdz4C5b1@scott-latitude-e6320> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <1373558.UHCXZLjJRI@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027ABE@XCHANGE.rvl.internal> <3510820.QBJdz4C5b1@scott-latitude-e6320> Date: Tue, 31 Jul 2012 00:36:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0401236f7395a504c61b3d25 Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 07:36:51 -0000 --f46d0401236f7395a504c61b3d25 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 30, 2012 at 11:22 PM, Scott Kitterman wrote: > On Tuesday, July 31, 2012 04:05:08 PM Wayne Doust wrote: > ... > > > Nothing in the picture has anything to do with the SPF protocol. > > > > If we remember that all we are doing with SPF (and other ant-spam > > devices) is fixing an IETF specification that started out broken (SMTP); > > then we must assume that it is incumbent upon us to develop a spec that > > assumes a worst-case scenario rather than a best-case. > You mean a 1980s protocol failed to foresee the environment present in 2010? How could that possibly happen? But seriously, I don't think the premise is valid here. SPF is not an attempt to fix something that's broken. It's a policy layer on top of a system that does exactly what it was designed to, and does it just fine. > > Implementors of email systems and mail filters will never expose mail > > system administrators to the nuts and bolts. That will only generate > > service-desk calls. They will make is as dumbed down as they can. The > > problem is that without guidance, vendor A's dumbing down will be > > different to vendor B's. Why not provide recommendations for dumbing > > down in the spec? That recommendation SHOULD include treating PERMERROR > > and TEMPERROR in same category as a NEUTRAL. It could be a "Best > > Practice for SPF" recommendation. > > I would encourage you to review the group's charter. We have a pretty > tightly > specified set of work we're scoped to do. IMO, independent of if this is a > good idea or not, it's outside our scope. > I think considering advice like this is probably fine, assuming we can come to consensus on such, but certainly altering the protocol or establishing new normative requirements for receivers is not what we're authorized to do here. -MSK --f46d0401236f7395a504c61b3d25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 30, 2012 at 11:22 PM, Scott Kitterman <spf2@kitterman.com= > wrote:
On Tuesday, July 31, 2012 04:05:08 PM Wayne Doust wrote:
...
> > Nothing in the picture has anything to do with = the SPF protocol.
>
> If we remember that all we are doing with SPF (and other ant-spam
> devices) is fixing an IETF specification that started out broken (SMTP= );
> then we must assume that it is incumbent upon us to develop a spec tha= t
> assumes a worst-case scenario rather than a best-case.

You mean a 1980s protocol failed to foresee the environment= present in 2010?=A0 How could that possibly happen?

But seriously, = I don't think the premise is valid here.=A0 SPF is not an attempt to fi= x something that's broken.=A0 It's a policy layer on top of a syste= m that does exactly what it was designed to, and does it just fine.
=A0
> Implemen= tors of email systems and mail filters will never expose mail
> system administrators to the nuts and bolts. That will only generate > service-desk calls. They will make is as dumbed down as they can. The<= br> > problem is that without guidance, vendor A's dumbing down will be<= br> > different to vendor B's. Why not provide recommendations for dumbi= ng
> down in the spec? That recommendation SHOULD include treating PERMERRO= R
> and TEMPERROR in same category as a NEUTRAL. It could be a "Best<= br> > Practice for SPF" recommendation.

I would encourage you to review the group's charter. =A0We have a= pretty tightly
specified set of work we're scoped to do. =A0IMO, independent of if thi= s is a
good idea or not, it's outside our scope.

I th= ink considering advice like this is probably fine, assuming we can come to = consensus on such, but certainly altering the protocol or establishing new = normative requirements for receivers is not what we're authorized to do= here.

-MSK
--f46d0401236f7395a504c61b3d25-- From prvs=552ecb598=fmartin@linkedin.com Tue Jul 31 08:13:41 2012 Return-Path: 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 9AB6121F8673 for ; Tue, 31 Jul 2012 08:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] 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 WImy8bfXJwSL for ; Tue, 31 Jul 2012 08:13:40 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id B4F0921F8671 for ; Tue, 31 Jul 2012 08:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim; t=1343747620; x=1375283620; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2oxdPK8r+hryLMNRvw8tk7Rqur8ePIGcse4QMlQzT2c=; b=oSHulU28FOk/1VUAmPtNJhSMyUEKMzOOUpoTbNdb7pSMmikPTWOyBoP4 qVy8cjRxJOPYO5vKInGPjU3DFpAfDm0Ha99rYBec7xAhhzP3W9BLV214t Lig6W4RGG+tBXku; X-IronPort-AV: E=Sophos;i="4.77,686,1336374000"; d="scan'208";a="20426250" Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.01.0355.002; Tue, 31 Jul 2012 08:13:16 -0700 From: Franck Martin To: Roland Turner Thread-Topic: [spfbis] SPF and empty mail from envelope spec is unclear. Thread-Index: AQHNa4zJSInjtc1rf0KkMKN4sD5TeZc9FpkAgAGp3YCAAACbgIADgc8AgAB+KYD//5DPgIAAeISA//+gb4CAAO4mgIAAo2sA Date: Tue, 31 Jul 2012 15:13:16 +0000 Message-ID: References: <50176D0B.5040202@raz.cx> In-Reply-To: <50176D0B.5040202@raz.cx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 15:13:41 -0000 The first helo will not work because the SPF record is on the second one. If you take postfix by default the helo contains the hostname http://www.po= stfix.org/postconf.5.html#smtp_helo_name but the spf record is usually on t= he domain name, not the hostname. So the document needs to make a bit more = of advocacy regarding this issue. This is why I suggest to insert 9.1.3 to = discuss this case in detail and draw attention to it. On Jul 30, 2012, at 10:28 PM, Roland Turner wrote: > Franck, >=20 > I've read the thread, and don't understand what you're getting at. 4408 2= .2 is clear, when MAIL FROM is empty (DSN/MDN/bounce), the identifier that'= s being assessed is postmaster@$HeloIdentity. Questions of matching organis= ational suffixes are not addressed by SPF (and may not make much sense; if = the machine generating the bounce is a gateway for a thousand domains, whic= h is the "correct" one for you to look at?). >=20 > Perhaps another way to tackle this is to ask: why do you care about the d= ifference between "HELO a.example.com" and "HELO example.com"? What use are= you trying to make of an authenticated HELO string? >=20 > - Roland >=20 >=20 >=20 > On 31/07/2012 06:16, Franck Martin wrote: >> Thanks. >>=20 >> I'm confused because I see often host.domain where domain is the one wit= h >> the SPF record. >>=20 >> Based on http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ >>=20 >> An added section under 9.1 could be useful >>=20 >>=20 >> 9.1.3 Bounces >> As explained in 2.2, [RFC5321] allows the reverse-path to be null, which >> is typical of some Delivery Status Notification [RFC3464], commonly call= ed >> email bounces. In this case the only entity available for performing an >> SPF check is the HELO identity defined in 1.1. Administrators >> MUST(SHOULD?) ensure that this identity is set correctly and has an >> appropriate SPF record. It is common to have the HELO identity set to >> hostname instead of domain. Administrators SHOULD consider publishing an >> SPF for *.domain (wildcard domains) in that case. >>=20 >> Feel free to rewrite, which I'm sure you will. >>=20 >> On 7/30/12 1:58 PM, "Scott Kitterman" wrote: >>=20 >>> Yes. >>>=20 >>> Scott K >>>=20 >>> On Monday, July 30, 2012 08:46:46 PM Franck Martin wrote: >>>> What I mean, is who present a correct helo string associated with a SP= F >>>> record, so the SPF validation can work for a bounce? Is that part wide= ly >>>> implemented? >>>>=20 >>>> On 7/30/12 1:25 PM, "Scott Kitterman" wrote: >>>>> I'm not sure what you mean. At least all open source libraries of >>>> which >>>>> I'm >>>>> aware implement this correctly. It's certainly not unused. >>>>>=20 >>>>> Scott K >>>>>=20 >>>>> On Monday, July 30, 2012 07:53:10 PM Franck Martin wrote: >>>>>> Digging more in this issue, I'm keen on proposing some text, but als= o >>>>>> looking at my anecdotal operational experience, isn't it something >>>> that >>>>>> should go on the deprecated list, due to lack of correct >>>> implementation? >>>>>> On 7/28/12 12:20 AM, "Scott Kitterman" wrote: >>>>>>> I guess I was speaking imprecisely. fully qualified hostname of th= e >>>>>>> client: >>>>>>> hostname.domain is exactly what you use. From spf2@kitterman.com Tue Jul 31 11:53:52 2012 Return-Path: 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 50A9E11E80FA for ; Tue, 31 Jul 2012 11:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] 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 AO4cjyHNgtpM for ; Tue, 31 Jul 2012 11:53:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3874E21F8779 for ; Tue, 31 Jul 2012 11:53:51 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 570EB20E40A3; Tue, 31 Jul 2012 14:53:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343760830; bh=/MNOvjc3qsG9HJGEP0yCid4XzqxxaZlaEzR4/+YVxIc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cCQ47JkUz931a2iP2eILh+tGxGUqLlItp9NPk8du9qxep17GYOUq07SONpv4XESK9 wxncoHJusveorI1/1fdALt8Z8inohGZW87JRFEf3SsrswggrlzHDxcl+6GNmtpotPL Nsqnmt01z34Rdi0YCncDOVNM1w97ly/MIIIDXUXk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3950E20E4095; Tue, 31 Jul 2012 14:53:50 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 31 Jul 2012 14:53:49 -0400 Message-ID: <2711875.Q74Jx7r6zr@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <50176D0B.5040202@raz.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:53:52 -0000 It's expected that one publishes SPF records for the hostname as well. This is not news. It's been this way since 2005. Scott K On Tuesday, July 31, 2012 03:13:16 PM Franck Martin wrote: > The first helo will not work because the SPF record is on the second one. > > If you take postfix by default the helo contains the hostname > http://www.postfix.org/postconf.5.html#smtp_helo_name but the spf record is > usually on the domain name, not the hostname. So the document needs to make > a bit more of advocacy regarding this issue. This is why I suggest to > insert 9.1.3 to discuss this case in detail and draw attention to it. > On Jul 30, 2012, at 10:28 PM, Roland Turner wrote: > > Franck, > > > > I've read the thread, and don't understand what you're getting at. 4408 > > 2.2 is clear, when MAIL FROM is empty (DSN/MDN/bounce), the identifier > > that's being assessed is postmaster@$HeloIdentity. Questions of matching > > organisational suffixes are not addressed by SPF (and may not make much > > sense; if the machine generating the bounce is a gateway for a thousand > > domains, which is the "correct" one for you to look at?). > > > > Perhaps another way to tackle this is to ask: why do you care about the > > difference between "HELO a.example.com" and "HELO example.com"? What use > > are you trying to make of an authenticated HELO string? > > > > - Roland > > > > On 31/07/2012 06:16, Franck Martin wrote: > >> Thanks. > >> > >> I'm confused because I see often host.domain where domain is the one with > >> the SPF record. > >> > >> Based on http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ > >> > >> An added section under 9.1 could be useful > >> > >> > >> 9.1.3 Bounces > >> As explained in 2.2, [RFC5321] allows the reverse-path to be null, which > >> is typical of some Delivery Status Notification [RFC3464], commonly > >> called > >> email bounces. In this case the only entity available for performing an > >> SPF check is the HELO identity defined in 1.1. Administrators > >> MUST(SHOULD?) ensure that this identity is set correctly and has an > >> appropriate SPF record. It is common to have the HELO identity set to > >> hostname instead of domain. Administrators SHOULD consider publishing an > >> SPF for *.domain (wildcard domains) in that case. > >> > >> Feel free to rewrite, which I'm sure you will. > >> > >> On 7/30/12 1:58 PM, "Scott Kitterman" wrote: > >>> Yes. > >>> > >>> Scott K > >>> > >>> On Monday, July 30, 2012 08:46:46 PM Franck Martin wrote: > >>>> What I mean, is who present a correct helo string associated with a SPF > >>>> record, so the SPF validation can work for a bounce? Is that part > >>>> widely > >>>> implemented? > >>>> > >>>> On 7/30/12 1:25 PM, "Scott Kitterman" wrote: > >>>>> I'm not sure what you mean. At least all open source libraries of > >>>> > >>>> which > >>>> > >>>>> I'm > >>>>> aware implement this correctly. It's certainly not unused. > >>>>> > >>>>> Scott K > >>>>> > >>>>> On Monday, July 30, 2012 07:53:10 PM Franck Martin wrote: > >>>>>> Digging more in this issue, I'm keen on proposing some text, but also > >>>>>> looking at my anecdotal operational experience, isn't it something > >>>> > >>>> that > >>>> > >>>>>> should go on the deprecated list, due to lack of correct > >>>> > >>>> implementation? > >>>> > >>>>>> On 7/28/12 12:20 AM, "Scott Kitterman" wrote: > >>>>>>> I guess I was speaking imprecisely. fully qualified hostname of the > >>>>>>> client: > >>>>>>> hostname.domain is exactly what you use. > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From superuser@gmail.com Tue Jul 31 13:03:20 2012 Return-Path: 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 36CB921F887E for ; Tue, 31 Jul 2012 13:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.665 X-Spam-Level: X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 AZuNCxPC4Up7 for ; Tue, 31 Jul 2012 13:03:19 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0066E21F8868 for ; Tue, 31 Jul 2012 13:03:08 -0700 (PDT) Received: by ggnc4 with SMTP id c4so7014756ggn.31 for ; Tue, 31 Jul 2012 13:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sJXCHbbd3wDBfx0DmzfSgJc2tBT0+0JXs2m8y1UX3KY=; b=AVEzF5/peFnIXW2+G/JqsXlDfYhYQx/Y1AE0spJUvPeqmR3FPyjSFa0phwRsNJcjeX eaavPFVVOX+RkkrVi0eicBdwTP5MgitMmvgVodxOiEdzIwb+NNxzkVk62TXsrvDsnF9J 8o4I7A8pJ6wm/bZxSccSeADXftvTmIyMb1196TNQCTtj7o/34vnvXTvQhdZ6/J9h/0xL 2bPrbNFOJZW0ZxHJpB1y61JuzZnGwxc+i1N7oafRoA2OAt5h9AVTkCDKuMiUcnB2eDaC 54C7vmoydVqGO6Pks+0eRvOxSwPdwoCzKgTyEoaZPTbhtZbwVjEDM0p2RgbURB0FVPfC oF0g== MIME-Version: 1.0 Received: by 10.60.8.8 with SMTP id n8mr25710606oea.38.1343764988329; Tue, 31 Jul 2012 13:03:08 -0700 (PDT) Received: by 10.182.116.98 with HTTP; Tue, 31 Jul 2012 13:03:08 -0700 (PDT) In-Reply-To: <2711875.Q74Jx7r6zr@scott-latitude-e6320> References: <50176D0B.5040202@raz.cx> <2711875.Q74Jx7r6zr@scott-latitude-e6320> Date: Tue, 31 Jul 2012 13:03:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=e89a8ff1c6d4ca7d5e04c625aa79 Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:03:20 -0000 --e89a8ff1c6d4ca7d5e04c625aa79 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 31, 2012 at 11:53 AM, Scott Kitterman wrote: > It's expected that one publishes SPF records for the hostname as well. > This > is not news. It's been this way since 2005. > > It doesn't take much thinking to realize that if one wants to rely on HELO validation, this is a necessary step. That said, does anyone feel strongly that RFC4408bis should say so? -MSK --e89a8ff1c6d4ca7d5e04c625aa79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 31, 2012 at 11:53 AM, Scott Kitterman <spf2@kitterman.com= > wrote:
It's expected that one publishes SPF records for the hostname as well. = =A0This
is not news. =A0It's been this way since 2005.


It doesn't take much thinking to realize that= if one wants to rely on HELO validation, this is a necessary step.

= That said, does anyone feel strongly that RFC4408bis should say so?

-MSK

--e89a8ff1c6d4ca7d5e04c625aa79-- From ajs@anvilwalrusden.com Tue Jul 31 15:38:41 2012 Return-Path: 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 33B4121F88B3 for ; Tue, 31 Jul 2012 15:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 d7IGklzmNQ3g for ; Tue, 31 Jul 2012 15:38:40 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B0EBF21F88B1 for ; Tue, 31 Jul 2012 15:38:40 -0700 (PDT) Received: from crankycanuck.ca (dhcp-21ac.meeting.ietf.org [130.129.33.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D752E8A032 for ; Tue, 31 Jul 2012 22:38:38 +0000 (UTC) Date: Tue, 31 Jul 2012 18:38:36 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120731223835.GB31188@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Process decisions about scope of charter X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 22:38:41 -0000 Dear colleagues, In some recent discussion about 4408bis, there was disagreement as to whether we may remove a feature that is in very little use. The arguments turned on the question of whether extremely little use qualifies as "unused". After careful consideration of the arguments, the history of the chartering of the WG, and some hallway discussions here at the Vancouver meeting, your chairs have determined that, for our purposes, "unused" has its ordinary English meaning: not in use, at all. We appreciate that this is not the way we as a community normally proceed when advancing a document on the standards track. That is actually part of the reason we have come to this conclusion. At the time the WG was chartered, the aim was to move RFC 4408 to the standards track with the barest minimum of changes. This is why the charter says in more than one place that we're not allowed to change things that are in use. We are not moving a document along the standards track; we are converting from the experimental track to the standards track, and we want to do that with maximal backward compatibility. This means that the RFC that eventually gets published probably will have some features in it that are broken or poor ideas; these will need to be removed in a second pass. We recognize that this is inefficient, and are not completely happy with such a result, but we believe that this is the only approach that is consistent with the intent of the charter. We acknowledge that the charter's text is written in such a way that different readers of good will could come to different conclusions about what it means. That's why we are issuing this process decision. We hope that this decision can close the discussion of the meta-issue about whether we can remove a little-used feature, and allow us to return our focus to completing our remaining work items. Best regards, AS and SM SPFBIS co-chairs. -- Andrew Sullivan ajs@anvilwalrusden.com From derek.diget+spfbis@wmich.edu Tue Jul 31 15:59:25 2012 Return-Path: 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 A349C11E8167 for ; Tue, 31 Jul 2012 15:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 GmjkqaF4jfoP for ; Tue, 31 Jul 2012 15:59:25 -0700 (PDT) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by ietfa.amsl.com (Postfix) with ESMTP id 0BACA11E8166 for ; Tue, 31 Jul 2012 15:59:24 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/Plain; charset=US-ASCII Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0M81002D3RUSYD30@mta01.service.private> for spfbis@ietf.org; Tue, 31 Jul 2012 18:59:24 -0400 (EDT) X-WMU-Spam: Gauge=X, Probability=10% on Tue Jul 31 18:59:24 2012, Report=' WMU_MSA_SMTP+ 0, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_900_999 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NS ' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.31.224817 - Tue Jul 31 18:59:23 2012 Date: Tue, 31 Jul 2012 18:59:16 -0400 (EDT) From: Derek Diget X-X-Sender: diget@spaz.oit.wmich.edu To: spfbis@ietf.org In-reply-to: Message-id: References: <50176D0B.5040202@raz.cx> <2711875.Q74Jx7r6zr@scott-latitude-e6320> Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 22:59:25 -0000 On Jul 31, 2012 at 13:03 -0700, Murray S. Kucherawy wrote: =>On Tue, Jul 31, 2012 at 11:53 AM, Scott Kitterman wrote: => =>> It's expected that one publishes SPF records for the hostname as well. =>> This is not news. It's been this way since 2005. =>> =>It doesn't take much thinking to realize that if one wants to rely on HELO =>validation, this is a necessary step. => =>That said, does anyone feel strongly that RFC4408bis should say so? No it shouldn't. It is already mentioned at and would go in the BCP/deployment guide (if there is one). -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** From W.Doust@racingvictoria.net.au Tue Jul 31 16:33:01 2012 Return-Path: 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 5660711E8168 for ; Tue, 31 Jul 2012 16:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 ufIWZ-G9DeZR for ; Tue, 31 Jul 2012 16:33:00 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDA611E808E for ; Tue, 31 Jul 2012 16:33:00 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 9558) id ; Wed, 01 Aug 2012 09:32:57 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2012 09:32:33 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B05@XCHANGE.rvl.internal> In-Reply-To: <3510820.QBJdz4C5b1@scott-latitude-e6320> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1u5N7siCrD3uvwS26cdHDIh4+yZAAj94wQ References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal><1373558.UHCXZLjJRI@scott-latitude-e6320><0D2A0D5F64179F4F9556D3DEDE39F9AF01027ABE@XCHANGE.rvl.internal> <3510820.QBJdz4C5b1@scott-latitude-e6320> From: "Wayne Doust" To: "Scott Kitterman" , Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 23:33:01 -0000 -----Original Message----- I would encourage you to review the group's charter. We have a pretty tightly specified set of work we're scoped to do. IMO, independent of if this is a good idea or not, it's outside our scope. Scott K _______________________________________________ I accept that introducing new blanket classifications is possibly outside the scope of the charter, however this does not mean that recommendations on how to deal with the various results cannot be made. Section 2.5 - Interpreting the result already does this. It provides recommendations on dealing with the results. Sections 2.5.6 and 2.5.6 could easily be amended to recommend treating them the same as SPF Neutral. Section 2.5.4 "SHOULD use an SMTP reply code of 550" Section 2.5.5 "can use and SMTP reply code of 451" IMO Section 2.5.6 should be modified to remove the recommendation "SHOULD use a reply code of 451". Section 2.5.7 should be modified to recommend treating the PERMERROR as NEUTRAL or NONE. *************************************************************************= ******************************* Disclaimer: This email message and any attachments are confidential. =20 The information contained in this email message and any attachments may b= e=20 confidential information. If you are not the intended recipient, any use,= =20interference with,=20 disclosure or copying of this material is unauthorised and prohibited. This email and any attachments are also subject to copyright. =20 No part of them may be reproduced, adapted or transmitted without the wri= tten permission of the copyright owner. If you have received this email in error please immediately advise the se= nder=20 by return email and delete the message from your system.=20 Although this email has been checked for viruses and other defects, no re= sponsibility=20 can be accepted for any loss or damage arising from its receipt or use. Racing Victoria Limited respects your privacy. Our privacy policy can be = accessed=20 from our web site: "http://www.racingvictoria.net.au" *************************************************************************= ******************************* From spf2@kitterman.com Tue Jul 31 16:37:34 2012 Return-Path: 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 2FF9921F8917 for ; Tue, 31 Jul 2012 16:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 45ngyI2s9wZ7 for ; Tue, 31 Jul 2012 16:37:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDA721F890F for ; Tue, 31 Jul 2012 16:37:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D8E7D20E406D; Tue, 31 Jul 2012 19:37:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343777852; bh=AFQbTYQju3U3WoAQEge9P5FkRy7ejngN+mAk8CZP6qE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jprp69/qAIfFJXzaDyI6mh9BlEH2WHPYcYHH5bijtJ9NiE0nbrTUtp8RGtYQ7L0+8 dxBWAeDO7hJmfO9ExCWvKg3ZoXFG2yVLkP0OYJbup6l+OA24ozz3cJsNVZmMBYTtFI lD787AFOGdPPZabKHh1TltG2LV68jOU/55oz3AZA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id AB2AE20E4061; Tue, 31 Jul 2012 19:37:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 31 Jul 2012 19:37:31 -0400 Message-ID: <3725056.uMTa6O8Y0m@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B05@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <3510820.QBJdz4C5b1@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B05@XCHANGE.rvl.internal> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 23:37:34 -0000 On Wednesday, August 01, 2012 09:32:33 AM Wayne Doust wrote: ... > Section 2.5.4 "SHOULD use an SMTP reply code of 550" > Section 2.5.5 "can use and SMTP reply code of 451" ... There are important if statements in those sections before the bits you quote that mean they don't at all do what you're claiming they do. All they as is that if you are going to take certain actions, here is how you should communicate them. They say nothing at all about what one should do. Scott K From W.Doust@racingvictoria.net.au Tue Jul 31 16:52:40 2012 Return-Path: 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 34E1311E817F for ; Tue, 31 Jul 2012 16:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.362 X-Spam-Level: X-Spam-Status: No, score=-1.362 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 MRGhXIQqzOp1 for ; Tue, 31 Jul 2012 16:52:39 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0B07521F89A0 for ; Tue, 31 Jul 2012 16:52:38 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 9558) id ; Wed, 01 Aug 2012 09:52:38 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2012 09:48:58 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B0B@XCHANGE.rvl.internal> In-Reply-To: <3725056.uMTa6O8Y0m@scott-latitude-e6320> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1vdXkhTb9+ROwfQo+ERTS3hixpcwAAE3oQ References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal><3510820.QBJdz4C5b1@scott-latitude-e6320><0D2A0D5F64179F4F9556D3DEDE39F9AF01027B05@XCHANGE.rvl.internal> <3725056.uMTa6O8Y0m@scott-latitude-e6320> From: "Wayne Doust" To: "Scott Kitterman" , Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 23:52:40 -0000 -----Original Message----- There are important if statements in those sections before the bits you quote that mean they don't at all do what you're claiming they do. All they as is that if you are going to take certain actions, here is how you should communicate them. They say nothing at all about what one should do. Scott K _______________________________________________ Using other sections as a template. The following sections could be modified as follows: 2.5.6. TempError =20 A "TempError" result means that the SPF client encountered a =20 transient error while performing the check. Checking software can =20 choose to accept or temporarily reject the message. If the message =20 is rejected during the SMTP transaction for this reason, the softwar= e =20 SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DS= N =20 code with a note the first time the message is received, but accept =20 it the second time. 2.5.7. PermError =20 A "PermError" result means that the domain's published records could= =20 not be correctly interpreted. This signals an error condition that =20 requires manual intervention to be resolved, as opposed to the =20 TempError result. Be aware that if the domain owner uses macros =20 (Section 8), it is possible that this result is due to the checked =20 identities having an unexpected format. A "PermError" result may als= o =20 be due to a local parsing failure or DNS resolution error rather tha= n a =20 problem with the published SPF record. For these reasons, Receiving = =20 software SHOULD NOT reject the message based solely on this result, =20 but MAY subject the message to closer scrutiny than normal.=20 These changes should be within the scope of the charter. *************************************************************************= ******************************* Disclaimer: This email message and any attachments are confidential. =20 The information contained in this email message and any attachments may b= e=20 confidential information. If you are not the intended recipient, any use,= =20interference with,=20 disclosure or copying of this material is unauthorised and prohibited. This email and any attachments are also subject to copyright. =20 No part of them may be reproduced, adapted or transmitted without the wri= tten permission of the copyright owner. If you have received this email in error please immediately advise the se= nder=20 by return email and delete the message from your system.=20 Although this email has been checked for viruses and other defects, no re= sponsibility=20 can be accepted for any loss or damage arising from its receipt or use. Racing Victoria Limited respects your privacy. Our privacy policy can be = accessed=20 from our web site: "http://www.racingvictoria.net.au" *************************************************************************= ******************************* From prvs=5536a0696=fmartin@linkedin.com Tue Jul 31 18:48:33 2012 Return-Path: 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 D2DD611E8184 for ; Tue, 31 Jul 2012 18:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 aA6J9a4xYwtG for ; Tue, 31 Jul 2012 18:48:33 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2677211E8198 for ; Tue, 31 Jul 2012 18:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim; t=1343785713; x=1375321713; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=1wIohAiMiEdv7ceLdjWbKRe4ddZ7tS27sLBMuhyPbto=; b=fcUVuUxlUsTHJFZUw9QTjKTW8RcZPdjnylnVd8s7RbJtnfpq8TfDsJjQ uV63h1rkRVZvU9E7GS7e6a2yVA3bfxKwkfTXl6HWBQ0hjZJfg3Q+/uCy/ SyQ90Hb69gbsoX+; X-IronPort-AV: E=Sophos;i="4.77,690,1336374000"; d="scan'208";a="22173473" Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.01.0355.002; Tue, 31 Jul 2012 18:48:08 -0700 From: Franck Martin To: "spfbis@ietf.org" Thread-Topic: [spfbis] SPF and empty mail from envelope spec is unclear. Thread-Index: AQHNa4zJSInjtc1rf0KkMKN4sD5TeZc9FpkAgAGp3YCAAACbgIADgc8AgAB+KYD//5DPgIAAeISA//+gb4CAAO4mgIAAo2sAgAA9h4CAABNeAIAAMTYA//+554A= Date: Wed, 1 Aug 2012 01:48:07 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 01:48:33 -0000 On 7/31/12 3:59 PM, "Derek Diget" wrote: > >On Jul 31, 2012 at 13:03 -0700, Murray S. Kucherawy wrote: >=3D>On Tue, Jul 31, 2012 at 11:53 AM, Scott Kitterman >wrote: >=3D> >=3D>> It's expected that one publishes SPF records for the hostname as wel= l. >=3D>> This is not news. It's been this way since 2005. >=3D>> >=3D>It doesn't take much thinking to realize that if one wants to rely on >HELO >=3D>validation, this is a necessary step. >=3D> >=3D>That said, does anyone feel strongly that RFC4408bis should say so? > >No it shouldn't. It is already mentioned at > and would go in the >BCP/deployment guide (if there is one). So why is it such a common mistake? $ dig +short txt ietf.org "v=3Dspf1 ip4:12.22.58.0/26 ip4:64.170.98.0/26 ip4:208.66.40.224/27 ip6:2001:1890:123a::0/56 ip6:2001:1890:1112:1::0/64 -all" $ dig +short txt mail.ietf.org Received: from [65.55.34.216] ([65.55.34.216:9424] helo=3Dcol0-omc4-s14.col0.hotmail.com) $ dig +short txt col0-omc4-s14.col0.hotmail.com $ dig +short txt hotmail.com "v=3Dspf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all" May I suggest because it is not mentioned clearly in the RFC? :P From spf2@kitterman.com Tue Jul 31 19:34:02 2012 Return-Path: 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 81A1721F8810 for ; Tue, 31 Jul 2012 19:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 RfZ5wkvU7K+1 for ; Tue, 31 Jul 2012 19:34:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFE821F880E for ; Tue, 31 Jul 2012 19:34:00 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 61C8120E4085; Tue, 31 Jul 2012 22:33:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343788433; bh=6cDBlhV35UrWz8KBK0FsmTn8H0kdckBC7LafFZW7qXk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=K/Pg4v+YPnWLe1k3Lt3IPA7nqG24AiUFgqQVqlkwTKVlnm85zrNAYoGBBsot14xsP SOQjtlL7f881FhnZJm7oGECtSyFZoBaWYY2AV1CQfix/uPxT6frNexmyIaeFe/qClK Mm3hK5Jcj06cw9x6XpCUl9Yg2hdLcR9YxOSGQvg0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3A12620E4079; Tue, 31 Jul 2012 22:33:52 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 31 Jul 2012 22:33:52 -0400 Message-ID: <2831708.BQVxDdug3p@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 02:34:02 -0000 On Wednesday, August 01, 2012 01:48:07 AM Franck Martin wrote: > On 7/31/12 3:59 PM, "Derek Diget" wrote: > >On Jul 31, 2012 at 13:03 -0700, Murray S. Kucherawy wrote: > >=>On Tue, Jul 31, 2012 at 11:53 AM, Scott Kitterman > >wrote: > >=> > >=>> It's expected that one publishes SPF records for the hostname as well. > >=>> This is not news. It's been this way since 2005. > >=>> > >=>It doesn't take much thinking to realize that if one wants to rely on > >HELO > >=>validation, this is a necessary step. > >=> > >=>That said, does anyone feel strongly that RFC4408bis should say so? > > > >No it shouldn't. It is already mentioned at > > and would go in the > >BCP/deployment guide (if there is one). > > So why is it such a common mistake? > > $ dig +short txt ietf.org > "v=spf1 ip4:12.22.58.0/26 ip4:64.170.98.0/26 ip4:208.66.40.224/27 > ip6:2001:1890:123a::0/56 ip6:2001:1890:1112:1::0/64 -all" > $ dig +short txt mail.ietf.org > > > Received: from [65.55.34.216] ([65.55.34.216:9424] > helo=col0-omc4-s14.col0.hotmail.com) > > $ dig +short txt col0-omc4-s14.col0.hotmail.com > > $ dig +short txt hotmail.com > "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com > include:spf-c.hotmail.com include:spf-d.hotmail.com ~all" > > > May I suggest because it is not mentioned clearly in the RFC? :P I think it's worth mentioning in section 9. I've got your proposed words and when I dive through the document next, I'll see how I can fit them in. HELO/EHLO definitely gets a lot less attention than Mail From and so I think it's worth mentioning. Scott K From vesely@tana.it Tue Jul 31 19:38:47 2012 Return-Path: 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 BF86321F8819 for ; Tue, 31 Jul 2012 19:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 SxEQ3kxxIp23 for ; Tue, 31 Jul 2012 19:38:47 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD4C21F8818 for ; Tue, 31 Jul 2012 19:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1343788725; bh=4gj+HMdNCz5KCvPL+B4f8kiDHBrLixkrEDgK8TKORw0=; l=741; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=G36sNvaN9RIK4u0H3SmoRsBol5iI40zmXZ4EbtJ5waSYOWmzG5zGVVEB5w4MSCibA gJv4R9X3IYcsd9b2r5Enj5CDUvGGDKiOsMlLfLSiFDaOSLEUJ1XNUgfi2U3co+Ds+T EcYOortVWsCt0bnOZD+mbg1n0OYSoEMSF8wfLS6I= Received: from [208.181.207.155] (softdnserr [64.114.255.126]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 01 Aug 2012 04:38:43 +0200 id 00000000005DC042.00000000501896B4.00006C05 Message-ID: <501896AD.8040408@tana.it> Date: Tue, 31 Jul 2012 19:38:37 -0700 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <50176D0B.5040202@raz.cx> <2711875.Q74Jx7r6zr@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 02:38:47 -0000 On Tue 31/Jul/2012 13:03:08 -0700 Murray S. Kucherawy wrote: > On Tue, Jul 31, 2012 at 11:53 AM, Scott Kitterman wrote: > >> It's expected that one publishes SPF records for the hostname as >> well. This is not news. It's been this way since 2005. > > It doesn't take much thinking to realize that if one wants to rely on > HELO validation, this is a necessary step. It takes too much thinking. Some of it is required to determine if one needs to rely on HELO validation. At this point the plot thickens: What difference does that make? > That said, does anyone feel strongly that RFC4408bis should say so? I, for one. We have an open ticket that is (also) about this: http://trac.tools.ietf.org/wg/spfbis/trac/ticket/12 From spf2@kitterman.com Tue Jul 31 19:42:40 2012 Return-Path: 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 5620E11E8097 for ; Tue, 31 Jul 2012 19:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 zxgZqRb81Zyv for ; Tue, 31 Jul 2012 19:42:39 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9986C11E8072 for ; Tue, 31 Jul 2012 19:42:39 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 243B920E4085; Tue, 31 Jul 2012 22:42:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343788959; bh=ghZxO+gW/tjB6JOMbpAHNdn1b84XbbwU73I+xK9ODXY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aP80HaUuIcXqvLY0RvorzOpMLi+25mWTeGJLW1q968sEVgLc/c2v4XkhvBQ7iTIRI rSrUC8cKqe6KY6bQerQHYsSp3mdfl6v10nFWa7ZaaaqqsHFETJv3Ww5WVylvDIMUKE ZG/uUDulMUe0PesLmAZNjKHKVB/RR7jW4wq3m8oM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EC62220E4079; Tue, 31 Jul 2012 22:42:38 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 31 Jul 2012 22:42:38 -0400 Message-ID: <1472908.4zQmik4QZ7@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B0B@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <3725056.uMTa6O8Y0m@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B0B@XCHANGE.rvl.internal> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 02:42:40 -0000 On Wednesday, August 01, 2012 09:48:58 AM Wayne Doust wrote: > -----Original Message----- > > There are important if statements in those sections before the bits you > quote that mean they don't at all do what you're claiming they do. All > they as is that if you are going to take certain actions, here is how > you should communicate them. They say nothing at all about what one > should do. > > Scott K > _______________________________________________ > > Using other sections as a template. The following sections could be > modified as follows: > > 2.5.6. TempError > > A "TempError" result means that the SPF client encountered a > transient error while performing the check. Checking software can > choose to accept or temporarily reject the message. If the message > is rejected during the SMTP transaction for this reason, the software > SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN > code with a note the first time the message is received, but accept > it the second time. > > 2.5.7. PermError > > A "PermError" result means that the domain's published records could > not be correctly interpreted. This signals an error condition that > requires manual intervention to be resolved, as opposed to the > TempError result. Be aware that if the domain owner uses macros > (Section 8), it is possible that this result is due to the checked > identities having an unexpected format. A "PermError" result may also > be due to a local parsing failure or DNS resolution error rather than > a > problem with the published SPF record. For these reasons, Receiving > software SHOULD NOT reject the message based solely on this result, > but MAY subject the message to closer scrutiny than normal. > > > These changes should be within the scope of the charter. I think you are repeating the mistakes of some of the early SPF evangelists. Your suggested wording for 2.5.6 reads to me as if SPF can ever provide a definitive result for message acceptance. It can't. If I read your rewrite of 2.5.6 correctly, I believe that what you're after is a receiver policy specification that based on temperror the only local policy actions that are acceptable are accept or defer. I gather that what you want is to suggest reject on temperror is a bad idea? I'm guessing similarly that for 2.5.7 you want to suggest rejecting on permerror is a bad idea. What's an example of a permerrror that could be caused by local parsing failure or DNS resolution problems (I think all DNS errors end up as temperrors)? Scott K From prvs=5536a0696=fmartin@linkedin.com Tue Jul 31 19:49:28 2012 Return-Path: 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 7D4AE21F8864 for ; Tue, 31 Jul 2012 19:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 wObzKyt8Z9Pn for ; Tue, 31 Jul 2012 19:49:28 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id EE82121F885E for ; Tue, 31 Jul 2012 19:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim; t=1343789367; x=1375325367; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Tr0KNebvl/VY95nCHT2HDZYEl57wiJInuwycSFNFqZk=; b=FyZhpZ4A0mICzeeiMKfp93cvIL4t2vsMEEhtY4Yb4ETvFhNmqu5s7f4Q ii3RC+4udcNl45e4hk3r2p64AZLTtR/xJsNhJzgBtZuozYyfZMhuqkJ3C 4hsADECj7GjTLL8; X-IronPort-AV: E=Sophos;i="4.77,690,1336374000"; d="scan'208";a="20478641" Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.01.0355.002; Tue, 31 Jul 2012 19:49:05 -0700 From: Franck Martin To: Scott Kitterman Thread-Topic: [spfbis] SPF and empty mail from envelope spec is unclear. Thread-Index: AQHNa4zJSInjtc1rf0KkMKN4sD5TeZc9FpkAgAGp3YCAAACbgIADgc8AgAB+KYD//5DPgIAAeISA//+gb4CAAO4mgIAAo2sAgAA9h4CAABNeAIAAMTYA//+554AAEEHQAP//jucC Date: Wed, 1 Aug 2012 02:49:05 +0000 Message-ID: References: , <2831708.BQVxDdug3p@scott-latitude-e6320> In-Reply-To: <2831708.BQVxDdug3p@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 02:49:28 -0000 I think the issue is nobody think about bounces when deploying SPF. Thanks for looking into fitting the words. Toute connaissance est une r=E9ponse =E0 une question. On Jul 31, 2012, at 7:33 PM, "Scott Kitterman" wrote: > On Wednesday, August 01, 2012 01:48:07 AM Franck Martin wrote: >> On 7/31/12 3:59 PM, "Derek Diget" wrote: >>> On Jul 31, 2012 at 13:03 -0700, Murray S. Kucherawy wrote: >>> =3D>On Tue, Jul 31, 2012 at 11:53 AM, Scott Kitterman >>> wrote: >>> =3D> >>> =3D>> It's expected that one publishes SPF records for the hostname as = well. >>> =3D>> This is not news. It's been this way since 2005. >>> =3D>> >>> =3D>It doesn't take much thinking to realize that if one wants to rely = on >>> HELO >>> =3D>validation, this is a necessary step. >>> =3D> >>> =3D>That said, does anyone feel strongly that RFC4408bis should say so? >>>=20 >>> No it shouldn't. It is already mentioned at >>> and would go in the >>> BCP/deployment guide (if there is one). >>=20 >> So why is it such a common mistake? >>=20 >> $ dig +short txt ietf.org >> "v=3Dspf1 ip4:12.22.58.0/26 ip4:64.170.98.0/26 ip4:208.66.40.224/27 >> ip6:2001:1890:123a::0/56 ip6:2001:1890:1112:1::0/64 -all" >> $ dig +short txt mail.ietf.org >> >>=20 >> Received: from [65.55.34.216] ([65.55.34.216:9424] >> helo=3Dcol0-omc4-s14.col0.hotmail.com) >>=20 >> $ dig +short txt col0-omc4-s14.col0.hotmail.com >> >> $ dig +short txt hotmail.com >> "v=3Dspf1 include:spf-a.hotmail.com include:spf-b.hotmail.com >> include:spf-c.hotmail.com include:spf-d.hotmail.com ~all" >>=20 >>=20 >> May I suggest because it is not mentioned clearly in the RFC? :P >=20 > I think it's worth mentioning in section 9. I've got your proposed words= and=20 > when I dive through the document next, I'll see how I can fit them in. >=20 > HELO/EHLO definitely gets a lot less attention than Mail From and so I th= ink=20 > it's worth mentioning. >=20 > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From W.Doust@racingvictoria.net.au Tue Jul 31 20:45:31 2012 Return-Path: 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 C5BF921F8755 for ; Tue, 31 Jul 2012 20:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 Qq68r6W4Sy4n for ; Tue, 31 Jul 2012 20:45:31 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC4421F8750 for ; Tue, 31 Jul 2012 20:45:29 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 9558) id ; Wed, 01 Aug 2012 13:45:27 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2012 13:44:06 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B4F@XCHANGE.rvl.internal> In-Reply-To: <1472908.4zQmik4QZ7@scott-latitude-e6320> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1vj1U8bz7b53rAR5aSnUmcyHNYXAABGoWQ References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal><3725056.uMTa6O8Y0m@scott-latitude-e6320><0D2A0D5F64179F4F9556D3DEDE39F9AF01027B0B@XCHANGE.rvl.internal> <1472908.4zQmik4QZ7@scott-latitude-e6320> From: "Wayne Doust" To: "Scott Kitterman" , Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 03:45:31 -0000 > Your suggested wording for 2.5.6 reads to me as if SPF can ever provide a definitive result for message acceptance. It can't. I've used the wording from other parts of the same section. It doesn't seem to be a problem there to recommend a course Of action without mandating it. > I gather that what you want is to suggest reject on temperror is a bad idea? Basically. As in section 2.5.5 - which recommends that treating it as "greylisted" is the most extreme method of treating=20 The response. Why should TEMPERROR or PERMERROR be treated more harshly than Softfail? > I'm guessing similarly that for 2.5.7 you want to suggest rejecting on permerror is a bad idea. Correct. > What's an example of a permerrror that could be caused by local parsing failure or DNS resolution problems (I think all DNS errors end up as temperrors)? <450 4.7.1 : Recipient address rejected: SPF-Result=3Dmail01.mvrc.net.au: 'SERVFAIL' error on DNS 'SPF' lookup of 'mail01.mvrc.net.au'> NB: I rarely see a 550 error on SPF. I think most sysadmins (including myself) prefer to use 45x when rejecting messages based on SPF. The following SPF record caused problems with some receivers - apparently due to difficulty with parsing two lines of record: afl.com.au. 600 IN TXT "v=3Dspf1 mx ptr include:servers.mcsv.net ~all" afl.com.au. 600 IN TXT "v=3Dspf1 a mx ip4:203.89.249.0/26 ~all" This record passes the Beveridge check but fails SK's check: Mail sent from this IP address: 69.167.149.85=20 Mail from (Sender): emma.cashman@afl.com.au=20 Mail checked using this SPF policy: v=3Dspf1 mx ptr include:servers.mcsv.net ~all=20 Results - softfail domain owner discourages use of this host Change the record to a single line: afl.com.au. 600 IN TXT "v=3Dspf1 a mx ptr ip4:203.89.249.0/26 include:servers.mcsv.net ~all" and the result is: Mail sent from this IP address: 69.167.149.85=20 Mail from (Sender): emma.cashman@afl.com.au=20 Mail checked using this SPF policy: v=3Dspf1 a mx ptr ip4:203.89.249.0/26= include:servers.mcsv.net ~all=20 Results - PASS sender SPF authorized The simple reality is that in RL, Receivers are lumping TempErrors and PermErrors along with Fails. The spec should recommend something along the lines of this type of "order of goodness" for SPF results: Pass Neutral None TempError PermError SoftFail Fail In Meng's terminology of "Good" "Bad" and "Ugly", that could be: Good: Pass Bad: Fail (optionally) Ugly: SoftFail, TempError, PermError Neutral: Neutral, None With "Neutral" potentially being lumped in with ugly. *************************************************************************= ******************************* Disclaimer: This email message and any attachments are confidential. =20 The information contained in this email message and any attachments may b= e=20 confidential information. If you are not the intended recipient, any use,= =20interference with,=20 disclosure or copying of this material is unauthorised and prohibited. This email and any attachments are also subject to copyright. =20 No part of them may be reproduced, adapted or transmitted without the wri= tten permission of the copyright owner. If you have received this email in error please immediately advise the se= nder=20 by return email and delete the message from your system.=20 Although this email has been checked for viruses and other defects, no re= sponsibility=20 can be accepted for any loss or damage arising from its receipt or use. Racing Victoria Limited respects your privacy. Our privacy policy can be = accessed=20 from our web site: "http://www.racingvictoria.net.au" *************************************************************************= ******************************* From spf2@kitterman.com Tue Jul 31 21:01:42 2012 Return-Path: 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 005FA21F8504 for ; Tue, 31 Jul 2012 21:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 SwMdVTqm+xmb for ; Tue, 31 Jul 2012 21:01:41 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6E721F84F5 for ; Tue, 31 Jul 2012 21:01:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6E6DA20E4085; Wed, 1 Aug 2012 00:01:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343793700; bh=r0Kce5Z4ZJzeOvqlVmzZsxN8Ciw0FMZIOAJLlgwek0U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pBEIxrJPYON+z5JM+ArIK+/ZBTSDe/XwmDRosyZzTNc4LU2tp8L7D78Y2uLf8wghV QIvINJlOhrb65N8GYI7pwLONLcXgHg0E8uPzvyWJtkrv2zVhqbYQX86DtyfQDkL685 szuQTLhnhFju1e9D6XTrUBS/sdOE1sDNoDFSZkz0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 48F1620E4079; Wed, 1 Aug 2012 00:01:39 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 01 Aug 2012 00:01:39 -0400 Message-ID: <2356084.rOqJxuchnj@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B4F@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <1472908.4zQmik4QZ7@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B4F@XCHANGE.rvl.internal> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 04:01:42 -0000 On Wednesday, August 01, 2012 01:44:06 PM Wayne Doust wrote: > > Your suggested wording for 2.5.6 reads to me as if SPF can ever > > provide a definitive result for message acceptance. It can't. > > I've used the wording from other parts of the same section. It doesn't > seem to be a problem there to recommend a course > Of action without mandating it. With one exception, RFC 4408 doesn't specify receiver policy. The furthest is goes is to say, if you do X, then do it this way. That's significantly different than what I think you are suggesting. > > I gather that what you want is to suggest reject on temperror is a > > bad idea? > > Basically. As in section 2.5.5 - which recommends that treating it as > "greylisted" is the most extreme method of treating > The response. Why should TEMPERROR or PERMERROR be treated more harshly > than Softfail? That's a matter for local policy, not protocol in the RFC 4408 design and I don't think we should change that. > > I'm guessing similarly that for 2.5.7 you want to suggest rejecting on > > permerror is a bad idea. > > Correct. > > > What's an example of a permerrror that could be caused by local > > parsing failure or DNS resolution problems (I think all DNS errors end > up as temperrors)? > > <450 4.7.1 : Recipient address rejected: > SPF-Result=mail01.mvrc.net.au: 'SERVFAIL' error on DNS 'SPF' lookup of > 'mail01.mvrc.net.au'> > > NB: I rarely see a 550 error on SPF. I think most sysadmins (including > myself) prefer to use 45x when rejecting messages based on SPF. Those are properly temperrors, which is why they get 45X responses. 45X is not a reject, it's a deferral. So not a permerror. > The following SPF record caused problems with some receivers - > apparently due to difficulty with parsing two lines of record: > > afl.com.au. 600 IN TXT "v=spf1 mx ptr include:servers.mcsv.net ~all" > afl.com.au. 600 IN TXT "v=spf1 a mx ip4:203.89.249.0/26 ~all" > > This record passes the Beveridge check but fails SK's check: > > Mail sent from this IP address: 69.167.149.85 > Mail from (Sender): emma.cashman@afl.com.au > Mail checked using this SPF policy: v=spf1 mx ptr > include:servers.mcsv.net ~all > Results - softfail domain owner discourages use of this host > > Change the record to a single line: > > afl.com.au. 600 IN TXT "v=spf1 a mx ptr ip4:203.89.249.0/26 > include:servers.mcsv.net ~all" > > and the result is: > > Mail sent from this IP address: 69.167.149.85 > Mail from (Sender): emma.cashman@afl.com.au > Mail checked using this SPF policy: v=spf1 a mx ptr ip4:203.89.249.0/26 > include:servers.mcsv.net ~all > Results - PASS sender SPF authorized Having two SPF record is a permerror. That's not a permerror due to local DNS parsing. It's a permerror due to bad record publishing. I agree that temperrors can happen due to bad DNS on the receiver side, but not permerror. > The simple reality is that in RL, Receivers are lumping TempErrors and > PermErrors along with Fails. The spec should > recommend something along the lines of this type of "order of goodness" > for SPF results: > > Pass > Neutral > None > TempError > PermError > SoftFail > Fail > > In Meng's terminology of "Good" "Bad" and "Ugly", that could be: > > Good: Pass > Bad: Fail (optionally) > Ugly: SoftFail, TempError, PermError > Neutral: Neutral, None > > With "Neutral" potentially being lumped in with ugly. Ironically, the one piece of receiver poilcy in RFC 4408 is that Neutral MUST be treated the same as None. I think the fact that you're suggesting that perhaps the one place where receiver policy is specified should be changed should be an indicator of the folly of trying to do so even more. Receivers are going to do what they are going to do. Considering you are in your last mail incorrectly conflating temperrors and permerrors, claiming permerrors are inappropriate when they are not, and ascribing issues to receiver side processing that belong to the sender side I suspect to you ought to go revisit some of your assumptions and analysis before proceeding further. Scott K From hsantos@isdg.net Tue Jul 31 21:19:52 2012 Return-Path: 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 21C0F21F871D for ; Tue, 31 Jul 2012 21:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 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 jR5MQXu702f2 for ; Tue, 31 Jul 2012 21:19:51 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2419821F8718 for ; Tue, 31 Jul 2012 21:19:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2272; t=1343794782; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=V1R7Jr4MiLgrTQYj5KW6N4gRHLM=; b=cTyv2HHWvHzM2Q+t5S4h hFhdIidMNynz5wJF27BHYmHK0Yt67eo/+H9PF3TD0gsbWIgS1ZYzT10PoV61mA4W IeIsWJu42Jilxo8qCkGGFwrDysiOtmbftxbB/fCy/9TmDp1NTNX6RyfpdyiISCq/ QDMuRsDP1o8YtbcNgGDZVHQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 01 Aug 2012 00:19:42 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4111568988.4324.4284; Wed, 01 Aug 2012 00:19:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2272; t=1343794629; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=UMMTeTL se1Sc3KPfr6JqV2uoufyh0kOOPfIdTggmJpU=; b=mTVMdshfwf4ro8R7tYk1be1 owZ2TjPl/FwfwdDEdt4GJ900XkgK09H/0sjtKi25aFGf8xXWONU/EDtBxV6HQDAa 0k89hAuMXz1a4ASdiwEjkpGIfq6BFKJtpQBW3v+M6cNKexREm0FfuAUG12HS7Mkn mmsGwSIyt0guGJ4yggLw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 01 Aug 2012 00:17:09 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 415427895.9.6768; Wed, 01 Aug 2012 00:17:09 -0400 Message-ID: <5018AE61.4010202@isdg.net> Date: Wed, 01 Aug 2012 00:19:45 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Wayne Doust References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal><3725056.uMTa6O8Y0m@scott-latitude-e6320><0D2A0D5F64179F4F9556D3DEDE39F9AF01027B0B@XCHANGE.rvl.internal> <1472908.4zQmik4QZ7@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B4F@XCHANGE.rvl.internal> In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B4F@XCHANGE.rvl.internal> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 04:19:52 -0000 Wayne Doust wrote: > Why should TEMPERROR or PERMERROR be treated more harshly > than Softfail? Does it? First, TEMPERROR and PERMERROR are not domain policies where SoftFail is, they are local policy design concepts. The main problem with any sort of error processing is that it presents a "security loophole" and it erroneous illusion of strong policies. In other words, a bad guy could use a HARDFAIL (-ALL) or SOFTFAIL (~ALL) to give the appearance of a strong exclusive policy allowing for rejection, but then intentionally embeds an invalid syntax error. If we relaxed the protocol with an PERMERROR fallbacks to a NEUTRAL result (possibly overriding the DOMAIN policy) then it become a potential security loophole to preemption, skipping or indeterminate (no result) condition, and the mail is accepted (after perhaps it passes any other testings, if any). IMV, this is an implementation design to consider and how it could be offered to deployments. That package you mentioned used a STRICT, MODERATE, RELAXED concept. I don't think this is general protocol material, but it could be information (not specifically this way) that can be provided as insight in 4408BIS. But lets remember that ABUSE is also not just the user but also the receiver getting slammed with malicious abusive spoofers. What will you do if it was a bad guy with syntax errors? Accept the mail? Even in SMTP, there are software that have a strict or relayed 821 compliance level or 2821 or 5321. That is why it more interesting to find out if there some particular issue with SPF syntax processing that can false positives. But if this is a matter of "lazy" software, well, thats not our fault. In SMTP, for mail form, technically, there is no space after the colon and before the left angle bracket. MAIL FROM:
# VALID: No space after the colon Having a space is a SMTP syntax violation. Yet, here is a history to be relaxed here to accept the form with a space: MAIL FROM:
# INVALID: space after the colon Some SMTP software may enforce this strict rule. Is there anything in SPF that can cause a PERMERROR in this similar manner? Where it can be too STRICT and needs to be RELAXED? -- HLS From W.Doust@racingvictoria.net.au Tue Jul 31 21:39:00 2012 Return-Path: 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 500C321F87E8 for ; Tue, 31 Jul 2012 21:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 xDES+FZ6AY9Z for ; Tue, 31 Jul 2012 21:38:59 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id A078321F87E7 for ; Tue, 31 Jul 2012 21:38:58 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 9558) id ; Wed, 01 Aug 2012 14:38:57 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2012 14:36:20 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B67@XCHANGE.rvl.internal> In-Reply-To: <2356084.rOqJxuchnj@scott-latitude-e6320> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1vml/gLzrN6bOFS12ZHSdmUf4FgQAARIyg References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal><1472908.4zQmik4QZ7@scott-latitude-e6320><0D2A0D5F64179F4F9556D3DEDE39F9AF01027B4F@XCHANGE.rvl.internal> <2356084.rOqJxuchnj@scott-latitude-e6320> From: "Wayne Doust" To: "Scott Kitterman" , Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 04:39:00 -0000 I'll restrict my comments to PermErrors. > With one exception, RFC 4408 doesn't specify receiver policy. The furthest is goes is to say, if you do X, then do it this way. That's significantly different than what I think you are suggesting. Currently, there is no recommendation for PermErrors at all. I think it should be clearly stated that PermErrors should be treated as no worse than None. >> Basically. As in section 2.5.5 - which recommends that treating it as >> "greylisted" is the most extreme method of treating The response. Why >> should TEMPERROR or PERMERROR be treated more harshly than Softfail? > That's a matter for local policy, not protocol in the RFC 4408 design and I don't think we should change that. That doesn't seem to be a problem for 2.5.2 and 2.5.5 =20- A "Neutral" result MUST be treated exactly like the "None" result=20 =20- A "SoftFail" result should be treated as somewhere between a "Fail" =20 and a "Neutral". I'm advocating similar wording for 2.5.7.=20 > Those are properly temperrors, which is why they get 45X responses. 45X is not a reject, it's a deferral. So not a permerror. However the deferrals just go on and on... the email is still never delivered. In most cases, 45x is the most extreme result given. This is what I mean. You don't 45x on a SoftFail. The spec even says that if you do this, only do it once. Why treat a PermError more harshly than a SoftFail? It's not good enough to say it's local choice because the spec doesn't even give a recommendation when it does do so for Softfail and Neutral? With a recommendation it is still a local choice even if the word SHOULD is used. > Having two SPF record is a permerror. That's not a permerror due to local DNS parsing. It's a permerror due to bad record publishing. Okay, they publish a bad SPF record. So the default for many sites is to block their email on the basis of SPF? The correct way to deal with this should be to treat it as though they have no published record. > I agree that temperrors can happen due to bad DNS on the receiver side, but not permerror. These two get lumped in together an awful lot. In many cases, the SPF Failure reason is not given or is simply ambiguous. > Ironically, the one piece of receiver poilcy in RFC 4408 is that Neutral MUST be treated the same as None. I think the fact that you're suggesting that perhaps the one place where receiver policy is specified should be changed should be an indicator of the folly of trying to do so even more. I'm suggesting that SHOULD is the appropriate mechanism. Logically, any site publishing an SPF record should not be punished for either of the two situations: 1) They publish a bad SPF record.=20 2) The receiver can't correctly parse a good SPF record. In either case, it seems to me sensible that they should treat the domain as having no SPF record rather than issuing a 45x or 550.=20 To go one step further, a recommendation would be to reject email once with a 45x with the message "Your SPF record is incorrect. Please advise your systems administrators to fix it." And then accept it a second time. This recommendation is not without precedent. A similar recommendation is found in section 2.5.5: =20 ... the receiving MTA could give the sender a =20 message using a technique called "greylisting" whereby the MTA can =20 issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the =20 first time the message is received, but accept it the second time. *************************************************************************= ******************************* Disclaimer: This email message and any attachments are confidential. =20 The information contained in this email message and any attachments may b= e=20 confidential information. If you are not the intended recipient, any use,= =20interference with,=20 disclosure or copying of this material is unauthorised and prohibited. This email and any attachments are also subject to copyright. =20 No part of them may be reproduced, adapted or transmitted without the wri= tten permission of the copyright owner. If you have received this email in error please immediately advise the se= nder=20 by return email and delete the message from your system.=20 Although this email has been checked for viruses and other defects, no re= sponsibility=20 can be accepted for any loss or damage arising from its receipt or use. Racing Victoria Limited respects your privacy. Our privacy policy can be = accessed=20 from our web site: "http://www.racingvictoria.net.au" *************************************************************************= ******************************* From W.Doust@racingvictoria.net.au Tue Jul 31 22:09:59 2012 Return-Path: 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 5D05121F8474 for ; Tue, 31 Jul 2012 22:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.54 X-Spam-Level: X-Spam-Status: No, score=-1.54 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 KSLJqQLwoFF5 for ; Tue, 31 Jul 2012 22:09:58 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 893CF21F8750 for ; Tue, 31 Jul 2012 22:09:49 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 9558) id ; Wed, 01 Aug 2012 15:09:49 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 1 Aug 2012 15:09:37 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B6E@XCHANGE.rvl.internal> In-Reply-To: <5018AE61.4010202@isdg.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1vnOj6Zog9TvNZSiO+SB4sI8FEkgAAuJPw References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal><3725056.uMTa6O8Y0m@scott-latitude-e6320><0D2A0D5F64179F4F9556D3DEDE39F9AF01027B0B@XCHANGE.rvl.internal> <1472908.4zQmik4QZ7@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B4F@XCHANGE.rvl.internal> <5018AE61.4010202@isdg.net> From: "Wayne Doust" To: "Hector Santos" Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 05:09:59 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpJbiBvdGhlciB3b3JkcywgYSBiYWQgZ3V5 IGNvdWxkIHVzZSBhIEhBUkRGQUlMICgtQUxMKSBvciBTT0ZURkFJTA0KKH5BTEwpIHRvIGdpdmUg dGhlIGFwcGVhcmFuY2Ugb2YgYSBzdHJvbmcgZXhjbHVzaXZlIHBvbGljeSBhbGxvd2luZyBmb3Ig cmVqZWN0aW9uLCBidXQgdGhlbiBpbnRlbnRpb25hbGx5IGVtYmVkcyBhbiBpbnZhbGlkIHN5bnRh eCBlcnJvci4gDQogIElmIHdlIHJlbGF4ZWQgdGhlIHByb3RvY29sIHdpdGggYW4gUEVSTUVSUk9S IGZhbGxiYWNrcyB0byBhIE5FVVRSQUwgcmVzdWx0IChwb3NzaWJseSBvdmVycmlkaW5nIHRoZSBE T01BSU4gcG9saWN5KSB0aGVuIGl0IGJlY29tZSBhIHBvdGVudGlhbCBzZWN1cml0eSBsb29waG9s ZSB0byBwcmVlbXB0aW9uLCBza2lwcGluZyBvciBpbmRldGVybWluYXRlIChubyByZXN1bHQpIGNv bmRpdGlvbiwgYW5kIHRoZSBtYWlsIGlzIGFjY2VwdGVkIChhZnRlciBwZXJoYXBzIGl0IHBhc3Nl cyBhbnkgb3RoZXIgdGVzdGluZ3MsIGlmIGFueSkuDQotLS0tLQ0KDQpJIGRvbid0IHNlZSBob3cg dGhpcyBmb2xsb3dzLiBUaGUgIkJhZCBHdXkiIHdvdWxkIGhhdmUgdG8gb3duIHRoZSBkb21haW4g YW5kIHB1Ymxpc2ggdGhlIFNQRiByZWNvcmQuIEEgYmFkIGd1eSB3aXRoIGFuIGludmFsaWQgU1BG IHJlY29yZCBpcyBpbiBhIHdvcnNlIHBvc2l0aW9uIHRoYW4gYSAiQmFkIEd1eSIgd2l0aCBhIHZh bGlkIFNQRiByZWNvcmQuDQoNCg0KPiBCdXQgbGV0cyByZW1lbWJlciB0aGF0IEFCVVNFIGlzIGFs c28gbm90IGp1c3QgdGhlIHVzZXIgYnV0IGFsc28gdGhlIHJlY2VpdmVyIGdldHRpbmcgc2xhbW1l ZCB3aXRoIG1hbGljaW91cyBhYnVzaXZlIHNwb29mZXJzLg0KDQpUaGlzIGlzIE9ULCBidXQgdGhl IG9ubHkgY2FzZSB3aGVyZSBJIHNlZSB0aGlzIGFwcGxpZXMgaXMgcHVibGlzaGluZyBhIGNvc3Rs eSBTUEYgcmVjb3JkIGFuZCB0aGVuIHNwYW1taW5nIHBvc3NpYmx5IGNhdXNpbmcgRE9TLg0KDQo+ IFdoYXQgd2lsbCB5b3UgZG8gaWYgaXQgd2FzIGEgYmFkIGd1eSB3aXRoIHN5bnRheCBlcnJvcnM/ ICBBY2NlcHQgdGhlIG1haWw/DQoNClRyZWF0IHRoZW0gYXMgYSBiYWQgZ3V5IHdpdGggbm8gU1BG IHJlY29yZC4gSSBkb24ndCBzZWUgbWFueSBiYWQgYnV5cyBXSVRIIFNQRiByZWNvcmRzICh5ZXQp Lg0KDQo+IElzIHRoZXJlIGFueXRoaW5nIGluIFNQRiB0aGF0IGNhbiBjYXVzZSBhIFBFUk1FUlJP UiBpbiB0aGlzIHNpbWlsYXIgbWFubmVyPyAgV2hlcmUgaXQgY2FuIGJlIHRvbyBTVFJJQ1QgYW5k IG5lZWRzIHRvIGJlIFJFTEFYRUQ/DQoNClRoZSBncmFtbWFyIGZvciBTUEYgaXMgcXVpdGUgc3Ry b25nLiBIb3dldmVyIElNRSwgdGhlcmUgYXJlIG1haWwgc2Nhbm5pbmcgImRldmljZXMiIHRoYXQg aGF2ZSBjaG9rZWQgb24gcHJvcGVyIFNQRiBlbnRyaWVzLg0KDQoNCg0KDQoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KRGlzY2xhaW1lcjogVGhpcyBlbWFp bCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbC4gICANClRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlbWFpbCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNo bWVudHMgbWF5IGJlIA0KY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgdXNlLCBpbnRlcmZlcmVuY2Ugd2l0aCwgDQpkaXNj bG9zdXJlIG9yIGNvcHlpbmcgb2YgdGhpcyBtYXRlcmlhbCBpcyB1bmF1dGhvcmlzZWQgYW5kIHBy b2hpYml0ZWQuDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGFsc28gc3ViamVj dCB0byBjb3B5cmlnaHQuICANCk5vIHBhcnQgb2YgdGhlbSBtYXkgYmUgcmVwcm9kdWNlZCwgYWRh cHRlZCBvciB0cmFuc21pdHRlZCB3aXRob3V0IHRoZSB3cml0dGVuDQpwZXJtaXNzaW9uIG9mIHRo ZSBjb3B5cmlnaHQgb3duZXIuDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBpbW1lZGlhdGVseSBhZHZpc2UgdGhlIHNlbmRlciANCmJ5IHJldHVybiBlbWFp bCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGZyb20geW91ciBzeXN0ZW0uIA0KQWx0aG91Z2ggdGhp cyBlbWFpbCBoYXMgYmVlbiBjaGVja2VkIGZvciB2aXJ1c2VzIGFuZCBvdGhlciBkZWZlY3RzLCBu byByZXNwb25zaWJpbGl0eSANCmNhbiBiZSBhY2NlcHRlZCBmb3IgYW55IGxvc3Mgb3IgZGFtYWdl IGFyaXNpbmcgZnJvbSBpdHMgcmVjZWlwdCBvciB1c2UuDQpSYWNpbmcgVmljdG9yaWEgTGltaXRl ZCByZXNwZWN0cyB5b3VyIHByaXZhY3kuIE91ciBwcml2YWN5IHBvbGljeSBjYW4gYmUgYWNjZXNz ZWQgDQpmcm9tIG91ciB3ZWIgc2l0ZTogImh0dHA6Ly93d3cucmFjaW5ndmljdG9yaWEubmV0LmF1 Ig0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg== From spf2@kitterman.com Tue Jul 31 23:12:05 2012 Return-Path: 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 2AA2B21F867E for ; Tue, 31 Jul 2012 23:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 HoIgTeA5f5Ww for ; Tue, 31 Jul 2012 23:12:03 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BF17021F867F for ; Tue, 31 Jul 2012 23:12:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B0DCB20E4085; Wed, 1 Aug 2012 02:12:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343801522; bh=Z+X2EcxUk85d753aKAMvYZcwv6dPceOtnATUSm8aT6Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KXW/jAT32tTCa9lkG1qxIdL0lD+eTSJaFcSspFan00oDNTw7OgkWR7eO1BO90aRAt eKIHGvxvXizw089cZDSLtLWYtWNbMK/FH5FeBv7vQ9zuUYEVjT150thXMMtlinwaaX sOtqmnOpRpxM4kHfrwE93E9emL95WttRSYAhyTBo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8967420E4079; Wed, 1 Aug 2012 02:12:02 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 01 Aug 2012 02:12:01 -0400 Message-ID: <1973063.dZIxepSB2u@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B67@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <2356084.rOqJxuchnj@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B67@XCHANGE.rvl.internal> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 06:12:05 -0000 On Wednesday, August 01, 2012 02:36:20 PM Wayne Doust wrote: > I'll restrict my comments to PermErrors. > > > With one exception, RFC 4408 doesn't specify receiver policy. The > > furthest is goes is to say, if you do X, then do it this way. That's > > significantly different than what I think you are suggesting. > > Currently, there is no recommendation for PermErrors at all. I think it > should be clearly stated that PermErrors should be treated as no worse > than None. The original name for permerror was "unknown". It's been a matter of some discussion in the SPF community about what the best approach is. If you teat it like None, then bad records persist. The theory behind reject is then the problem gets noticed and fixed. The difference between a temperror and a permerror is that permerrors can't be fixed without an operator making a change, so there's value to not just depending on people reading their mail logs (which apparently almost no one bothers to do). I've distributed software for over half a decade that defaults to reject on permerror with no complaints about it. It also initially defaulted to deferring on temperror, but that caused problems and got complaints, so I changed it. > >> Basically. As in section 2.5.5 - which recommends that treating it as > >> "greylisted" is the most extreme method of treating The response. Why > >> should TEMPERROR or PERMERROR be treated more harshly than Softfail? That is purely an example. Receivers can treat softfail more harshly than none/neutral in whatever way they think makes sense. > > That's a matter for local policy, not protocol in the RFC 4408 design > > and I don't think we should change that. > > That doesn't seem to be a problem for 2.5.2 and 2.5.5 > > - A "Neutral" result MUST be treated exactly like the "None" result That's the one exception to the no receiver policy rule. It makes sense to require treating ?all the same as no record so that senders aren't punished for publishing partial records. For organizations of any size it can be quite complex to get everything figured out. This is much different than the basic syntax and DNS operations errors that permerror and temperror address. > - A "SoftFail" result should be treated as somewhere between a "Fail" > and a "Neutral". > > I'm advocating similar wording for 2.5.7. The softfail wording doesn't give any operational guidance. Only 2.5.2 affects the protocol design and specifies what receivers SHOULD do. That's there for a very specific reason to avoid discouraging deployment that I don't think applies to any other results. > > Those are properly temperrors, which is why they get 45X responses. > > 45X is not a reject, it's a deferral. So not a permerror. > > However the deferrals just go on and on... the email is still never > delivered. In most cases, 45x is the most extreme result given. Some temperrors resolve themselves. Some don't. This is a problem that we have an open issue to try and address. If they really take operator intervention to fix, they should be permerrors not temperrors. We have some words in the draft that try to address this by suggesting that receivers may want to keep state and treat persistent temperrors as permerrors instead. Whether they are then accepted or rejected, I think it's better than staying in the queue for the life of the queue and then being rejected. > This is what I mean. You don't 45x on a SoftFail. The spec even says > that if you do this, only do it once. Why treat a PermError more harshly > than a SoftFail? It's not good enough to say it's local choice because > the spec doesn't even give a recommendation when it does do so for > Softfail and Neutral? With a recommendation it is still a local choice > even if the word SHOULD is used. The spec only gives the greylisting idea as an example. It's completely non- normative. The spec really doesn't give a recommendation for softfail other than between neutral/none and fail, which is extremely broad and in my opinion meaningless. If faced with a choice between removing the rule that neutral has to be treated like none and extending receiver policy guidance to the rest of the results, I'd prefer removing it for none (not that I think it's a good idea). I can tell you that none == neutral is probably the most ignored item in RFC 4408. It simply doesn't help to write in an RFC what receivers HAVE to do. They won't. > > Having two SPF record is a permerror. That's not a permerror due to > > local DNS parsing. It's a permerror due to bad record publishing. > > Okay, they publish a bad SPF record. So the default for many sites is to > block their email on the basis of SPF? > > The correct way to deal with this should be to treat it as though they > have no published record. People have different opinions on this. You aren't the only one that thinks that. > > I agree that temperrors can happen due to bad DNS on the receiver > > side, but not permerror. > > These two get lumped in together an awful lot. In many cases, the SPF > Failure reason is not given or is simply ambiguous. In the cases you've given, it's been you that lumped them together despite clearly identifiable unambiguous reasons for failure. I haven't seen a lot of trouble with this, so I'm not sure your generalizations are correct. > > Ironically, the one piece of receiver poilcy in RFC 4408 is that > > Neutral MUST be treated the same as None. I think the fact that you're > > suggesting that perhaps the one place where receiver policy is specified > > should be changed should be an indicator of the folly of trying to do so > > even more. > > I'm suggesting that SHOULD is the appropriate mechanism. > > Logically, any site publishing an SPF record should not be punished for > either of the two situations: > > 1) They publish a bad SPF record. > 2) The receiver can't correctly parse a good SPF record. > > In either case, it seems to me sensible that they should treat the > domain as having no SPF record rather than issuing a 45x or 550. > > To go one step further, a recommendation would be to reject email once > with a 45x with the message "Your SPF record is incorrect. Please advise > your systems administrators to fix it." And then accept it a second > time. This recommendation is not without precedent. A similar > recommendation is found in section 2.5.5: > > ... the receiving MTA could give the sender a > message using a technique called "greylisting" whereby the MTA can > issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the > first time the message is received, but accept it the second time. Users don't generally see the 45X message. It only goes in the mail log. After some period, users might get warned. In the case of postfix, the MTA with which I'm most familiar, the default is 4 days. Deferring once only helps if the sender is reading mail logs closely. Senders that do that are not, in my experience, the ones likely to have broken setups. It's true that a temperror can be caused by broken DNS at the receiver. I still don't see any examples of a case where anything other than the sender screwing up can cause a permerror. I think you need to go back and reconsider again as you're still mixing temperror and permerrror. Scott K From spf2@kitterman.com Tue Jul 31 23:14:51 2012 Return-Path: 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 40ABA21F867E for ; Tue, 31 Jul 2012 23:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 75z97o8ym8aq for ; Tue, 31 Jul 2012 23:14:50 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3696521F8620 for ; Tue, 31 Jul 2012 23:14:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B6B2B20E4085; Wed, 1 Aug 2012 02:14:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1343801689; bh=eiKYgA/vGV33BcwtC7j3H0LlxYUcuZXIA+Necia/abk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PcQx2sG7AffxoE5GELX0M6RS0yM7coZ3/2JvlJ6WMot3e4TVDJWUJsi3APhYMb5Rl TeC0lGUUT39c1V4NIXxpRQLb7Gk8/rBvCFVKg6TfbrVyLnV3E/6gU+jtZ3Z9kDXEC1 bP5p4ayFd9pLkg8tCCnaSohZgkNqnlbW53XpSZBg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8C4FA20E4079; Wed, 1 Aug 2012 02:14:49 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 01 Aug 2012 02:14:48 -0400 Message-ID: <1627591.RxK7Tpjk7J@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B6E@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <5018AE61.4010202@isdg.net> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B6E@XCHANGE.rvl.internal> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 06:14:51 -0000 On Wednesday, August 01, 2012 03:09:37 PM Wayne Doust wrote: > -----Original Message----- > In other words, a bad guy could use a HARDFAIL (-ALL) or SOFTFAIL > (~ALL) to give the appearance of a strong exclusive policy allowing for > rejection, but then intentionally embeds an invalid syntax error. If we > relaxed the protocol with an PERMERROR fallbacks to a NEUTRAL result > (possibly overriding the DOMAIN policy) then it become a potential security > loophole to preemption, skipping or indeterminate (no result) condition, > and the mail is accepted (after perhaps it passes any other testings, if > any). ----- > > I don't see how this follows. The "Bad Guy" would have to own the domain and > publish the SPF record. A bad guy with an invalid SPF record is in a worse > position than a "Bad Guy" with a valid SPF record. > > But lets remember that ABUSE is also not just the user but also the > > receiver getting slammed with malicious abusive spoofers. > This is OT, but the only case where I see this applies is publishing a > costly SPF record and then spamming possibly causing DOS. > > What will you do if it was a bad guy with syntax errors? Accept the mail? > > Treat them as a bad guy with no SPF record. I don't see many bad buys WITH > SPF records (yet). > > Is there anything in SPF that can cause a PERMERROR in this similar > > manner? Where it can be too STRICT and needs to be RELAXED? > The grammar for SPF is quite strong. However IME, there are mail scanning > "devices" that have choked on proper SPF entries. Yes. There is buggy software on the Internet. This is not a surprise. Part of what we're trying to do in this working group is to make RFC4408bis more useful for producing more correct implementations that RFC4408. Improved clarity is a good thing. There will still be bugs. We can't design protocol around bugs. Scott K