From nobody Sun Jul 22 12:25:04 2018 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B1E130FFA for ; Sun, 22 Jul 2018 12:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4K5qKs7T2c3L for ; Sun, 22 Jul 2018 12:25:01 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FDE130FF5 for ; Sun, 22 Jul 2018 12:25:00 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l189-v6so6115381ywb.10 for ; Sun, 22 Jul 2018 12:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:from:subject:date:importance; bh=mj4j6qnF9GaqiTnobDo/fBSPY16aEUjineZmnxfeQy8=; b=TIRMmZt2s1ANuwyO3aZFJ33ZD09yLyreY9x1WAopMXEEw47xRB1/xnxySOui9PwcpX 4yewvqqLlUqDP11999cMa34EGj0a/zXJMULUNYlh/MCMfRiMUgchiEleXE1kjiK0WvAF x+I7A1P1nHyaZ1KLbq246Z4hC/LAOWMjdUC3OcnSgXseBSVTU9Rx45DUsBXOoecmz9b0 ra49LcJVKWbTzXb1x198micC97LvXa/QcyHOXe/k3q1g63StO7pMK4GtI9h/eQstPPDg n9N0JZnE1CEk5F/tz2oYSmIv0CI7u0o8/iUR5GIqlA6JIcJWszClfk1avhgZUSkzdb0/ i9Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance; bh=mj4j6qnF9GaqiTnobDo/fBSPY16aEUjineZmnxfeQy8=; b=IPxrKasZNVBhM5HXePhCcuNIIKB9DCGU55XnziCkEwaJl4z79+xy8wEgU6CWYWtJRu KtL4NTfZAGijIMGv0shwo8HtaBNFa7NrUxdBbKox+dIbAdp9fLRjHwqyBGY0scmqiv7b oUKjgQUaqi0vA1U2XMlpAoQuFBgmBTVJoxJIeknqpdoLXcEAE2xNjTheQLKjfTPlnYqf +hh6lJjs3hZ2l5Xyuc7J/Y7Q6OWmcFRbDfrDcUXJSi1FNDV2A65yQMZUENCTnKEd/VMx UWNAutgrzGyfxpG8Wf1wRYKZP9beNLJnUH769Ge4z9WXRulMAPEND2qGi/nJ9MLLjSf1 zWgw== X-Gm-Message-State: AOUpUlFgZVIH72SF2dEs+5NulF0mNRkSqUEfQEmLC3+5tpFQn83n/hsV /wr7ZoDw1KNCy/w1mg32doQfPCfx X-Google-Smtp-Source: AAOMgpcMIAyMyQBzUl5Jm1DK8m5wWvkzwwh4jujs9ym9Le0NwN21Ez8+jl42C0pEaVeFKsVSwyb9Lw== X-Received: by 2002:a0d:f245:: with SMTP id b66-v6mr5361381ywf.473.1532287500038; Sun, 22 Jul 2018 12:25:00 -0700 (PDT) Received: from ?IPv6:2601:192:4e00:596:22:8b71:4eb9:6006? ([2601:192:4e00:596:22:8b71:4eb9:6006]) by smtp.gmail.com with ESMTPSA id b11-v6sm7090095ywa.46.2018.07.22.12.24.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 12:24:59 -0700 (PDT) Message-ID: <5b54da0b.1c69fb81.14020.81f2@mx.google.com> MIME-Version: 1.0 To: "spfbis@ietf.org" From: Peter Occil Date: Sun, 22 Jul 2018 15:24:59 -0400 Importance: normal X-Priority: 3 Content-Type: multipart/alternative; boundary="_C160E97F-C391-49DE-B049-B7AFE8739D72_" Archived-At: Subject: [spfbis] Question regarding RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 19:25:03 -0000 --_C160E97F-C391-49DE-B049-B7AFE8739D72_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" RFC 7208 includes the following ABNF for the Received-SPF header field: header-field =3D "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF As specified, however, this ABNF doesn't allow a header field value like re= sult-FWS-comment with no FWS or key-value-list following it, a header field= value which occurs very often in Received-SPF header fields I see in pract= ice. (Note that FWS must contain at least one white space.) An ABNF like the following would better follow practice in implementations. header-field =3D "Received-SPF:" [CFWS] result [ FWS comment ] [ FWS key-value-list ] [FWS] CRLF Is a header field parser allowed to be so robust as to use the latter ABNF = to parse the Received-SPF header field? Is a correction to use that ABNF w= ithin the scope of an erratum to RFC 7208? (In addition, many cases I've seen include an IPv6 address in the client-ip= parameter, which includes colons, without that address being a "quoted-str= ing" or fitting the production "dot-atom". But this issue can wait until I= get answers on the main issue I raised in this message.) --Peter --_C160E97F-C391-49DE-B049-B7AFE8739D72_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

