Doing it now might overload the WG. If DKIM for binary has its own merit, we
can just hypothesize we'll do. Meanwhile we can mention it and suggest to
use it for https: when it comes, if ever. After all, that's what RFC 2045
does with "binary".
Since client certificates exist and http DKIM
On 1/26/21 9:16 AM, John R Levine wrote:
Even if you can deduce a From: email address after the Subject Alt
Name, you cannot reliably associate it to an organizational domain.
Sorry, that makes no sense at all. The cert has a domain name, or a
bunch of domain names. You can do exactly as
On Tue 26/Jan/2021 18:23:35 +0100 Murray S. Kucherawy wrote:
On Tue, Jan 26, 2021 at 9:16 AM John R Levine wrote:
Sheesh. That isn't mission creep, it's mission gallop.
The spec can be commissioned to a narrowly focused WG (like dcrup).
Really, no. It's something we might think about on i
On Tue, Jan 26, 2021 at 9:16 AM John R Levine wrote:
> >> Sheesh. That isn't mission creep, it's mission gallop.
> > The spec can be commissioned to a narrowly focused WG (like dcrup).
>
> Really, no. It's something we might think about on its own merits some
> other time, but its absurd to try
On Tue, 26 Jan 2021, Alessandro Vesely wrote:
Won't we put a DKIM-Signature: in the http: header?
Sheesh. That isn't mission creep, it's mission gallop.
The spec can be commissioned to a narrowly focused WG (like dcrup).
Really, no. It's something we might think about on its own merits so
On Mon 25/Jan/2021 22:22:25 +0100 John Levine wrote:
In article <14fba490-7b6b-39bc-9a88-7a28aad5c...@tana.it> you write:
On Mon 25/Jan/2021 21:07:01 +0100 Michael Thomas wrote:
On 1/25/21 11:53 AM, Alessandro Vesely wrote:
On Sun 24/Jan/2021 19:49:34 +0100 Michael Thomas wrote:
issue #99 ne
In article <14fba490-7b6b-39bc-9a88-7a28aad5c...@tana.it> you write:
>On Mon 25/Jan/2021 21:07:01 +0100 Michael Thomas wrote:
>>
>> On 1/25/21 11:53 AM, Alessandro Vesely wrote:
>>> On Sun 24/Jan/2021 19:49:34 +0100 Michael Thomas wrote:
issue #99 needs to be addressed.
>>>
>>> Won't we put a
In article you write:
>On Sun 24/Jan/2021 19:49:34 +0100 Michael Thomas wrote:
>> issue #99 needs to be addressed.
>
>Won't we put a DKIM-Signature: in the http: header?
No, there's no spec for signing an http transaction.
If you want a client domain identity, It's easy enough to permit a
client
On Mon 25/Jan/2021 21:07:01 +0100 Michael Thomas wrote:
On 1/25/21 11:53 AM, Alessandro Vesely wrote:
On Sun 24/Jan/2021 19:49:34 +0100 Michael Thomas wrote:
issue #99 needs to be addressed.
Won't we put a DKIM-Signature: in the http: header?
I don't know. That would need to be specified. T
On 1/25/21 11:53 AM, Alessandro Vesely wrote:
On Sun 24/Jan/2021 19:49:34 +0100 Michael Thomas wrote:
issue #99 needs to be addressed.
Won't we put a DKIM-Signature: in the http: header?
I don't know. That would need to be specified. To me it sounds like a
good reason to not try to specif
On Sun 24/Jan/2021 19:49:34 +0100 Michael Thomas wrote:
issue #99 needs to be addressed.
Won't we put a DKIM-Signature: in the http: header?
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmar
On Sun 24/Jan/2021 19:46:58 +0100 John Levine wrote:
Here's a concrete proposal for https reporting:
In draft-ietf-dmarc-aggregate-reporting, in the transport section,
between Email and Other Methods add:
Https POST
The message is an XML file with GZIP compression, sent with an https POST
mes
On 1/24/21 1:36 PM, John Levine wrote:
In article you write:
any reporting needs to be authenticated. if you're going to use http,
you need to show how you're going to do that.
DMARC systems have been producing and consuming reports for a decade
without authentication, without any problems I
In article you write:
>any reporting needs to be authenticated. if you're going to use http,
>you need to show how you're going to do that.
DMARC systems have been producing and consuming reports for a decade
without authentication, without any problems I am aware of other than
the occasional fa
any reporting needs to be authenticated. if you're going to use http,
you need to show how you're going to do that.
Mike
On 1/24/21 11:08 AM, John Levine wrote:
In article you write:
issue #99 needs to be addressed.
I don't see any connection between issue 99 and this proposal. This is not
In article you write:
>issue #99 needs to be addressed.
I don't see any connection between issue 99 and this proposal. This is not
about failure reports.
R's,
John
>On 1/24/21 10:46 AM, John Levine wrote:
>> Here's a concrete proposal for https reporting:
>>
>> In draft-ietf-dmarc-aggregate-r
issue #99 needs to be addressed.
On 1/24/21 10:46 AM, John Levine wrote:
Here's a concrete proposal for https reporting:
In draft-ietf-dmarc-aggregate-reporting, in the transport section,
between Email and Other Methods add:
Https POST
The message is an XML file with GZIP compression, sent wi
Here's a concrete proposal for https reporting:
In draft-ietf-dmarc-aggregate-reporting, in the transport section,
between Email and Other Methods add:
Https POST
The message is an XML file with GZIP compression, sent with an https POST
message
to the given URI as media type application/gzip.
T
On Thu, 21 Jan 2021, Alessandro Vesely wrote:
Whaddaya mean fluffy? Try a PUT or POST to that URI and it'll work.
Surely you don't expect a DMARC report generator to parse https: and scream
out "Oh Gosh, here's what I've been hopelessly waiting for...". For
non-human parsers, it's fluff, no
On Thu 21/Jan/2021 01:05:53 +0100 Michael Thomas wrote:
On 1/20/21 3:10 PM, Steven M Jones wrote:
I think we should specify HTTPS URIs, and following 7489 section 12.6
"Secure Protocols" and current practices, HTTP should not be
specified/permitted.
However I don't yet see a compelling case fo
On Wed 20/Jan/2021 20:19:23 +0100 John R Levine wrote:
On Wed, 20 Jan 2021, Alessandro Vesely wrote:
John's record looks more workable, but it's still fluffy:
"v=DMARC1; p=none; rf=afrf;
rua=mailto:dmar...@abuse.net,https://dmreport.abuse.net/dmreport/;
ruf=mailto:dmar...@abuse.net";
Whadda
In article <3c89c5f8-853e-8a8a-d026-3a834d26e...@crash.com> you write:
>On 1/20/21 15:10, Steven M Jones wrote:
>>
>> Duplicate reports to the same destination are not
>> the base case
>
>I may be an idiot, or at least too quick to hit Send. Since nobody
>implements https:// yet, what does the tran
On 1/20/21 3:10 PM, Steven M Jones wrote:
I think we should specify HTTPS URIs, and following 7489 section 12.6
"Secure Protocols" and current practices, HTTP should not be
specified/permitted.
However I don't yet see a compelling case for the OR- syntax or a
separate "ruap" tag. Duplicate re
On 1/20/21 15:10, Steven M Jones wrote:
>
> Duplicate reports to the same destination are not
> the base case
I may be an idiot, or at least too quick to hit Send. Since nobody
implements https:// yet, what does the transition look like? Likely two
URIs to the same report processor, using each me
On 1/19/21 06:02, Todd Herr wrote:
> Picking up the thread on a ticket that was brought before the group
> pre-holidays and has lain fallow since the end of 2020...
Prompted me to read from the start of the thread through:
On 1/20/21 11:19, John R Levine wrote:
> On Wed, 20 Jan 2021, Alessandro V
On 1/20/21 1:37 PM, John Levine wrote:
In article <78ab729e-7ec5-b154-8e29-b02197933...@mtcc.com> you write:
A little off topic, but is there any normative text in DMARC about the
authenticity of the reporting?
See section 7.2.
Sorry, I'm not seeing it.
It seems like there ought to be
In article <78ab729e-7ec5-b154-8e29-b02197933...@mtcc.com> you write:
>A little off topic, but is there any normative text in DMARC about the
>authenticity of the reporting?
See section 7.2.
It seems like there ought to be normative
>text that the report should have a valid DKIM signature from
A little off topic, but is there any normative text in DMARC about the
authenticity of the reporting? It seems like there ought to be normative
text that the report should have a valid DKIM signature from the domain
reporting. I'm not sure how you'd go about doing that with HTTPS though
since c
On Wed, 20 Jan 2021, Alessandro Vesely wrote:
John's record looks more workable, but it's still fluffy:
"v=DMARC1; p=none; rf=afrf;
rua=mailto:dmar...@abuse.net,https://dmreport.abuse.net/dmreport/;
ruf=mailto:dmar...@abuse.net";
Whaddaya mean fluffy? Try a PUT or POST to that URI and it'll
On Wed 20/Jan/2021 03:31:51 +0100 John Levine wrote:
In article
you write:
Can you provide more details, please?
Are you receiving reports by HTTPS, or have you not seen any reduction in
reports, or both, or other?
No, I didn't put a real server's URL. Just this:
"v=DMARC1; p=none; rua=ma
On 1/19/2021 2:22 PM, Todd Herr wrote:
I'm sorry, but I'm not clear on what position you're advocating here.
You assert that "any problem would be a known tag with new
functionality than originally expected" (which would seem to argue for
using a new tag such as ruap) but then you state that you
In article
you write:
>Can you provide more details, please?
>
>Are you receiving reports by HTTPS, or have you not seen any reduction in
>reports, or both, or other?
I didn't try Ale's OR- thing but I did add an https URL to my rua= tag and set
up
a web server to catch any POST or PUT traffic.
In article
you write:
>My mention of "other concerns ... about privacy and security" is in
>reference to a post in this thread that Mike Hammer made in early December,
>where he wrote:
>
>"I don't recall a strong security and privacy concerns discussion around
>HTTP(S) reporting. Presumably the r
On Tue, Jan 19, 2021 at 2:18 PM Alessandro Vesely wrote:
> On Tue 19/Jan/2021 15:02:39 +0100 Todd Herr wrote:
> > Concerns were voiced about interoperability impacts for Ale's
> suggestions,
> > and Ale committed to running an experiment to see if there were changes
> to
> > his inbound report fl
It seems that I was not successful in conveying my meaning in a few
statements, so allow me to try again...
On Tue, Jan 19, 2021 at 10:28 AM Hector Santos wrote:
> On 1/19/2021 9:02 AM, Todd Herr wrote:>
> > Other concerns were raised about privacy and security issues that
> > might be inherent
On Tue 19/Jan/2021 15:02:39 +0100 Todd Herr wrote:
Concerns were voiced about interoperability impacts for Ale's suggestions,
and Ale committed to running an experiment to see if there were changes to
his inbound report flows when he implemented one variant for expressing the
URI in the rua tag (
On 1/19/2021 9:02 AM, Todd Herr wrote:>
Other concerns were raised about privacy and security issues that
might be inherent in and unique to adding this kind of functionality,
issues that may not have been fully discussed or understood by the
community over the years. There was also a question ab
Picking up the thread on a ticket that was brought before the group
pre-holidays and has lain fallow since the end of 2020...
In reviewing the discussion, I don't believe a consensus has emerged on how
to implement this feature, or even whether to do it.
John proposed a new tag, ruap, for specify
On Thu 31/Dec/2020 16:37:38 +0100 John R Levine wrote:
On Thu, 31 Dec 2020, Alessandro Vesely wrote:
On Wed 30/Dec/2020 22:23:20 +0100 John R Levine wrote:
[ add ruap= to allow https in preference to mailto ]
I still like better sticking to a unique tag (rua=) and applying OR-slashes.
With
On Thu, 31 Dec 2020, Alessandro Vesely wrote:
On Wed 30/Dec/2020 22:23:20 +0100 John R Levine wrote:
[ add ruap= to allow https in preference to mailto ]
I still like better sticking to a unique tag (rua=) and applying OR-slashes.
With a comma, it is backward compatible:
v=DMARC1; p=none;
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
repo
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,
On Wed 09/Dec/2020 00:56:22 +0100 John Levine wrote:
In article you write:
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 reportin
In article you write:
>>> 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.
>>
>> I thought it's about interoperability. Simply having a webserver running
>> doesn't come close to interoperabili
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.
I thought it's about interoperability. Simply having a webserver running
doesn't come close to interoperability, and certainly not at scale.
I guess
On Mon, Dec 7, 2020 at 4:41 PM John Levine wrote:
> >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
>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
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.
Was this requested by someone?
I don't recall a strong security and privacy concerns discussion around
HTTP(S) reporting. Presum
On Mon, Dec 7, 2020 at 2:18 AM Murray S. Kucherawy
wrote:
> On Tue, Dec 1, 2020 at 2:22 PM John R Levine wrote:
>
>> 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 DMA
On Tue, Dec 1, 2020 at 2:22 PM John R Levine wrote:
> 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 propo
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.
Legacy producers u
On Sat 05/Dec/2020 22:06:38 +0100 John Levine wrote:
> In article you write:
>
>> 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
In article you write:
>>> 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. ...
>The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom
>us
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
On Fri 04/Dec/2020 19:21:33 +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 t
> -Original Message-
> From: dmarc On Behalf Of John R Levine
> Sent: Friday 4 December 2020 18:22
> To: Alessandro Vesely ; John R Levine ;
> dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI
> functionality
>
> >> I mean
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 ent
On Thu 03/Dec/2020 20:54:03 +0100 John R Levine wrote:
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.
I meant "at the same time" as in during the same reporting run. As Dave
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.
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 thr
On 12/3/2020 11:30 AM, Alessandro Vesely wrote:
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.
Rather than meaning the same report will be sent by both mechanisms,
perhaps he
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu 03/Dec/2020 18:08:50 +0100 John R Levine wrote:
>>> 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.
>>
>> However faster, an https PUT/
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.
However faster, an https PUT/POST at midnight arrives later than a mailto at
midday.
I'm sorry but this makes no sense at all. Why do you believ
On Thu 03/Dec/2020 00:34:32 +0100 John Levine wrote:
In article you write:
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 tha
In article you write:
>On Tue 01/Dec/2020 23:21:48 +0100 John R Levine wrote:
>> 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.
>
>TL;DR: neutra
On Tue 01/Dec/2020 23:21:48 +0100 John R Levine wrote:
We would like to close this ticket by Dec 15, two weeks from now, so short
trenchant comments are welcome.
[...]
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
th
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,
66 matches
Mail list logo