Subject: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

From: "John R Levine" <[email-masked]>
Date: 1 Dec 2020 17:21:48 -0500

We would like to close this ticket by Dec 15, two weeks from now, so short 
trenchant comments are welcome.

Ticket #1 is about https reporting.  Early drafts of the DMARC spec had a 
poorly defined http report which we took out.  I propose we add back https 
reporting similar to that for mta-sts, with a POST of the gzipped report 
to the HTTPS URI.

R's,
John

================================================================

Right now, reporting only functions via mailto: but other
functionality had been previously discussed. Does the group wish to
extend reporting mechanisms?

See: ​https://mailarchive.ietf.org/arch/msg/dmarc/iKpLKGdneTs85ioOiG_RwR5Vssc/

Changed by johnl@…

We can adapt the approach MTA-STS uses in RFC 8460.

If rua= has an https URI, the reporter uses HTTP POST to that URI with
the report as an uncompressed or gzipped XML file as the POST body.
The media type is the same as is used in mail reports, application/xml
or application/gzip. Reports SHOULD be gzipped. If we keep the !size
hack, they MUST be no larger than the size limit.

I suppose failure reports could be posted the same way with the same
message type as if mailed, but they're not usually very big and I
don't think there are many generated.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 2 Dec 2020 11:20:57 +0100

On Tue 01/Dec/2020 23:21:48 +0100 John R Levine wrote:
> [...]

TL;DR: neutral

Delivery via https, with possible retry queue, imposes an additional burden to 
report producers.  Since there seem to be less producers than consumers, it may 
be fair to grant the choice of transport to the former.  That is, to make the 
mailto scheme mandatory and https optional.

Even if the the spec allows consumers to specify the transport they like 
better, there will probably be producers which only honor one type.  So, 
consumers may want to specify both schemes anyway.

A better means to control report size is to gauge the reporting interval.

The addition of the new transport doesn't seem to simplify things.  I fail to 
see the advantage, but I can cope with it if it comes.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 2 Dec 2020 18:34:32 -0500

>consumers may want to specify both schemes anyway.

That seems reasonable to make mailto: mandatory and https: optional if
you have an rua tag. I wouldn't expect reporters to provide queueing
if https fails, and mailto is certainly not going away. But if both
are available, http is a lot faster.

>A better means to control report size is to gauge the reporting interval.

When this came up before someone said that reports can be extremely
large, many megabytes.  An HTTP POST or PUT is a much better way to send that.

Here's another nit: POST doesn't pass the report's filename. There
should be a copy of the name in the header of the gzip data, but
semantically it would be better to do an https PUT to
<url>/<filename>. That also has the advantage of being idempotent so
if it puts the same file twice the server can tell it's a duplicate.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 3 Dec 2020 13:39:25 +0100

> large, many megabytes.  An HTTP POST or PUT is a much better way to send that.

However faster, an https PUT/POST at midnight arrives later than a mailto at 
midday.

> if it puts the same file twice the server can tell it's a duplicate.

Yes, PUT is better than POST.

How about pgp-signing the file with the dkim key?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 3 Dec 2020 12:08:50 -0500

> However faster, an https PUT/POST at midnight arrives later than a mailto at 

I'm sorry but this makes no sense at all.  Why do you believe that people 
would not send reports by mail and by https at the same time?

> How about pgp-signing the file with the dkim key?

Sorry, that doesn't make any sense either.  DKIM keys and PGP keys are 
different.  It is hypothetically possible to sign an http transaction with 
DKIM but that would be a giant distraction from what we're doing here.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 3 Dec 2020 20:30:20 +0100

On Thu 03/Dec/2020 18:08:50 +0100 John R Levine wrote:
> I'm sorry but this makes no sense at all.

I said so because you said https is faster.  The spec is unclear about intervals, but this is matter for another ticket.

> Why do you believe that people would not send reports by mail and by https
> at the same time?

Oh my.  Hadn't thought about that.  It will certainly cause duplicates.