RFC 7208 includes the following ABNF= for the Received-SPF header field:

 

=C2=A0=C2=A0=C2=A0 header-field=C2=A0=C2=A0=C2= =A0=C2=A0 =3D "Received-SPF:" [CFWS] result FWS [comment FWS]

=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 [ key-value-list ] CRLF

=  

As specified, however, this ABNF doesn= 't allow a header field value like result-FWS-comment with no FWS or key-va= lue-list following it, a header field value which occurs very often in Rece= ived-SPF header fields I see in practice.=C2=A0 (Note that FWS must contain= at least one white space.)

 

An ABNF like the following would better follow practice = in implementations.

 

=C2=A0=C2=A0=C2=A0 header-field=C2=A0=C2=A0=C2=A0=C2=A0 =3D &q= uot;Received-SPF:" [CFWS] result [ FWS comment ]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 [ FWS key-value-list ] [FWS] CRLF

 

Is a header field parser allowed to be so robu= st as to use the latter ABNF to parse the Received-SPF header field?=C2=A0 = Is a correction to use that ABNF within the scope of an erratum to RFC 7208= ?

 

(In add= ition, many cases I've seen include an IPv6 address in the client-ip parame= ter, which includes colons, without that address being a "quoted-strin= g" or fitting the production "dot-atom".=C2=A0 But this issu= e can wait until I get answers on the main issue I raised in this message.)=

 

--Peter<= /p>

= --_C160E97F-C391-49DE-B049-B7AFE8739D72_-- From nobody Sun Jul 22 13:08:20 2018 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6937A130EC6 for ; Sun, 22 Jul 2018 13:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=zSlnsWlz; dkim=pass (1536-bit key) header.d=taugh.com header.b=AsVmYKnt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7ixfKffBaqx for ; Sun, 22 Jul 2018 13:08:17 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D62131002 for ; Sun, 22 Jul 2018 13:08:16 -0700 (PDT) Received: (qmail 74380 invoked from network); 22 Jul 2018 20:08:15 -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; s=1228a.5b54e42f.k1807; bh=m7GDH5KuSpTwInCJRh+t6wQWSc5Fd/ePa4d/yFYFLfU=; b=zSlnsWlzBOSXaBxS11HB+0JciTOvZ6BQBPQHny8rKkI//l8UWmkU7AKLhXhZgxnLu68IOzj9wRCM3xqmNc+7YoIT0g3+0tZ1v6xq7MDfd3UiiAAUj/904hcmUWevRlJofbUV1sjSRsh5GexYM4v955mjB8K8+yKSzw43iZq259mmCLUniDLc3lkjtd4jLeC8Sg3ju3VeaDQfNdP2stzzKO8CA9+3Y4QSO53+hfptJXoXWknoWrggqwcARr5BJDzL 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; s=1228a.5b54e42f.k1807; bh=m7GDH5KuSpTwInCJRh+t6wQWSc5Fd/ePa4d/yFYFLfU=; b=AsVmYKnts+sIdQJWZvn9QHuuO9DsNmm0LMMXjeCh0oq5+kZi0jvN95fOPuyRom4p+/Zk1dDNZ+Kk4qph6Cr6T1zWM2BGjWtWwCYslOv0MSCKMrJVXf35KyuzK6Wj1aRhYxy8mSsUXYzF0LGDt0VIG8HEG80Aq18XcUloiWdPn51qJAZnjd2zI6rD07XA11BbqB0B9AwKQF6V6ZB1us6Zh+Jl3xM/g2Osqlrxkspo4ACCMNLt7uUvoFmxRc5KUdUV Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 22 Jul 2018 20:08:15 -0000 Received: by ary.qy (Postfix, from userid 501) id 1E20220028DCC1; Sun, 22 Jul 2018 16:08:14 -0400 (EDT) Date: 22 Jul 2018 16:08:14 -0400 Message-Id: <20180722200815.1E20220028DCC1@ary.qy> From: "John Levine" To: spfbis@ietf.org Cc: poccil14@gmail.com In-Reply-To: <5b54da0b.1c69fb81.14020.81f2@mx.google.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [spfbis] Question regarding RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 20:08:18 -0000 In article <5b54da0b.1c69fb81.14020.81f2@mx.google.com> you write: >An ABNF like the following would better follow practice in implementations. > > header-field = "Received-SPF:" [CFWS] result [ FWS comment ] > [ FWS key-value-list ] [FWS] CRLF While we can have a theological argument about whether the problem is that the spec doesn't describe the protocol or the programmers didn't follow the spec, I agree that this ABNF seems more likely to match what people would consider to be reasonable syntax. >Is a header field parser allowed to be so robust as to use the latter ABNF to parse the Received-SPF header field? Is a correction to use that ABNF within the scope of an erratum to RFC 7208? We are not the protocol police. You can do whatever you want. Adjusting your code to handle common benign sender mistakes is often a good idea. >(In addition, many cases I've seen include an IPv6 address in the client-ip parameter, which includes colons, without that address being a "quoted-string" >or fitting the production "dot-atom". But this issue can wait until I get answers on the main issue I raised in this message.) I think that's a bug in the spec, due to forgetting that dot-atom doesn't include colons. R's, John From nobody Mon Jul 23 09:32:44 2018 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBC7130EA7 for ; Mon, 23 Jul 2018 09:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2S7wyoB16bVx for ; Mon, 23 Jul 2018 09:32:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFA1129385 for ; Mon, 23 Jul 2018 09:32:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9A308B81350; Mon, 23 Jul 2018 09:32:32 -0700 (PDT) To: scott@kitterman.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, sm+ietf@elandsys.com, ajs@anvilwalrusden.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: poccil14@gmail.com, spfbis@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180723163232.9A308B81350@rfc-editor.org> Date: Mon, 23 Jul 2018 09:32:32 -0700 (PDT) Archived-At: Subject: [spfbis] [Technical Errata Reported] RFC7208 (5436) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 16:32:42 -0000 The following errata report has been submitted for RFC7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5436 -------------------------------------- Type: Technical Reported by: Peter Occil Section: GLOBAL Original Text ------------- header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF Corrected Text -------------- header-field = "Received-SPF:" [CFWS] result [ FWS comment ] [ FWS key-value-list ] [FWS] CRLF Notes ----- As specified, this ABNF doesn't allow a header field value like result-FWS-comment with no FWS or key-value-list following it, a header field value which occurs very often in Received-SPF header fields I see in practice. (Note that FWS must contain at least one white space.) The corrected ABNF better follows practice in implementations. Instructions: ------------- This erratum 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 can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7208 (draft-ietf-spfbis-4408bis-21) -------------------------------------- Title : Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Publication Date : April 2014 Author(s) : S. Kitterman Category : PROPOSED STANDARD Source : SPF Update Area : Applications Stream : IETF Verifying Party : IESG From nobody Tue Jul 24 20:17:14 2018 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E80E130F84; Tue, 24 Jul 2018 20:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6gBRjgqzCzs; Tue, 24 Jul 2018 20:17:10 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0EDE130F66; Tue, 24 Jul 2018 20:17:09 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id q129-v6so2358225ywg.8; Tue, 24 Jul 2018 20:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=IUiVG+MkICAFv043J5sfFKD+3xx9trjkQoCZwHWrQ7U=; b=MfKa2eaRk6zBmQ2mmmLfbQCVaaU2NgFRC1Ln66EgWC0VhQrQxMYSId8s1xruVAsEC3 ME0Jj1QGhSNYtgfDPhHj3u2qXub64QOs+i1HjoILNLlNYOPFUdFJShaEfSYj6B28bGQa S8W5/7FGH1mLFdePqejshrozKOkU0qd5miSz1H9OW22nVy2pBvlA3Q41uvSUgV+DsUk4 7lTre/TN7CvgoCySRqTbGbXJxKSmSN58l5wuanalMURT56/jPOI9fFi+1xBkxOG4ketk c5jpqpKdXf94VYsCLyKSyVGh4lue/sRUBOp9ueZQYdoKeLI5GdOo6NxmFcD7nTdImXDX PEuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=IUiVG+MkICAFv043J5sfFKD+3xx9trjkQoCZwHWrQ7U=; b=sUUuwvtjgo9MNU0YrU4q4a8lzCrIM5gq7LJqwIRTcSLHQ303L5NPqYlqVo2PMEL7rQ IgYx6hEKDgqVwsz76Z/1CP2lhEnuj6qc7d9H0oy2O1ku7Cvi5cOf9M7fCGnvo8bEF6Gj nh+l53zSDm6eMlEEELszve/2PL1LIkKlKLg2143V1g8LTs6Jkjoji8UShV4j3cF3ucEy ZVUDc0+c0LpDa+iErvfeWFKfjUjoy3opfBpIEOJWNLukgHtkPm5K+iHVa12ztZR07xSq CC1ksO2xIvL3ZXMGv/tAvedgOMOeUBhrhGSbmgVYXVlnX/YyNXF2kKl2pN4QNV2LVaAf 3TpA== X-Gm-Message-State: AOUpUlHG9XZYcyRHfkEXf8+sSy7pYuhRH5zaI30uLvVe1EOWvQ1GTu0V vPlaFg/mts44n4UgKvjv4dvBt6UXIW0= X-Google-Smtp-Source: AAOMgpc1zhkYufNhXWJy2i/Y4SryDlY3M7gG5yNyINmeqULp5NLvfJIaRgozwR6RgEAXMmS7F9amig== X-Received: by 2002:a81:e301:: with SMTP id q1-v6mr10762917ywl.499.1532488628807; Tue, 24 Jul 2018 20:17:08 -0700 (PDT) Received: from ?IPv6:2601:192:4e00:596:22:8b71:4eb9:6006? ([2601:192:4e00:596:22:8b71:4eb9:6006]) by smtp.gmail.com with ESMTPSA id n66-v6sm10660810ywn.77.2018.07.24.20.17.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jul 2018 20:17:08 -0700 (PDT) Message-ID: <5b57ebb4.1c69fb81.6780d.c349@mx.google.com> MIME-Version: 1.0 To: "ietf-822@ietf.org" Cc: "dmarc@ietf.org" , "spfbis@ietf.org" From: Peter Occil Date: Tue, 24 Jul 2018 23:17:08 -0400 Importance: normal X-Priority: 3 In-Reply-To: <5b569cf1.1c69fb81.faa6a.8e55@mx.google.com> References: <5b569cf1.1c69fb81.faa6a.8e55@mx.google.com> Content-Type: multipart/alternative; boundary="_2FF26A6A-47FD-4B50-A24C-2E5003C5B5E4_" Archived-At: Subject: Re: [spfbis] Most common mail header fields seen with nonsyntactic values X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 03:17:13 -0000 --_2FF26A6A-47FD-4B50-A24C-2E5003C5B5E4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Adding additional mailing lists because three header fields listed below (R= eceived-SPF, Authentication-Results, Arc-Authentication-Results) are within= their scope. --Peter From: Peter Occil Sent: Monday, July 23, 2018 11:28 PM To: ietf-822@ietf.org Subject: Most common mail header fields seen with nonsyntactic values The following is a list of email header fields where I find a significant p= roportion of those fields in practice using a different form from the docum= ented syntax of those fields. This list is, for the moment, for your information only.=C2=A0 Whether the = documents defining the header fields listed below should be updated (whethe= r to accommodate how those fields are used in practice or otherwise), or wh= at error handling a program should use if it encounters any of these header= fields, are matters that require further discussion.=C2=A0 (In one case, t= he note in RFC 5322 provides guidance on error handling, but in many other = cases, those documents don't seem to suggest or require any particular erro= r-handling behavior.) ARC-Authentication-Results. Some nonsyntactic values of this header field contain a "header.b" paramete= r value containing a slash, which cannot occur in a "pvalue". Authentication-Results. Many nonconforming Authentication-Results values are of an unusual form tha= t I've already reported elsewhere, in the "dmarc" mailing list.=C2=A0 Unlik= e most of the other forms I report here, this one may be truly nonconformin= g. Other nonsyntactic Authentication-Results values-- - don't mention the domain name of the authentication server (they generall= y have a comment like "(sender IP is ...)"), - contain a "header.b" parameter value containing a slash, which cannot occ= ur in a "pvalue", - contain an "x-tls.subject" parameter right after the authserv name (which= only one specific implementation apparently generates), and/or - contain "d=3D" or "reason=3D" after the form "=3D= (comment)", which doesn't conform to the documented syntax. Content-ID. Of the Content-ID header fields I've seen in practice, a significant propor= tion of them (almost half) do not follow the syntax of "msg-id", even thoug= h they contain angle-brackets.=C2=A0 Some examples use UUIDs inside angle-b= rackets rather than "msg-id"s with an at-sign, while other examples, such a= s "" and "", were obviously generated to be messag= e-unique rather than "world-unique" as required by RFC 2045 sec. 7.=C2=A0 (= On the other hand, I see very few instances of Message-ID header fields not= following the syntax of that header field.)=C2=A0 A smaller number of fiel= ds do not use angle-brackets at all, and some of them include the values "h= tml-body" and "text-body". List-Archive. All of the nonsyntactic List-Archive values I've seen so far involve GitHub= URLs.=C2=A0 Here the URL appears without angle brackets. List-ID. Some List-ID values either include no dots or domain names, or they are num= bers or underscore-separated number sequences with no angle-brackets. List-Unsubscribe. Many nonsyntactic List-Unsubscribe values involve either URLs not appearing= in angle brackets, or URLs encoded with RFC 2047 encoded words (compare wi= th Content-Location, which does allow the latter). Received. Many nonsyntactic Received bodies-- - include fractional seconds in the date and time, - include unquoted IPv6 addresses (which contain colons and don't conform t= o the "received-token" syntax),=20 - have no semicolon before the date/time, and/or - include a "for" clause containing "" (without the qu= otation marks). In one case, I have noticed a Received header field with an ASCII control c= haracter (U+0001, I think) in the "by" clause; unfortunately such a field i= s not downgradable under RFC 6857, nor can it appear in a generated header = field under RFC 5322. Received-SPF. Many nonsyntactic Received-SPF bodies include an unquoted IPv6 in the "clie= nt-ip" parameter (which conform to neither "dot-atom" nor "quoted-string" b= ecause of the colons), and some include an unquoted email address in the "e= nvelope-from" parameter. Return-Path. Many Return-Path header-field values don't include angle brackets (and appe= ar as "addr-spec", rather than "path" as required by RFC 5322.)=C2=A0 A ver= y small number also include a display name (and appear as "mailbox" under t= hat RFC). ------- For other standard header fields, nonconforming values occur very rarely if= at all (in my experience). --Peter --_2FF26A6A-47FD-4B50-A24C-2E5003C5B5E4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Adding additional mailing lists beca= use three header fields listed below (Received-SPF, Authentication-Results,= Arc-Authentication-Results) are within their scope.

 

--Peter

 

From: Peter Occil
Sent: Monday, July 23, 2018 11:28 = PM
To: ietf-822@ietf.org=
Subject: Most common mail header fields seen with nonsyntactic v= alues

 

The following is a list of email header fields where I find a significan= t proportion of those fields in practice using a different form from the do= cumented syntax of those fields.

&n= bsp;

This list is, for the moment, for your i= nformation only.  Whether the documents defining the header fields lis= ted below should be updated (whether to accommodate how those fields are us= ed in practice or otherwise), or what error handling a program should use i= f it encounters any of these header fields, are matters that require furthe= r discussion.  (In one case, the note in RFC 5322 provides guidance on= error handling, but in many other cases, those documents don't seem to sug= gest or require any particular error-handling behavior.)

 

ARC-Authenticati= on-Results.

 

Some nonsyntactic values of this header field contain a "= ;header.b" parameter value containing a slash, which cannot occur in a= "pvalue".

 

Authentication-Results.

 

Many nonconforming Authent= ication-Results values are of an unusual form that I've already reported el= sewhere, in the "dmarc" mailing list.  Unlike most of the ot= her forms I report here, this one may be truly nonconforming.

 

Other nonsy= ntactic Authentication-Results values--

=  

- don't mention the domain name o= f the authentication server (they generally have a comment like "(send= er IP is ...)"),

- contain a "= header.b" parameter value containing a slash, which cannot occur in a = "pvalue",

- contain an "x= -tls.subject" parameter right after the authserv name (which only one = specific implementation apparently generates), and/or

- contain "d=3D<pvalue>" or "reason=3D&l= t;pvalue>" after the form "<method>=3D<result> (co= mment)", which doesn't conform to the documented syntax.

 

 =

Content-ID.

 

Of the Content-ID header field= s I've seen in practice, a significant proportion of them (almost half) do = not follow the syntax of "msg-id", even though they contain angle= -brackets.  Some examples use UUIDs inside angle-brackets rather than = "msg-id"s with an at-sign, while other examples, such as "&l= t;example.jpg>" and "<down_arrow>", were obviously = generated to be message-unique rather than "world-unique" as requ= ired by RFC 2045 sec. 7.  (On the other hand, I see very few instances= of Message-ID header fields not following the syntax of that header field.= )  A smaller number of fields do not use angle-brackets at all, and so= me of them include the values "html-body" and "text-body&quo= t;.

 

List-Archive.

 

All of the nonsyntactic List-Archive values I've seen= so far involve GitHub URLs.  Here the URL appears without angle brack= ets.

 

List-ID.

 

Some List-ID values either include no dots or domain name= s, or they are numbers or underscore-separated number sequences with no ang= le-brackets.

 

List-Unsubscribe.

&n= bsp;

Many nonsyntactic List-Unsubscribe value= s involve either URLs not appearing in angle brackets, or URLs encoded with= RFC 2047 encoded words (compare with Content-Location, which does allow th= e latter).

 

Received.

 =

Many nonsyntactic Received bodies--

=

 

- include fr= actional seconds in the date and time,

-= include unquoted IPv6 addresses (which contain colons and don't conform to= the "received-token" syntax),

- have no semicolon before the date/time, and/or

- include a "for" clause containing "<multip= le recipients>" (without the quotation marks).

 

In one case, I hav= e noticed a Received header field with an ASCII control character (U+0001, = I think) in the "by" clause; unfortunately such a field is not do= wngradable under RFC 6857, nor can it appear in a generated header field un= der RFC 5322.

 

Received-SPF.

 = ;

Many nonsyntactic Received-SPF bodies inclu= de an unquoted IPv6 in the "client-ip" parameter (which conform t= o neither "dot-atom" nor "quoted-string" because of the= colons), and some include an unquoted email address in the "envelope-= from" parameter.

 <= /p>

Return-Path.

 

Many Return-Path header-field values= don't include angle brackets (and appear as "addr-spec", rather = than "path" as required by RFC 5322.)  A very small number a= lso include a display name (and appear as "mailbox" under that RF= C).

 

-------

 

For other standard header fields, nonconforming values occu= r very rarely if at all (in my experience).

 

--Peter

 

 

= --_2FF26A6A-47FD-4B50-A24C-2E5003C5B5E4_--