From nobody Tue Oct 3 23:15:18 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860091320D9 for ; Tue, 3 Oct 2017 23:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl 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 esHyKoOvzU0R for ; Tue, 3 Oct 2017 23:15:14 -0700 (PDT) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 5F4D012EC30 for ; Tue, 3 Oct 2017 23:15:13 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud9.xs4all.net with ESMTP id zcxadme6DnIXbzcxbdHkpG; Wed, 04 Oct 2017 08:15:12 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1507097704; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=Zcgjn++5oziW4VeJTPLrWVO+BLyXpRjY4Dt2sGlxswg=; b=QPFk8ybfvOYrEGtOO6HTgayXS5j4T/dxBW+ocXcAuMM7gxu5RLu0HsZb gxPP5YQ3PXUGDuQC0I98dDxM2DRdJ06tM6bScY6OwYN16CCKKsnyTr8qqG 980m6Retkkwq09yn2UYz/5SSOmesd12ElfEUjII1jTSL54kW1+6FBuRlo= Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id C12B21AB4F; Wed, 4 Oct 2017 06:15:03 +0000 (UTC) Message-ID: <59D47C66.4020502@openfortress.nl> Date: Wed, 04 Oct 2017 08:15:02 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Scott Kitterman CC: dmarc@ietf.org References: <20170926225856.13967.qmail@ary.lan> <59CDDFEE.40104@openfortress.nl> <3942982.pm2zWRk9M4@kitterma-e6430> In-Reply-To: <3942982.pm2zWRk9M4@kitterma-e6430> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfFa0pYAwuwn92hyUuRlWqzYEAQRKT3QkDhDOzUW+22Qel5kGi8dDNjpEwEeViw09wdZC20ZBHax9Yyvc41NoWuYiLYMNjpXreK6hHZTDS/MQ5gFcsKLk cjECZmAmj+o5ZtGC4FvCYiW5XezcEFtI2AnL82STHnPc7dgx5wWrd9dgupkafi6w9miOGTjXYgCA6G1ueGuCKoiGneB4Y3ZksiQ= Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet Draft) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 06:15:16 -0000 Hello, Thanks to Scott for his feedback: > Making DKIM signing MIME aware was specifically rejected during DKIM > development due to implementation complexity. I'm afraid I wasn't there, but would like to learn from the past. Any references are welcome. But what exactly do you mean by "implementation complexity"? - the need to incorporate MIME-knowledge into an MTA (which one might argue is not new -- but it is now a requirement for the signing and verifying MTA, which may have gotten by without until now) - the added complexity during signing and verification (I would agree; but argue that this reflects the complexity of the mail system, and ends there; it will not grow without bounds) - the need for two passes during verification (I am working on that; recognising an initial bit of text may be better than a rolling checksum over the entire text) - ...? I think the most important advantage of Lenient DKIM is that it avoids that a choice made in one place invalidates existing, constructive things taking place elsewhere. ARC will not solve that discrepancy; it imposes one administrator's choice onto others. To me, that is the most dire form of complexity (and a reason why people may hold back on deploying DKIM; look at this email for example, probably being rewritten to UTF-8 and thereby invalidating my DKIM-Signature made with dkimpy). Anywhere I repeat things already said, please feel free to point me back to discussions I've missed. Thanks, -Rick From nobody Wed Oct 4 03:09:50 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E121F133054 for ; Wed, 4 Oct 2017 03:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=kitterman.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 hwOMDPmBGXXh for ; Wed, 4 Oct 2017 03:09:47 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8DA134231 for ; Wed, 4 Oct 2017 03:09:47 -0700 (PDT) Received: from [192.168.1.115] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6ECE8C403DC; Wed, 4 Oct 2017 05:09:46 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2001409; t=1507111786; bh=drSuPahnqqM1neDk5lG2Kg3Z7xxFGpoITCtBnyhcGcQ=; h=Date:In-Reply-To:References:Subject:To:From:From; b=jWpwcz8EraheQAYxCDfPXt3+QwxciU+kC0obPCjve3UNk8Tc7dBCG7vLLK3/ozHvB roifOU16b6Gvd8bOWcWcg86IDPk++D0zo7eNaaBhAYora5gyrkY3pJA4u+D3HeHRFx BWVzbMw4fGB9Kv3FJbIdPzDN+evMUtnhb3ZX2V04= Date: Wed, 04 Oct 2017 10:09:42 +0000 In-Reply-To: <59D47C66.4020502@openfortress.nl> References: <20170926225856.13967.qmail@ary.lan> <59CDDFEE.40104@openfortress.nl> <3942982.pm2zWRk9M4@kitterma-e6430> <59D47C66.4020502@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <7B05BC1B-5D78-4F97-9B5A-B07810BB420B@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet Draft) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 10:09:49 -0000 It was the second=2E I personally don't have time to hunt through decade o= ld email archives=2E That argument was made, but didn't carry the day=2E Scott K On October 4, 2017 2:15:02 AM EDT, Rick van Rein = wrote: >Hello, > >Thanks to Scott for his feedback: > >> Making DKIM signing MIME aware was specifically rejected during DKIM >> development due to implementation complexity=2E > >I'm afraid I wasn't there, but would like to learn from the past=2E Any >references are welcome=2E > > >But what exactly do you mean by "implementation complexity"? > > - the need to incorporate MIME-knowledge into an MTA (which one might >argue is not new -- but it is now a requirement for the signing and >verifying MTA, which may have gotten by without until now) > > - the added complexity during signing and verification (I would agree; >but argue that this reflects the complexity of the mail system, and >ends >there; it will not grow without bounds) > > - the need for two passes during verification (I am working on that; >recognising an initial bit of text may be better than a rolling >checksum >over the entire text) > > - =2E=2E=2E? > >I think the most important advantage of Lenient DKIM is that it avoids >that a choice made in one place invalidates existing, constructive >things taking place elsewhere=2E ARC will not solve that discrepancy; it >imposes one administrator's choice onto others=2E To me, that is the >most >dire form of complexity (and a reason why people may hold back on >deploying DKIM; look at this email for example, probably being >rewritten >to UTF-8 and thereby invalidating my DKIM-Signature made with dkimpy)=2E > > >Anywhere I repeat things already said, please feel free to point me >back >to discussions I've missed=2E > > >Thanks, > -Rick From nobody Fri Oct 6 13:28:15 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C73D133075 for ; Fri, 6 Oct 2017 13:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.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 Oxg35cEmPi-5 for ; Fri, 6 Oct 2017 13:28:11 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 07E09132EA7 for ; Fri, 6 Oct 2017 13:28:10 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id i1so10260644vke.12 for ; Fri, 06 Oct 2017 13:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7SKrzkIwwRKK1dnh7qzr4XuXhjzQzqkEqZlC9gMnU6w=; b=eXE5tJ6T9oc3ILE17Q9YPZU/4zuzS5qMPGHh1wsj0HwWMZyfKz0nilzyFRsjro7QC8 LryLghY2YAU9itUcXEI+fiRpoQWUXDp4fByhcWUyrcsHGY/vmH52CZX7D3Jrf5c4Urv3 wmXDe5q+FXsOVVQHFjJyR9iEJOluHrgZAgMNVzLRPNXenqpJkUVjjYepk0FYJy3denx+ 80fEw37i5UQ3Xi0nYQSLhlV3EiNTezr7oEQjunVtHC4cHTk+4uWRw3mt4OIeF+NZEcHj xpaSsk36WRSeXuwr01BQqNepR6IY+QidVsTpCTq2+Sr7nfYMlm9qXuHS2yw9WCK/JU4i dBHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7SKrzkIwwRKK1dnh7qzr4XuXhjzQzqkEqZlC9gMnU6w=; b=SEORFqj/Xafj161unDZ7Jkakl5VB2H4AHzKJGW+2gSRiFP5swzG4hKXC1J1nLW7cLZ wxSCVH9n6mGF6tYUXb+NAGXw4MeRBfLmOQVo+zLm7H3CCuWH+s1IJ3LYwpn0x6ESM29l x4qM59rv8el0Uwp14mgg82EFdyA3MdJvBFXTbpWGnTY4+XsQRb7mSOgF0GCLPwHzPl2O ugWH57x3e7tlGn0xPvcFjYBWGtF0gJzxwI6CcVyPOmazpYA2WUtrA1Z7t+ZoagBQdGR8 3aXnqSTOMAEJHq0Oq34t2U0bJLLWTWoIpoFQDex2jXmdcwfn5TiK80NSKUjlTc2HJ1S+ 0DBg== X-Gm-Message-State: AMCzsaUimgPu6Qb4A8vhmXp2W77+iT6LH9036+SWOJxqU9yU1cbzRve+ GMDJvgowjai4VSEYi4YggLjddTzE6uWctYDUiUGat3ya X-Google-Smtp-Source: AOwi7QB1muDyv6KGf4NnZO9P7uOVmnpFcGTtYDnB4UTkjiFNjL4TQRi9De0Z7FrU8/vo/G8sfUdrrKV8MPEMT21K8gk= X-Received: by 10.31.169.88 with SMTP id s85mr1413215vke.86.1507321689728; Fri, 06 Oct 2017 13:28:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.17.17 with HTTP; Fri, 6 Oct 2017 13:27:49 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Fri, 6 Oct 2017 16:27:49 -0400 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a11426546e11b1a055ae6ad1b" Archived-At: Subject: Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 20:28:14 -0000 --001a11426546e11b1a055ae6ad1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Questions 1, 2, and 4 as they relate to the text I suggested are still open - and I don't believe the text that was pulled into -09 is correct until these questions are answered. On Tue, Sep 5, 2017 at 5:52 PM, Seth Blank wrote: > There have been substantial comments both on and off list about section > 5.1.1. I've suggested new language for all of 5.1, below, to remove > normative modification of 7601, and address several other issues. There a= re > questions for the WG below the suggested text. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Replace 5.1 with: > > The ARC-Authentication-Results (AAR) header field is semantically and > syntactically identical to the Authentication-Results header defined in > [RFC7601#2.2] as authres-header (A-R), except that the first element > =E2=80=9CAuthentication-Results:=E2=80=9D in authres-header is replaced w= ith > arc-authres-prefix as follows: > > arc-authres-header-prefix =3D "ARC-Authentication-Results:" [CFWS] > arc-info > > arc-info =3D %x69 =E2=80=9C=3D=E2=80=9D arc-hop *([CFWS] =E2=80=9C;= =E2=80=9D [CFWS] propspec) [CFWS] =E2=80=9C;=E2=80=9D > > arc-hop =3D 1*2DIGIT ; 1-50 > > The purpose of this header field is to transmit the results of any > authentication done on the message upstream to participating ADMDs > validating and continuing the chain. > > The AAR MUST contain all A-R results from within the participating ADMD, > regardless of how many A-R headers are on the message. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Replace 5.1.1 with: > > 5.1.1. ptypes and properties for arc-info > > Certain information pertinent to ascertaining message disposition can be > lost in transit when messages are handled by intermediaries. For example, > failing DKIM signatures are sometimes removed by MTAs, and most DKIM > signature on messages modified by intermediaries will fail. Therefore, a > passing DKIM-Signature from the first ARC signer is likely to have been > removed by final receipt of the message. > > The AAR, and in particular the ptype-properties stamped in arc-info, > provide a mechanism for this information to survive transit. > > The ptypes and properties defined in this section SHOULD be stamped in th= e > AAR: > > * smtp.client_id - The connecting client IP address from which the messag= e > is received; > * header.ds - The domain/selector pair for each dkim signature on the > message (header.ds=3Dexample.com,selector) > * arc.closest_fail - The hop number of the most recent AMS that fails to > validate, or 0 if all hops pass. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Open questions: > > 1) The optimal ABNF for AAR would inherit the A-R payload ABNF from 7601. > Unfortunately, authres-header was defined in a way that makes this > difficult. Is there a better way to say that the AAR inherits the A-R > payload, and if anything modifies the definition of authres-header in 760= 1, > the AAR also needs to inherit this change? > > To be super specific, this is the current authres-header ABNF from 7601: > > authres-header =3D "Authentication-Results:" [CFWS] authserv-id > [ CFWS authres-version ] > ( no-result / 1*resinfo ) [CFWS] CRLF > > Optimally, there would be: > > authres-payload =3D [CFWS] authserv-id > [ CFWS authres-version ] > ( no-result / 1*resinfo ) [CFWS] CRLF > > And then we could have: > > arc-authres-header =3D "ARC-Authentication-Results:" [CFWS] arc-info > authres-payload > > 2) The optimal way to transmit DKIM selector information is in the DKIM > A-R methodspec as header.s. If we want to prevent a normative modificatio= n > of 7601, I've proposed "header.ds" which will accomplish the same thing. > > 3) In the ARC-Seal megathread, there was an aside about knowing the last > hop which validated: > > On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana > wrote: > > That seems like it would be enough to fix that objection. An additiona= l > "first AMS failure" header at each hop would give you a list of who > actually modified the message. > > arc.closest_fail has been defined to accomplish this. > > 4) Have the ptype-properties been defined properly, and will these AAR > ptype-properties need an IANA registry? > > 5) Finally, the ams[n] and as[n] entities were dropped, as these values > are guaranteed to be on the final message if an ARC chain passes, so > there's no need to encode them separately. > > Seth > --001a11426546e11b1a055ae6ad1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Questions 1, 2, and 4 as they relate to the text I suggest= ed are still open - and I don't believe the text that was pulled into -= 09 is correct until these questions are answered.

On Tue, Sep 5, 2017 at 5:52 PM, Seth Blank = <seth@sethblank.com> wrote:
There have been substantial comments both on and off li= st about section 5.1.1. I've suggested new language for all of 5.1, bel= ow, to remove normative modification of 7601, and address several other iss= ues. There are questions for the WG below the suggested text.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Replace 5.1 with:

