From nobody Wed Sep 5 02:49:59 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91648130DC5 for ; Wed, 5 Sep 2018 02:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.428
X-Spam-Level:
X-Spam-Status: No, score=0.428 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nz.smxemail.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 bQPuOXp61HEY for ; Wed, 5 Sep 2018 02:49:56 -0700 (PDT)
Received: from out1101.nz.smxemail.com (out1101.nz.smxemail.com [203.84.134.32]) (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 7548012DD85 for ; Wed, 5 Sep 2018 02:49:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=nz.smxemail.com; s=alpha; c=relaxed/relaxed; q=dns/txt; i=@nz.smxemail.com; t=1536140993; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc; bh=LX4FQVxav4HXHuQV42a7fshtPYp3+THMC8vO9esD82M=; b=lTOPbb7UcVLLD/ny5Qs0eVB0dSKlVCe4OogNxTpSi0vdKEGEDqt/iLNRJfpfyt47 NIxmibitMC+n2+AiqwoKF9msNYuSv4/0kbQ6SV+RZkY16FNKdEiaI+rDo0O6SxdT MGMOnTwtYa2lmThxE0X5xA6+Cq1hAQozERu3BSOv/KI=;
Received: from [121.99.132.45] by smtp.nz.smxemail.com with ESMTP (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) id 5B8FA6C1-3A832A0E@mta1102.omr; Wed, 05 Sep 2018 09:49:53 +0000
To: uta@ietf.org
From: Richard Gray
Message-ID:
Date: Wed, 5 Sep 2018 21:49:49 +1200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------5AE79743C8DAEF4123D66BA4"
Content-Language: en-GB-large
Archived-At:
Subject: [Uta] Typo in MTA-STS policy definition (draft-ietf-uta-mta-sts-21)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 05 Sep 2018 09:49:58 -0000
This is a multi-part message in MIME format.
--------------5AE79743C8DAEF4123D66BA4
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Is there a typo in the formal definition of an MTA-STS policy in
draft-ietf-uta-mta-sts-21 section 3.2?
Specifically, sts-policy-mx is not referenced from anywhere else in the
ABNF definition. It seems that this was referenced by sts-policy-field
in version 20 of the draft, but went missing in version 21. The
identifiers sts-policy-mx-label and sts-policy-mx-toplabel also seem to
be "orphaned" in this way.
Regards,
--
*Richard Gray* | Operations Technical Lead
*DDI:* +64 9 950 2196 *Fax:* +64 9 302 0518
*Mobile:* +64 21 050 8178 *Freephone:*0800 SMX SMX (769 769)
*SMX Limited:* Level 10, 19 Victoria Street West, Auckland, New Zealand
*Web:* http://smxemail.com
SMX | Cloud Email Hosting & Security
_____________________________________________________________________________
This email has been filtered by SMX. For more info visit http://smxemail.com
_____________________________________________________________________________
--------------5AE79743C8DAEF4123D66BA4
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit
Is there a typo in the formal definition of an MTA-STS policy in
draft-ietf-uta-mta-sts-21 section 3.2?
Specifically, sts-policy-mx is not referenced from anywhere else in
the ABNF definition. It seems that this was referenced by
sts-policy-field in version 20 of the draft, but went missing in
version 21. The identifiers sts-policy-mx-label and
sts-policy-mx-toplabel also seem to be "orphaned" in this way.
Regards,
--
Richard Gray | Operations Technical Lead
DDI: +64 9 950 2196 Fax:
+64 9 302 0518
Mobile: +64 21 050 8178 Freephone:0800
SMX SMX (769 769)
SMX Limited: Level 10, 19 Victoria
Street West, Auckland, New Zealand
Web: http://smxemail.com
This email has been filtered by SMX. For more information visit smxemail.com.
--------------5AE79743C8DAEF4123D66BA4--
From nobody Wed Sep 5 04:01:23 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD96E130DF7 for ; Wed, 5 Sep 2018 04:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 ES4eJkdAIOOa for ; Wed, 5 Sep 2018 04:01:20 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 25399130DF2 for ; Wed, 5 Sep 2018 04:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1536145279; d=isode.com; s=june2016; i=@isode.com; bh=tSRrw/mn32+BzLVpJ/kOtEiKltxN8khmHXoB/4Z3MoM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=q6XdCt8dhEjeKJMU2oVg6d/tpKCtl2+3sJhX+MmXOdoTxOnA/W/Fd9oAZKpqgxMR+8c58d txvNakYdqTbPOY2bAs7CoPHg7SRG3M5G7iWE+3eJ+sR2eylRNd5HhuedcdY4nzWHxSZlx3 JOggGJj5UEltKbpTjmDiN5uyHEfKqUw=;
Received: from [192.168.0.9] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 5 Sep 2018 12:01:19 +0100
From: Alexey Melnikov
X-Mailer: iPad Mail (14F89)
In-Reply-To:
Date: Wed, 5 Sep 2018 12:02:51 +0100
Cc: uta@ietf.org
Message-Id:
References:
To: Richard Gray
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=Apple-Mail-7FC5F81F-3397-4C5C-8CBE-57D67B2FF03C
Content-Transfer-Encoding: 7bit
Archived-At:
Subject: Re: [Uta] Typo in MTA-STS policy definition (draft-ietf-uta-mta-sts-21)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 05 Sep 2018 11:01:22 -0000
--Apple-Mail-7FC5F81F-3397-4C5C-8CBE-57D67B2FF03C
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Hi Richard,
> On 5 Sep 2018, at 10:49, Richard Gray wrote:
>=20
> Is there a typo in the formal definition of an MTA-STS policy in draft-iet=
f-uta-mta-sts-21 section 3.2?
>=20
> Specifically, sts-policy-mx is not referenced from anywhere else in the AB=
NF definition. It seems that this was referenced by sts-policy-field in vers=
ion 20 of the draft, but went missing in version 21. The identifiers sts-pol=
icy-mx-label and sts-policy-mx-toplabel also seem to be "orphaned" in this w=
ay.
You are correct. There were a few more typos found, which should be fixed be=
fore the final RFC is published.
I recorded some of the issues found so far at
Best Regards,
Alexey
>=20
> Regards,
> --=20
> Richard Gray | Operations Technical Lead=20
> DDI: +64 9 950 2196 Fax: +64 9 302 0518=20
> Mobile: +64 21 050 8178 Freephone:0800 SMX SMX (769 769)=20
> SMX Limited: Level 10, 19 Victoria Street West, Auckland, New Zealand=20
> Web: http://smxemail.com=20
>=20
>=20
> This email has been filtered by SMX. For more information visit smxemail.c=
om.
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
--Apple-Mail-7FC5F81F-3397-4C5C-8CBE-57D67B2FF03C
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 7bit
Hi Richard,
Is there a typo in the formal definition of an MTA-STS policy in
draft-ietf-uta-mta-sts-21 section 3.2?
Specifically, sts-policy-mx is not referenced from anywhere else in
the ABNF definition. It seems that this was referenced by
sts-policy-field in version 20 of the draft, but went missing in
version 21. The identifiers sts-policy-mx-label and
sts-policy-mx-toplabel also seem to be "orphaned" in this way.
You are correct. There were a few more typos found, which should be fixed before the final RFC is published.
Best Regards,Alexey
Regards,
--
Richard Gray | Operations Technical Lead
DDI: +64 9 950 2196 Fax:
+64 9 302 0518
Mobile: +64 21 050 8178 Freephone:0800
SMX SMX (769 769)
SMX Limited: Level 10, 19 Victoria
Street West, Auckland, New Zealand
Web: http://smxemail.com
This email has been filtered by SMX. For more information visit smxemail.com.
--Apple-Mail-7FC5F81F-3397-4C5C-8CBE-57D67B2FF03C--
From nobody Fri Sep 14 13:00:08 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C529130F39 for ; Fri, 14 Sep 2018 12:59:55 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 k2oCynP4YIeZ for ; Fri, 14 Sep 2018 12:59:52 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 C1192130F41 for ; Fri, 14 Sep 2018 12:59:52 -0700 (PDT)
Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w8EJxoXx005066 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 14 Sep 2018 12:59:52 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1536955192; bh=+cPdvoVHvDJ6AtoAZ2H5SW4XsGUKMu/lJoqTSbaHGd8=; h=To:From:Subject:Date; b=CEqEhyfFnWCb8CxQw7IiOkbSjfcmQtjpT+XDX7G/zfvpWMadjk+wJsA/8ddajDj6Q KfDdlURPQdeTgklnpYJA2Ek4CRdWQC2pvB+/ChPIOVS33z/41pC2HnoEKAy7aXfAVC Lnx++5gFAOqaVPolmdSnGPbMnslPUnzTHF9s4tpU=
To: "uta@ietf.org"
From: Jim Fenton
Message-ID: <51ad6c35-38e2-c899-96e1-9f7540e614c3@bluepopcorn.net>
Date: Fri, 14 Sep 2018 12:59:44 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------F7CEE0D4BB2715C7E8CC32DE"
Content-Language: en-US
Archived-At:
Subject: [Uta] Late comment on REQURIETLS: Received header field
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 14 Sep 2018 20:00:07 -0000
This is a multi-part message in MIME format.
--------------F7CEE0D4BB2715C7E8CC32DE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
In addition to the comment from Viktor a couple of weeks ago, I received
a suggestion off-list the other day that is worthy of discussion. The
submitter did not want to join the mailing list but did agree to the
terms of the Note Well.
The suggestion:
> I had the idea, that it would be useful to see the status of the
> requested REQUIRETLS service level in the "Received" trace header,
> which is inserted by the MTA using simple comments. Having this, you
> could see at which point in message flow the REQUIRETLS was inserted
> (and lost), as well as detection of mis-behaving MTAs. And it gives
> the recipient of such a message more confidence because he can see
> what really happened. For this purpose, adding such information into
> the trace header must be mandatory for each MTA supporting Require TLS.
> Examples:
>
> Received: from example.com (example.com [127.0.0.1])
> by relay.com (Postfix) with ESMTP
> (using REQUIRETLS)
> for; Thu, 6 Sep 2018 11:46:34 +0200 (CEST)
> or
>
> Received: from example.com (example.com [127.0.0.1])
> by relay.com (Postfix) with ESMTP
> (using RequireTLS:No)
> for; Thu, 6 Sep 2018 11:46:34 +0200 (CEST)
>
> These strings should be well-defined by RFC.
>
I am under the impression that the contents of the Received header field
are (in practice, at least) somewhat ad hoc, at least with respect to
transport characteristics like the use of TLS. So I'm not sure how
well-defined these can be, but we could at least suggest the annotation
of whether the message was received with the RequireTLS option included.
This would be primarily for diagnostic purposes, because of course any
MTA along the path could falsify that information.
I'm less convinced of the value in the RequireTLS:no case, because that
is already expressed in a header field, and there isn't any
characteristic of the incoming SMTP session to note.
Any other thoughts on whether this would be a valuable addition?
-Jim
--------------F7CEE0D4BB2715C7E8CC32DE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
In addition to the comment from Viktor a couple of weeks ago, I
received a suggestion off-list the other day that is worthy of
discussion. The submitter did not want to join the mailing list
but did agree to the terms of the Note Well.
The suggestion:
I had the idea, that it would be useful to
see the status of the requested REQUIRETLS service level in the
"Received" trace header, which is inserted by the MTA using
simple comments. Having this, you could see at which point in
message flow the REQUIRETLS was inserted (and lost), as well as
detection of mis-behaving MTAs. And it gives the recipient of
such a message more confidence because he can see what really
happened. For this purpose, adding such information into the
trace header must be mandatory for each MTA supporting Require
TLS.
Examples:
Received: from example.com (example.com [127.0.0.1])
by relay.com (Postfix) with ESMTP
(using REQUIRETLS)
for <user@domain.de>; Thu, 6 Sep 2018 11:46:34 +0200 (CEST)
or
Received: from example.com (example.com [127.0.0.1])
by relay.com (Postfix) with ESMTP
(using RequireTLS:No)
for <user@domain.de>; Thu, 6 Sep 2018 11:46:34 +0200 (CEST)
These strings should be well-defined by RFC.
I am under the impression that the contents of the Received
header field are (in practice, at least) somewhat ad hoc, at least
with respect to transport characteristics like the use of TLS. So
I'm not sure how well-defined these can be, but we could at least
suggest the annotation of whether the message was received with
the RequireTLS option included. This would be primarily for
diagnostic purposes, because of course any MTA along the path
could falsify that information.
I'm less convinced of the value in the RequireTLS:no case,
because that is already expressed in a header field, and there
isn't any characteristic of the incoming SMTP session to note.
Any other thoughts on whether this would be a valuable addition?
-Jim
--------------F7CEE0D4BB2715C7E8CC32DE--
From nobody Fri Sep 14 16:50:10 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056B012426A for ; Fri, 14 Sep 2018 16:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 iWsxyA9bCfkW for ; Fri, 14 Sep 2018 16:49:59 -0700 (PDT)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 D77BC130F62 for ; Fri, 14 Sep 2018 16:49:59 -0700 (PDT)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w8ENna6j055008; Fri, 14 Sep 2018 23:49:51 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=xAl71YQ9Y0n2zSenc0ykBIb4YfY6qEUBAu8pCS41VbA=; b=nVZbosc7PvATK1OaLN87pBfo6w6Wg7cC6AR2dk9bJmJF3kZFWCEyQGPD+RDlitGluTOG u+o4np6s4KGarftHzQEsTfiUWKHb3RikKF6W8qWqMPA6Ey6p1qqAm6xqVEyiFSyqHOkm +WqM2miuOOFChPw3P3OkKUYi6VYHv8WR2sTL3tN/nd+d67f3QhDKF3VFu63dMCacmjSI YT8LiTnhgjNg8b1vFGIGX289G0jZlwqnmdRlzUs1RlV8YGbEmV4cq5zx7GNVa7T15j8q Y0lWblB/kiDRGkbuZ1fFFyeMf0lHplYVgbzvN8oKaESYoh3P0uTRnrd6ZMo/LbNagDjJ Eg==
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2mc6cq9j7n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Sep 2018 23:49:51 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w8ENnoo8005375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Sep 2018 23:49:50 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w8ENnlQ0031133; Fri, 14 Sep 2018 23:49:47 GMT
Received: from [10.145.183.37] (/10.145.183.37) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Sep 2018 23:49:47 +0000
From: "Chris Newman"
To: "Jim Fenton"
Cc: uta@ietf.org
Date: Fri, 14 Sep 2018 16:49:43 -0700
X-Mailer: MailMate (1.12r5523)
Message-ID:
In-Reply-To: <51ad6c35-38e2-c899-96e1-9f7540e614c3@bluepopcorn.net>
References: <51ad6c35-38e2-c899-96e1-9f7540e614c3@bluepopcorn.net>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9016 signatures=668708
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809140241
Archived-At:
Subject: Re: [Uta] Late comment on REQURIETLS: Received header field
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 14 Sep 2018 23:50:09 -0000
On 14 Sep 2018, at 12:59, Jim Fenton wrote:
> In addition to the comment from Viktor a couple of weeks ago, I =
> received a suggestion off-list the other day that is worthy of =
> discussion. The submitter did not want to join the mailing list but =
> did agree to the terms of the Note Well.
>
> The suggestion:
>
>> I had the idea, that it would be useful to see the status of the =
>> requested REQUIRETLS service level in the "Received" trace header, =
>> which is inserted by the MTA using simple comments. Having this, you =
>> could see at which point in message flow the REQUIRETLS was inserted =
>> (and lost), as well as detection of mis-behaving MTAs. And it gives =
>> the recipient of such a message more confidence because he can see =
>> what really happened. For this purpose, adding such information into =
>> the trace header must be mandatory for each MTA supporting Require =
>> TLS.
>> Examples:
>>
>> Received: from example.com (example.com [127.0.0.1])
>> by relay.com (Postfix) with ESMTP
>> (using REQUIRETLS)
>> for; Thu, 6 Sep 2018 11:46:34 +0200 (CEST)
>> or
>>
>> Received: from example.com (example.com [127.0.0.1])
>> by relay.com (Postfix) with ESMTP
>> (using RequireTLS:No)
>> for; Thu, 6 Sep 2018 11:46:34 +0200 (CEST)
>>
>> These strings should be well-defined by RFC.
>>
>
> I am under the impression that the contents of the Received header =
> field are (in practice, at least) somewhat ad hoc, at least with =
> respect to transport characteristics like the use of TLS. So I'm not =
> sure how well-defined these can be, but we could at least suggest the =
> annotation of whether the message was received with the RequireTLS =
> option included. This would be primarily for diagnostic purposes, =
> because of course any MTA along the path could falsify that =
> information.
>
> I'm less convinced of the value in the RequireTLS:no case, because =
> that is already expressed in a header field, and there isn't any =
> characteristic of the incoming SMTP session to note.
>
> Any other thoughts on whether this would be a valuable addition?
Received has a well-defined extensible syntax as of RFC 2822. Comments =
are not an extensibility mechanism and the contents of comments have no =
interoperable semantic value and should never be standardized if there's =
a reasonable non-comment alternative syntax.
Since Received is a trace header I think it's more important to record =
what actually happened with respect to TLS rather than to record policy =
that impacted what happened. There's already a standard way to record =
the fact TLS was used via the "WITH clause":
https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#=
mail-parameters-5
and a standard way to record the cipher suite:
https://tools.ietf.org/html/rfc8314#section-4.3
If the WG deems it important to record 'requiretls' policy, I'd prefer =
that be done by adding new options to the "WITH" clause of Received for =
the sake of consistency with prior work.
- Chris
From nobody Mon Sep 17 02:51:15 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080CB130DC1 for ; Mon, 17 Sep 2018 02:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.411
X-Spam-Level:
X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.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 NzBVw45dTBwr for ; Mon, 17 Sep 2018 02:51:12 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 17A751277D2 for ; Mon, 17 Sep 2018 02:51:11 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id q22-v6so2114815lfa.13 for ; Mon, 17 Sep 2018 02:51:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:openpgp:autocrypt:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=lcPrP0AcSWesuFOoZTjCMwLCznFbPXBGuoorXunSO38=; b=Xt90b/MX70xNV9/m/BnbQYD+VQNg3M5oEExjHzNyJyMx4VTgvTu5jPws2lOhd5cnrA KxXPpIARLxr3Wv9S4G2/WQeYN4oPH0fBv6Heb6Wd3vnM52ui8Ch6cC7EmWBjzNNy6/Jn W1yGqYuHcezM143X/qBF2/aeD9WRpjAinQ2xiJDntWM1MHmU/mw5Ti58Qlkz4BbujRX5 5jPnuvk9GNewQgGKOBjFrUsBowJJrQqFp0auP+Rux5blqk9WGPaaSAaCfhNDFmvLp52G S3Zy9vmTfI94PP8tND2f/tCatGpw3dTUcWVz++de0rwbVBvMm0Ur5kKUcj9kW1JiV/+M yOqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:openpgp:autocrypt:subject:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=lcPrP0AcSWesuFOoZTjCMwLCznFbPXBGuoorXunSO38=; b=mgA6mQvk1o/9iBH8WxN+QKZALKDZy4lx1NKMKNMxm6jXxuRwyM4xFssTbQ7oaemwjQ FnPrwGqzv8lwhvQL2n1G2KeUaPwSIxe2H7o3G8mEWh87G+olmwJc5WcEgoD76P43iPF9 XInbnR6rivmqqyvcOiq9sK0NxBn7Prck+ccuHC7f+ZQfzoXsIkJuth3JOanEtlUVNg7b DIxyxieFRuvb7dZ4b0uHf4tv9J+MsETpxnV6bpLeAhMG4cwnYi7FjeuV/Cf6Uz2rpIAy eFaocBEaZUH6I+9EuTSk4ZgisX3uIqrwPRsQDHypG0PHUPpAHtqxHjWz7niu3qnrp/pV 2ekw==
X-Gm-Message-State: APzg51ARsoOMV3thbwfvLO7QuNXAP51EdmqKymcz/KFmeDxXa/TuSu1E 15vuwqxC56d0s9FwrG/8x5T2BJqFSDw=
X-Google-Smtp-Source: ANB0VdZ16IZV1ClIlwtftC8SoYQgfJtpVGCDDDGUPgi+hppYjMPQeKiHk9m98y1V6D7bImx9Y64h+g==
X-Received: by 2002:a19:870b:: with SMTP id j11-v6mr16573812lfd.4.1537177869328; Mon, 17 Sep 2018 02:51:09 -0700 (PDT)
Received: from [10.101.1.150] ([62.119.166.1]) by smtp.gmail.com with ESMTPSA id a1-v6sm1411594lff.53.2018.09.17.02.51.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Sep 2018 02:51:08 -0700 (PDT)
To: uta@ietf.org
From: Leif Johansson
Openpgp: preference=signencrypt
Autocrypt: addr=leifj@sunet.se; prefer-encrypt=mutual; keydata= xsBNBFJK9qIBCACypED81H1N4YmhMJrb4uOtTDzo+lFZDVVOcK11+NhTFl+AZZFnWH/7UPn+ q5ZZBd/IhONfb5QGw5FzTyBWHsbAteXgCvHAIyumwhQzhZnow6myyC6/MwDhomT5rb3MkCKC yQMNfj/yMgL6ZRsXVhlGOLMmOekRfKe2wiC5BhRaQQwPZPwgFS5D0Tro8Xfxjk98u8rNpQXi 9walRAffRY+byhkPiBj0sVA2RXK9Dx2DL3EY0xx07r6Qhs2XkbXNDDCHRuChhHSHwWC16VS9 x7Nhfg2EwKqmMGRNREikjwzDl/aHKz+FXTLONdmc83sRyklqgH90f3na6s/RT5XTb08xABEB AAHNH0xlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZT7CwH4EEwECACgCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheABQJWEnueBQkJax9wAAoJENc61kMK1HjWmvcH/2jmnz/1uC+r oyhQIjDWe6+5GzNdhOICG6s17AFNeKQ8WshygcBgSy57nwTVPJPPqngpfM8kMk4cVUHH+2h3 110d4LAAJGOcGDh9rIaJE+mPMv84lirRkwpih+MQMjW7tg/zxdhXrgKr5piBhKwitoI6Lc0o LoBWQP3EEjrzNyj+WR9MFUwvVio9LWGamly+XZocf221Vo9PYp08v+oF0o1HWnDffQYSOfX4 RdvgHrcvU/k9EzgZNr/ys8ihSAOxWZCC9ou9kwnV04mcvEOQFQGF2W+ziP6UCku8RCXaYNPe pRqWXUKWBg5mrW0DriVbgxrm3oqKjt4lE9tIMWXjnGvOwE0EUkr2ogEIAL6TW0U54NLiAzES BGR+JUscV6bAlZCIZkdiG0OCOHrDqYHwbdZn7+APYIynkOAcVELWxbaIyPeA7Ot/LHN30CZZ uFdhx5HoQWRNzo5Wxohv54cf9mjcMrIHUOr0IDl+OOcRDO2L4opJlhbMHQWS3uqt85LpgzXM yMRTFRTCyXWqKvHkO4HJYsNftQtTsf/GY9WEdRVk7xcRoVXab4gLHxjoH3wox4nRDPxvzCna Du9YSTBLZHoiMXSQytHGfFS/ADoRSJm4WmGG5j+VYIm6wuXWiWA4T4EowRRK0lYSLSz6l3wU vW84t40pshQWujT6hmv1vIAGmQ82MzEpXfq6PV0AEQEAAcLAZQQYAQIADwIbDAUCVhJ8BAUJ CWsf3wAKCRDXOtZDCtR41i6VB/wOwgEM9j2r3nr6dkI9E3M255h2BllS309gafyTSLkiyTeX nz6NRoU61fqFtqUt2Y5kMgIzqlOL7M823twudx52t9fwuE3AqrAX5Jg53SwSABhUHmXgAwX8 tNEYhC97g0WQgPU1CffIgNszVSZ2Xt7YoDAUE1Q+Y1yEFg4BC2UJEnHZRPtIqL/Mvob1URgZ tUqg5cgsCKADZo0bJzSVQtfaAcr1+/hGwBtIReZe57dX+xF5YMrBkrc5mrvpK73ZcpRwpqb1 B9dtUJBX/6Sfx4Gf//X3jKg2md/HwEXoh5SL3xa0m6StcOiel/1SRN3YqbY7i+8brziVkKuE sXIjcqKa
Message-ID: <192a9528-ab0e-ac2f-5549-7b75063145f2@sunet.se>
Date: Mon, 17 Sep 2018 11:51:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At:
Subject: [Uta] Reasons to meet in Bangkok?
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 17 Sep 2018 09:51:14 -0000
Activity on the list suggest we don't have reason to request a meeting
for Bangkok. If anyone thinks otherwize... please say so and include
a suggestion for agenda items before the session request cut-off on
Friday.
Best R
Leif
From nobody Thu Sep 20 00:43:55 2018
Return-Path:
X-Original-To: uta@ietf.org
Delivered-To: uta@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F036A130DD1; Thu, 20 Sep 2018 00:43:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool
To:
Cc: uta@ietf.org, uta-chairs@ietf.org, leifj@sunet.se, aamelnikov@fastmail.fm
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153742943197.19722.6308538327160199205.idtracker@ietfa.amsl.com>
Date: Thu, 20 Sep 2018 00:43:51 -0700
Archived-At:
Subject: [Uta] uta - Not having a session at IETF 103
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 20 Sep 2018 07:43:52 -0000
Leif Johansson, a chair of the uta working group, indicated that the uta working group does not plan to hold a session at IETF 103.
This message was generated and sent by the IETF Meeting Session Request Tool.
From nobody Fri Sep 21 04:13:16 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F659130DC7 for ; Fri, 21 Sep 2018 04:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Mp-PsgTWtT9i for ; Fri, 21 Sep 2018 04:13:13 -0700 (PDT)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 D6B3A130DC3 for ; Fri, 21 Sep 2018 04:13:12 -0700 (PDT)
Received: by mail-it1-x136.google.com with SMTP id p79-v6so1543515itp.3 for ; Fri, 21 Sep 2018 04:13:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YKic6uNI+D0GBNYvC1F/IDjRym5FstG1QcTUIjK/eTU=; b=JRsrLKbm7C+/zetTJ6LmFRGGfZPQRBEt8W09m3jg/amrGkFSzk/FkXnWx64p8XYNSo vsO/2g0vopPyhwD4Vn4VrjvB7kbjrm3992eQw9+5IRc6PGeoQAX+N/+143r3SssKhFVV 2d5MiyLyJ3EEwXns2h7wkDXZwAsnm2uJdHIHdptINZW19zZyd8pPnvNHWOgGqwLWNtbS s6IZ4sKqfJ3X0ehkkVSts2zdPvOF9E29OXav14RIYnX82iqH8dxxBOgxYPg7hoexDhk7 +7pyQlDByIZmX97B4L9grI0zxnAIt7yB/mUGSHO9KNCF2TYvsxzlegtGMp/m5p53OYIQ ZlvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YKic6uNI+D0GBNYvC1F/IDjRym5FstG1QcTUIjK/eTU=; b=C2rFRLHUVZY5ylg/F/hEDBTmy6BRTykC/YVCvGUoLS2S5RpZK2dHu37nzhXByplbpB HvL3bLulua8ChLfqKK3Mabhv2SB4wLuV2UOYUgvb7NVuVoZ4DTTF4UlEJmfslZAbBCm0 CPZkdu+5Jff1xuEWr8d43Ev5OeSG0WINL/TRt3Y++jS9YFUM/3yqq3Ak8tiNnk9lr3ap VlKcVk2wIA1Pp+rNFzVv2alb4LvzJJQ55A0qC35VMX7ukz6Ayvv8s7cVQpTzXOFihFgU Zu1lBt2JkdmzclmMqKndOZNZKypLXbUXqfmGSY1ZASBOQZvH//EwMIPaGEpaxpbL5ggQ K//g==
X-Gm-Message-State: APzg51BkxaKRoa4Gs+kfFFOiwHVoqI2uINv3Fx36x1RRhbCuSkZguJW2 ONK4y7+bIXQM5Xk9T+IVHUf3Z6M+y9C8WezV5nCma9+QSNQ=
X-Google-Smtp-Source: ANB0VdZqQvlnqMvgCezdNZP21c8S+irBB92L8aJdnfwNrh/oa4vMm1Hq9rg2bTm/SsjIH8OzzSYXzGiLPoiV84nga7Y=
X-Received: by 2002:a24:140f:: with SMTP id 15-v6mr5484808itg.57.1537528391975; Fri, 21 Sep 2018 04:13:11 -0700 (PDT)
MIME-Version: 1.0
From: Loganaden Velvindron
Date: Fri, 21 Sep 2018 15:12:59 +0400
Message-ID:
To: uta@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At:
Subject: [Uta] Proposed draft
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 21 Sep 2018 11:13:14 -0000
Dear UTA folks,
Please find the link here
(https://www.ietf.org/id/draft-lvelvindron-tls-for-email-00.txt) for
the draft for Switching the minimum requirement for TLS in mail from
TLS 1.1 to TLS 1.2. This is inline with what is happening here:
https://github.com/tlswg/oldversions-deprecate/blob/master/draft-ietf-tls-oldversions-deprecate.txt
where TLS 1.0 and TLS 1.1 are deprecated.
Feedback welcome.
Kind regards,
//Logan
C-x-C-c
From nobody Wed Sep 26 09:52:38 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72EA12958B; Wed, 26 Sep 2018 09:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yDBAmKtTEd7; Wed, 26 Sep 2018 09:52:28 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96653130FB1; Wed, 26 Sep 2018 09:52:19 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id D99E4B81209; Wed, 26 Sep 2018 09:52:17 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, uta@ietf.org
Content-type: text/plain; charset=UTF-8
Message-Id: <20180926165217.D99E4B81209@rfc-editor.org>
Date: Wed, 26 Sep 2018 09:52:17 -0700 (PDT)
Archived-At:
Subject: [Uta] =?utf-8?q?RFC_8460_on_SMTP_TLS_Reporting?=
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 26 Sep 2018 16:52:37 -0000
A new Request for Comments is now available in online RFC libraries.
RFC 8460
Title: SMTP TLS Reporting
Author: D. Margolis,
A. Brotman,
B. Ramakrishnan,
J. Jones,
M. Risher
Status: Standards Track
Stream: IETF
Date: September 2018
Mailbox: dmargolis@google.com,
alex_brotman@comcast.com,
prbinu@yahoo.com,
janet.jones@microsoft.com,
risher@google.com
Pages: 34
Characters: 67126
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-uta-smtp-tlsrpt-23.txt
URL: https://www.rfc-editor.org/info/rfc8460
DOI: 10.17487/RFC8460
A number of protocols exist for establishing encrypted channels
between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS-
Based Authentication of Named Entities (DANE) TLSA, and MTA Strict
Transport Security (MTA-STS). These protocols can fail due to
misconfiguration or active attack, leading to undelivered messages or
delivery over unencrypted or unauthenticated channels. This document
describes a reporting mechanism and format by which sending systems
can share statistics and specific information about potential
failures with recipient domains. Recipient domains can then use this
information to both detect potential attacks and diagnose
unintentional misconfigurations.
This document is a product of the Using TLS in Applications Working Group of the IETF.
This is now a Proposed Standard.
STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol. Distribution of this
memo is unlimited.
This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
https://www.ietf.org/mailman/listinfo/ietf-announce
https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
The RFC Editor Team
Association Management Solutions, LLC
From nobody Wed Sep 26 09:52:49 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFA1130F2C; Wed, 26 Sep 2018 09:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hD5A2Y8Kw7tB; Wed, 26 Sep 2018 09:52:41 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF45130F7C; Wed, 26 Sep 2018 09:52:31 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 2E88BB81226; Wed, 26 Sep 2018 09:52:30 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, uta@ietf.org
Content-type: text/plain; charset=UTF-8
Message-Id: <20180926165230.2E88BB81226@rfc-editor.org>
Date: Wed, 26 Sep 2018 09:52:30 -0700 (PDT)
Archived-At:
Subject: [Uta] =?utf-8?q?RFC_8461_on_SMTP_MTA_Strict_Transport_Security_?= =?utf-8?b?KE1UQS1TVFMp?=
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 26 Sep 2018 16:52:47 -0000
A new Request for Comments is now available in online RFC libraries.
RFC 8461
Title: SMTP MTA Strict Transport Security
(MTA-STS)
Author: D. Margolis,
M. Risher,
B. Ramakrishnan,
A. Brotman,
J. Jones
Status: Standards Track
Stream: IETF
Date: September 2018
Mailbox: dmargolis@google.com,
risher@google.com,
prbinu@yahoo.com,
alex_brotman@comcast.com,
janet.jones@microsoft.com
Pages: 29
Characters: 59461
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-uta-mta-sts-21.txt
URL: https://www.rfc-editor.org/info/rfc8461
DOI: 10.17487/RFC8461
SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling
mail service providers (SPs) to declare their ability to receive
Transport Layer Security (TLS) secure SMTP connections and to specify
whether sending SMTP servers should refuse to deliver to MX hosts
that do not offer TLS with a trusted server certificate.
This document is a product of the Using TLS in Applications Working Group of the IETF.
This is now a Proposed Standard.
STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol. Distribution of this
memo is unlimited.
This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
https://www.ietf.org/mailman/listinfo/ietf-announce
https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
The RFC Editor Team
Association Management Solutions, LLC
From nobody Wed Sep 26 14:32:09 2018
Return-Path:
X-Original-To: uta@ietf.org
Delivered-To: uta@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF371130DDE; Wed, 26 Sep 2018 14:32:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To:
Cc: uta@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: uta@ietf.org
Message-ID: <153799752172.21587.656470503791418522@ietfa.amsl.com>
Date: Wed, 26 Sep 2018 14:32:01 -0700
Archived-At:
Subject: [Uta] I-D Action: draft-ietf-uta-smtp-require-tls-04.txt
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 26 Sep 2018 21:32:02 -0000
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Using TLS in Applications WG of the IETF.
Title : SMTP Require TLS Option
Author : Jim Fenton
Filename : draft-ietf-uta-smtp-require-tls-04.txt
Pages : 15
Date : 2018-09-26
Abstract:
The SMTP STARTTLS option, used in negotiating transport-level
encryption of SMTP connections, is not as useful from a security
standpoint as it might be because of its opportunistic nature;
message delivery is, by default, prioritized over security. This
document describes an SMTP service extension, REQUIRETLS, and message
header field, RequireTLS. If the REQUIRETLS option or RequireTLS
message header field is used when sending a message, it asserts a
request on the part of the message sender to override the default
negotiation of TLS, either by requiring that TLS be negotiated when
the message is relayed, or by requesting that recipient-side policy
mechanisms such as MTA-STS and DANE be ignored when relaying a
message for which security is unimportant.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-04
https://datatracker.ietf.org/doc/html/draft-ietf-uta-smtp-require-tls-04
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-require-tls-04
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
From nobody Wed Sep 26 14:41:45 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1CC130DD4 for ; Wed, 26 Sep 2018 14:41:42 -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=bluepopcorn.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 qyqcz23HxGae for ; Wed, 26 Sep 2018 14:41:40 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 E4AEC1294D7 for ; Wed, 26 Sep 2018 14:41:39 -0700 (PDT)
Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w8QLfb8n028819 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 26 Sep 2018 14:41:39 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1537998099; bh=U54Z4X+9wdqFcw4V9PKtitFL8WN3jT2D4qUfKcN+jkA=; h=Subject:To:References:From:Date:In-Reply-To; b=Mkgw34OV90vYCHSzBUpHoGpyuQin81XOmSuXyR4ZQrIrC+YJ+RshP0b9JYe6kPkdP NzrKH2AmWm7uYZECkaOnWYI9Fbeq3wMED8VaO1cVta0twSdcpDRunbw3lTji22eJEV aSDYsoTQYD795v2NFPb1qF0heIP5wsUfyBPilHYM=
To: uta@ietf.org
References: <153799752172.21587.656470503791418522@ietfa.amsl.com>
From: Jim Fenton
Message-ID: <759248b8-78a1-0479-e0d0-8e6a7bc33a8d@bluepopcorn.net>
Date: Wed, 26 Sep 2018 14:41:31 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <153799752172.21587.656470503791418522@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At:
Subject: Re: [Uta] I-D Action: draft-ietf-uta-smtp-require-tls-04.txt
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 26 Sep 2018 21:41:43 -0000
This revision incorporates comments, primarily corrections, that were
received during Working Group Last Call.
Two significant comments were not addressed because of lack of direction
from the Working Group:
- Suggestion from Viktor Dukhovni that DANE or MTA-STS be required for
recipient domains when REQUIRETLS is specified:
https://www.ietf.org/mail-archive/web/uta/current/msg02712.html
https://www.ietf.org/mail-archive/web/uta/current/msg02713.html
- Suggestion from external reviewer that use of REQUIRETLS be noted in
Received header fields:
https://www.ietf.org/mail-archive/web/uta/current/msg02720.html
-Jim
On 9/26/18 2:32 PM, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Using TLS in Applications WG of the IETF.
>
> Title : SMTP Require TLS Option
> Author : Jim Fenton
> Filename : draft-ietf-uta-smtp-require-tls-04.txt
> Pages : 15
> Date : 2018-09-26
>
> Abstract:
> The SMTP STARTTLS option, used in negotiating transport-level
> encryption of SMTP connections, is not as useful from a security
> standpoint as it might be because of its opportunistic nature;
> message delivery is, by default, prioritized over security. This
> document describes an SMTP service extension, REQUIRETLS, and message
> header field, RequireTLS. If the REQUIRETLS option or RequireTLS
> message header field is used when sending a message, it asserts a
> request on the part of the message sender to override the default
> negotiation of TLS, either by requiring that TLS be negotiated when
> the message is relayed, or by requesting that recipient-side policy
> mechanisms such as MTA-STS and DANE be ignored when relaying a
> message for which security is unimportant.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-04
> https://datatracker.ietf.org/doc/html/draft-ietf-uta-smtp-require-tls-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-require-tls-04
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
From nobody Fri Sep 28 08:17:23 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD73130DF7 for ; Fri, 28 Sep 2018 08:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, 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 eWXh4KEj4v4T for ; Fri, 28 Sep 2018 08:17:19 -0700 (PDT)
Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D255D130DC7 for ; Fri, 28 Sep 2018 08:17:18 -0700 (PDT)
Received: from computer ([2a01:598:a00d:7855:5f1d:b64e:d987:a684]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Fri, 28 Sep 2018 17:17:15 +0200 id 00000000000000B9.000000005BAE45FB.00001125
Date: Fri, 28 Sep 2018 17:17:14 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?=
To: uta@ietf.org
Message-ID: <20180928171714.14397439@computer>
X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At:
Subject: [Uta] Old draft usage of MTA-STS "mode: report" vs. "mode: testing"
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 28 Sep 2018 15:17:22 -0000
Hi,
With the release of MTA-STS I did some scans for policies on popular
domains.
I found a few policies published that use
mode: report
This seems to have been valid until draft 11, however it was later
changed and should be "mode: testing" according to later drafts and
the final RFC.
Given that MTA-STS is an RFC now I think it'd be good if all people
having policies using the syntax from early drafts update them asap.
--=20
Hanno B=C3=B6ck
https://hboeck.de/
mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
From nobody Fri Sep 28 11:07:22 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF57130E64 for ; Fri, 28 Sep 2018 11:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 t2lA1VHvWXGx for ; Fri, 28 Sep 2018 11:07:19 -0700 (PDT)
Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 C20591274D0 for ; Fri, 28 Sep 2018 11:07:18 -0700 (PDT)
Received: by mail-it1-x129.google.com with SMTP id p129-v6so3703810ite.3 for ; Fri, 28 Sep 2018 11:07:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tUbULjRu8665AIg0MqnFYcjrUtCh0xnCXwJVR1h2F6w=; b=GQnqPSWhDLENCF+Z9tt67ICrZId24fHrYOEX+cwZ1L01syh57EEJw4+nplCN8DeBQX 1xtWz7xPP6NPO3h8ej2djGk3vfExDqUFR6gCP6+B3b78isMbFOjGdygFuVgVGdzIzrRG z5QLcVrZcQa9p/P1xLbNVnp35nSqlQXruRhc8G42EodYXznh2StQPkHBt9weTYifWuJ8 C/obcPBcREFa/IPmWoWsNQ/qNRhfQSFPE+Kr3toxI65R/leZ5EZAGwXlg53bFDfto8hy NYskxn1dCgcAHO3jZueiEFZIGcqvHyxiTUP24lMxheMpXdTdC4J7/qEOxZ5m9WsY4A8x dT4Q==
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:cc; bh=tUbULjRu8665AIg0MqnFYcjrUtCh0xnCXwJVR1h2F6w=; b=NsTfJAyq8t25ngbhBJyUUJfu+JFPKsR+Wdk4+L0zG1iJ4YDE0Yw8ervGPFYOOoFri0 N//uyLmpzY1QAC1GEH5j3r+N4bI1INHhLNug2oNwwU+7CTZCeOpqwLm/tLHP1Q3UK5GM yCbPJQua1+h0B/M/6fOlK+Fpi20B7FzziSRKedAU8B8sDFggnl7hJ/AffYdBqBGmwPRt ZxS218+JXmG8M2+nKtIOPFdME83JlMbmrRdo1rK+jkzpr6RrARGuiyfMKvbOrcYl0nCc jZ2RbPOzmB7p5LX4Y/rZHqKAt1Ni9Z5lkNfEUVw2NLQvu+GrIZQCOmPs/xZTvnLp6mXZ OCQQ==
X-Gm-Message-State: ABuFfoi0tXDua/7nRKpdpgLTL4xB1RdphZYFsRISLKZT/YeHFH5MMgTi UuD5Azf6XKo4Wf9XQx5aBFOkCTZmvUl1E1Cu8UPoXUb5QUDkLg==
X-Google-Smtp-Source: ACcGV604+ZxJEW97Scf67Z+c8HbiWK4b3ZwzLtCrOasMqoufr+/UFa31k2RdXo4IShuHXta1ZLjVmDurRH9e2vEEsZE=
X-Received: by 2002:a02:1103:: with SMTP id 3-v6mr13971205jaf.144.1538158037673; Fri, 28 Sep 2018 11:07:17 -0700 (PDT)
MIME-Version: 1.0
References: <20180928171714.14397439@computer>
In-Reply-To: <20180928171714.14397439@computer>
From: Daniel Margolis
Date: Fri, 28 Sep 2018 20:07:04 +0200
Message-ID:
To: hanno@hboeck.de
Cc: uta@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000007bab460576f253e0"
Archived-At:
Subject: Re: [Uta] Old draft usage of MTA-STS "mode: report" vs. "mode: testing"
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 28 Sep 2018 18:07:20 -0000
--0000000000007bab460576f253e0
Content-Type: multipart/alternative; boundary="0000000000007257060576f25302"
--0000000000007257060576f25302
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thanks for pointing that out! There are also a few validators out there
that you can use to check your policy:
https://aykevl.nl/apps/mta-sts/ <-- I think this is effectively up to date
with the published version
https://www.hardenize.com/ <-- I don't know which revision this is based o=
n
Hope that helps.
Dan
On Fri, Sep 28, 2018 at 5:17 PM Hanno B=C3=B6ck wrote:
> Hi,
>
> With the release of MTA-STS I did some scans for policies on popular
> domains.
>
> I found a few policies published that use
> mode: report
>
> This seems to have been valid until draft 11, however it was later
> changed and should be "mode: testing" according to later drafts and
> the final RFC.
>
> Given that MTA-STS is an RFC now I think it'd be good if all people
> having policies using the syntax from early drafts update them asap.
>
> --
> Hanno B=C3=B6ck
> https://hboeck.de/
>
> mail/jabber: hanno@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>
--=20
How's my emailing? http://go/dan-email-slo
--0000000000007257060576f25302
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thanks for pointing that=
out!=C2=A0 There are also a few validators out there that you can use to c=
heck your policy:
Hope=
that helps.=C2=A0
Dan
<=
/div>
Hi,
With the release of MTA-STS I did some scans for policies on popular
domains.
I found a few policies published that use
mode: report
This seems to have been valid until draft 11, however it was later
changed and should be "mode: testing" according to later drafts a=
nd
the final RFC.
Given that MTA-STS is an RFC now I think it'd be good if all people
having policies using the syntax from early drafts update them asap.
--
Hanno B=C3=B6ck
https:/=
/hboeck.de/
mail/jabber: hanno@hbo=
eck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
--
--0000000000007257060576f25302--
--0000000000007bab460576f253e0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw
NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG
A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F
GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes
BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3
Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6
6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB
/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt
r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n
c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG
9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse
Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x
t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h
isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA
NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA
AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt
IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw
MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB
MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB
Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge
C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2
52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua
eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD
rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY
MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt
7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e
oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7
qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT
Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk
WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw
TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x
EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG
A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi
FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X
17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm
KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp
sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7
DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL
QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s
bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV
3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr
VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMFg3DbRgssHwvPbQgMA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDcxNTE4NDIxOVoXDTE5MDEx
MTE4NDIxOVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCWKSqYGCOO/mAn0Zr2WgoDMzvFSkjrSyEWkD9aMxPZ2QB8
dbi9v+kn0wV3M5RqQmhkL4WkAHTnEyMUVGsO45NoTrvh1pj6HfzhnXOgB8H6/UgC8+KofYe7id6I
dZB7j+/G+SGRlqqUeKrCv8+eZWPJpex55yPgzvzjcL9pCxrpP+mIY+yGWAdiurp2MB2g+w+KpG6E
tuX+wHXyDiEY9N0Db03qUH08/vAQc8VXdLSmYK3NioG8Tt7tee9lvmKVzBoy2bqcCIZu340IjlCc
pPx1mJgIZZ/tfZmPAoZef1bEBu/S74XgRDohBhTp2fLHo7uMaNSBFTRqn+4hBVOHQK+TAgMBAAGj
ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw
QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt
ZWNhMS5jcnQwHQYDVR0OBBYEFHFJsxRAZqACW/l1hEGpNUpmkT3cMB8GA1UdIwQYMBaAFMs4ErDH
mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0
dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0
dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBq1+6WGyIp
iVheSaD8Soke5tmwuN5tdJpPtxa4C9egQTF+7PlFPhRany83Na4/j6P7qzVjgYN/Sm7M/AtJz5Tg
mrfgs33+jSrU6VFJsbyywqGEj0dY2ZE3hqtvNmjWgND3PNJ6j2yK8dw3t+uMtZCZiVa0a6WFeBQ1
DNjK25f3jbwcKsYxr/F1dELBpVWMcCxSOw3Ov04QSt8CaeR61yIk+Q//fv++rcv7SEWExpWEBw97
QR2QdGlkB4OsM6RuvXcCCjkJzbmMY8SpeoaVmou1vbOyK7INnEg9C+WXyZaQP3/M3xAgavvoLcW/
pwj+O+Z9ljoSX+v0nibNGd8u6tk6MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE
ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM
Fg3DbRgssHwvPbQgMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCvRJg/LnjZsTyY
561ZpqwWuQDM7t3squegcRL528oZaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0xODA5MjgxODA3MThaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG
SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB
BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEADpDdMKthLk/Kb/HmShxmQoPwt1dlsiOd
Tco+5gEt/AEDtKSL/Dd4BsOShE8+WyIue3h0vdFGM1MHqNx0Z7txd5W/5vmKl9rfaG2o+LtUUb6i
TndgCAK0knqJQadsr1o1UVoby16sSWvbgkHtj+kQ60qp4FzJnbz55AJNwF4WcBYh9fXLbmcYtBnW
DTUOZDghmUM25fDBBvC8uUqoLyVRmnJ5NTDihxGoLOzpp8Aaevzg5HTex/lGcvzIVvOAI27dvMQ8
FPJBBNc7vPbqZt0W+RhMz0gBBrxlbYx43VSLXL1AgVl+Z/5Q22DsFpoqTwgBOXfPn80veR8SGV3Z
nked7w==
--0000000000007bab460576f253e0--
From nobody Sat Sep 29 11:13:31 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDFF130E3A for ; Sat, 29 Sep 2018 11:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=andreasschulze.de header.b=1DlNpXRo; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=4kZhYXbw
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 AK3qrrCQIImI for ; Sat, 29 Sep 2018 11:13:27 -0700 (PDT)
Received: from mta.somaf.de (mta.somaf.de [IPv6:2001:470:77b3:103::25]) (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 AEE8D130E3F for ; Sat, 29 Sep 2018 11:13:27 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=andreasschulze.de; i=@andreasschulze.de; q=dns/txt; s=ed25519; t=1538244802; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : subject : from : date; bh=eOrD/cC/lF24yE7UKtyt4w9qSYteJaGpp5cxDrUrKAs=; b=1DlNpXRo4OuMpu9z238GmzFQKdGR8HAB70SyArODHTL/nQdRgcqNQAgm 8o3bD1k0/UHRgMm1Cn5f4nZjIpasCg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=20180826-48EA; t=1538244801; x=1543244801; bh=eOrD/cC/lF24yE7UKtyt4w9qSYteJaGpp5cxDrUrKAs=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To: Content-Type:from:reply-to:subject:date:to:cc:content-type: message-id; b=4kZhYXbwxhevyP9WW6DQa7jwGwgvHlUeM+CpVKPldeyJ1h299e4fXg0tP2wbPu7D7 0+sIBy8hO1fec/sUENBlW04cXBKYyEpL12HghYZgXeHGB/fNFl6j4m11t6WDBfEJv+ hZYeYoPjovATtUJdriaGxQ/4Zm+ZiA9lzl70mN/4MxeNN0O98bjKzNmAN7RK55gdhn /aRRnX2+6xNrMPJrubGqQwZW+qUiagk0wcNSzO/wyXScNE8rp7iNjP1siEfpXonPS7 Vo+dk/6N9G2yKG79BazzW9clxZ0vuNsI52FgMfOZmaItQQEfNsDWK1R29fbcfXU2kz ZJDrqPjwkfVNA==
To: uta@ietf.org
References: <20180926165230.2E88BB81226@rfc-editor.org>
From: "A. Schulze"
Message-ID: <6241bc06-1356-4675-57b2-6d0d4af274da@andreasschulze.de>
Date: Sat, 29 Sep 2018 20:13:20 +0200
MIME-Version: 1.0
In-Reply-To: <20180926165230.2E88BB81226@rfc-editor.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At:
Subject: Re: [Uta] RFC 8461 on SMTP MTA Strict Transport Security (MTA-STS)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 29 Sep 2018 18:13:30 -0000
Am 26.09.18 um 18:52 schrieb rfc-editor@rfc-editor.org:
> A new Request for Comments is now available in online RFC libraries.
>
>
> RFC 8461
>
> Title: SMTP MTA Strict Transport Security
> (MTA-STS)
> SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling
> mail service providers (SPs) to declare their ability to receive
> Transport Layer Security (TLS) secure SMTP connections and to specify
> whether sending SMTP servers should refuse to deliver to MX hosts
> that do not offer TLS with a trusted server certificate.
Hello WG,
I consider implementing MTA-STS on our platform hosting thousand+ Domains.
Now I just found the following text:
Note that in all such cases, the policy endpoint
("https://mta-sts.user.example/.well-known/mta-sts.txt" in this
example) must still present a certificate valid for the Policy Host
("mta-sts.user.example"), and not for that host at the provider's
domain ("mta-sts.provider.example").
Does that really mean I have to setup thousand+ virtual hosts https://mta-sts.domain1...1000.example?
Or are there other strategies for hosting provider?
Andreas
From nobody Sat Sep 29 11:36:10 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26591130E3F for ; Sat, 29 Sep 2018 11:36:09 -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 xIZw-2puJXWP for ; Sat, 29 Sep 2018 11:36:07 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6DA130E4C for ; Sat, 29 Sep 2018 11:36:06 -0700 (PDT)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 1386230B0BB for ; Sat, 29 Sep 2018 14:36:05 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Viktor Dukhovni
In-Reply-To: <6241bc06-1356-4675-57b2-6d0d4af274da@andreasschulze.de>
Date: Sat, 29 Sep 2018 14:36:04 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: uta@ietf.org
Message-Id: <70A2F4AD-F4A6-4AE0-9B25-C7CA03DECD89@dukhovni.org>
References: <20180926165230.2E88BB81226@rfc-editor.org> <6241bc06-1356-4675-57b2-6d0d4af274da@andreasschulze.de>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At:
Subject: Re: [Uta] RFC 8461 on SMTP MTA Strict Transport Security (MTA-STS)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 29 Sep 2018 18:36:09 -0000
> On Sep 29, 2018, at 2:13 PM, A. Schulze wrote:
>=20
> I consider implementing MTA-STS on our platform hosting thousand+ =
Domains.
> Now I just found the following text:
>=20
> Note that in all such cases, the policy endpoint
> ("https://mta-sts.user.example/.well-known/mta-sts.txt" in this
> example) must still present a certificate valid for the Policy Host
> ("mta-sts.user.example"), and not for that host at the provider's
> domain ("mta-sts.provider.example").
>=20
> Does that really mean I have to setup thousand+ virtual hosts =
https://mta-sts.domain1...1000.example?
Yes.
> Or are there other strategies for hosting provider?
None that I know of.
--=20
Viktor.
From nobody Sat Sep 29 23:56:37 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61BE130DDD for ; Sat, 29 Sep 2018 23:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, 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 DQa2LW2DCbr0 for ; Sat, 29 Sep 2018 23:56:33 -0700 (PDT)
Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3EB112F1AB for ; Sat, 29 Sep 2018 23:56:32 -0700 (PDT)
Received: from computer ([2a02:8109:83c0:4bfd:aade:c5c7:26b2:2c2d]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sun, 30 Sep 2018 08:56:30 +0200 id 000000000000006E.000000005BB0739E.00000E06
Date: Sun, 30 Sep 2018 08:56:32 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?=
To: uta@ietf.org
Message-ID: <20180930085632.580797ab@computer>
In-Reply-To: <6241bc06-1356-4675-57b2-6d0d4af274da@andreasschulze.de>
References: <20180926165230.2E88BB81226@rfc-editor.org> <6241bc06-1356-4675-57b2-6d0d4af274da@andreasschulze.de>
X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At:
Subject: Re: [Uta] RFC 8461 on SMTP MTA Strict Transport Security (MTA-STS)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 30 Sep 2018 06:56:36 -0000
On Sat, 29 Sep 2018 20:13:20 +0200
"A. Schulze" wrote:
> I consider implementing MTA-STS on our platform hosting thousand+
> Domains. Now I just found the following text:
>=20
> Note that in all such cases, the policy endpoint
> ("https://mta-sts.user.example/.well-known/mta-sts.txt" in this
> example) must still present a certificate valid for the Policy Host
> ("mta-sts.user.example"), and not for that host at the provider's
> domain ("mta-sts.provider.example").
>=20
> Does that really mean I have to setup thousand+ virtual hosts
> https://mta-sts.domain1...1000.example? Or are there other strategies
> for hosting provider?
This seems to be the one thing that is confusing a lot of people about
MTA-STS. The answer is yes you have to, no, there are no other
strategies.
The policy host is the thing that ties your domain name's identity to
your policy. This makes sure you can only serve a policy for
user.example if you control and have a certificate for user.example.
If you could serve a policy for user.example on provider.example you'd
not have that connection.
There is of course a good solution for this: Automate your virtual host
and certificate creation.
--=20
Hanno B=C3=B6ck
https://hboeck.de/
mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
From nobody Sun Sep 30 00:15:08 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2268130E23 for ; Sun, 30 Sep 2018 00:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkIzc5hQw745 for ; Sun, 30 Sep 2018 00:15:04 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF076130DE0 for ; Sun, 30 Sep 2018 00:15:04 -0700 (PDT)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 26C0C30B73A for ; Sun, 30 Sep 2018 03:15:03 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Viktor Dukhovni
In-Reply-To: <20180930085632.580797ab@computer>
Date: Sun, 30 Sep 2018 03:15:02 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: uta@ietf.org
Message-Id:
References: <20180926165230.2E88BB81226@rfc-editor.org> <6241bc06-1356-4675-57b2-6d0d4af274da@andreasschulze.de> <20180930085632.580797ab@computer>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At:
Subject: Re: [Uta] RFC 8461 on SMTP MTA Strict Transport Security (MTA-STS)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 30 Sep 2018 07:15:07 -0000
> On Sep 30, 2018, at 2:56 AM, Hanno B=C3=B6ck wrote:
>=20
>> Does that really mean I have to setup thousand+ virtual hosts
>> https://mta-sts.domain1...1000.example? Or are there other strategies
>> for hosting provider?
>=20
> This seems to be the one thing that is confusing a lot of people about
> MTA-STS. The answer is yes you have to, no, there are no other
> strategies.
>=20
> The policy host is the thing that ties your domain name's identity to
> your policy.=20
This is one way in which DANE is less onerous. For a domain with
signed MX records, the TLSA records are in the provider's zone
at _25._tcp.the.mxhost.example. Allowing just one TLSA RRset
managed by the provider to take care of all the (signed) hosted
domains. This works even when the MX hosting provider does not
control the customer's domain, and is not in a position to
obtain the requisite certificates. In that case setting up the
MTA-STS policy is up to the customer.
--=20
Viktor.
From nobody Sun Sep 30 02:33:45 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3360130DF2 for ; Sun, 30 Sep 2018 02:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=andreasschulze.de header.b=pJq44ZIP; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=WWmrryIA
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 bI-rdiObFdMR for ; Sun, 30 Sep 2018 02:33:40 -0700 (PDT)
Received: from mta.somaf.de (mta.somaf.de [IPv6:2001:470:77b3:103::25]) (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 81353130DF0 for ; Sun, 30 Sep 2018 02:33:40 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=andreasschulze.de; i=@andreasschulze.de; q=dns/txt; s=ed25519; t=1538300013; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : subject : from : date; bh=SVOMdbxZIS1VObkRahuVhYVXM+IHPrVWRVzWeI9wokU=; b=pJq44ZIPa2a1ls5uv1vyFSgTSfhDn7PQ37MEIt/vYSUOSuWfkm1tRSo1 HQPeAB2o2QaAS0CDMv+DnZaUNbyQCw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=20180826-48EA; t=1538300013; x=1543300013; bh=SVOMdbxZIS1VObkRahuVhYVXM+IHPrVWRVzWeI9wokU=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To: Content-Type:from:reply-to:subject:date:to:cc:content-type: message-id; b=WWmrryIAO6Mdqob3aQT6IXlH00OPtescBRSDX3EQKnEoDx8wxA/jv7H6xYeLG1e81 9XE2hkAEHUBEAljjBiZLk6A6NHavxTnckbvsXZlNqXFeWDbV+5wn013nBvp5ImBkgs +mOGg+gAS7xXUdglons1lCCXyFwmx8USBDmEjOUKhXv17Y46oMhD5GHzlypsVwUIXy aeezpBm26qai7rnwjF+JavyLgrhXu6c3lFGXI+1r3Mrg6jnV8ZXgyxIxA7udrYPrX4 gZ4heai/ycRpIbGSAmkF1e1/7r9TcNIb5W/wNIhGKwzKT9KuOCHCsjhrziqMHQpucv tgXpdrWMxtGqw==
To: uta@ietf.org
References: <20180926165230.2E88BB81226@rfc-editor.org> <6241bc06-1356-4675-57b2-6d0d4af274da@andreasschulze.de> <20180930085632.580797ab@computer>
From: "A. Schulze"
Message-ID: <824bb910-9d62-4327-6b42-56d4692b5c91@andreasschulze.de>
Date: Sun, 30 Sep 2018 11:33:26 +0200
MIME-Version: 1.0
In-Reply-To:
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At:
Subject: Re: [Uta] RFC 8461 on SMTP MTA Strict Transport Security (MTA-STS)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 30 Sep 2018 09:33:44 -0000
Am 30.09.18 um 09:15 schrieb Viktor Dukhovni:
>> On Sep 30, 2018, at 2:56 AM, Hanno Böck wrote:
>>
>>> Does that really mean I have to setup thousand+ virtual hosts
>>> https://mta-sts.domain1...1000.example? Or are there other strategies
>>> for hosting provider?
>>
>> This seems to be the one thing that is confusing a lot of people about
>> MTA-STS. The answer is yes you have to, no, there are no other
>> strategies.
>>
>> The policy host is the thing that ties your domain name's identity to
>> your policy.
>
> This is one way in which DANE is less onerous. For a domain with
> signed MX records, the TLSA records are in the provider's zone
> at _25._tcp.the.mxhost.example. Allowing just one TLSA RRset
> managed by the provider to take care of all the (signed) hosted
> domains. This works even when the MX hosting provider does not
> control the customer's domain, and is not in a position to
> obtain the requisite certificates. In that case setting up the
> MTA-STS policy is up to the customer.
>
Hello,
thanks for clarification.
As a side effect one could enumerate domains supporting MTA-STS just by watching the CT logs.
Andreas
From nobody Sun Sep 30 11:11:40 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FCE1293FB for ; Sun, 30 Sep 2018 11:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, 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 dPFmrg2Dx95B for ; Sun, 30 Sep 2018 11:11:35 -0700 (PDT)
Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A8F12426A for ; Sun, 30 Sep 2018 11:11:34 -0700 (PDT)
Received: from computer ([2a02:8109:83c0:4bfd:aade:c5c7:26b2:2c2d]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sun, 30 Sep 2018 20:11:32 +0200 id 000000000000006C.000000005BB111D4.000056DE
Date: Sun, 30 Sep 2018 20:11:34 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?=
To: uta@ietf.org
Message-ID: <20180930201134.3956a25c@computer>
X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At:
Subject: [Uta] Scanresults mta-sts policies
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 30 Sep 2018 18:11:38 -0000
Hi,
I did now some more scans for MTA-STS and I thought it might be
interesting for the list to learn the results.
A very effective way of finding hosts that support mta-sts is to scrape
the Certificate Transparency logs. (With the exception of hosts that
use wildcard certificates.)
This gave me 697 hosts with an mta-sts subdomain. Of those 416 served
something that looked like an mta-sts policy file, indicating that a
large number (281) are either in the process of deploying MTA-STS and
haven't finished yet or have wrongly implemented it, e.g. by using the
wrong filename/path.
I found a few syntax issues:
* The most worrying one is that 24 hosts use policies like
"mx: .example.org" which was valid in older drafts. I say this is the
most worrying, because it may actually lead to delivery failures.
It'd be good to get them converted quickly before this creates
hassle. However only 4 of them have "mode: enforce" (with "mode:
testing" I'm not overly worried).
* 11 hosts use "mode: report", which is also from earlier drafts and
should be "mode: testing". However a number of hosts have already been
fixed before I made this scan.
* Some have trailing or leading spaces. It's not entirely clear to me
if this is something to be considered an invalid policy.
* I also wonder about line endings. 263 use Unix line endings (LF
only), 154 use Windows line endings (CRLF). The RFC reads like CRLF
is correct (3.2), which would indicate a large number of bad policies.
However the formal definition in the RFC also lists . I am not
familiar with how to read the formal definition. (It also says
something about spaces.)
I'd appreciate if someone could clarify whether leading/trailing spaces
and unix line breaks should be considered policies that should be
fixed or if this is okay.
Some stats about modes:
211 mode: enforce
194 mode: testing
11 mode: report (invalid)
no mode: none found.
--=20
Hanno B=C3=B6ck
https://hboeck.de/
mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
From nobody Sun Sep 30 11:50:36 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D419130DFF for ; Sun, 30 Sep 2018 11:50:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnTA0g7ynQ9E for ; Sun, 30 Sep 2018 11:50:32 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588C9128D0C for ; Sun, 30 Sep 2018 11:50:32 -0700 (PDT)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 5584630BCB7; Sun, 30 Sep 2018 14:50:30 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Viktor Dukhovni
In-Reply-To: <20180930201134.3956a25c@computer>
Date: Sun, 30 Sep 2018 14:50:28 -0400
Cc: uta@ietf.org
Reply-To: uta@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B77497B-BA9C-4349-9948-68F6E13F8D53@dukhovni.org>
References: <20180930201134.3956a25c@computer>
To: =?utf-8?Q?Hanno_B=C3=B6ck?=
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At:
Subject: Re: [Uta] Scanresults mta-sts policies
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 30 Sep 2018 18:50:34 -0000
> On Sep 30, 2018, at 2:11 PM, Hanno B=C3=B6ck wrote:
>=20
> I did now some more scans for MTA-STS and I thought it might be
> interesting for the list to learn the results.
Thanks for the data collection!
> A very effective way of finding hosts that support mta-sts is to =
scrape
> the Certificate Transparency logs. (With the exception of hosts that
> use wildcard certificates.)
>=20
> This gave me 697 hosts with an mta-sts subdomain.
A small comment on terminology, I find your use of "host" here rather
confusing. I'm used to speak of "domains" that receive email, and
a given domain's MX hosts ("MX host" is not a formal IETF term, but
is widely used and understood). The domain part of an email address
need not correspond to any host, and many don't. The domain names
that appear as the "exchange" field of an MX record RDATA (i.e.
MX hosts) are of course names of hosts, since they are expected to
terminate TCP connections to the SMTP (port 25) service.
Thus, with MTA-STS, the policy is associated with a domain, and is
provided via HTTPS by the host whose name is constructed by prefixing
the label "mta-sts" the policy domain.
--=20
Viktor.
From nobody Sun Sep 30 12:48:39 2018
Return-Path:
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48826130DFF for ; Sun, 30 Sep 2018 12:48:37 -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 (2048-bit key) header.d=jhcloos.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 VSR52Tpwezb1 for ; Sun, 30 Sep 2018 12:48:34 -0700 (PDT)
Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 A8D051286D9 for ; Sun, 30 Sep 2018 12:48:34 -0700 (PDT)
Received: by ore.jhcloos.com (Postfix, from userid 10) id AA8611E51F; Sun, 30 Sep 2018 19:48:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1538336912; bh=E0ThKm7M9R/ZJSoZAe4FbfXVFSqqvwZOO7FFSw1fqXg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JCfgNwGMqX9BhPSdM4WxHdIAXNOnunVIjyhTodWUJfn5nv1CJM28+TYaeqpkC9yq9 tf9pS1HF6CfTKxfWLR0040bvAyNUxHdXMRx6uUeU1ZT9sw/tOzS9GvSr1PfmIyBUIs kM+dcRaWxSxeCjEPKdkhOeB7nYAhFKmddWlm8A9hGs3YLp8cUTdQD50nruHSx0K9O2 h1Gr5uthKnR+o71yrw7NQYZNNWORMIeiAfNG8+oXj7rwOGgUKRPLSxVY78wXTrGIyK R6wtqtrRfH3NtOWIVGOOdPGIF7ivE3Tb5P12gNUs9UIQmg1nZd2te3j7T7tqFSIgJP A5gmC7DleRsRw==
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 3D4C210A6FF2F; Sun, 30 Sep 2018 19:48:26 +0000 (UTC)
From: James Cloos
To: uta@ietf.org
Cc: Hanno =?iso-8859-1?Q?B=F6ck?=
In-Reply-To: <20180930201134.3956a25c@computer> ("Hanno =?iso-8859-1?Q?B?= =?iso-8859-1?Q?=F6ck=22's?= message of "Sun, 30 Sep 2018 20:11:34 +0200")
References: <20180930201134.3956a25c@computer>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2018 James Cloos
OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
Date: Sun, 30 Sep 2018 15:48:25 -0400
Message-ID:
Lines: 17
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Archived-At:
Subject: Re: [Uta] Scanresults mta-sts policies
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 30 Sep 2018 19:48:37 -0000
>>>>> "HB" == Hanno Böck writes:
HB> * I also wonder about line endings. 263 use Unix line endings (LF
HB> only), 154 use Windows line endings (CRLF). The RFC reads like CRLF
HB> is correct (3.2), which would indicate a large number of bad policies.
HB> However the formal definition in the RFC also lists . I am not
HB> familiar with how to read the formal definition. (It also says
HB> something about spaces.)
It would be much easier if works. I also got the impression
that is required, and manually had to add to the end
of each line in the file to ensure that it would be served with
them. A proper, simple text file would be easier.
-JimC
--
James Cloos