> different.

Hm... let me try and sign this message.

$ cat delta.private | PEM2OPENPGP_USAGE_FLAGS=sign pem2openpgp "Delta selector <[email-masked]>" | gpg --import

Now I have:
sec   rsa1148 2020-12-03 [SC]
      500982D49712C507C236B2D6B8ABBBF9A091CC0D
uid           [ unknown] Delta selector <[email-masked]>

$ gpg -u 500982D49712C507C236B2D6B8ABBBF9A091CC0D --clearsign < this text

Can you verify it?  I cannot find how to transform the delta selector public key into a pgp public key block.

That is to transform this:

$ eval $(digs delta._domainkey.tana.it txt |sed -rn -e 's/^"//' -e 's/" *"//g' -e 's/"$//p') && printf -- '-----BEGIN PUBLIC KEY-----\n%s\n-----END PUBLIC KEY-----\n' "$(echo $p |base64 -d |base64)"
- -----BEGIN PUBLIC KEY-----
MIGuMA0GCSqGSIb3DQEBAQUAA4GcADCBmAKBkA5YMrfcQD3kzCQJFRXLatbXbl6h07EE1TrJOVp9
4EeBV50QFuBIk0igZgPTA39O77mUyNii81hD4q2g9/Hoj9asqQHTTKjqk+gwZWC+X46K5BYSRPTC
C9sidg20Laubyn0ATGaz+OyIl4JcE2rsEXwXLJ98OFEaa3gWyUVO9+lNwebs932bOtHbM2YpzJzE
PQIDAQAB
- -----END PUBLIC KEY-----

To this:

$ gpg  --export --armor 500982D49712C507C236B2D6B8ABBBF9A091CC0D\!
- -----BEGIN PGP PUBLIC KEY BLOCK-----

=KJkG
- -----END PGP PUBLIC KEY BLOCK-----

> It is hypothetically possible to sign an http transaction with DKIM

Any example?

> but that would be a giant distraction from what we're doing here.

Should be optional, like DKIM-signing aggregate reports sent by mailto.

Best
Ale
- --

---

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Dec 2020 11:49:23 -0800

> Oh my.  Hadn't thought about that.  It will certainly cause duplicates.

Rather than meaning the same report will be sent by both mechanisms, 
perhaps he merely meant that either mechanism could be used at any 
time.  That is, there is no need for the choice of the mechanism to make 
any difference in when they get used.

That is, your:

> However faster, an https PUT/POST at midnight arrives later than a 
> mailto at midday.
established a false point of distinction.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 3 Dec 2020 14:54:03 -0500

> I said so because you said https is faster.  The spec is unclear about intervals, but this is matter for another ticket.

For any given report, stuffing it into a web server with a PUT or POST 
will be faster than base64 encoding it and relaying it through mail 
servers.  This is just arithmetic.

> Oh my.  Hadn't thought about that.  It will certainly cause duplicates.

I meant "at the same time" as in during the same reporting run.  As Dave 
noted, if you sent any particular report by https, there's no need to send 
it again by mail.

Systems receiving reports have to be prepared for duplicates anyway since 
double deliveries of mail messages happens.  That's the point of the 
filename on the report, to provide a unique name for each report so it's 
easy to tell if you've seen a report before.

> Can you verify it?  I cannot find how to transform the delta selector public key into a pgp public key block.

It says it can't find a public key which is not surprising.  I still don't 
think this is a productive direction to go.

If people really are worried about fake reports, there is a well defined 
way to put a signature in an XML document.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 4 Dec 2020 09:21:36 +0100

On Thu 03/Dec/2020 20:54:03 +0100 John R Levine wrote:
> I meant "at the same time" as in during the same reporting run.  As Dave noted, 
> if you sent any particular report by https, there's no need to send it again by 
> mail.

Got it.  However, the spec says it's a list of addresses to which aggregate 
feedback is to be sent.  When there are multiple entries, up to now, reports 
are sent to each.  If services like dmarcian switch to an https URI, a sender 
could end up with that URI along with its local mailto one.  How does a report 
producer know whether multiple URIs are mutually exclusive or inclusive?