The ARC-Authentication-Re= sults (AAR) header field is semantically and syntactically identical to the= Authentication-Results header defined in [RFC7601#2.2] as authres-header (= A-R), except that the first element =E2=80=9CAuthentication-Results:=E2=80= =9D in authres-header is replaced with arc-authres-prefix as follows:
=

=C2=A0 =C2=A0arc-authres-header-prefix =3D "ARC-Au= thentication-Results:" [CFWS] arc-info

=C2=A0= =C2=A0 arc-info =3D %x69 =E2=80=9C=3D=E2=80=9D arc-hop *([CFWS] =E2=80=9C;= =E2=80=9D [CFWS] propspec) [CFWS] =E2=80=9C;=E2=80=9D

<= div>=C2=A0 =C2=A0 arc-hop =3D 1*2DIGIT =C2=A0; 1-50

The purpose of this header field is to transmit the results of any authen= tication done on the message upstream to participating ADMDs validating and= continuing the chain.

The AAR MUST contain all A-= R results from within the participating ADMD, regardless of how many A-R he= aders are on the message.

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Replace 5.1.1= with:

5.1.1. ptypes and properties for arc-info

Certain information pertinent to ascertaining messa= ge disposition can be lost in transit when messages are handled by intermed= iaries. For example, failing DKIM signatures are sometimes removed by MTAs,= and most DKIM signature on messages modified by intermediaries will fail. = Therefore, a passing DKIM-Signature from the first ARC signer is likely to = have been removed by final receipt of the message.

The AAR, and in particular the ptype-properties=C2=A0stamped in arc-info, = provide a mechanism for this information to survive transit.

=
The ptypes and properties=C2=A0defined in this section SHOULD be= stamped in the AAR:

* smtp.client_id - The connec= ting client IP address from which the message is received;
* head= er.ds - The domain/selector pair for each dkim signature on the message (he= ader.ds=3Dexample.com,= selector)
* arc.closest_fail - The hop number of the most re= cent AMS that fails to validate, or 0 if all hops pass.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Open questions:

1) The optimal ABNF fo= r AAR would inherit the A-R payload ABNF from 7601. Unfortunately, authres-= header was defined in a way that makes this difficult. Is there a better wa= y to say that the AAR inherits the A-R payload, and if anything modifies th= e definition of authres-header in 7601, the AAR also needs to inherit this = change?

To be super specific, this is the current = authres-header ABNF from 7601:

=C2=A0 =C2=A0 = =C2=A0authres-header =3D "Authentication-Results:" [CFWS] authser= v-id
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CFWS auth= res-version ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ( = no-result / 1*resinfo ) [CFWS] CRLF

Opti= mally, there would be:

=C2=A0 =C2=A0 =C2=A0au= thres-payload =3D [CFWS]=C2=A0authserv-id
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CFWS authres-version ]
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ( no-result / 1*resinfo ) [CFWS] CRL= F

And then we could have:

=
=C2=A0 =C2=A0arc-authres-header =3D "ARC-Authentication-Results:&= quot; [CFWS] arc-info authres-payload

2) The= optimal way to transmit DKIM selector information is in the DKIM A-R metho= dspec as header.s. If we want to prevent a normative modification of 7601, = I've proposed "header.ds" which will accomplish the same thin= g.

3) In the ARC-Seal megathread, there was an asi= de about knowing the last hop which validated:

On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana <brong@fastmailteam.com> wrote:=
> That seems like it would be enough to fix that objection.= =C2=A0 An additional "first AMS failure" header at each hop would= give you a list of who actually modified the message.
=
arc.closest_fail has been defined to accomplish this.
<= div>
4) Have the ptype-properties been defined properly, and = will these AAR ptype-properties need an IANA registry?

=
5) Finally, the ams[n] and as[n] entities were dropped, as these value= s are guaranteed to be on the final message if an ARC chain passes, so ther= e's no need to encode them separately.

