Subject: [ietf-smtp] MTA-STS reports via HTTPS

From: "John R. Levine" <[email-masked]>
Date: 9 Apr 2020 14:00:22 -0400

While avoiding actual work I twiddled my STS reporting setup to get 
reports for some of my domains by https rather than mailto.  So far I have 
one (1) report from Socketlabs and nothing from anyone else.

Does anyone else send reports by https?  If anything it's easier than 
sending them by mail since there's no DKIM or other verification needed, 
just do a POST and you're done.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Brian Godiksen <[email-masked]>
Date: Thu, 9 Apr 2020 22:06:12 +0000

Adoption rates of those looking to receive TLS reports via https are as low as those sending them.  Https reports account for about 0.2% of the total reports that we send. I would love to see more adoption here, as I agree in your thought that they are preferable.  

Our biggest gripe with the current spec is specific to DKIM and the suggestion of using a service type declaration of “s=tlsrpt” in the DKIM public key.  Support for this service type at receiving systems appears to be rather abysmal based on our logs and DMARC reports.  While we originally included this service type in our key, we’ve since removed it to reduce DMARC failures.

Thanks,
Brian Godiksen
SocketLabs

> On Apr 9, 2020, at 2:00 PM, John R. Levine <[email-masked]> wrote:
> 
> While avoiding actual work I twiddled my STS reporting setup to get reports for some of my domains by https rather than mailto.  So far I have one (1) report from Socketlabs and nothing from anyone else.
> 
> Does anyone else send reports by https?  If anything it's easier than sending them by mail since there's no DKIM or other verification needed, just do a POST and you're done.
> 
> Regards,
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: "John Levine" <[email-masked]>
Date: 9 Apr 2020 19:02:59 -0400

In article <[email-masked]> you write:
>Our biggest gripe with the current spec is specific to DKIM and the suggestion of using a service type
>declaration of “s=tlsrpt” in the DKIM public key.  Support for this service type at receiving
>systems appears to be rather abysmal ...

Per my previous messages, it's pretty clear that was a mistake in 8460
due to misunderstanding what service types are for.  It's also pretty
strange that it has a hugely overspecfied set of rules for validating
mailed reports and nothing at all for https ones.

R's,
John

---

From: James Cloos <[email-masked]>
Date: Mon, 13 Apr 2020 07:13:50 -0400

>>>>> "JRL" == John R Levine <[email-masked]> writes:

JRL> Does anyone else send reports by https?

I get them regularly from goog.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: "John R. Levine" <[email-masked]>
Date: 13 Apr 2020 09:23:50 -0400

> I get them regularly from goog.

Odd, they're still mailing them to me.

Regards,

---

From: James Cloos <[email-masked]>
Date: Mon, 13 Apr 2020 11:58:47 -0400

>>>>> "JL" == John R Levine <[email-masked]> writes:
>>>>>>> "JL" == John R Levine <[email-masked]> writes:

JL> Does anyone else send reports by https?

JC> I get them regularly from goog.

JL> Odd, they're still mailing them to me.

i ay have mixed up why they are sening those reports...

(a nodei used for internal mail went dark when i was back in the stroke
center -- the vendor shut down -- and i only just got internal mail
woking again.  including delivery of 4 months of backlog.

the mail from the webmachine mentioned sts, but looking at my dns i see
that they are actually due to TLSRPTv1 TXT RRs for _smtp._tls.$DOMAIN.

i hadn't thought about this stuff in too long...

-JimC

---

From: "John R. Levine" <[email-masked]>
Date: 13 Apr 2020 12:27:15 -0400

> that they are actually due to TLSRPTv1 TXT RRs for _smtp._tls.$DOMAIN.

Yup, that's what I was referring to.

My _smtp._tls TXT records have had both mailto: and https: in them, so I 
just took out the mailto:.  Will report back.

Regards,

---

From: James Cloos <[email-masked]>
Date: Fri, 17 Apr 2020 08:37:20 -0400

>>>>> "JL" == John R Levine <[email-masked]> writes:

JL> My _smtp._tls TXT records have had both mailto: and https: in them, so
JL> I just took out the mailto:.  Will report back.

i've (finally) recalled that i set up my _smtp._tls RRs w/ only https to
avoid having to do any work on the MXs to ensure no bouncing or dropping.

i got a couple today from socketlabs.com (whoever they are).  the 2nd
entity to send them so far.

-JimC

---

From: "John R. Levine" <[email-masked]>
Date: 17 Apr 2020 08:45:02 -0400

> JL> I just took out the mailto:.  Will report back.

All of my mail reports stopped, the trickle from Socketlabs continued.

So I added the mailto: back.  Strange.

Regards,

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 18 Apr 2020 15:24:43 -0400

The reporting address might be cached as part of the policy, perhaps if
you toggle the "id" field of your _mta-sts.$DOMAIN TXT record, the relevant
senders will refresh your policy and along with it your TLSRPT record.

[ I would have expected TLSRPT to not be cached, and looked up live, but
  implementors get up to all sorts of unexpected designs. ]

> On Apr 17, 2020, at 8:45 AM, John R. Levine <[email-masked]> wrote:
> 

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 18 Apr 2020 17:05:22 -0400

>senders will refresh your policy and along with it your TLSRPT record.

It clearly wasn't cached, since the reports all stopped other than the few
from socketlabs that send them via HTTPS.

Now I set it back to both, the mail from Google has resumed but the reports from Comcast
I use to get have not.  I do get mail from Comcast, kind of odd that they're not sending reports.

R's,
John