> double deliveries of mail messages happens.  That's the point of the filename 
> on the report, to provide a unique name for each report so it's easy to tell if 
> you've seen a report before.

Right, but if that happens everyday the (small) efficiency gain is lost.

> think this is a productive direction to go.

Not for the subject at hand, maybe.  The possibility to further deploy DKIM key 
distribution by coding some dkim2openpgp utility seems interesting to me.

> If people really are worried about fake reports, there is a well defined way to 
> put a signature in an XML document.

However, XML signatures require a certificate, not just a key.  Consider that a 
DNSSEC-authenticated DKIM signature is semantically superior to CA 
certificates.  First, because registrars know what they're signing better than 
CAs.  Second, because the way to associate DKIM signatures with the issuing 
domains is better standardized than X509 subject common name or alternative name.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 4 Dec 2020 13:21:33 -0500

> are sent to each.

Hm, we might want to revisit that.  If a domain wants mail sent to three 
places, it's not like it's hard to arrange for forwarding.  My intention 
is that if you send the report by https, you're done.

Regards,

---

From: Ken O'Driscoll <[email-masked]>
Date: Fri, 4 Dec 2020 19:23:34 +0000

> -----Original Message-----
> From: dmarc <[email-masked]> On Behalf Of John R Levine
> Sent: Friday 4 December 2020 18:22
> To: Alessandro Vesely <[email-masked]>; John R Levine <[email-masked]>;
> [email-masked]
> Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI
> functionality
> 
> >> I meant "at the same time" as in during the same reporting run.  As
> >> Dave noted, if you sent any particular report by https, there's no
> >> need to send it again by mail.
> >
> > Got it.  However, the spec says it's a list of addresses to which
> > aggregate feedback is to be sent.  When there are multiple entries, up
> > to now, reports are sent to each.
> 

In many circumstances, mail forwarding may be quite difficult to arrange.

Many organisations use an external service to handle their reports. Currently, if such an organisation wishes to add another report receiver, they are in control of that process by modifying their DNS zone.

However, if they can only specify one report receiver then it is that report receiver who must handle any forwarding in the case of multiple parties.

The pre and post acceptance filtering that most mailbox providers implement can make them unreliable for delivering DMARC reports to user mailboxes. So, an organisation would likely have to set up a separate mail infrastructure should they wish to retain control of what parties receive their DMARC reports.

Of course, third party report processing services could also add support for such forwarding. But, given that such a feature could facilitate a competitor, I'm sceptical it would make business sense to many of them. On top of that, it's easier to receive than send so there is an ongoing cost in providing email forwarding.

As to the utility of having more than one report destination, I regularly receive client DMARC reports on top of their existing service as part of consultancy engagements. It is also the only way for an organisation without their own email infrastructure to simultaneously evaluate more than one report processing service. So I believe there is utility there.

Ken.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 5 Dec 2020 13:13:17 +0100

On Fri 04/Dec/2020 19:21:33 +0100 John R Levine wrote:
> places, it's not like it's hard to arrange for forwarding.  My intention is 
> that if you send the report by https, you're done.

The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom used in email addresses and ubiquitous in https URIs.  We could convene that when a mailto is to be considered as an alternative to an https, then the former should precede the latter, separated by a slash.  For example:

v=DMARC1; p=none; rua=mailto:[email-masked], mailto:[email-masked]/https://service.example/report/;

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 5 Dec 2020 12:56:05 -0500

>> My intention is that if you send the report by https, you're done.

> v=DMARC1; p=none; rua=mailto:[email-masked], mailto:[email-masked]/https://service.example/report/;

Ugh.  Given what other people have said it sounds like it would be more 
useful to keep the current rules that you try to deliver the report 
everywhere.  That preseves the ability to send it both to your local 
address and to someone like Dmarcian, even if Dmacian also supports https.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 5 Dec 2020 16:06:38 -0500

