Interesting. That's possible.
Actually, let me step back. Not to be stupid, but reading the RFC, is there
a clear statement on when an MTA should send TLSRPT reports? Sending them
to a domain to whom you've never communicated before seems a bit odd, but I
actually can't figure out (at a quick skim
> "DM" == Daniel Margolis writes:
DM> Google should only be sending TLSRPT reports for time periods in which
DM> there was mail sent.
They send me daily reports for each of my tlsrpt zones to which they've
sent any mail since they started grabbing the .well-knowns. But not for
those to whic
On 4/14/19 11:47 AM, Grant Taylor wrote:
On 4/14/19 10:49 AM, Alice Wonder wrote:
Yes, and they are sending them to me even when there are no errors.
They are sending them to my little used mail server when they have
made no attempts to deliver to that domain.
I'm surprised they are sending t
> "VD" == Viktor Dukhovni writes:
VD> For me, it is JSON by large margin. Largely because I can use "jq", and
VD> don't have to go near "xslt".
I specified an https uri rather than an smtp one.
jq and json_pp work very well.
And it is easier to do whatever one wants with the reports.
The
> On Apr 14, 2019, at 2:59 PM, Grant Taylor
> wrote:
>
> I think I actually prefer the XML reports as they have not had all their
> white space removed. As such, I think they are easier to parse.
For me, it is JSON by large margin. Largely because I can use "jq", and
don't have to go near "x
On 4/14/19 12:47 PM, Grant Taylor wrote:
I don't know what I think of JSON vs XML vs something else.
Never mind.
I think I actually prefer the XML reports as they have not had all their
white space removed. As such, I think they are easier to parse.
--
Grant. . . .
unix || die
smime.p
On 4/14/19 10:49 AM, Alice Wonder wrote:
Yes, and they are sending them to me even when there are no errors.
They are sending them to my little used mail server when they have made
no attempts to deliver to that domain.
I'm surprised they are sending them to you when you say they are not
deli
On 4/12/19 8:01 AM, James Cloos wrote:
I see that google has started sending tls reports to the rua listed in
_smtp._tls.ZONE. TXT RRs.
Has anyone else?
-JimC
Yes, and they are sending them to me even when there are no errors.
They are sending them to my little used mail server when they hav
> "BA" == Brotman, Alexander writes:
BA> Yes, we've gotten a couple now. There was an announcement on their blog:
Thanks, and apologies for my ambiguity.
I meant has any one else started sending tlsrpts?
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
_
On 4/12/19 9:01 AM, James Cloos wrote:
I see that google has started sending tls reports to the rua listed in
_smtp._tls.ZONE. TXT RRs.
Has anyone else?
I received my first one this morning.
--
Grant. . . .
unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
__
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
+1 for a JSON array.
On Mon, Jul 16, 2018 at 11:43 PM Brotman, Alexander <
alexander_brot...@comcast.com> wrote:
> 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 hostname
> On Feb 19, 2018, at 6:30 PM, Brotman, Alexander
> wrote:
>
> 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
On 2017-12-20 04:14, Viktor Dukhovni wrote:
>
>
>> On Dec 18, 2017, at 5:58 PM, Leif Johansson wrote:
>>
>> Great. I suggest we spend the time reading and reviewing specific text
>> instead of spending additional time re-iterating "bugreports".
>>
>> Putting some words together is arguably less
> On Dec 18, 2017, at 5:58 PM, Leif Johansson wrote:
>
> Great. I suggest we spend the time reading and reviewing specific text
> instead of spending additional time re-iterating "bugreports".
>
> Putting some words together is arguably less work than you're spending
> arguing that they are ne
On 2017-12-18 21:52, Viktor Dukhovni wrote:
>
>
>> On Dec 18, 2017, at 11:42 AM, Leif Johansson wrote:
>>
>> Certainly we can do changes to the document but the IETF consensus
>> process depends on multiple people making their voices heard - this
>> is the rough part of "rough consensus and ru
> On Dec 18, 2017, at 11:42 AM, Leif Johansson wrote:
>
> Certainly we can do changes to the document but the IETF consensus
> process depends on multiple people making their voices heard - this
> is the rough part of "rough consensus and running code". Sometimes
> under-specified is actually g
On 2017-12-18 16:50, Viktor Dukhovni wrote:
>
>
>> On Dec 18, 2017, at 8:23 AM, Leif Johansson wrote:
>>
>> Victor - this draft has passed WGLC and since you're the only one who
>> has (so far) raised a requirement for a formal syntax here, so unless
>> you or somebody provides concrete sugges
> On Dec 18, 2017, at 10:50 AM, Viktor Dukhovni wrote:
>
> This is an esoteric topic, I don't expect that very many others
> did a close reading of the document. I am sorry I got to it
> somewhat late, but it is not a published RFC yet, and I hope
> that bug-fixes are still possible.
If one o
> On Dec 18, 2017, at 8:23 AM, Leif Johansson wrote:
>
> Victor - this draft has passed WGLC and since you're the only one who
> has (so far) raised a requirement for a formal syntax here, so unless
> you or somebody provides concrete suggestions *and* there is clear WG
> support for the change
>>
>> Can you please provide an alternate format?
>
> I don't have cycles to draft a more formal grammar, but it should be
> done. The TLSA part should be a JSON encoding of the RData of the
> MX host's TLSA RRSet in the form:
Victor - this draft has passed WGLC and since you're the only one
On Fri, Dec 15, 2017 at 04:46:10PM +0300, Valery Smyslov wrote:
> > >> It should be noted that
> > >> if the reporter's systems are having problems resolving
> > >> destination DNS records due to DNSSEC failures, it's possible they
> > >> will also be unable to resolve the TLSR
Hi,
a few comments are below.
> >> "dnssec-invalid": This would indicate that no valid records were
> >> returned from the recursive resolver. The request returned with
> >> SERVFAIL for the requested TLSA record. It should be noted that
> >> if the reporter's systems are ha
> On Dec 7, 2017, at 8:17 AM, Brotman, Alexander
> wrote:
>
>
>> Section 4.3.2.1:
>>
>> "dnssec-invalid": This would indicate that no valid records were
>> returned from the recursive resolver. The request returned with
>> SERVFAIL for the requested TLSA record. It should be
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
25 matches
Mail list logo
