Yes, we've gotten a couple now. There was an announcement on their blog:
https://security.googleblog.com/2019/04/gmail-making-email-more-secure-with-mta.html
Mostly talking about MTA-STS, but they do mention that TLSRPT started as well.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Polic
-Abuse & Messaging Policy
Comcast
From: Jim Fenton
Sent: Thursday, March 28, 2019 9:57 AM
To: Brotman, Alexander ; uta@ietf.org
Subject: Re: [Uta] Revised wording on security consideration re TLS-Required
Good thought. Since it's acting as though it doesn't implement MTA-STS, then
Jim,
I’m not sure how much of an impact this might have, but should there be a
reference to TLSRPT? Either not to be counted or to explain the lack of TLS
based on “TLS-Required: no” being set?
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: Uta On Behalf Of Jim Fen
Hello,
Should that count as a consensus, or would others like additional information?
Thank you
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
From: Daniel Margolis [mailto:dmargo...@google.com]
Sent: Tuesday, July 17, 2018 9:32 AM
To: Brotman, Alexander
Cc: uta@ietf.org
Subject: [EXTERNAL
Hello,
While someone was beginning to write their code for TLSRPT, they noticed that
mx-host-pattern is under specified.
o "mx-host-pattern": The pattern of MX hostnames from the applied
policy. It is provided as a string, and is interpreted in the
same manner as the "Checking o
Alberto,
"comcast.net" also has an MTA-STS record, as well as a TLSRPT record.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
-Original Message-
From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Alberto Bertogli
Sent: Sunday, July 01, 2018 6:19 PM
To: uta@ietf.org
Subject: [Uta] Li
email addresses/
> On Jun 15, 2018, at 2:09 PM, Brotman, Alexander
> wrote:
>
> A few smaller updates for this. ABNF updates, and a few small language
> changes.
--
Viktor.
___
Uta mailing list
Uta@ietf.org
https://www.i
A few smaller updates for this. ABNF updates, and a few small language changes.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
-Original Message-
From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Friday, June 15, 2018 2:06 PM
To: i-d-annou...@ietf.org
Hello,
We have just uploaded a new revision for each of the above drafts. We believe
we've incorporated all of the most recent feedback from reviewers. The largest
change for MTA-STS was relating to the MX/SAN matching. For TLSRPT, we added a
field for the DKIM record, removed mention of the
ERNAL] Re: I-D Action: draft-ietf-uta-smtp-tlsrpt-19.txt
> On May 10, 2018, at 11:09 AM, Brotman, Alexander
> wrote:
>
>> "The text in Section does not make it clear to what name the prefix
>> "_smtp._tls"
>> should be prepended. I think this would
Sure, let me get that in there. I'll try to get it uploaded shortly.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
-Original Message-
From: Alexey Melnikov [mailto:alexey.melni...@isode.com]
Sent: Wednesday, May 02, 2018 1:00 PM
To: Brotman, Alexander ; uta@ietf.org
Su
Hello,
We wanted to upload another set of drafts so that we could ensure we've
properly addressed items previously raised. I believe Alexey and Ned were
still discussing an item relating to MTA-STS, and the concerns from Sabrina for
TLSRPT are still to be addressed. Please let us know if ther
For the DISCUSS section:
We did note that the reports could be made to be submitted elsewhere via
hijacked DNS, as you've noted. I don't believe that an expired or self-signed
certificate from the HTTPS endpoint should be a reason to stop the submission,
so we can leave it to the submitter. A
Thank you for the correction, the IPs have been altered now.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
-Original Message-
From: Suresh Krishnan [mailto:sur...@kaloom.com]
Sent: Tuesday, April 17, 2018 10:44 PM
To: The IESG
Cc: draft-ietf-uta-smtp-tls...@ietf.org; Valery Smyslov
Folks,
We're not there quite yet, but I wanted to send out some revised copies. I
believe we still have a couple of outstanding questions to some folks, but we
should have responses soon. I believe all of the changes are related to the
meeting in London, or the WGLC items that were raised to
permiting the appropriate service
See RFC 6376 section 3.6.1, description of s= tag.
-Jim
On 3/14/18 4:21 AM, Brotman, Alexander wrote:
> I don't see any reason a specific DKIM selector wouldn't be possible.
>
> We'll see if we can get some language added to address th
I may have missed the consensus on this. I don’t believe the final DNS entry
is hugely important as it pertains to TLSRPT on its own, as long as it extends
from the target domain. So, today we have "_smtp-tlsrpt.example.com", but it
seems like to get more in line with a proper IANA registratio
items
causing reports show failures.
3) I believe 2 and 3 are similar situations.
Does that answer some of your questions?
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
-Original Message-
From: Ayke van Laethem [mailto:a...@aykevl.nl]
Sent: Saturday, March 24, 2018 5:56 PM
To: Brotman, Alex
I don't see any reason a specific DKIM selector wouldn't be possible.
We'll see if we can get some language added to address the clarifications
you've requested.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent
[mailto:uta-boun...@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Tuesday, March 13, 2018 11:50 AM
To: Brotman, Alexander
Cc: uta@ietf.org; draft-ietf-uta-smtp-tlsrpt@ietf.org; i...@ietf.org;
sec...@ietf.org
Subject: Re: [Uta] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17
If
I'm not opposed to change this to be in that form. I don't believe this would
cause any technical issues.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
-Original Message-
From: Phillip Hallam-Baker [mailto:hal...@gmail.com]
Sent: Thursday, March 08, 2018 2:39 PM
To: sec...@ietf.org
r 4, 2018, at 1:47 PM, Brotman, Alexander
> wrote:
>
> Hello folks,
>
> We used the feedback from folks during the WGLC and have submitted a new
> version. This is mostly editorial changes or minor inconsistencies. We did
> also remove any relation between the TLS-
Hello folks,
We used the feedback from folks during the WGLC and have submitted a new
version. This is mostly editorial changes or minor inconsistencies. We did
also remove any relation between the TLS-Report-Submitter and the filename. If
you have any comments, please let us know. Thank yo
Hello folks,
We just updated TLSRPT and welcome comments. The changes mostly reflect
comments from Viktor and others around the Content-Type.
- Altered policy report section to be JSON strings
- Content-Type changes to match comments from UTA mailing list
- Added receiving IP
Thank you for any
Sorry for the late response folks, last week was fairly busy.
I'll work with Viktor to resolve the remaining changes, and discuss the
Content-Type with Alexey.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
-Original Message-
From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Vikto
Hello,
We uploaded a new version of the TLSRPT a few moments ago. The majority of the
changes are meant to address comments submitted by Viktor Dukhovni
(https://www.ietf.org/mail-archive/web/uta/current/msg02388.html). A rough
list of changes:
- Update to mime type
- Add dnssec-required
- T
To reference the other message, we'll change that reference for DANE. I'll try
to respond in-line for this one.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
-Original Message-
From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Viktor Dukhovni
Sent: Tuesday, December 05, 2017 11:14
Hello folks,
These two drafts were uploaded last night, and we'd like any feedback. For the
MTA-STS, there are changes relating to SNI, minimum TLS version, and reverse
proxy language. There are also some minor nits that were resolved. For
TLSRPT, we added some language about DoS attacks, om
iktor Dukhovni
Sent: Monday, October 09, 2017 3:55 PM
To: uta@ietf.org
Subject: Re: [Uta] Updated MTA-STS & TLSRPT
On Mon, Oct 09, 2017 at 06:24:36PM +, Brotman, Alexander wrote:
> Do we think we really need to allow caching? From what are we trying
> to protect the backend systems?
Do we think we really need to allow caching? From what are we trying to
protect the backend systems? Feels like it would be easier to disallow caching
(or recommend against). I understand the sense that a smaller company could be
overwhelmed by an attacker or ill-configured legit sender, but
g the STS policy (which was a JSON
body itself, which no longer is the case).
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
-Original Message-
From: James Cloos [mailto:cl...@jhcloos.com]
Sent: Friday, September 29, 2017 2:54 PM
To: Brotman, Alexander
Cc: uta@ietf.org
Subject: Re:
Folks,
We've just uploaded new revisions for the drafts mentioned above. Not a ton of
changes, but wanted to share with the group.
MTA-STS: Added Policy Delegation and a few other clarifications
TLSRPT: Changed the domains associated with reporting, added examples for
policy-strings, and adde
Quick conversation with some DNS folks, and they say that we can publish a TXT
record at the apex of a delegated sub-domain. CNAMEs would not be allowed, but
A/TXT should be okay.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Daniel Margo
Hello folks,
The biggest change of these two is the addition of the "none" policy for the
MTA-STS and the description of how to deactivate an existing policy. There are
a few smaller items such as language for lengthy TXT records. There is also
now a short section in TLSRPT about the HTTPS re
Hello folks,
We just uploaded new versions of these drafts. For MTA-STS, the major change
is the K/V is now in the main tree, and some ABNF cleanups. We're still
working on incorporating some feedback from late last week. For TLSRPT, we've
tried to incorporate feedback from the group. We al
Jim,
To be clear, you'd like to remove the headers (5.3) and filename (5.1)
sections, and have all the filtering based solely on the subject that is
specified in 5.3? And relating to "draft-ietf-dnsop-attrleaf", could you
clarify that a bit? Are you asking me to request an alteration of the a
Hello Folks,
We attempted to incorporate the feedback from Alexey and Chris as best we
could, and we believe we have addressed each of their concerns either via the
updated draft or via the mailing list. The period for the WGLC is nearly over,
and we wanted to try to provide an interim/updated
or similar) so
that we don’t need to do this.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
x5364
From: David Illsley [mailto:davidills...@gmail.com]
Sent: Monday, July 17, 2017 3:37 PM
To: Brotman, Alexander
Cc: uta@ietf.org
Subject: Re: [Uta] MTA-STS: A Key-Value Alternative
Is there a
Hello,
The authors of the MTA-STS draft and the UTA group have been attempting to
reach a consensus on the issue of JSON versus KV for the policy file that is
served via HTTPS. In order to attempt to get over that issue, we've made a
rough draft[1] that now uses key-value pairs instead of JSO
All,
A new draft for MTA-STS has been submitted. The changes include some wording
relating to Certificate Validation, and IANA Registry sections. There is also
some discussion on the list about the JSON/KV subject. We are looking forward
to feedback regarding the previous items. Thank you.
We believe so. We'd like to gather as many comments as possible to go with
Alexey's and bundle those up, and hopefully finalize this.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
x5364
-Original Message-
From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Leif Johansson
Sent: Wedn
Most of these seem reasonable, and we'll get to work sorting them out. The
only question I have is relating to:
--
o "policy-type": The type of policy that was applied by the sending
domain. Presently, the only three valid choices are "tlsa",
"sts", and the litera
Hello,
We just uploaded new revisions of the MTA-STS and TLSRPT. We made some minor
clarifications in MTA-STS. For the TLSRPT we created a new content-type to
define the tlsrpt data, which should make the processing a bit easier. We do
still need to create some of the IANA sections, and we'l
Hello folks,
A fair bit of these updates were cleanup for various smaller items. Some
changes to the pseudocode, clearing language around cached policies, and
addressing many of the items Alexey had noted. We still have a few of Alexey's
notes to go over in the near future, as well as the IAN
lsrpt-04 review
On 06/04/17 14:17, Brotman, Alexander wrote:
> In section 4, it mentions the Policy section should include the domain for
> which the policy was applied. I can add another reference in Section 3 if
> that's preferred.
The point I'm trying to make is that the ge
In section 4, it mentions the Policy section should include the domain for
which the policy was applied. I can add another reference in Section 3 if
that's preferred.
We can add an explicit CNAME mention.
With regard to the JSON policy (though that's STS, not TLSRPT). It's a small
file, whi
Hello,
I meant to send these yesterday, but got sidetracked with some things at the
office, as well as a rather long meeting.
Probably the biggest alteration is that we altered both to utilize the SAN
instead of the CN for hostname/policy validation. We made several
clarifications, and update
Folks,
We uploaded new revisions for MTA-STS and TLSRPT. There are minor changes to
each:
1) Remove the "_" from DNS records to be consistent with A/ records used
with the HTTPS retrieval, and make this a bit less confusing for deployments.
We did this for both MTA-STS and TLSRPT.
2) Cla
If a system is misbehaving in some way that causes TLS problems, it may be
malfunctioning in other ways that would prevent reports from making it to the
appropriate place. It might be useful to get that new command (QUIT does not
take an optional parameter that I'm aware) to indicate to the rec
>From what I know of my organization, it would be easier to create a separate
>hostname (policy._mta_sts.comcast.net) than to get some content served by the
>main domain's realm (comcast.net/foo/bar/sts-policy). I'm not saying it can't
>be done, just that I interact often with the DNS group I w
Hello,
We've incorporated much of the feedback we've received from the community, and
would like to present updated drafts.
* One of the most evident changes is that we've split the draft into two
separate documents; one for the STS policy, and one for the TLS reporting.
These are meant to r
so that others can easily follow along.
--
Alex Brotman
Engineer, Anti-Abuse
Comcast
x5364
-Original Message-
From: Aaron Zauner [mailto:a...@azet.org]
Sent: Friday, December 04, 2015 5:56 PM
To: Brotman, Alexander
Cc: uta@ietf.org
Subject: Re: [Uta] Dealing with STARTTLS Stripping
Aaron,
There's a group of folks from M3AAWG that are working toward a sort of
mechanism for SMTP, roughly using some ideas relating to HSTS and/or
certificate transparency. The idea being that you would specify a published
policy where a sender can see that you expect that sessions will be enc
53 matches
Mail list logo