In article <[email-masked]> you write:
>>> are sent to each. ...

>The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom used in email addresses and
>ubiquitous in https URIs.  We could convene that when a mailto is to be considered as an alternative ...

If we want to do something like that, I would overload the existing
!size hack. For example, add an "f" for finished flag and say that the
URIs are conceptually processed from left to right and if you send
your report to one with a !f (or !10mf or the like) flag, you can stop.

Still not convinced this is useful but it is slightly more backward
compatible.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 6 Dec 2020 12:31:57 +0100

> your report to one with a !f (or !10mf or the like) flag, you can stop.

Legacy producers unable to interpret "f" may discard the whole URI.

> Still not convinced this is useful but it is slightly more backward

For backward compatibility, one could add a comma before the OR-slash:

v=DMARC1; p=none; rua=mailto:[email-masked], mailto:[email-masked], /https://service.example/report/;

A legacy producer will discard "/https" as an unknown scheme.  It would have discarded "https" as well.

Am upgraded producer can interpret a leading slash as introducing an alternative to the preceding destination.  Possibly, there can be a series of them, to allow for secondary servers in case the previous URI fails.  The first scheme without a leading slash introduces a new series of alternatives.

For compatibility, mailto has to be the first URI of each series.  Logically, however, it must be considered to be the last alternative.  In fact, sending mail can only fail if the local submission server is unavailable.  So it doesn't make sense to have multiple mailto's in the same series.  This, the fact that supporting mailto is mandated, and backward compatibility justify the logic exception.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 6 Dec 2020 11:41:09 -0500

> Legacy producers unable to interpret "f" may discard the whole URI.

At this point we're both just guessing what current code might do with 
syntax errors in a rua= tag.  Here's something that's definitely 
compatible:

We add a new ruap= tag for rua preferred, with the same syntax as rua.  If 
the reporting system can handle all of the URIs in the ruap tag, it uses 
them.  (They don't all have to successfully deliver, but it knows how to 
try.)  Otherwise it falls back to rua.  The goal here is that someone can 
put the new https: URI in ruap and the old mailto: URI in rua.

To send a report using the https: URI, the reporter appends the filename 
described in section 7.2.1.1 to the given URI and does a PUT of the 
report, with MIME type application/gzip if it's compressed an text/xml if 
not. The server responds with code 201 if the report is succesfully 
stored.

It'd be something like this if the URI is https://report.bar.com/dmarc/

PUT https://report.bar.com/dmarc/foo.com%21bar.com%211607068800%211607155200.xml.gz

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 6 Dec 2020 23:18:22 -0800

> reporting similar to that for mta-sts, with a POST of the gzipped report

Was this requested by someone?

-MSK

---

From: Dotzero <[email-masked]>
Date: Mon, 7 Dec 2020 06:17:19 -0500

> Was this requested by someone?

I don't recall a strong security and privacy concerns discussion around
HTTP(S) reporting. Presumably the report contents are protected in transit
but to what extent is access by arbitrary parties an issue. Notwithstanding
that things like GDPR are political issues, they are worth noting as a real
life operational consideration.

Michael Hammer

---

From: "John R Levine" <[email-masked]>
Date: 7 Dec 2020 11:49:09 -0500

>>> poorly defined http report which we took out.  I propose we add back
>>> https reporting similar to that for mta-sts, with a POST of the gzipped report
>>> to the HTTPS URI.
>>

The original motivation was performance, since uploading a big file via 
https is a lot faster than base64 encoding it and relaying it by mail.

I don't understand the security or GDPR references.  For one thing, these 
are aggregate reports which generally don't have any PII.  For another, 
https reporting would be considerably more secure than mail reporting. 
The report goes via an encrypted channel directly to the target server 
which is identified by its ssl certificate.  There's no relaying through 
intermediate servers.  If the report can't be delivered, the upload just 
fails and there's no possibility of it being diverted by spam filters or 
bouncing into some random admin mailbox.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2020 16:41:32 -0500