Seth
--001a11426546e11b1a055ae6ad1b-- From nobody Sun Oct 8 14:51:53 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73DA132D45 for ; Sun, 8 Oct 2017 14:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl 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 y5ceSZrrWUiq for ; Sun, 8 Oct 2017 14:51:49 -0700 (PDT) Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (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 96BC7132A89 for ; Sun, 8 Oct 2017 14:51:48 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud9.xs4all.net with ESMTP id 1JU8ej8k5nIXb1JU9eZDp6; Sun, 08 Oct 2017 23:51:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1507499498; h=message-id : date : from : mime-version : to : subject : content-type : content-transfer-encoding : date : from : subject; bh=1VrSJt4sg/nSH07PxfjZTsJrOEIvqORGE1G95rcI2q0=; b=aIPK5QYMmbAs4Bx7N9rmtjdfgSlGrsrLDe0MJN+1Xtvc8y3UcwkO53g0 TwubzdTV4wQvzCLwowb8u/V7kVf+dBJ2SxzvFfNMk4EbnRshQ6ep3pfnst lzWd2uX+bbPQ3Qo2PnP9nuTDfnPfdHNCfsIkhS05pSPfZhJntMd25rwmM= Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id B57B01B84D; Sun, 8 Oct 2017 21:51:38 +0000 (UTC) Message-ID: <59DA9DE9.4000102@openfortress.nl> Date: Sun, 08 Oct 2017 23:51:37 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "dmarc@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfFvYDBtjFQKymKXkhw17OjW9QwML/7fWLDRQQo6nliB74IC4Mq3Yfz0SRm44tpghEJBugvjj6OwR4QoqmChTCDgWt+xMQ2zYLd29ji79NhWgrfI6jnDn b4qVIYC5TrCueQyxtHoa6uD/fBda2ifaPDx7eHn623jdqrn9UAaFvyZa Archived-At: Subject: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 21:51:52 -0000 Hello, This is a solution for SPF after forwarding and lists that I've been aware of for a while; I wonder if this is already commonly done? Forwarding is an action on the receiving end, and can only be solved reliably by the recipient. Notably, a mailbox user could specify addresses that are forwarded to their mailbox. Mailing list subscriptions may be seen as a special form of forwarding. When incoming mail is SPF-validated and the envelope sender does not match the sending MTA address, those forwarded domains can be looked up for the envelope _recipient_ address. Lenient SPF validation would add permission to sending MTAs from these forwarded domains. The result would be that forwarding never breaks, when configured on the receiving mailbox. I am not sure if this is part of the "mark as NOT spam" procedures in common mailbox services, but AFAIK it would fix quite a bundle of problems. I suppose this could also lead to a definition of Lenient DMARC. Cheers, -Rick From nobody Sun Oct 8 19:29:27 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D051321A7 for ; Sun, 8 Oct 2017 19:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 pm98xuT-pbRK for ; Sun, 8 Oct 2017 19:29:25 -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 CBD1A133068 for ; Sun, 8 Oct 2017 19:29:24 -0700 (PDT) Received: (qmail 45379 invoked from network); 9 Oct 2017 02:29:23 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 9 Oct 2017 02:29:23 -0000 Date: 9 Oct 2017 02:29:01 -0000 Message-ID: <20171009022901.21038.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: rick@openfortress.nl In-Reply-To: <59DA9DE9.4000102@openfortress.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 02:29:26 -0000 In article <59DA9DE9.4000102@openfortress.nl> you write: >Forwarding is an action on the receiving end, and can only be solved >reliably by the recipient. Notably, a mailbox user could specify >addresses that are forwarded to their mailbox. Mailing list >subscriptions may be seen as a special form of forwarding. Sorry but this is another WKBI. Off the top of my head some of the reasons it doesn't work are: * There is no way to tell who forwarded a message, in particular you cannot expect the recipient to be in a To: or Cc: header. You could invent a Forwarded-By: header, but of course bad guys add fake headers, so you'd have to track who's supposed to be forwarding what and you'd end up with a very complex and fragile forwarder whitelist. * There is a kludge called SRS that embeds the original bounce address in the forwarder's bounce address, but it doesn't help. * Mailing lists invariably replace the incoming bounce address with their own bounce address so they can handle the bounces, which among other things means there you can't tell that a mailing list message is a mutated forwarded message from whoever originally sent it. Skipping ahead, you might at best end up with a very complex and fragile mailing list whitelist. * Asking users to manage their own security settings doesn't work. See prior discussion of MUA highlighting and browser warnings. R's, John PS: Most courtesy forwards don't break DKIM signatures. That's not an accident. From nobody Mon Oct 9 10:49:51 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF998134746 for ; Mon, 9 Oct 2017 10:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl 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 yJtT15xBqSML for ; Mon, 9 Oct 2017 10:49:39 -0700 (PDT) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 E79E41346B0 for ; Mon, 9 Oct 2017 10:49:35 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud9.xs4all.net with ESMTP id 1cBHevLoznIXb1cBIeegT4; Mon, 09 Oct 2017 19:49:32 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1507571365; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=7/lkuV6fFsHFaBQnNqNltZYrEz5Vp30fvDhd0n2Wuus=; b=hyaHldh2qkc4HsDjMvzmt2taiiaNOrCI2bhACsXJEzXOalPOp26uZfVU vMDZuwMKk9lCY17ouTgh9Fh38eb44+ECxASWWUMNJrcR5fVlWlniOeYij6 XPIPQEquxToXyoJq8MC1XuYdm9IB6IPfONj1jy3hkI99vrO+baQTJoZso= Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 9855E1BC1E; Mon, 9 Oct 2017 17:49:24 +0000 (UTC) Message-ID: <59DBB6A3.3010009@openfortress.nl> Date: Mon, 09 Oct 2017 19:49:23 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: John Levine CC: dmarc@ietf.org References: <20171009022901.21038.qmail@ary.lan> In-Reply-To: <20171009022901.21038.qmail@ary.lan> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfCA/onyGtnpzWp1MIWVzjr3KpQngYFTM9vB3tjR3uIESapxfW+166gqTvKn5tdgLIjBlkQt+oZWB9lVq1qlIWlMidGL33rKUbid5SLkPniMY6DkPzPXL P2scKEuIez61TuNo8sd1pJNyhNK+SbOOHExw985KszLlHP5dIPYqWJqS6VY0883ko/wQY8cz3SiQ0UDwZCFAdaeEY9q2DlUuQFA= Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 17:49:44 -0000 Hi, > > Sorry but this is another WKBI. Off the top of my head some of the > reasons it doesn't work are: Thank you for your comments, John! > > * There is no way to tell who forwarded a message, in particular you > cannot expect the recipient to be in a To: or Cc: header. You could > invent a Forwarded-By: header, but of course bad guys add fake > headers, so you'd have to track who's supposed to be forwarding what > and you'd end up with a very complex and fragile forwarder whitelist. The Received: header actually does most of this -- it contains the EHLO and MAIL FROM information of previous envelopes. It does not always contain the RCPT TO (max one ends up in optional "for"). Given that SPF approves of a sender [because it is configured as a reliable provider], one might trust the topmost Received: header to have been delivered by that reliable party. That assures us of the sender one step down, and after a few steps we've left the entrance points to our own realm [over which we have control, so not all bad] and then... the customary SPF magic can take place, based on the envelope data available there. The last IP address logged comes from the last trusted Received: header and that's the one that did the crossover to our realm of control. The devil will be in the details, I realise that. But a lot of the info you mentioned actually is there already, and is even obliged. Things like one domain leaving multiple Received: headers, and complex MTA infra that doesn't share input and output addresses. > > * There is a kludge called SRS that embeds the original bounce address > in the forwarder's bounce address, but it doesn't help. I agree. And unpacking the address from SRS doesn't sound like a dream of interoperability either. One might actually rely on the From: header more than SPF does now; unlike To: and Cc: this is a reliable address source [except for bounces, which will normally transport directly and SPF-compliant]. The From: address can then be used at the end of the unraveled envelope history from Received: headers. Whee, it almost sounds like DMARC is teaching SPF how it's done :) > > * Mailing lists invariably replace the incoming bounce address with > their own bounce address so they can handle the bounces, which among > other things means there you can't tell that a mailing list message is > a mutated forwarded message from whoever originally sent it. Skipping > ahead, you might at best end up with a very complex and fragile > mailing list whitelist. Same as SRS, really. > > * Asking users to manage their own security settings doesn't work. > See prior discussion of MUA highlighting and browser warnings. Maybe. They do manage their spam folders, and this may piggyback on that. > > PS: Most courtesy forwards don't break DKIM signatures. That's not an > accident. I know; I am not focussing on these "most" cases, but on the rest. Like this list :-) that requires DKIM re-signing. Thanks for your thoughtful thoughts! -Rick From nobody Mon Oct 9 11:22:24 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5391326F6 for ; Mon, 9 Oct 2017 11:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=K8IaJwtJ; dkim=pass (1536-bit key) header.d=taugh.com header.b=VAvQ+BvT 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 9t-AbKr7DEqz for ; Mon, 9 Oct 2017 11:22:20 -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 202F71321B6 for ; Mon, 9 Oct 2017 11:22:19 -0700 (PDT) Received: (qmail 17963 invoked from network); 9 Oct 2017 18:22: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:references:mime-version:content-type:user-agent; s=4629.59dbbe59.k1710; bh=jqFR8dmhPrsrhC8LuyepNEffSbmoYH21WAy6U6NmtI8=; b=K8IaJwtJSJJS9eH2Z/SCb0uXOkPRME1tKhnAJGJeqXbWBTmNLiDsOaCyqgn/hGdDr3xdxhXnoLD6rMWafFGYwRSdI/2wg7mBXCJNqhegCUbumhdmR6PtewN/HZC3fqQpd/e8xwfQqp1c5k0A+cvTyVMfEjv44iyWJVIbcDbr9wFkflJ1lww4cGisIjY7JeW9s36xcwPLktaYTDG534LT1H2wk1dhomlD3u8u9dTzMQb3I//0Vb4Go5ESDzYsCW0c DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4629.59dbbe59.k1710; bh=jqFR8dmhPrsrhC8LuyepNEffSbmoYH21WAy6U6NmtI8=; b=VAvQ+BvT+W7GCsbUW2/WblZbLJPSti6r1ODOiTcd7O/DGFxsr+wbiWmQIv3oM4tlypUo0eUwKPAdIfrB2zZIKV+xbwXYbcmhnbOYQ1147oCIYw3YC+QmV0zf6KepsH8xwxIfz67RaQJNG/FGI/XYTOJ5Cql0FGy7UAVzF8wSyuK2/P0IRg3R70w/pgwZybiiEQpnJDcDDymyx5UPoTppy9s8Et/lC2u2jPxDSwQPMak+sARW5OmUHkB+Z09j++uz Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 09 Oct 2017 18:22:17 -0000 Date: 9 Oct 2017 14:22:16 -0400 Message-ID: From: "John R Levine" To: "Rick van Rein" Cc: dmarc@ietf.org In-Reply-To: <59DBB6A3.3010009@openfortress.nl> References: <20171009022901.21038.qmail@ary.lan> <59DBB6A3.3010009@openfortress.nl> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 18:22:22 -0000 > The devil will be in the details, I realise that. Really, this is not a new idea. It doesn't work. Please go back and read the archives from a decade ago when all of these ideas were considered and rejected. R's, John PS: >> * Asking users to manage their own security settings doesn't work. >> See prior discussion of MUA highlighting and browser warnings. > > Maybe. They do manage their spam folders, and this may piggyback on that. Very, very badly. People at large webmail providers tell me that users retrieve phishes out of their spam folders all the time and complain when it doesn't let them click on the links. From nobody Mon Oct 9 11:25:59 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E68F133338 for ; Mon, 9 Oct 2017 11:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 7KVL8TPijalz for ; Mon, 9 Oct 2017 11:25:56 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 CDFDB134534 for ; Mon, 9 Oct 2017 11:25:56 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id v132so21879094oie.1 for ; Mon, 09 Oct 2017 11:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NsEnIO53AVAhCBTT49ptNL2NREG5fD1ZIlVz1lTOnwQ=; b=PnrWnFh4wWCQisCoDsDuOZP7jWiy9+y6bK8clHzlxqrHRm34SAejPVk++iHPHrUJ4K wd1FeLAiU/3QF55J/nIOv75ELqOwtIt8xfXTPEMkMUpjmHLy66nrVty6JiGWFulF0Dox Qr2H6muduWZwbaF7TSTdNCx9oz5+WjsOB9Zh6srvIyIcvJVabKyhfsZ/G98LUW4B+MYM Wg386gCviCXrGxsak+DR+92Uw/9IttHseiqBiOis7iKeA0JfiN0SBhHh5INdKhtTs0hY nlobW3sknaqPbl7lZ+pG7ZDFY0AiNsCe8joVmnEzfw3xxPXlI+ksmeeohKzl2c6rSFhY qW5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NsEnIO53AVAhCBTT49ptNL2NREG5fD1ZIlVz1lTOnwQ=; b=VJTvcx+kal0Y6A48lz9+Y+gR9x59z0HsgR1/1c15MDZrVvvdhylQ5VegN7yJKbhQYG iUg1Qc2z+7j/rPH47C3Way1e/IuAw6Gqh4g1X+nsqi9YHCNp2xrYtcc4HlcRvNxVHe+1 fo8vOlxoqeO0mE7ip3SzoRnhV05kA4DAxer6Em8kVVGIBejcODDVAwhXsU74K7mBZKMf N/ydrt4xTBJmR98IOkQkBJpLkkHdqkTtQUEXA+wx8WZHmDcB/TuPii/6yNXGR8y1lGBQ 4Coz7g//w1uLMEhM9uI0BtndpElHtTZrMy6oelzWbWrfuyduNC0E17/iPsAcorEcnQx/ rlpQ== X-Gm-Message-State: AMCzsaU7DM8hsPwVYJB0rigEKdZfTekm3STKnJ1gztKzVr/NGqzdCbKg D5r9gpS+RtMDjC7DdE6YnKWSNTBo X-Google-Smtp-Source: AOwi7QA6Ez//3lXJHHcJn0RcDhp2tGfXfQDQPunPsr2qkneAdVoiOuO7Or7Rhi7LTsTaqqKkmPo3Sw== X-Received: by 10.157.85.200 with SMTP id z8mr223952oti.111.1507573555849; Mon, 09 Oct 2017 11:25:55 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:c4e8:d795:bbab:6d47? ([2602:304:cda0:8800:c4e8:d795:bbab:6d47]) by smtp.gmail.com with ESMTPSA id w69sm4558111otb.4.2017.10.09.11.25.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 11:25:55 -0700 (PDT) To: John R Levine Cc: dmarc@ietf.org References: <20171009022901.21038.qmail@ary.lan> <59DBB6A3.3010009@openfortress.nl> From: Dave Crocker Message-ID: <09a7fb39-8d77-d473-86e2-5e0dca0f828a@gmail.com> Date: Mon, 9 Oct 2017 11:25:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 18:25:58 -0000 On 10/9/2017 11:22 AM, John R Levine wrote: >> The devil will be in the details, I realise that. > > Really, this is not a new idea.  It doesn't work.  Please go back and > read the archives from a decade ago when all of these ideas were > considered and rejected. If we want to give constructive guidance to folk who offer ideas that have previously been rejected, we need to document them and the reasons for rejecting them, rather than give this kind of generic, vague pointer to the past. I'm glad to help, but don't feel I have enough of the detail to be primary for the effort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Oct 10 13:53:33 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA181326DF for ; Tue, 10 Oct 2017 13:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 eWTp0j1IvQGl for ; Tue, 10 Oct 2017 13:53:28 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 64D971320D9 for ; Tue, 10 Oct 2017 13:53:28 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id b11so17522816uae.12 for ; Tue, 10 Oct 2017 13:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c5jo93HXzJdCOiqgQ/y7UpD77URLTfAhVx2yLxG4kK4=; b=fP8Ytd6/EbYVKI/6nnHp8b/nkOjdLMDOmUhgYdM4ojrX9w+HDCFkHcKwkuUB79QV0Z qACY7je0e+0qZUYvUDUA3RLZEHQYFf/xYP4wRvTN1WgvPu+35KlGKTd6vJm2SCabDIcZ O2ElceROvGSucRZXrYbRvBlm0jhqcLWlJ6S9SWCHwxT1P2kZEdBbpbXm9v9YATTvz1Kp /dR258ElNA44FBn3UBLb+jImyFLH8HkVYc9LP/25YiD4QyGPmJW08A4LmAVRmJcFsw55 zyZZRTEdKKZV7s8zxgEbrqRTLG8HL/eM8SYxjYhIOYS39+h8ZT5MRFnYpH0/cGAgfjsb Y4Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c5jo93HXzJdCOiqgQ/y7UpD77URLTfAhVx2yLxG4kK4=; b=UBTTGcUhhZXzbAIVHPXopSR3vnFPqT0tGhElGfKoMuqcgzjUv2+SK/LqsIrdbQnW+Z lwIwkZ1/dg1qYflXTLAv7qS9bmQXtrUYj00irV0gmlYuBaG4q2ybRIX93xhYC6vwle3v R25gsYdTgMG/jQ3mF+NvzkZk1ThEi3Wy02feWFO9NZTQykdSUrMGi8+UgshL4MZakAqm 4E2kKqZZGGfTrUzTUlywACMb+Felmm+AT+EYJ9MldepwuSaL7OKDwF9OGlZma7t8S5BN gJT67n3956vth/8o3wXQH10Dchz10y0ZGW8SHkE5PsXQuBCPFkmdi5vcv+ldzjSwJv4E dpQQ== X-Gm-Message-State: AMCzsaXAFLOXYfkTfTBkOfL6S5YibrXVFOBN+zcvuYXH0/z2ImTpegTz 8FsPwVLG7lM48Exwx9VkyOP+8oOmlsqkoKoFXUH5 X-Google-Smtp-Source: AOwi7QBaBKs+aM7Xl9PGgwwQn/9pQ0VwRdTYK4EgvcZGTPdiZEiIEiwL7z8UcjJ2Tb/U15sdMU+26l9MfxGzJbSMoxs= X-Received: by 10.159.33.195 with SMTP id 61mr8797084uac.63.1507668806735; Tue, 10 Oct 2017 13:53:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.55.82 with HTTP; Tue, 10 Oct 2017 13:53:25 -0700 (PDT) In-Reply-To: <59DBB6A3.3010009@openfortress.nl> References: <20171009022901.21038.qmail@ary.lan> <59DBB6A3.3010009@openfortress.nl> From: Brandon Long Date: Tue, 10 Oct 2017 13:53:25 -0700 Message-ID: To: Rick van Rein Cc: John Levine , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114505a0ab0482055b377f28" Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 20:53:32 -0000 --001a114505a0ab0482055b377f28 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 9, 2017 at 10:49 AM, Rick van Rein wrote: > Hi, > > > > > Sorry but this is another WKBI. Off the top of my head some of the > > reasons it doesn't work are: > > > Thank you for your comments, John! > > > > > * There is no way to tell who forwarded a message, in particular you > > cannot expect the recipient to be in a To: or Cc: header. You could > > invent a Forwarded-By: header, but of course bad guys add fake > > headers, so you'd have to track who's supposed to be forwarding what > > and you'd end up with a very complex and fragile forwarder whitelist. > > > The Received: header actually does most of this -- it contains the > EHLO and MAIL FROM information of previous envelopes. It does not > always contain the RCPT TO (max one ends up in optional "for"). > > Given that SPF approves of a sender [because it is configured as a > reliable provider], one might trust the topmost Received: header to > have been delivered by that reliable party. That assures us of the > sender one step down, and after a few steps we've left the entrance > points to our own realm [over which we have control, so not all bad] > and then... the customary SPF magic can take place, based on the > envelope data available there. The last IP address logged comes from > the last trusted Received: header and that's the one that did the > crossover to our realm of control. > > The devil will be in the details, I realise that. But a lot of the > info you mentioned actually is there already, and is even obliged. > Things like one domain leaving multiple Received: headers, and > complex MTA infra that doesn't share input and output addresses. > So, to a certain extent, sure. Or, you can just do the SPF evaluation on the edge, and pass that evaluation into your ADMD via the Authentication-Results header. Or, use some sort of specific local equivalent. GSuite does allow customers to specify the IP addresses of their inbound gateways, so that when the message finally reaches GSuite, we'll walk the received headers for the first one that specifies an IP address not on their list and evaluate SPF based on that. This works ok for most use cases, though we've recently had some issues because the list of IPs in an ADMD can be fairly large (O365 is moving to using non-private IPv6 addresses for internal servers, which can make maintaining the list challenging). Note that ARC is the end result of thinking of this, that we can create a signed Received header chain containing the info we need to pass an observed spf=pass at hop 1 and pass that information on to follow on's across trust/ADMD boundaries and know who the actors are so we can trust the information passed. Brandon --001a114505a0ab0482055b377f28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 9, 2017 at 10:49 AM, Rick van Rein <rick@openfortress.n= l> wrote:
Hi,

>
> Sorry but this is another WKBI.=C2=A0 Off the top of my head some of t= he
> reasons it doesn't work are:


Thank you for your comments, John!

>
> * There is no way to tell who forwarded a message, in particular you > cannot expect the recipient to be in a To: or Cc: header.=C2=A0 You co= uld
> invent a Forwarded-By: header, but of course bad guys add fake
> headers, so you'd have to track who's supposed to be forwardin= g what
> and you'd end up with a very complex and fragile forwarder whiteli= st.


The Received: header actually does most of this -- it contains the EHLO and MAIL FROM information of previous envelopes.=C2=A0 It does not
always contain the RCPT TO (max one ends up in optional "for").
Given that SPF approves of a sender [because it is configured as a
reliable provider], one might trust the topmost Received: header to
have been delivered by that reliable party.=C2=A0 That assures us of the sender one step down, and after a few steps we've left the entrance
points to our own realm [over which we have control, so not all bad]
and then... the customary SPF magic can take place, based on the
envelope data available there.=C2=A0 The last IP address logged comes from<= br> the last trusted Received: header and that's the one that did the
crossover to our realm of control.

The devil will be in the details, I realise that.=C2=A0 But a lot of the info you mentioned actually is there already, and is even obliged.
Things like one domain leaving multiple Received: headers, and
complex MTA infra that doesn't share input and output addresses.

So, to a certain extent, sure.=C2=A0 Or, you = can just do the SPF evaluation on the edge, and pass that evaluation into y= our ADMD via the Authentication-Results header.=C2=A0 Or, use some sort of = specific local equivalent.

GSuite does allow custo= mers to specify the IP addresses of their inbound gateways, so that when th= e message finally reaches GSuite, we'll walk the received headers for t= he first one that specifies an IP address not on their list and evaluate SP= F based on that.=C2=A0 This works ok for most use cases, though we've r= ecently had some issues because the list of IPs in an ADMD can be fairly la= rge (O365 is moving to using non-private IPv6 addresses for internal server= s, which can make maintaining the list challenging).

Note that ARC is the end result of thinking of this, that we can create = a signed Received header chain containing the info we need to pass an obser= ved spf=3Dpass at hop 1 and pass that information on to follow on's acr= oss trust/ADMD boundaries and know who the actors are so we can trust the i= nformation passed.

Brandon
--001a114505a0ab0482055b377f28-- From nobody Wed Oct 11 07:12:13 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8885F13292A for ; Wed, 11 Oct 2017 07:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=f7FjyjRp; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=fDF2ryjb 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 QDc2aMvd0p3C for ; Wed, 11 Oct 2017 07:12:09 -0700 (PDT) Received: from pop3.winserver.com (groups.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4479E126E64 for ; Wed, 11 Oct 2017 07:12:09 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4595; t=1507731118; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=yGwMiEPz/WJrBDyFxFpvHfPxpkA=; b=f7FjyjRpWt0Hpqx4ZuDrO+PY7Db7PRxoyEL2WjBT0L4f5J3CB/FBnzGrbe/B5b 0Soho9TE+IhyAmPokU0y48ACherrkO6gZMJcOGpoBpavwmfoaqnli+iLsY/2xF5j nyZzGenCRf3s0kjSKptvAdSEqFxjmcI1uj204SqkXaClE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Wed, 11 Oct 2017 10:11:58 -0400 Authentication-Results: dkim.winserver.com; dkim=fail (DKIM_SELECTOR_DNS_PERM_FAILURE) 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 ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1894848781.38664.3120; Wed, 11 Oct 2017 10:11:48 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4595; t=1507731035; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=yJmvA/H +4nO26lbAUHa8/iEHf5caKZFRrgHoQrZ7Cl4=; b=fDF2ryjbg+AmDZi7l49Awfh IdUk86cYBiWjiL/FwEgkVlARwnESnIBWLjfVrK9HgJhBHms6mrWvE9FzIxPKYJcp umk1M6XoGNkTaCYgfF3hY7HID3hg1TwSJpPJfSUbzlRCIx1/nX3eyATIU8IKBtJ0 Vr2txXcHGRByi60yGnFo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Wed, 11 Oct 2017 10:10:35 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1894843828.9.75708; Wed, 11 Oct 2017 10:10:35 -0400 Message-ID: <59DE26A4.4020401@isdg.net> Date: Wed, 11 Oct 2017 10:11:48 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Rick van Rein , "dmarc@ietf.org" References: <59DA9DE9.4000102@openfortress.nl> In-Reply-To: <59DA9DE9.4000102@openfortress.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 14:12:11 -0000 On 10/8/2017 5:51 PM, Rick van Rein wrote: > Hello, > > This is a solution for SPF after forwarding and lists that I've been > aware of for a while; I wonder if this is already commonly done? > > Forwarding is an action on the receiving end, and can only be solved > reliably by the recipient. Notably, a mailbox user could specify > addresses that are forwarded to their mailbox. Mailing list > subscriptions may be seen as a special form of forwarding. > > When incoming mail is SPF-validated and the envelope sender does not > match the sending MTA address, those forwarded domains can be looked up > for the envelope _recipient_ address. Lenient SPF validation would add > permission to sending MTAs from these forwarded domains. The result > would be that forwarding never breaks, when configured on the receiving > mailbox. > > I am not sure if this is part of the "mark as NOT spam" procedures in > common mailbox services, but AFAIK it would fix quite a bundle of problems. > > I suppose this could also lead to a definition of Lenient DMARC. > > > Cheers, > -Rick Hi Rick, A few highly opinionated points: Keep in mind that SPF is a PAYLOAD (DATA smtp state) technology. In other words, it is generally processed, as it was originally intended, before the DATA smtp state. Therefore, there are limited process parameters available pre-DATA: CIP Connection/Client IP address CDN Client Domain Name (HELO/EHLO) RP Return Path (MAIL FROM) FP Forwarding Path (RCPT) So SPF is basically a function of the CIP, CDN and/or RP and generally not the FP, however some implementations, lioe ours, do not process SPF until FP is first acceptable. i.e. no need to perform the SPF Overhead if the user does not exist or the user or domain is not locally hosted. Hence there is no PAYLOAD data to be used in an SPF method unless the implementation is designed to wait until the DATA is transferred to begin an SPF. This was a latter design, in particular when Payload technologies were proposed, like ADSP and "Super ADSP" (DMARC). DMARC combined SPF, so to support DMARC, your implementation would delay SPF processing until DATA is transferred. But a key point is that no one can dictate how/when SPF should be employed during an SMTP session. High scale optimization is still important. Since 2003, my statistics showed very early on that 83% of the time, it would be a high overhead waste because if SPF was to fail at DATA, it would of also failed at PRE-DATA. This is where the old Microsoft SPF-clone Sender-ID with its PRA algorithm came into play where it took the 5322.From into account. It was a DATA technology and as with my early data analysis, if Sender-ID failed at DATA, so would SPF at PRE-DATA. It was rare to see the difference. By far, more overhead in SMTP processing by delaying SPF and waiting until the potentially wasteful DATA payload was transferred. It was certainly not optimal. But there were the conditions where there were false positives. Finally, what if the bad guy created the Headers you wanted to see? How can you stop it? When DKIM finally come along (after SPF), it helped deal with the integrity of the payload AS DEFINED by the originating author domain (5322.From). But when it was altered by the 3rd party mailers, it threw the proverbial "wrench" into the process. How to trust the 3rd party "interfering" system became the ultimate problem we have been trying to resolve. At the end of the day, nothing works when the required information needed to "answer the authorizing question" is not coming from the authoring/originating domain. ADSP and its successor, DMARC. all fail because it lacks 3rd party authorization methods. ATPS was proposed to augment ADSP to address 3rd party resigners. Still scratching head why it wasn't carried on to DMARC. It will not address all scales, but it will for most of them them. In the mean time, we continue to look for extremely high head PAYLOAD algorithms that 80% of the time, is just waste when it comes to hard rejection exclusive SPF policies or 5322.From Policies like ADSP or DMARC. It is that 20% or less, of dealing with the middle ware list server that is ignoring SPF, ADSP, DMARC and just blindly altering and resigning with DKIM. If we allow that, then any 3rd party can do the same. There is no trust. We don't have an authorization process. Thats been the dearth of tbe problem of completing this 14+ years of DKIM R&D project. We never completed a sound POLICY layer. -- HLS From nobody Wed Oct 11 07:18:42 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA02C132355 for ; Wed, 11 Oct 2017 07:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=S36jJN7m; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=ubPshkKE 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 tlrj8Zn5xfbN for ; Wed, 11 Oct 2017 07:18:39 -0700 (PDT) Received: from pop3.winserver.com (ntbbs.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4D8126CB6 for ; Wed, 11 Oct 2017 07:18:39 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4863; t=1507731509; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=rYU/u7L1Nge7XgOdLe4M4SG/T14=; b=S36jJN7mkrPQYHIPXbogLHFx5f0PsR7UTQpMAeoHdYQX4rY0EujGQfbVYJK6iJ ohCufCPS05Ch7uHr0gsREjdJAcwN56X6C4vKrAWx2fkb9Oc/JWaNw9X2qE7uFhdF 6D4qP9XoR1ZUBqbzdm2OaTpg/VSDtsj3kzDiMIIIayPKA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Wed, 11 Oct 2017 10:18:29 -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 ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1895249017.38664.2752; Wed, 11 Oct 2017 10:18:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4863; t=1507731435; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DdHjwRD k/Qmdim1HLJPWOgiUXYT3Kssd//aT9T7AZUo=; b=ubPshkKEmLzhkNMyYElYrl4 B418o7/0VvQw1MsdWKAWnydm+Wa1yQA+Qz0OThOgYVno3t/jID3TozUUy443Jxxr k6eUg1kgZpvP3XEBbWB+43o0beX2djNYXnh7mx7GVqla6fjB3Xjs1vm2+Y4Ts7E5 XuV0y919YrMebRzW5ipo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Wed, 11 Oct 2017 10:17:15 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1895243046.9.73628; Wed, 11 Oct 2017 10:17:14 -0400 Message-ID: <59DE2834.3080301@isdg.net> Date: Wed, 11 Oct 2017 10:18:28 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Rick van Rein , "dmarc@ietf.org" References: <59DA9DE9.4000102@openfortress.nl> <59DE26A4.4020401@isdg.net> In-Reply-To: <59DE26A4.4020401@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 14:18:41 -0000 sorry, meant to say SPF is NOT a payload technology. On 10/11/2017 10:11 AM, Hector Santos wrote: > On 10/8/2017 5:51 PM, Rick van Rein wrote: >> Hello, >> >> This is a solution for SPF after forwarding and lists that I've been >> aware of for a while; I wonder if this is already commonly done? >> >> Forwarding is an action on the receiving end, and can only be solved >> reliably by the recipient. Notably, a mailbox user could specify >> addresses that are forwarded to their mailbox. Mailing list >> subscriptions may be seen as a special form of forwarding. >> >> When incoming mail is SPF-validated and the envelope sender does not >> match the sending MTA address, those forwarded domains can be looked up >> for the envelope _recipient_ address. Lenient SPF validation would add >> permission to sending MTAs from these forwarded domains. The result >> would be that forwarding never breaks, when configured on the receiving >> mailbox. >> >> I am not sure if this is part of the "mark as NOT spam" procedures in >> common mailbox services, but AFAIK it would fix quite a bundle of >> problems. >> >> I suppose this could also lead to a definition of Lenient DMARC. >> >> >> Cheers, >> -Rick > > Hi Rick, > > A few highly opinionated points: > > Keep in mind that SPF is a PAYLOAD (DATA smtp state) technology. In > other words, it is generally processed, as it was originally intended, > before the DATA smtp state. Therefore, there are limited process > parameters available pre-DATA: > > CIP Connection/Client IP address > CDN Client Domain Name (HELO/EHLO) > RP Return Path (MAIL FROM) > FP Forwarding Path (RCPT) > > So SPF is basically a function of the CIP, CDN and/or RP and generally > not the FP, however some implementations, lioe ours, do not process > SPF until FP is first acceptable. i.e. no need to perform the SPF > Overhead if the user does not exist or the user or domain is not > locally hosted. > > Hence there is no PAYLOAD data to be used in an SPF method unless the > implementation is designed to wait until the DATA is transferred to > begin an SPF. This was a latter design, in particular when Payload > technologies were proposed, like ADSP and "Super ADSP" (DMARC). DMARC > combined SPF, so to support DMARC, your implementation would delay SPF > processing until DATA is transferred. But a key point is that no one > can dictate how/when SPF should be employed during an SMTP session. > High scale optimization is still important. > > Since 2003, my statistics showed very early on that 83% of the time, > it would be a high overhead waste because if SPF was to fail at DATA, > it would of also failed at PRE-DATA. > > This is where the old Microsoft SPF-clone Sender-ID with its PRA > algorithm came into play where it took the 5322.From into account. It > was a DATA technology and as with my early data analysis, if Sender-ID > failed at DATA, so would SPF at PRE-DATA. It was rare to see the > difference. By far, more overhead in SMTP processing by delaying SPF > and waiting until the potentially wasteful DATA payload was > transferred. It was certainly not optimal. But there were the > conditions where there were false positives. > > Finally, what if the bad guy created the Headers you wanted to see? > How can you stop it? When DKIM finally come along (after SPF), it > helped deal with the integrity of the payload AS DEFINED by the > originating author domain (5322.From). But when it was altered by > the 3rd party mailers, it threw the proverbial "wrench" into the > process. How to trust the 3rd party "interfering" system became the > ultimate problem we have been trying to resolve. > > At the end of the day, nothing works when the required information > needed to "answer the authorizing question" is not coming from the > authoring/originating domain. > > ADSP and its successor, DMARC. all fail because it lacks 3rd party > authorization methods. > > ATPS was proposed to augment ADSP to address 3rd party resigners. > Still scratching head why it wasn't carried on to DMARC. It will not > address all scales, but it will for most of them them. > > In the mean time, we continue to look for extremely high head PAYLOAD > algorithms that 80% of the time, is just waste when it comes to hard > rejection exclusive SPF policies or 5322.From Policies like ADSP or > DMARC. > > It is that 20% or less, of dealing with the middle ware list server > that is ignoring SPF, ADSP, DMARC and just blindly altering and > resigning with DKIM. If we allow that, then any 3rd party can do the > same. There is no trust. We don't have an authorization process. > Thats been the dearth of tbe problem of completing this 14+ years of > DKIM R&D project. > > We never completed a sound POLICY layer. > -- HLS From nobody Thu Oct 12 11:53:39 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402EB13451B for ; Thu, 12 Oct 2017 11:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net 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 NvXSU-B6kgfF for ; Thu, 12 Oct 2017 11:53:37 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 04B191344A8 for ; Thu, 12 Oct 2017 11:53:36 -0700 (PDT) Received: from [IPv6:198:18:18::251] (drscriptt-2-pt.tunnel.tserv1.den1.ipv6.he.net [IPv6:2001:470:39:62a:0:0:0:2]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id v9CIrX84026801 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 12 Oct 2017 13:53:36 -0500 ARC-Filter: OpenARC Filter v0.1.0 tncsrv06.tnetconsulting.net v9CIrX84026801 Authentication-Results: tncsrv06.tnetconsulting.net; arc=none header.d=tnetconsulting.net ARC-Seal: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1507834416; cv=none; b=dX5sLu+3d9CjdeZ+nvS3KCoHC2knZklkMFuv6fUGhY8A43R88IW4bxGQh02sUUAbl2s4B/zMkL0yKsdC7WJTz6ReTyqQ7iMmbgnZTrnOSVk/FnQIhHvf09UrOM9O5y57Su1eXi09JFfXhkhUnw5kvXzDbhSe1H8Vc2bl32tf00U= ARC-Message-Signature: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1507834416; c=relaxed/simple; bh=TU4DLGBja/TQnwnboP6swdd2sUMvjZ/C60tPxmedTu0=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:User-Agent: MIME-Version:Content-Type:Content-Language: Content-Transfer-Encoding; b=sJXHXD8QQFSIA/1UlCfk7uAMEneo161GUHRQNdLnSmyVZKO54vescbu77UnTCL7HJybM8g31VBunq1BZI1/wHW5P5EPRvczi//FWePxQgcf1k1fQ89UJ/Fu/Unw00jPefPdd5FEP/HiVyjAfx/GNjQpTrsizbTMJs1S61YX6wKY= ARC-Authentication-Results: i=1; tncsrv06.tnetconsulting.net; none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1507834416; bh=TU4DLGBja/TQnwnboP6swdd2sUMvjZ/C60tPxmedTu0=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:Cc:Content-Disposition:Content-Language: Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To: Message-ID:MIME-Version:References:Reply-To:Resent-Date: Resent-From:Resent-To:Resent-Cc:Sender:Subject:To:User-Agent; b=N5KoXOP8Y/rUt3CzOk5GyrqcNun/3fe+sI1SsaRb16YN+/xMcEdiK6mqnv3xRSzhD 4gA5snOIM7skfPlpOO/FfqtXJ3DlbfpfkHnGdT8btGhQlG07ihrtRNRhrdjsMYwN3g 6a3M9eL+sLUyLgKM5Vm6BRRCZwh+EJTuJP4QtxPc= To: dmarc@ietf.org References: <20171009022901.21038.qmail@ary.lan> From: Grant Taylor Message-ID: <6a14ffbc-d704-b168-c5f4-6b971d48d885@tnetconsulting.net> Date: Thu, 12 Oct 2017 12:53:38 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171009022901.21038.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 18:53:38 -0000 On 10/08/2017 08:29 PM, John Levine wrote: > * There is a kludge called SRS that embeds the original bounce address > in the forwarder's bounce address, but it doesn't help. Where can I find out more about how / why SRS does not help. I've been aware of SRS for quite some time and I always thought that it did address SPF issues caused by forwarding messages. -- Grant. . . . unix || die From nobody Thu Oct 12 12:17:23 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC431126B6E for ; Thu, 12 Oct 2017 12:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=WhHlcji2; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=pn6Wd5Xp 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 GFQq1ls6Dehq for ; Thu, 12 Oct 2017 12:17:20 -0700 (PDT) Received: from ntbbs.santronics.com (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 02C37120724 for ; Thu, 12 Oct 2017 12:17:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=804; t=1507835832; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=94U3e2aT1hhuc/w2HrJ0tvNzC8U=; b=WhHlcji2ix+qQ4ckxTYJzap/s4OEjaC5BKqBbYajThH4dck7csX+CncBTxH44J fGfcVT6lArcLg2vlxSqV6CfxtByZsV00M9aeUv6WrsqlVc86jXWLruTC/LvJim+t lmFCiGxjZgEYV01lm2G+n8ySflT9OTrfnmKb8QpWUrSbo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Thu, 12 Oct 2017 15:17: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 ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1999570380.38664.3176; Thu, 12 Oct 2017 15:17:11 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=804; t=1507835755; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=z4rH1pT ZZ/LFuhtA1eZLfYWU8x32JEP/Ews98CNL16A=; b=pn6Wd5XpTJnrSwLxJh6UqVQ mEbCwoeJLVNYW12J3eAj11zwAwL6kt43ccLT7FMZHAyzqDb0jTowZ1KL6De/U2W4 Ecv66uDwihC0qDM3v2KuJ/swPMBGWAGKaZhATYqdMcOGVoYh8HIG+rf0gUup77wv DW2kOuJtbSXDXyF8Z+Ps= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Thu, 12 Oct 2017 15:15:55 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1999563515.9.80004; Thu, 12 Oct 2017 15:15:54 -0400 Message-ID: <59DFBFB8.4040008@isdg.net> Date: Thu, 12 Oct 2017 15:17:12 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20171009022901.21038.qmail@ary.lan> <6a14ffbc-d704-b168-c5f4-6b971d48d885@tnetconsulting.net> In-Reply-To: <6a14ffbc-d704-b168-c5f4-6b971d48d885@tnetconsulting.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 19:17:22 -0000 On 10/12/2017 2:53 PM, Grant Taylor wrote: >> * There is a kludge called SRS that embeds the original bounce >> address in the forwarder's bounce address, but it doesn't help. > > Where can I find out more about how / why SRS does not help. > > I've been aware of SRS for quite some time and I always thought that > it did address SPF issues caused by forwarding messages. SRS "didn't work" (catch on) because there is/was a fundamental concept/idea/methodology/philosophy/taboo that the Return Path (5321.MailFrom) should never be changed/altered/tampered with along the transport path/route. It's the same long time mail engineering ethics mindset against altering the 5322.From original/authoring address to deal with 3rd party issues and ADSP/DMARC strong policies. -- HLS From nobody Thu Oct 12 13:58:10 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2095134572 for ; Thu, 12 Oct 2017 13:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net 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 xChYxP_niWe8 for ; Thu, 12 Oct 2017 13:58:08 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 27387132EDA for ; Thu, 12 Oct 2017 13:58:08 -0700 (PDT) Received: from [IPv6:198:18:18::251] (drscriptt-2-pt.tunnel.tserv1.den1.ipv6.he.net [IPv6:2001:470:39:62a:0:0:0:2]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id v9CKw5mW030747 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 12 Oct 2017 15:58:07 -0500 ARC-Filter: OpenARC Filter v0.1.0 tncsrv06.tnetconsulting.net v9CKw5mW030747 Authentication-Results: tncsrv06.tnetconsulting.net; arc=none header.d=tnetconsulting.net ARC-Seal: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1507841887; cv=none; b=Ty1QkNnBHlV0XZpEN1/8S4qw2KJTBzo1MlbdLMAYG/dC6ukvhuICVdpomd1cWx3pc5aw1dV39ToWp3k317vuwbTyfv7LwUfXCleA4bKQNCrg1RghKpuD2kEHUl+EMxirU5rX7FYbryP469dz7gEKSb2JRTqJu81COu6D5e/Y/zc= ARC-Message-Signature: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1507841887; c=relaxed/simple; bh=vZ73vH1VSzoQJg/A/geXlbs5Y+gAM+rK8UkXFWfzQss=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:User-Agent: MIME-Version:Content-Type:Content-Language: Content-Transfer-Encoding; b=6FStPZqqs3/SzTff1fM1VQ2jiQtGLbBUBnJDi1K+mPoIQ/mi/VDvxts3jtIs3WZUcSPbPbE/wsAg8EJptoOLp7kIuDhdiaz7Z51uPCNQcTl6teWH1TNxKRicgvzMa0Ij/bpgKLrjvr+nW6E7K8v1VGKEkGXn9TtHUuOGSCJZpCs= ARC-Authentication-Results: i=1; tncsrv06.tnetconsulting.net; none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1507841887; bh=vZ73vH1VSzoQJg/A/geXlbs5Y+gAM+rK8UkXFWfzQss=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:Cc:Content-Disposition:Content-Language: Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To: Message-ID:MIME-Version:References:Reply-To:Resent-Date: Resent-From:Resent-To:Resent-Cc:Sender:Subject:To:User-Agent; b=GlSWg5/e90unVJP0UTVdVYYUbOb3KasrnhiPAEudRUOvE3I8OEpVNX4hfrS/F3gs/ cfyBsNs3263txlMEKnqHf4F6X4yNSWEIrGMRFmvEVu4fInSJ1Hi9Jy6tqy7RwRAe0J Z7e847KSwc33bTXQxt89i3wgBnKYy7U08IozeUXE= To: dmarc@ietf.org References: <20171009022901.21038.qmail@ary.lan> <6a14ffbc-d704-b168-c5f4-6b971d48d885@tnetconsulting.net> <59DFBFB8.4040008@isdg.net> From: Grant Taylor Message-ID: Date: Thu, 12 Oct 2017 14:58:10 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <59DFBFB8.4040008@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 20:58:10 -0000 On 10/12/2017 01:17 PM, Hector Santos wrote: > SRS "didn't work" (catch on) because there is/was a fundamental > concept/idea/methodology/philosophy/taboo that the Return Path > (5321.MailFrom) should never be changed/altered/tampered with along the > transport path/route. Interesting. That's new to me. But I haven't administered email as a day job in a number of years. Just personal / friend / family things now. I can see why people might view the Return Path (RFC 5321 Mail From) and From header (RFC 5322 From) as sacrosanct. I can somewhat get behind it. At least for the normal delivery path, including relays. I guess I personally view things like forwarding email and mailing lists as being the end of one delivery path and the start of a second delivery path. > It's the same long time mail engineering ethics mindset against altering > the 5322.From original/authoring address to deal with 3rd party issues > and ADSP/DMARC strong policies. I strongly view things like the original recipient's .forward file and mailing lists to be entities unto themselves. I deliver messages to them, and they can do what ever they want to with them. If that means that they generate new messages (Auto-Submitted: auto-generated) based on the incoming messages, so be it. - I view these new messages as being from said entity, thus think the 5321.MailFrom and 5322.From /should/ reflect said entity. I know that I am *not* personally sending /individual/ messages to all of the DMARC list subscribers. - I /am/ sending a single message the DMARC mailing list. Subsequently the DMARC mailing list is sending many individual messages to all the list subscribers. ;-) But, to each his / her own. Thank you for the enlightenment Hector. -- Grant. . . . unix || die From nobody Fri Oct 13 10:04:22 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31F213320C for ; Fri, 13 Oct 2017 10:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable 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 1HWLOXk3nnGe for ; Fri, 13 Oct 2017 10:04:19 -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 3A84F13243A for ; Fri, 13 Oct 2017 09:54:43 -0700 (PDT) Received: (qmail 93732 invoked from network); 13 Oct 2017 16:54:41 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 13 Oct 2017 16:54:41 -0000 Date: 13 Oct 2017 16:54:19 -0000 Message-ID: <20171013165419.49325.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: gtaylor@tnetconsulting.net In-Reply-To: <6a14ffbc-d704-b168-c5f4-6b971d48d885@tnetconsulting.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 17:04:20 -0000 In article <6a14ffbc-d704-b168-c5f4-6b971d48d885@tnetconsulting.net> you write: >On 10/08/2017 08:29 PM, John Levine wrote: >> * There is a kludge called SRS that embeds the original bounce address >> in the forwarder's bounce address, but it doesn't help. > >Where can I find out more about how / why SRS does not help. SRS is one of those magic bullets that might have worked if everyone in the world implemented it at the same time, and the design were written by someone who understood the security issues. In the real world, any change to e-mail is implemented gradually, so you have to be prepared for the old way and new way to work in parallel for a long time. So if you have to be prepared to ignore overenthusiastic SPF -all anyway, who needs SRS? There's no technical way to tell an incoming message with a real rewritten SRS address from one with a fake SRS address intended to make spam look less spammy, other than by checking against a whitelist of known virtuous forwarders. But if you have that whitelist, you don't need SRS, you just skip the SPF check on mail from those forwarders. (Gmail approximately does that.) The other problem that SRS is supposed to fix, forwarding back bounce messages, barely exists any more. Due to the floods of spam with forged return addresses, bounce messages are now mostly reflected spam going back to someone who didn't send the message in the first place. MTAs (other than those written in Redmond WA) try hard to reject undeliverable mail during the initial SMTP session rather than accept and bounce. The comment about some rule against changing bounce addresses is wrong. Every mailing list rewrites the bounce address on mail it forwards. That makes sense for lists, since they need to handle subscriber bounces, not the person who originally sent the message. R's, John From nobody Fri Oct 13 10:24:32 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D101331FF for ; Fri, 13 Oct 2017 10:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net 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 CRk-NnAANcmj for ; Fri, 13 Oct 2017 10:24:29 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 ABA7B13330C for ; Fri, 13 Oct 2017 10:24:26 -0700 (PDT) Received: from hal9000.thn.corp.google.com ([IPv6:2620:0:102a:11:1142:fc0c:2906:8f16]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id v9DHOMdR029065 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 13 Oct 2017 12:24:26 -0500 ARC-Filter: OpenARC Filter v0.1.0 tncsrv06.tnetconsulting.net v9DHOMdR029065 Authentication-Results: tncsrv06.tnetconsulting.net; arc=none header.d=tnetconsulting.net ARC-Seal: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1507915466; cv=none; b=r6SYz6W3z9Y0SFedPlCcIJ3BDNqLmOY3mOtgX/okY7suRDvMWxGtFeMkdrOqyZT5KoForOxVQ2vddna87MOE08jiN7pvXuTUCkdd5p9F9iLwyf/x69dk/7qLcMPyIJ2uMKIdLKIrHcX7ao2gWeC/KH6hl8RalrkEGP7OyEbODJ8= ARC-Message-Signature: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1507915466; c=relaxed/simple; bh=1g8QuAQYX9x7ZBWddSkcvav/jtk6ax9xDHXa/jxv0qQ=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:User-Agent: MIME-Version:Content-Type; b=UJNm4C1GHRczocCIA4ati9cAOp9Cp2C4XlQ5mkeTaCPciwU+GWT+UaXB3Iy66AqFMjRaSKG2As5qyTFtyjt5ELKFe1R/8w8h0nWper7sKojdS9UNbDovP7ALXiq8IHL3fgIYwkTw297cYcUbeF48S7Cxmxc8cYPWyhW4wro5ork= ARC-Authentication-Results: i=1; tncsrv06.tnetconsulting.net; none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1507915466; bh=1g8QuAQYX9x7ZBWddSkcvav/jtk6ax9xDHXa/jxv0qQ=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=hTbzsoW3GLHL2cD/MPoy0c8M2NCAZbH60zfxvuK+E+F31+fLZUasz4M5ysogMhTkH K3bPJkdtXw7h0/JFfBJlLdZjIrYdCyLkXW9/zaTvXxcGPe2obN0bMS4wsCzlu0rS5q YRV/BZdL9DldueW86aAKCLGyzrgaRVXv9ARHGEiU= To: dmarc@ietf.org References: <20171013165419.49325.qmail@ary.lan> From: Grant Taylor Message-ID: <5fca5469-8673-9555-8e47-e2251632f3a1@tnetconsulting.net> Date: Fri, 13 Oct 2017 11:24:22 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171013165419.49325.qmail@ary.lan> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070900000705080509080804" Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 17:24:31 -0000 This is a cryptographically signed message in MIME format. --------------ms070900000705080509080804 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/13/2017 10:54 AM, John Levine wrote: > SRS is one of those magic bullets that might have worked if everyone=20 > in the world implemented it at the same time, and the design were=20 > written by someone who understood the security issues. Would you please elaborate on (or point me to existing documentation) on = the security issues that you're referring to? > In the real=20 > world, any change to e-mail is implemented gradually, so you have to=20 > be prepared for the old way and new way to work in parallel for a long = > time. Agreed. > So if you have to be prepared to ignore overenthusiastic SPF=20 > -all anyway, who needs SRS? Maybe it's just me, but I've never felt the desire to ignore=20 overenthusiastic SPF. Rather I've always been more of the opinion to=20 push back and have the (purported) sending domain adjust their SPF=20 record or persuade the forwarder to use something like SRS. I feel that if a sending domain sets "-all" they (hypothetically) know=20 what they are doing and that they do in fact want me to treat things=20 that fail SPF as spam. - Or the first few failed deliveries turns into = a learning opportunity for the sending domain and they adjust their polic= y. > There's no technical way to tell an incoming message with a real > rewritten SRS address from one with a fake SRS address intended to > make spam look less spammy, other than by checking against a whitelist > of known virtuous forwarders. What's wrong with using SPF to filter fake messages coming from an=20 invalid source? I.e. -all on the SRS domain. (I typically have each=20 MTA use it's hostname as the SRS domain and publish an SPF record for=20 the host that only allows it to send messages from it's name.) > But if you have that whitelist, you > don't need SRS, you just skip the SPF check on mail from those > forwarders. (Gmail approximately does that.) I've never felt the need for such a white list. - Maybe it's the=20 nature of my small mail server having different use cases compared to=20 the bigger players. > The other problem that SRS is supposed to fix, forwarding back bounce > messages, barely exists any more. Due to the floods of spam with > forged return addresses, bounce messages are now mostly reflected spam > going back to someone who didn't send the message in the first place. > MTAs (other than those written in Redmond WA) try hard to reject > undeliverable mail during the initial SMTP session rather than accept > and bounce. I agree that's how things should be. Sadly, I still see people not=20 doing so, and sending bounces after the fact. > The comment about some rule against changing bounce addresses is > wrong. Every mailing list rewrites the bounce address on mail it > forwards. That makes sense for lists, since they need to handle > subscriber bounces, not the person who originally sent the message. I assume you're referring to Hector's comment about the "Return Path=20 (5321.MailFrom)" being sacrosanct. --=20 Grant. . . . unix || die --------------ms070900000705080509080804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CgIwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVLMIIEM6ADAgECAhBWFNl+TpTaXY4YBuKunuW7MA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTYxMTIyMDAwMDAwWhcNMTcxMTIyMjM1OTU5WjArMSkwJwYJKoZIhvcNAQkB FhpndGF5bG9yQHRuZXRjb25zdWx0aW5nLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALQOeB9QxYwFjGM8smbnZihDiEsKsBBX0H1M9WC/HjeHf+AO26QH4mdiN+XpFMVy yVyZqEbgheL49o7qcRPf2PPVck+E67zn8b/kef1LbWde++QDMg56zZvAU4CbF7/v98WnHpzY LP+3AWK0z/7IfBwujQE8xW6E0vTZznq8GGP5z6pGSap4gKh/a8erEVcoYdK2IuWYa4sNxOvo FICiOoCMJhvU1F92yuuXCRZcZwFyav7P3+M36jHdViH2fuZuOhZBWb419mmhtUWS8r6aVdfk Vq+Pz3NdvLdo6AsUZpf7dZr/LeLW6gr2VoDQ5+j1JtI24wzl42RAVTsANoH/OusCAwEAAaOC AfgwggH0MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSxNT5f 50Ax2YRcuiCuDfxHUlkuGjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUE GTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/ MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9k by5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NP TU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAG CCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZ3RheWxv ckB0bmV0Y29uc3VsdGluZy5uZXQwDQYJKoZIhvcNAQELBQADggEBACCtfMI0hVAiQKvOx9Br ffT4YUPJRlXcs6yoDHfg0bnVw/ucEJ1neOi/aIUdA6EypUMNrshmgJTNaj6CsRH8c0yXOeGd nO5tNrPMYAhVvCQo/gpliYhIs2RAKXgFNtkUufwTqOQOLZva4LLVxSuSYncAgxdaj6TcORsd 9NEKPUC03F8yW0hk2M6WqvOpyIG4CWAP8Tmrxs0OKZuQeAoI3bs103EuMiMBTFIeEm8Obvx+ svg+UhK0CaMjEH92AwZ4blouFxqGTlgE/wclDCe+tZr/FvBP4Vflm/o82IkvyiNff8Qwz/BS z1hTRwSc7JexXVTms1cS7rMBRFwcvU2Le6kxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBWFNl+TpTaXY4YBuKunuW7 MA0GCWCGSAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzEwMTMxNzI0MjJaMC8GCSqGSIb3DQEJBDEiBCC4bh/Q2u0apHEHfoSWArPF qpa9Km6Rcye3gmvz/yaP4DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQVhTZfk6U2l2OGAbirp7luzCB wwYLKoZIhvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5k IFNlY3VyZSBFbWFpbCBDQQIQVhTZfk6U2l2OGAbirp7luzANBgkqhkiG9w0BAQEFAASCAQAq ZrQrjpa9tpaKQLp5Iepegf4ruFlSlsQJsu2rKJO9Ip09GVvEee50RGJQBZqGdfRtw2Z6/vAT i2DkgOdmbfyL9qdNxDJapQGPyLoy268RTWDrcaetDPhox5ImuvFDEfUKLe9hYHt82xCI+8NN TNSwfWK0dhAHL8PPfGvUSHWM0peapbQqV623pci+2ndUWOCYpK9ahWt/IzWx/NWNcw10Bxwx Vc6UO6h/ZqJSJvvpyxnROfQ9gGENGfCsSDXvw6G29SXjzxye+iffPaNRBC6VwbLrte0MDuA2 kR8SoCgICf1vosfoPCC24ai5G/5KFIGdXGIUdjaRihL2QuXDIvTKAAAAAAAA --------------ms070900000705080509080804-- From nobody Fri Oct 13 12:36:57 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD223132396 for ; Fri, 13 Oct 2017 12:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl 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 rjRFJRCSExJD for ; Fri, 13 Oct 2017 12:36:52 -0700 (PDT) Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (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 9563E126BF0 for ; Fri, 13 Oct 2017 12:36:51 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud9.xs4all.net with ESMTP id 35lGepQGFnIXb35lHeyVAF; Fri, 13 Oct 2017 21:36:50 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1507923399; h=message-id : date : from : mime-version : to : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=pc6eAl2r9QG9oeXI7baWhdZgrCmQyr8lH5vblze2sr8=; b=l+6ZXudmARczTAeknA6vzFnqj027kL11Est9fHyjxt38XuebxRwTTqlV KaNV44xI+WsBNhVZaIyUHQ5ihj18I9t+V/Olv5+fXEIE6G+FjdrYRXZASB rweCagEqiF5d18i5zHCOfWrAjpc6fMVWmobQkcXJcRj0ecNnDE72EvtYo= Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id E25EB1C6A8; Fri, 13 Oct 2017 19:36:39 +0000 (UTC) Message-ID: <59E115C0.7010507@openfortress.nl> Date: Fri, 13 Oct 2017 21:36:32 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "dmarc@ietf.org" References: <59DA9DE9.4000102@openfortress.nl> <59DE26A4.4020401@isdg.net> <59DE2834.3080301@isdg.net> In-Reply-To: <59DE2834.3080301@isdg.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfL/htTTRZ++Y2+nI9h+yhE9jrdh9T4PbreNih89gaQdliHHMuCfPvXDe2/mVkgAJRrZWLn2wd+6LV1A3SurTv/w9yLWkFuDQ/wImkbdbjJUcqoqOZRxG Etb90YY32hnnAf68n1ym9Auvs5hYf/LOnH7bXl4LssbZqxODjcPm//n0 Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 19:36:57 -0000 Hello Hector, Brandon, Dave and John, Thanks for the detailed responses to what may be naive questions that pop up again and again... It is quite clear that SPF is more problematic to make work through unknown relays and lists than DKIM, and so that my proposed work on Lenient DKIM is a better thing to work on. As for responding to such questions, it is indeed helpful to know *why* things were decided against, especially if this was 10 years ago. History should not repeat itself, but the grounds for a decision are useful to weigh again every now and then. This is one of the reasons why I was asking around. It's interesting to hear that rolling back of Received: headers is done at Google [apparently with /128 prefixes for IPv6, and resulting trouble with private address changes] and the reason I find it interesting is that we're designing an identity system that would also manage external aliases, so it could do the thing of which we discussed that [at least some] users might use to shoot themselves in the foot. Very clear in all this is that SPF is riddled with problems and should not be included lightly. SRS puts a strain on intermediates and won't solve things IMHO. I wish I could say otherwise for DKIM, but that too breaks more than I like, and so I am really really looking forward to the next ARC draft and hope to also come up with a MIME-aware canonicalisation proposal in proze/draft and poetry/code. Thanks, -Rick From nobody Fri Oct 13 14:21:42 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49235132811 for ; Fri, 13 Oct 2017 14:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=jHJV2gF/; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=LTrj92lt 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 dGjdNBH20cHa for ; Fri, 13 Oct 2017 14:21:39 -0700 (PDT) Received: from groups.winserver.com (listserv.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2F61321B6 for ; Fri, 13 Oct 2017 14:21:39 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1006; t=1507929689; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=6qFph8rgzXDXWC6weMyfN9jk4Zo=; b=jHJV2gF/x+Y4M6/HxSwzj/IWEYGNy/B/XzXS1nDwMB8vbP2ONtT90uLmyDXppK /bMQ2V+h0hrZR/JcOFAX1GrNh5Jt9x03CrSQc3j2vfh1m7zV43WF1eKRu6RQy55X hi7i6G1fOwfUvgYhydgGWTDAM8Vze6zLdBd6SDd2FtBIU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Fri, 13 Oct 2017 17:21:29 -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 ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2093426463.38664.4056; Fri, 13 Oct 2017 17:21:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1006; t=1507929611; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0zDYlzY ss42DnBQVxpMGRY3W5dzk95QrvkuK5YENTiw=; b=LTrj92ltpxcv9rLMroL2UbI Dm/q5slHHdkBh3LXx7PZL+lPZG+WGoxrG6peNGgAThUPP+bxPAxpQFTF8zGW63q8 6TAFRaqkQ4FtqeqiUmLKdJJUObMd+qF84vUaq1oKRAHtNxTUguJpxRzJV4nTNuyh Y0EmMyHOFQci/t7WiCSA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Fri, 13 Oct 2017 17:20:11 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2093419625.9.84520; Fri, 13 Oct 2017 17:20:10 -0400 Message-ID: <59E12E5C.2080006@isdg.net> Date: Fri, 13 Oct 2017 17:21:32 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20171013165419.49325.qmail@ary.lan> <5fca5469-8673-9555-8e47-e2251632f3a1@tnetconsulting.net> In-Reply-To: <5fca5469-8673-9555-8e47-e2251632f3a1@tnetconsulting.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 21:21:41 -0000 On 10/13/2017 1:24 PM, Grant Taylor wrote: >> The comment about some rule against changing bounce addresses is >> wrong. Every mailing list rewrites the bounce address on mail it >> forwards. That makes sense for lists, since they need to handle >> subscriber bounces, not the person who originally sent the message. > > I assume you're referring to Hector's comment about the "Return Path > (5321.MailFrom)" being sacrosanct. Note, a "Mailing List" is a whole different horse in this matter. That would be a 1::Many (one to many) group-ware distribution process where historically, the return path is (almost always) set to the bounce/error/list-admin/distributor/mailer-daemon address -- never the original message author submitter. It didn't make technical mail sense to do that. There was never any ambiguity about that with List Server development. That was not the case in a 1::1 direct/private transport where persistency was expected along the SMTP transport path. -- HLS From nobody Sun Oct 15 18:39:46 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431B11332E3 for ; Sun, 15 Oct 2017 18:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, URIBL_BLOCKED=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 lkUTRa_OD7wv for ; Sun, 15 Oct 2017 18:39:42 -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 9B7EA1332DA for ; Sun, 15 Oct 2017 18:39:42 -0700 (PDT) Received: (qmail 70126 invoked from network); 16 Oct 2017 01:39:41 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 16 Oct 2017 01:39:41 -0000 Date: 16 Oct 2017 01:39:19 -0000 Message-ID: <20171016013919.63039.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: gtaylor@tnetconsulting.net In-Reply-To: <5fca5469-8673-9555-8e47-e2251632f3a1@tnetconsulting.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 01:39:44 -0000 In article <5fca5469-8673-9555-8e47-e2251632f3a1@tnetconsulting.net> you write: >-=-=-=-=-=- > >On 10/13/2017 10:54 AM, John Levine wrote: >> SRS is one of those magic bullets that might have worked if everyone >> in the world implemented it at the same time, and the design were >> written by someone who understood the security issues. > >Would you please elaborate on (or point me to existing documentation) on >the security issues that you're referring to? See the paragraph about forged domains and whitelists in the original message. >> So if you have to be prepared to ignore overenthusiastic SPF >> -all anyway, who needs SRS? > >Maybe it's just me, but I've never felt the desire to ignore >overenthusiastic SPF. It's just you. I talk to people who run large mail systems, and without exception they tell me that they do not reject on spf -all other perhaps a plain -all which means someone sends no mail at all.. The false positive rate would just be too high. >I feel that if a sending domain sets "-all" they (hypothetically) know >what they are doing ... Wow, you're the optimist. R's, John From nobody Sun Oct 15 19:50:09 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CC6133352 for ; Sun, 15 Oct 2017 19:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=frnad7HI; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=koFVAMtp 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 ldR8p_brO0xO for ; Sun, 15 Oct 2017 19:50:01 -0700 (PDT) Received: from news.winserver.com (catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id D302013339D for ; Sun, 15 Oct 2017 19:49:57 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2544; t=1508122193; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=QQPoaZleOLVB28u7KhveXa0/5k4=; b=frnad7HIgOdrzpjj43hjgwNV2VDEaVgveHFAUJzhw8XCOhdLL6VgkumIrH3aZc QIzutpAXAbJnOPDCnXnAc8LsKfJ+vj4KK69ZZs6S9lOXiT2/UNpx3nEkkIRFfNq7 TRbFYr1oZLc5XtYtAkHkdLwsNmKAKjefi/Nh6ENmyaz/g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 15 Oct 2017 22:49:53 -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 ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2285928608.38664.3900; Sun, 15 Oct 2017 22:49:52 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2544; t=1508122112; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=kwGON1B X/93WN0bQoerAJqawaZ053Op9ApKhfdqqQfc=; b=koFVAMtpm53qI7qzBbM3jQQ JgbPiMFTBg8onhykXCd+BhKiGbl+A6gpuPp3hXAOPglAA2j/1R8oa3DZXNeuQid4 aM9YbJbVTTluXuHiX2njPKc2RWc7LjGhKOVS/7yDgfnVTh2KlQYMYGxfl8s2crWg JP288L+fYyLcZZthMvNw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 15 Oct 2017 22:48:32 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2285919937.9.90876; Sun, 15 Oct 2017 22:48:31 -0400 Message-ID: <59E41E4D.5030409@isdg.net> Date: Sun, 15 Oct 2017 22:49:49 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20171016013919.63039.qmail@ary.lan> In-Reply-To: <20171016013919.63039.qmail@ary.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 02:50:03 -0000 >> Maybe it's just me, but I've never felt the desire to ignore >> overenthusiastic SPF. > > It's just you. I talk to people who run large mail systems, and > without exception they tell me that they do not reject on spf -all > other perhaps a plain -all which means someone sends no mail at all.. > The false positive rate would just be too high. Expressing a different point of view since the world of electronic mail is not completely made of "large mail systems." Its not just him. Big difference on whether its a public ESP with forwarding, hosting operations or a private (any size) domain who generally deal with final destination operations only and are not in the business of forwarding/hosting or they got out of the hosting business like so many did. From a SPF functional specs standpoint, if a domain has a -ALL policy, it would be an operational mistake to presume or expect receivers will not be rejecting their mail on SPF failures. A mistake on their SPF policy holder part to believe that receivers will be accepting failures when the specs (old and new) has it burned in to be a rejectable condition. The older, original spec was very clear about, the newer spec appropriately expounded on the potential risk for false positives. Nonetheless, the SPF hard fail intention is to REJECT, not to ACCEPT. Therefore a mistake to believe receivers will always accept the failed SPF message. It would also be a operational mistake to presume rejection will not take place at SMTP immediately, before DATA and before DMARC is processed at DATA. Do not presume that a DMARC receiver will delay the rejection until the payload is transferred. For our package, out of the box, our mostly private operators have SMTP reject on hard fail policies. That is what the domain wanted, that is what the spec indicated can happen, that is what they can get -- an immediate dynamic rejection. In 14 years of using SPF, it has never been a big support discussion. SRS came up here and there but I don't think operators have been changing the default, but if they did, no big deal. Just do it because SPF was not for their operation. There have been operators who turned off SPF completely because they have combined their mail frontends but overall, 14 years worth of stats have shown a low to nil false positive, i.e. hardly ever any support concerns. To me, SPF has been highly successful with a high confidence payoff of between 4% to 8% dynamic rejection rate over the years. -- HLS From nobody Sun Oct 15 20:52:31 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C951270AE for ; Sun, 15 Oct 2017 20:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net 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 X775UwvAge1r for ; Sun, 15 Oct 2017 20:52:28 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 B6C89132A05 for ; Sun, 15 Oct 2017 20:52:28 -0700 (PDT) Received: from [IPv6:198:18:18::251] (drscriptt-2-pt.tunnel.tserv1.den1.ipv6.he.net [IPv6:2001:470:39:62a:0:0:0:2]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id v9G3qQGH026190 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 15 Oct 2017 22:52:27 -0500 ARC-Filter: OpenARC Filter v0.1.0 tncsrv06.tnetconsulting.net v9G3qQGH026190 Authentication-Results: tncsrv06.tnetconsulting.net; arc=none header.d=tnetconsulting.net ARC-Seal: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1508125948; cv=none; b=f/ZV5/v7zDnCBcjqQM+4NgXy44CQmmpngY84yexl/jFlzQRQRj0H27I3T/BBN4Ljr/FPxHe0yk/XQtKpKRkFuQBmm52n/nHYM1tFMN73TxHQTSq7pWivuo9x7UmiahEsQ5AgZ4ACfNArxKD0knbmsq1xEOo4nrrjRpJpgwSQm/o= ARC-Message-Signature: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1508125948; c=relaxed/simple; bh=ko1ZfqaaxomB9cnOu46M47I58bhNmV2HPnkTbz+seDo=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:User-Agent: MIME-Version:Content-Type:Content-Language: Content-Transfer-Encoding; b=fVQmrq5fXLYgiZcw4HBlZrJ5hFalmPjQsMtlww5dA/EOdbvKuITuToKSedCZheQ3r1vucHH+Ia9LGk7iIKBQojoDM9C/YM92fDDYoUiQ1ruEPJyu0LBgToi+8299OVVx6QBsY4ttt1B0iT8XR0ebVVBAasp6G5RCv3L+tRVR3Ts= ARC-Authentication-Results: i=1; tncsrv06.tnetconsulting.net; none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1508125948; bh=ko1ZfqaaxomB9cnOu46M47I58bhNmV2HPnkTbz+seDo=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:Cc:Content-Disposition:Content-Language: Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To: Message-ID:MIME-Version:References:Reply-To:Resent-Date: Resent-From:Resent-To:Resent-Cc:Sender:Subject:To:User-Agent; b=gsmZYm0KbLbSvzo+LuQnyHlx12e/0Dy4idZiaBvyDyvtLGppxDeq9FZ2Hq3fUryBM hMVo/fNGlVhm5UtPfPSzmcNKDqsVM+HUwEarZyMx0Yw0fcD/QsUyUDgGj7ZKzDg6H4 Z+QqtIC9tRvcceMMCP/nxJuJi8E2dFa/Y9Yus1ic= To: dmarc@ietf.org References: <20171016013919.63039.qmail@ary.lan> From: Grant Taylor Message-ID: Date: Sun, 15 Oct 2017 21:52:26 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171016013919.63039.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 03:52:30 -0000 On 10/15/2017 07:39 PM, John Levine wrote: > See the paragraph about forged domains and whitelists in the original message. *chuckle* Okay. I feel like having each forwarding host use SRS with it's own FQDN as the from domain -and- publishing an SPF record for the host with -ALL covers that. However, given what I think I've learned about your opinion of SPF -ALL, I can see why you say what you say. To each his / her own. > It's just you. I talk to people who run large mail systems, and > without exception they tell me that they do not reject on spf -all > other perhaps a plain -all which means someone sends no mail at all.. > The false positive rate would just be too high. I doubt that it's just me. I may well be in the extreme minority. But I find it hard to believe that it's just me. (Disregard if you were re-using the words that I poorly chose.) > Wow, you're the optimist. I am, but I think that's independent of this. If you tell me that you will only send email from given location(s) and that I should treat everything from anywhere else as suspect, that's exactly what I'm going to do. I believe that the onus is on you to either adhere to what you say, or change what you say to reflect your new sending location(s). I believe in Taylor Mali's "policy about honesty and ass-­‐kicking: if you ask for it, then I have to let you have it." Link - What Teachers Make - https://taylormali.com/poems/what-teachers-make/ If you put "-ALL" in your SPF record, I'm going to reject messages purportedly from you that fail your SPF record. ;-) -- Grant. . . . unix || die From nobody Sun Oct 15 23:23:50 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C77C1342E8 for ; Sun, 15 Oct 2017 23:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=fwH9YlGz; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=XsoQyu5/ 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 84p5pd3UxpFC for ; Sun, 15 Oct 2017 23:23:47 -0700 (PDT) Received: from ntbbs.santronics.com (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id DD75E1342EB for ; Sun, 15 Oct 2017 23:23:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2258; t=1508135023; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=V/v8+zOa7WeLuezxoJ81x1ytR64=; b=fwH9YlGz8gHez2owjchG8XSR0b2Oi7lFFVzltt2geFSY0eAaDVdFbIQOQOkR8p ZiUENyuvncrpQ45OPRxapksDoAH47nrqZvTndgpJHR1BHz/oCmY2mMoktd1udRaG GzcQQKLelldwrJzT2PxJnqoAmTo7o87+Uxum7HNPkugIs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Mon, 16 Oct 2017 02:23:43 -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 ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2298758879.38664.2828; Mon, 16 Oct 2017 02:23:43 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2258; t=1508134943; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=FlzEid2 zUK1NHw5DYPkLuEdbn+xCrakxnqLXxMxc/1o=; b=XsoQyu5/8WZ/9jGcNAxFYVe YJoiN0zweiGAtxw1lFAkFKUwlTGFjd9bAKVhISYh81bRmkbv3YGVSeMGx8v7o7Ad ZcUr9No0yKNppyOXBkTZL6YlX9IKPrbABhCR4RS5U3HHjIfj/4AmcgApraCtVpR4 Fyjfy1EH85Hj4abRLy+o= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Mon, 16 Oct 2017 02:22:23 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2298751671.9.95572; Mon, 16 Oct 2017 02:22:22 -0400 Message-ID: <59E4506D.8060300@isdg.net> Date: Mon, 16 Oct 2017 02:23:41 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20171016013919.63039.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Lenient SPF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 06:23:49 -0000 On 10/15/2017 11:52 PM, Grant Taylor wrote: > On 10/15/2017 07:39 PM, John Levine wrote: >> Wow, you're the optimist. > > I am, but I think that's independent of this. > > If you tell me that you will only send email from given location(s) > and that I should treat everything from anywhere else as suspect, > that's exactly what I'm going to do. > > I believe that the onus is on you to either adhere to what you say, or > change what you say to reflect your new sending location(s). > > I believe in Taylor Mali's "policy about honesty and ass-­‐kicking: if > you ask for it, then I have to let you have it." > > Link - What Teachers Make > - https://taylormali.com/poems/what-teachers-make/ > > If you put "-ALL" in your SPF record, I'm going to reject messages > purportedly from you that fail your SPF record. ;-) +1. For failures, the SPF domain declaring an -ALL is expecting rejection and if not, due to a receiver local policy, the SPF domain will|should expect the accepted message to be separated from the target user's main online mail in-box stream and/or POP3 mail stream which is generally a single pickup channel, not one combined with normal+spam folders. Don't presume IMAP is always users or Online only. POP3 is still active. See the RFC7208 security considerations section 11.7. https://tools.ietf.org/html/rfc7208#section-11.7 11.7. Delivering Mail Producing a "Fail" Result Operators that choose to deliver mail for which SPF produces a "fail" result need to understand that they are admitting content that is explicitly not authorized by the purported sender. While there are known failure modes that can be considered "false negatives", the distinct choice to admit those messages increases end-user exposure to likely harm. This is especially true for domains belonging to known good actors that are typically well-behaved; unauthorized mail from those sources might well be subjected to much higher skepticism and content analysis. SPF does not, however, include the capacity to distinguish good actors from bad ones, nor does it handle the concept of known actors versus unknown ones. Those notions are out of scope for this specification. -- HLS From nobody Wed Oct 18 15:19:49 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA37A1321A1 for ; Wed, 18 Oct 2017 15:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonnection.nl 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 ibgpNvzy393G for ; Wed, 18 Oct 2017 15:19:45 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id B46281320B5 for ; Wed, 18 Oct 2017 15:19:45 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3yHRLl6GM3z1LBKr for ; Thu, 19 Oct 2017 00:19:43 +0200 (CEST) Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3yHRLl30Xsz1L8k2 for ; Thu, 19 Oct 2017 00:19:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id 32D604222A0 for ; Thu, 19 Oct 2017 00:19:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id O88g3OQ37pYu for ; Thu, 19 Oct 2017 00:19:43 +0200 (CEST) Received: from [192.168.40.49] (unknown [192.168.40.49]) by tiger.sonnection.nl (Postfix) with ESMTPSA id 1BCEE42229F for ; Thu, 19 Oct 2017 00:19:43 +0200 (CEST) From: "Rolf E. Sonneveld" Organization: Sonnection B.V. To: "dmarc@ietf.org" Message-ID: <1bf4325a-b660-b77b-3f3e-aaf565e0084a@sonnection.nl> Date: Thu, 19 Oct 2017 00:19:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1508365183; bh=8FrO+SxovBprrZ3cWQ9RmY7bhv7/wX5Y9TbkXaOc2YE=; h=From:Subject:To:Message-ID:Date:From; b=UJs8PB9wd1KzP3tEjo+gBLRpMbiNF5aaxNngvZgG5yIrPwVAbqmTzjKNpl37e7lcF qaKNvBLtLPjbymziLCGEghvHIxSV1KpyZw/BDs2mRFZbr0N21MbJ3zpECx3/ExQkZI We3Dm6eQxrFsWuksFTy3rWh3qvyuxsseOZqUQlnM= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3yHRLl6GM3z1LBKr Archived-At: Subject: [dmarc-ietf] Binding Operational Directive 18-01 require agencies to implement STARTTLS, SPF and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 22:19:48 -0000 Hi, See https://cyber.dhs.gov/ DKIM is mentioned but not required, nor any negative side effects that the use of DMARC can have. Has anyone from the IETF been consulted for this directive? /rolf From nobody Fri Oct 20 03:12:09 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04AC13301F for ; Fri, 20 Oct 2017 03:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 rArBzijzfZDN for ; Fri, 20 Oct 2017 03:12:05 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 C00C41321DF for ; Fri, 20 Oct 2017 03:12:05 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id 1so17813081qtn.3 for ; Fri, 20 Oct 2017 03:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nAbs7sFS32NqmNYK12ut2FT65lofu/zTpRfaDoGXBtw=; b=e4lYj4FL4WZhaAQ9g/Aq39MqusoB3F7TTnm6YBvlV1sNKDZMY6tR7Lrulggj3hNJAR vDOWgTdfqfe1wXrHQXOq74QJaR1nEyWymcwCudSSS6QcaM0x/LVctHnqYQ7Xe18zRdor mtPpUQ0xAB4IPNPAA5b6e6udv5R+cATFFzM58lqKNDKpzVAx+hWdsWGfSDFJ86mPsT4u yrxXDmQ0SqViyhRJgwwvmMz4dwYH5wZlXivH7aSCFc22bi0Beo+HrezGQrmdSaB8qSy9 dsP+F1OsnK518SfdCWCbx1pmmedXarAaATeJkQmn6OldhnoJ9Kn2wqwpI5keZ6JHZcBE iagg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nAbs7sFS32NqmNYK12ut2FT65lofu/zTpRfaDoGXBtw=; b=Hldq/3LzzNf5HzEgUIsl+hF6hLKNM7OlomtVSorw4v2hUJ+M0WzgcUKCzOK0JgrIlk F14h7xfljYDZAoVqUg7LRSWyTBubMX1oanV41Vc2yfTNUAT3FVo4LJ7AARLj2OCaF2Xu 6ZQNtowyxxOIE4nBpkoPkSqLbs9vMn5ti+ItQ+GP/rmvdsTN/xiC4P2W88FB45c5BH/N O17IeLozEwNnixJT3TMT65Mk5RMI6H2qVfikpwLCeBO8/huNewYUPEpHBSbyjcOUAkb0 29ehx3DFgVbQFfqQ9prhXUlg/ren1gQ/+iFdHQj6LcubxwYQnT9US7nXa+4s/4HuR5hF PwjQ== X-Gm-Message-State: AMCzsaVLYpShveXknRyt5KZSq5VZLzNWuaxjgdEdOq1yhsCJDDLnf0m3 x/8evaQtP291EFEFpmLHY9P3Oje7pulL518ufP9EDqh9 X-Google-Smtp-Source: ABhQp+QlJl4qCwNtJJKFQXj4jLGcOFP736CEHLPTiLwEIfjSppSl4jXzvimJFSYTrOOyaDtXWWXQ68ghGFEPbpaXErw= X-Received: by 10.200.34.182 with SMTP id f51mr5555883qta.167.1508494324854; Fri, 20 Oct 2017 03:12:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.15.1 with HTTP; Fri, 20 Oct 2017 03:12:04 -0700 (PDT) In-Reply-To: <1bf4325a-b660-b77b-3f3e-aaf565e0084a@sonnection.nl> References: <1bf4325a-b660-b77b-3f3e-aaf565e0084a@sonnection.nl> From: Henrik Schack Date: Fri, 20 Oct 2017 12:12:04 +0200 Message-ID: To: "Rolf E. Sonneveld" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113f476c60f4e5055bf7b482" Archived-At: Subject: Re: [dmarc-ietf] Binding Operational Directive 18-01 require agencies to implement STARTTLS, SPF and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 10:12:08 -0000 --001a113f476c60f4e5055bf7b482 Content-Type: text/plain; charset="UTF-8" I've notified GlobalCyberAlliance, they have contacts at DHS /Henrik Schack On Thu, Oct 19, 2017 at 12:19 AM, Rolf E. Sonneveld < R.E.Sonneveld@sonnection.nl> wrote: > Hi, > > See https://cyber.dhs.gov/ > > DKIM is mentioned but not required, nor any negative side effects that the > use of DMARC can have. Has anyone from the IETF been consulted for this > directive? > > /rolf > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Mvh/Best regards Henrik Schack ICQ: 889295 http://henrik.schack.dk/ http://links.schack.dk/ --001a113f476c60f4e5055bf7b482 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've notified GlobalCyberAlliance, they have contacts = at DHS

/Henrik Schack

On Thu, Oct 19, 2017 at 12:19 AM, Rolf E= . Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:
Hi,

See https://cyber.dhs.gov/

DKIM is mentioned but not required, nor any negative side effects that the = use of DMARC can have. Has anyone from the IETF been consulted for this dir= ective?

/rolf

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



--
Mvh/Best regardsHenrik Schack
ICQ: 889295
http://henrik.schack.dk/
http://links.schack.dk/
--001a113f476c60f4e5055bf7b482-- From nobody Fri Oct 20 05:30:41 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C731A133211 for ; Fri, 20 Oct 2017 05:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 RxzjPBG1CZ8E for ; Fri, 20 Oct 2017 05:30:38 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EB2D132025 for ; Fri, 20 Oct 2017 05:30:38 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 20 Oct 2017 08:30:33 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Fri, 20 Oct 2017 08:30:32 -0400 Received: from [129.6.111.167] (pn107921.campus.nist.gov [129.6.111.167] (may be forged)) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9KCTSSD003520 for ; Fri, 20 Oct 2017 08:29:28 -0400 From: "Rose, Scott" To: "dmarc@ietf.org" Date: Fri, 20 Oct 2017 08:28:27 -0400 Message-ID: In-Reply-To: <1bf4325a-b660-b77b-3f3e-aaf565e0084a@sonnection.nl> References: <1bf4325a-b660-b77b-3f3e-aaf565e0084a@sonnection.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.7r5425) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [dmarc-ietf] Binding Operational Directive 18-01 require agencies to implement STARTTLS, SPF and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 12:30:41 -0000 We were consulted near the end (as in, the BOD was nearly final), but = none of our comments changed the text as it is now. From conversations we had, DHS did not include DKIM because they could = not figure out a way to fully test for compliance. They knew of it, and = have in fact asked agencies to report on DKIM usage in previous years. = The authors of the BOD knew about DKIM=E2=80=99s interactions with mailin= g = lists, so that might have been a reason to not include it. Our main concerns were the fairly quick deadlines (in gov=E2=80=99t terms= ). = Many agencies have long term contracts with their email providers and = may have issues meeting some of the deadlines. Scott On 18 Oct 2017, at 18:19, Rolf E. Sonneveld wrote: > Hi, > > See = > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fcybe= r.dhs.gov%2F&data=3D02%7C01%7Cscott.rose%40nist.gov%7Cb5347aa561ac4463b2c= 108d516765afb%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C63643961994586= 8015&sdata=3DpzPhmEpOJgCXqSOXVLtK8OMwNaIkkdywSmCSHDzoAKM%3D&reserved=3D0 > > DKIM is mentioned but not required, nor any negative side effects that = > the use of DMARC can have. Has anyone from the IETF been consulted for = > this directive? > > /rolf > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=3D02%7C01%7Cscott.rose%40nist.= gov%7Cb5347aa561ac4463b2c108d516765afb%7C2ab5d82fd8fa4797a93e054655c61dec= %7C1%7C0%7C636439619945868015&sdata=3DnK%2FlKruHCEWTNaF4flKnBy2aGeeFQu01%= 2BWsFRBLmzac%3D&reserved=3D0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST ITL scott.rose@nist.gov +1-301-975-8439 GV: +1-571-249-3671 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Fri Oct 20 06:55:51 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA9A1332D7 for ; Fri, 20 Oct 2017 06:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.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 ZZmbUGap1zg8 for ; Fri, 20 Oct 2017 06:55:47 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 9C327132125 for ; Fri, 20 Oct 2017 06:55:47 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id w45so8368830uac.3 for ; Fri, 20 Oct 2017 06:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=4KYKJ5lL7MbGf+X91ZiKJeXUqBZat8z6gMkNGh5FMoQ=; b=rHsOJr/0arqdlVV/QOJQXgwKPgD3rIh33J292gyeO+xIUZw28sY1CjqwhF6YvM2oRW BAs60OFLzJP2jshnST5Tsk0t7Sne803I29Ql3nfEo60HOuexc9V3FKq5kRiHdNTiY92z 4J3YKzLDVOxhTc1enB9MZFTw0b8rhXM+ojTcaHWhpb3MB5n1MLcg+02xT9dyFkWNn5lT uS4anyIVnCeTEJnKd0b1pNE/tNmnKo9BuWXhwk1BWA3H0BkGB9eic1bAsX00Q6Coyj/q SQTT4sU7yATbQo21Jv0to+vt5Dw6UcEfaH8saIkQFIg9H/vGzu+UZUmn+aNt7VKVYOJA 6RHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=4KYKJ5lL7MbGf+X91ZiKJeXUqBZat8z6gMkNGh5FMoQ=; b=bzcrFe5TPN9CXZdyr2fgtBhqIQv8+grjuryTE3oIWxU819pnvUyEBE3G9In6mnHcMK pj5ONN2nhqNQUhVT88NQZ9qUXbBG2RJjBZw0RzB/TsiQ7yzoes5Nh/KSyy8BkT9kDCIR VORzWPbSuN74XTeYTPmk0uT2EVGGzOF+dW6m2w2SWhGkARkXvlBhNU4QVAW+LMlqs1dz +e2tjs026nuPCHQLt9H3yJAu/4lYyD/zTS2xew16tze7FHuXxO1UJ/rrIB29tvW1yiMd ie5hnF75br/iCb129+QBqM59Kuiw5Mxuqn6bK0+lAHU1maz3YYqY2iRqSTPuirompZVY 0qVw== X-Gm-Message-State: AMCzsaXI3VYkPVw/YYw+E8i5vE2p+k8UGb+px71ogg8UmfKj6aW2D7Mv NVVCVqhZwYl07iAUK/mo183XY2KU5n9b13Ma52U94SZ2ZDs= X-Google-Smtp-Source: ABhQp+RoS9K4RajYzbnjUClZFC7Y5+qUR/qVosquByiA2gf1YXV1xPM6zU2b6ypMlaX/zB27GDAvdGkRsvoHVR+Wo/o= X-Received: by 10.176.90.151 with SMTP id w23mr4138823uae.179.1508507746382; Fri, 20 Oct 2017 06:55:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.8.15 with HTTP; Fri, 20 Oct 2017 06:55:25 -0700 (PDT) In-Reply-To: References: <1bf4325a-b660-b77b-3f3e-aaf565e0084a@sonnection.nl> From: Seth Blank Date: Fri, 20 Oct 2017 06:55:25 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045f8e7e5d5072055bfad4c2" Archived-At: Subject: Re: [dmarc-ietf] Binding Operational Directive 18-01 require agencies to implement STARTTLS, SPF and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 13:55:50 -0000 --f403045f8e7e5d5072055bfad4c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The directive site has a pretty comprehensive overview of email authentication in general (cyber.dhs.gov/intro/) and actually has a section on negative side effects of DMARC that also references this working group's efforts on ARC: https://cyber.dhs.gov/guide/#can-email-authentication-hinder-my-organizatio= ns-ability-to-deliver-email On Fri, Oct 20, 2017 at 5:28 AM, Rose, Scott wrote: > We were consulted near the end (as in, the BOD was nearly final), but non= e > of our comments changed the text as it is now. > > From conversations we had, DHS did not include DKIM because they could no= t > figure out a way to fully test for compliance. They knew of it, and have = in > fact asked agencies to report on DKIM usage in previous years. The autho= rs > of the BOD knew about DKIM=E2=80=99s interactions with mailing lists, so = that might > have been a reason to not include it. > > Our main concerns were the fairly quick deadlines (in gov=E2=80=99t terms= ). Many > agencies have long term contracts with their email providers and may have > issues meeting some of the deadlines. > > Scott > > On 18 Oct 2017, at 18:19, Rolf E. Sonneveld wrote: > > Hi, >> >> See https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A% >> 2F%2Fcyber.dhs.gov%2F&data=3D02%7C01%7Cscott.rose%40nist.gov%7 >> Cb5347aa561ac4463b2c108d516765afb%7C2ab5d82fd8fa4797a93e0546 >> 55c61dec%7C1%7C0%7C636439619945868015&sdata=3DpzPhmEpOJgCXqSOX >> VLtK8OMwNaIkkdywSmCSHDzoAKM%3D&reserved=3D0 >> >> DKIM is mentioned but not required, nor any negative side effects that >> the use of DMARC can have. Has anyone from the IETF been consulted for t= his >> directive? >> >> /rolf >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A% >> 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=3D02% >> 7C01%7Cscott.rose%40nist.gov%7Cb5347aa561ac4463b2c108d516765 >> afb%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C63643961994 >> 5868015&sdata=3DnK%2FlKruHCEWTNaF4flKnBy2aGeeFQu01% >> 2BWsFRBLmzac%3D&reserved=3D0 >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Scott Rose > NIST ITL > scott.rose@nist.gov > +1-301-975-8439 > GV: +1-571-249-3671 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f403045f8e7e5d5072055bfad4c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The directive site has a pretty comprehensive overview of = email authentication in general (cy= ber.dhs.gov/intro/) and actually has a section on negative side effects= of DMARC that also references this working group's efforts on ARC: https://cyber.dhs.gov/guide/#can-email= -authentication-hinder-my-organizations-ability-to-deliver-email

On Fri, Oct 20= , 2017 at 5:28 AM, Rose, Scott <scott.rose@nist.gov> wrote= :
We were consulted ne= ar the end (as in, the BOD was nearly final), but none of our comments chan= ged the text as it is now.

>From conversations we had, DHS did not include DKIM because they could not = figure out a way to fully test for compliance. They knew of it, and have in= fact asked agencies to report on DKIM usage in previous years.=C2=A0 The a= uthors of the BOD knew about DKIM=E2=80=99s interactions with mailing lists= , so that might have been a reason to not include it.

Our main concerns were the fairly quick deadlines (in gov=E2=80=99t terms).= Many agencies have long term contracts with their email providers and may = have issues meeting some of the deadlines.

Scott

On 18 Oct 2017, at 18:19, Rolf E. Sonneveld wrote:

Hi,

See https://na01.safelin= ks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fcyber.dhs.gov%2F&a= mp;data=3D02%7C01%7Cscott.rose%40nist.gov%7Cb5347aa561ac4463b2c10= 8d516765afb%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C63643961= 9945868015&sdata=3DpzPhmEpOJgCXqSOXVLtK8OMwNaIkkdywSmCSHDzoAK= M%3D&reserved=3D0

DKIM is mentioned but not required, nor any negative side effects that the = use of DMARC can have. Has anyone from the IETF been consulted for this dir= ective?

/rolf

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=3D02%= 7C01%7Cscott.rose%40nist.gov%7Cb5347aa561ac4463b2c108d516765= afb%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C6364396199458680= 15&sdata=3DnK%2FlKruHCEWTNaF4flKnBy2aGeeFQu01%2BWsFRBLmzac%3D= &reserved=3D0


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Scott Rose
NIST ITL
scott.rose@nist.go= v
= +1-301-975-8439
GV: +1-571-249-3671
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

--f403045f8e7e5d5072055bfad4c2-- From nobody Fri Oct 20 17:30:23 2017 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C284E1344B9; Fri, 20 Oct 2017 17:24:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dmarc@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546778.20809.10608584063019040033.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:27 -0700 Archived-At: Subject: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:28 -0000 Dear Barry Leiba, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dmarc Session 1 (1:00:00) Thursday, Morning Session I 0930-1200 Room Name: Orchard size: 50 --------------------------------------------- Special Note: 1100-1200 Request Information: --------------------------------------------------------- Working Group Name: Domain-based Message Authentication, Reporting & Conformance Area Name: Applications and Real-Time Area Session Requester: Barry Leiba Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: jmap dcrup uta dispatch People who must be present: Ned Freed Barry Leiba Alexey Melnikov Tim Draegen Kurt Andersen Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: --------------------------------------------------------- From nobody Tue Oct 31 07:58:20 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C985413F6DB for ; Tue, 31 Oct 2017 07:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no 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 6LNE08y7VdUH for ; Tue, 31 Oct 2017 07:58:17 -0700 (PDT) Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com [209.85.216.171]) (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 2205A13F617 for ; Tue, 31 Oct 2017 07:58:12 -0700 (PDT) Received: by mail-qt0-f171.google.com with SMTP id d9so21064431qtd.7 for ; Tue, 31 Oct 2017 07:58:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=honhmRNfiJHe2BQEJfL55mUDkIJRky6NqeYTPfnledk=; b=DGra3mw7ceZt4gmDXVD4/wr0AwXeUbRxxFUc2JglSEBdnT2InSTHJA5RoRSxXT2tPO LlvOEenh+DY1IEc8YLOD2RYFDc9Cqq5eCDfuUcdJiH1aAQWh/W3SROUYd4GGuB7pppz0 I7NzyAhEiVDwBnU1DrVAuC/qE/X8xIYElL71RSBvcclAEfy87lwsB61bYOV1UasZtQaU MkVHSORpGWneDcwFJGALnmk2xeS099GW+cOb12mnnX2DBjQ8lHo3e3zMGzRLk8yAOaB3 1a6/ujv/Jh6CTKFlHUt+R4pVky4EwN4WvTvFy7h6yVfMHeKN+XEciCjGFx1PSJUx2rZp 4q5Q== X-Gm-Message-State: AMCzsaXu66zS9twUEm8rPmxlq0wL20qULMRGqGFZerSPcXjdeCi8IVC0 nbHZDMtRhGkoc/2gk1kKJupaXWOTXgNBEvx0zMA= X-Google-Smtp-Source: ABhQp+ScBgLwnaVWu0Qc9vhsc5jjjZQIQmMV1YzgLrha6qeDlG2UnMz2H9VkzECyYJ6pMYtyDpCnC3DcbUOZN1Xnqzk= X-Received: by 10.200.53.152 with SMTP id k24mr3395226qtb.55.1509461890787; Tue, 31 Oct 2017 07:58:10 -0700 (PDT) MIME-Version: 1.0 References: <150854546778.20809.10608584063019040033.idtracker@ietfa.amsl.com> In-Reply-To: <150854546778.20809.10608584063019040033.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Tue, 31 Oct 2017 14:57:59 +0000 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1140a0c4cd79e7055cd8fb12" Archived-At: Subject: Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 14:58:19 -0000 --001a1140a0c4cd79e7055cd8fb12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In a couple of days I will ask Alexey to cancel the dmarc session in Singapore, unless someone very quickly shouts, =E2=80=9CNoooooooo, don=E2= =80=99t do that! We need to meet and talk about .=E2=80=9D Barry, as chair On Sat, Oct 21, 2017 at 4:33 AM "IETF Secretariat" wrote: > Dear Barry Leiba, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > dmarc Session 1 (1:00:00) > Thursday, Morning Session I 0930-1200 > Room Name: Orchard size: 50 > --------------------------------------------- > > > Special Note: 1100-1200 > > > Request Information: > > > --------------------------------------------------------- > Working Group Name: Domain-based Message Authentication, Reporting & > Conformance > Area Name: Applications and Real-Time Area > Session Requester: Barry Leiba > > Number of Sessions: 1 > Length of Session(s): 1 Hour > Number of Attendees: 30 > Conflicts to Avoid: > First Priority: jmap dcrup uta dispatch > > > > > People who must be present: > Ned Freed > Barry Leiba > Alexey Melnikov > Tim Draegen > Kurt Andersen > > Resources Requested: > Experimental Room Setup (U-Shape and classroom, subject to availability= ) > > Special Requests: > > --------------------------------------------------------- > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a1140a0c4cd79e7055cd8fb12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In a couple of days I will ask Alexey to cancel the dmarc= session in Singapore, unless someone very quickly shouts, =E2=80=9CNoooooo= oo, don=E2=80=99t do that!=C2=A0 We need to meet and talk about <this>= ;.=E2=80=9D

Barry, as ch= air

On Sat, Oct 21, 2017 at 4= :33 AM "IETF Secretariat" <= agenda@ietf.org> wrote:
Dear= Barry Leiba,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

dmarc Session 1 (1:00:00)
=C2=A0 =C2=A0 Thursday, Morning Session I 0930-1200
=C2=A0 =C2=A0 Room Name: Orchard size: 50
=C2=A0 =C2=A0 ---------------------------------------------


Special Note: 1100-1200


Request Information:


---------------------------------------------------------
Working Group Name: Domain-based Message Authentication, Reporting &amp= ; Conformance
Area Name: Applications and Real-Time Area
Session Requester: Barry Leiba

Number of Sessions: 1
Length of Session(s):=C2=A0 1 Hour
Number of Attendees: 30
Conflicts to Avoid:
=C2=A0First Priority: jmap dcrup uta dispatch




People who must be present:
=C2=A0 Ned Freed
=C2=A0 Barry Leiba
=C2=A0 Alexey Melnikov
=C2=A0 Tim Draegen
=C2=A0 Kurt Andersen

Resources Requested:
=C2=A0 Experimental Room Setup (U-Shape and classroom, subject to availabil= ity)

Special Requests:

---------------------------------------------------------

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--001a1140a0c4cd79e7055cd8fb12--