>I don't understand the security or GDPR references.

Well this is amusing. I wondered if anyone had ever implemented some
version of the http reporting in early DMARC drafts, so I set up a new domain
with a server that will accept POST or PUT requests and added its URI to my
DMARC records.

I didn't get any of those (the POSTs below are not to the right URI)
but it's impressive how fast Russian bots started to probe it, within
hours.

This is not a reason to avoid https reporting. Every web site gets
probed like this and so long as your web server rejects unknown URIs,
they're harmless. After all, my e-mail reporting addresses get a
certain amount of spam, too.

R's,
John

139.162.113.204 dmreport.abuse.net - [07/Dec/2020:03:15:11 -0500] "GET / HTTP/1.1" 404 719 "HTTP Banner Detection (https://security.ipip.net)"
192.241.209.169 dmreport.abuse.net - [07/Dec/2020:05:26:29 -0500] "GET / HTTP/1.1" 404 719 "Mozilla/5.0 zgrab/0.x"
192.241.237.68 dmreport.abuse.net - [07/Dec/2020:05:49:18 -0500] "GET /owa/auth/logon.aspx?url=https%3a%2f%2f1%2fecp%2f HTTP/1.1" 404 786 "Mozilla/5.0 zgrab/0.x"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:01 -0500] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 823 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:01 -0500] "POST /api/jsonws/invoke HTTP/1.1" 404 757 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:07 -0500] "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 823 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:07 -0500] "GET /index.php?s=/Index/\\think\\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21 HTTP/1.1" 404 858 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:09 -0500] "GET /?XDEBUG_SESSION_START=phpstorm HTTP/1.1" 404 753 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:11 -0500] "POST /mifs/.;/services/LogService HTTP/1.1" 404 779 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
91.241.19.84 dmreport.abuse.net - [07/Dec/2020:06:44:12 -0500] "GET /wp-content/plugins/wp-file-manager/readme.txt HTTP/1.1" 404 813 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
193.118.53.202 dmreport.abuse.net - [07/Dec/2020:11:45:14 -0500] "GET / HTTP/1.1" 404 719 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
67.205.149.169 dmreport.abuse.net - [07/Dec/2020:12:50:40 -0500] "GET / HTTP/1.0" 400 362 "-"
83.97.20.31 dmreport.abuse.net - [07/Dec/2020:14:46:30 -0500] "GET / HTTP/1.1" 404 723 "-"
185.141.63.14 dmreport.abuse.net - [07/Dec/2020:14:47:37 -0500] "GET / HTTP/1.1" 404 723 "libwww-perl/6.49"

---

From: Dotzero <[email-masked]>
Date: Tue, 8 Dec 2020 09:57:01 -0500

> with a server that will accept POST or PUT requests and added its URI to my

What is tht "mantra"? Running code and rough consensus? Has anyone
implemented such reporting?

> but it's impressive how fast Russian bots started to probe it, within

I thought it's about interoperability. Simply having a webserver running
doesn't come close to interoperability, and certainly not at scale.

> certain amount of spam, too.

My question was not intended to imply that HTTPS reporting should be
avoided. My point was that there has been basically no security discussion
or scrutiny of such an implementation. This document is now proposed
Standards Track, not Informational or Experimental. As such, proposed
changes or additions should be given. Your surprise at what happened so
quickly after your "implementation" proves my point that there has been
little if any thought of security considerations for this proposed change.
My comment about GDPR was simply meant to indicate that the world has
changed quite a bit since DMARC was made public in 2011. So too have
security considerations evolved. I have no objection in principle to HTTPS
reporting, only that such an addition be given the same consideration and
scrutiny that DMARC itself is being held to.

Michael Hammer

---

From: "John R Levine" <[email-masked]>
Date: 8 Dec 2020 10:54:28 -0500

> doesn't come close to interoperability, and certainly not at scale.

I guess I wasn't clear enough.  I know there's no http reporting in DMARC, 
but there was in an early version of the spec.  I was wondering if anyone 
had implemented that.  Apparently not.

> or scrutiny of such an implementation.

That's fine but as I said I think it is clear that the security of https 
reporting is better than of mail reporting.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 8 Dec 2020 18:56:22 -0500

>had implemented that.  Apparently not.

I must admit one thing that did surprise me was that something is looking at
DMARC DNS records and probing the https URIs they contain, since that is the
only place there are referecnes to my newly created https reporting URI.

R'sm
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 9 Dec 2020 15:39:50 +0100

> only place there are referecnes to my newly created https reporting URI.

dmreport.abuse.net was published on the DNS.  That's enough for probing.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 30 Dec 2020 16:23:20 -0500

> reporting similar to that for mta-sts, with a POST of the gzipped report to 
> the HTTPS URI.

I still think that reporting by POST is a swell idea, since it's 
considerably faster and more secure than e-mail for large reports. 
(There's no attachments or base64 coding, and the report goes direct to 
the recipient server, no mail relays or possible misrouting or bounces.)

There was some discussion about the detail that if there are multiple 
addresses in the rua= tag you send the report to all of them.  People were 
quite clear that is a feature.  I proposed as a hack a ruap= tag for rua 
preferred, if the reporting system can send reports to all of the URIs in 
the ruap tag it does so, otherwise it uses rua as it does now.  That lets 
you put the https URIs in the ruap tag which existing code will ignore.

Didn't get a lot of comments pro or con on that one.

R's,
John

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 31 Dec 2020 16:02:06 +0100

On Wed 30/Dec/2020 22:23:20 +0100 John R Levine wrote:
> There was some discussion about the detail that if there are multiple addresses 
> in the rua= tag you send the report to all of them.  People were quite clear 
> that is a feature.  I proposed as a hack a ruap= tag for rua preferred, if the 
> reporting system can send reports to all of the URIs in the ruap tag it does 
> so, otherwise it uses rua as it does now.  That lets you put the https URIs in 
> the ruap tag which existing code will ignore.
> 

I still like better sticking to a unique tag (rua=) and applying OR-slashes.  With a comma, it is backward compatible:

(The first scheme without a leading slash introduces a new series of alternatives.)

The main reason to stick to the same tag is to allow overriding.  For example, if the above record were:

$ORIGIN=_dmarc.example.com
IN TXT "v=DMARC1; p=none; rua=mailto:[email-masked], mailto:[email-masked]"

Then service.example can override rua=:

$ORIGIN=example.com._report._dmarc.service.example
IN TXT "v=DMARC1; rua=mailto:[email-masked], /https://service.example/report/;

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 31 Dec 2020 10:37:38 -0500

On Thu, 31 Dec 2020, Alessandro Vesely wrote:

>> [ add ruap= to allow https in preference to mailto ]
>

No, it's invalid according to the syntax in RFC 7489.  We have no idea 
what existing implementations do with DMARC records with syntax errors.

Here's an experiment -- put that slash syntax in the rua= in your DMARC 
record and see who does or doesn't continue sending reports.

In the meantime, anyone else have an opinion either way about adding HTTPS 
reporting?

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 31 Dec 2020 17:35:05 +0100

On Thu 31/Dec/2020 16:37:38 +0100 John R Levine wrote:
> No, it's invalid according to the syntax in RFC 7489.

I see.  We have:

     dmarc-auri      = "rua" *WSP "=" *WSP
                        dmarc-uri *(*WSP "," *WSP dmarc-uri)

     URI             = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

     scheme      = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

So /https cannot be a scheme.  How about:

     v=DMARC1; p=none; rua=mailto:[email-masked], mailto:[email-masked], OR-https://service.example/report/;

> We have no idea what existing implementations do with DMARC records with syntax errors.
> 
> Here's an experiment -- put that slash syntax in the rua= in your DMARC record 
> and see who does or doesn't continue sending reports.

Done, with the second alternative.

Best
Ale
--