On April 26, 2023 2:50:16 AM UTC, Hector Santos
wrote:
>On 4/25/2023 10:06 PM, Scott Kitterman wrote:
>> On April 26, 2023 1:47:14 AM UTC, Hector Santos wrote:
>>> On 4/25/2023 9:06 PM, John Levine wrote:
PS: If anyone was going to suggest we just tell people how to change
their
On April 26, 2023 2:23:52 AM UTC, Jesse Thompson wrote:
>On Tue, Apr 25, 2023, at 8:06 PM, John Levine wrote:
>> It appears that Scott Kitterman said:
>> >My recollection is that a general formulation that I proposed had at least
>> >some traction out of both groups:
>> >
>> >> [some
On 4/25/2023 10:06 PM, Scott Kitterman wrote:
On April 26, 2023 1:47:14 AM UTC, Hector Santos wrote:
On 4/25/2023 9:06 PM, John Levine wrote:
PS: If anyone was going to suggest we just tell people how to change
their mailing lists to work around DMARC, don't go there.
I don't follow.
A "no
On Tue, Apr 25, 2023, at 8:06 PM, John Levine wrote:
> It appears that Scott Kitterman said:
> >My recollection is that a general formulation that I proposed had at least
> >some traction out of both groups:
> >
> >> [some appropriate description] domains MUST NOT publish restrictive DMARC
> >>
On April 26, 2023 1:47:14 AM UTC, Hector Santos
wrote:
>On 4/25/2023 9:06 PM, John Levine wrote:
>> It appears that Scott Kitterman said:
>>> My recollection is that a general formulation that I proposed had at least
>>> some traction out of both groups:
>>>
[some appropriate
On 4/25/2023 9:06 PM, John Levine wrote:
It appears that Scott Kitterman said:
My recollection is that a general formulation that I proposed had at least
some traction out of both groups:
[some appropriate description] domains MUST NOT publish restrictive DMARC
policies due to
These should be the updates from the last two days or so. (except John's
s/malicious//, already altered for next run)
I found a few more places where the mmark/xml2rfc process was creating some
improper output, I believe all for the "_report._dmarc" bits.
--
Alex Brotman
Sr. Engineer,
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Domain-based Message
Authentication, Reporting & Conformance (DMARC) WG of the IETF.
Title : DMARC Aggregate Reporting
Author : Alex Brotman
It appears that Scott Kitterman said:
>My recollection is that a general formulation that I proposed had at least
>some traction out of both groups:
>
>> [some appropriate description] domains MUST NOT publish restrictive DMARC
>> policies due to interoperability issues
This seems like a
6.1. Data Exposure Considerations
Aggregate reports are limited in scope to DMARC policy and
disposition results, to information pertaining to the underlying
authentication mechanisms, and to the domain-level identifiers
involved in DMARC validation.
Aggregate reports may expose
Brotman, Alex wrote on 2023-04-25 19:32:
I'm not disagreeing with the idea below, just that by omitting this in the
draft, we could leave it open to interpretation that it *always* will be a
privacy violation. This could justify decisions by some receivers to decline
to send reports.
On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote:
> I raised this issue in the DMARC session in Vienna, and have let it
> sit for a while so as not to derail other discussion. As we're pretty
> close to finished with the DMARCbis document, I'd like to raise it
> again, this time with
There is no universal definition of private data, so I don't think we should
make universal claims about there being no private data involved. It's true
that some concerns might be assuaged by such an assurance, but I don't think
that's a good reason to do it as I don't think the statement is
On April 25, 2023 5:31:41 PM UTC, Benny Pedersen wrote:
>John R. Levine skrev den 2023-04-25 18:28:
Since the only mechanism is mail and nobody's going to S/MIME encrypt
their reports, I suggest just deleting it.
>>>
>>> TLS vs not TLS.
>>
>> I suppose, but that's not up to the
I'm not disagreeing with the idea below, just that by omitting this in the
draft, we could leave it open to interpretation that it *always* will be a
privacy violation. This could justify decisions by some receivers to decline
to send reports.
Otherwise, I'll remove 6.3.
--
Alex Brotman
Sr.
John R. Levine skrev den 2023-04-25 18:28:
Since the only mechanism is mail and nobody's going to S/MIME encrypt
their reports, I suggest just deleting it.
TLS vs not TLS.
I suppose, but that's not up to the report sender. If I say
"rua=mailto:rep...@cruddy.org;, and the MX for cruddy.org
Assuming for a moment that single user domains can't have a privacy violation
(I'm not sure I agree), how about a two person domain? Three? Unless it's
impossible to have a report that contains personal information, mail receivers
(report senders) absolutely can't rely on the assertion in
John is not alone, I too can recognize single posts. However, I'd argue that
in such cases there is no privacy violation. You violate privacy when you
collect personal data of (several) people *different from yourself*.
Best
Ale
On Tue 25/Apr/2023 18:36:34 +0200 Scott Kitterman wrote:
My
My suggestion is delete all of it. It's accurate for some cases, not for
others. If you want to keep any of it, I think it needs to be properly
caveated. I expect that would be a Sisyphean task that's not worth the effort.
Scott K
On April 25, 2023 2:54:46 PM UTC, "Brotman, Alex"
wrote:
Since the only mechanism is mail and nobody's going to S/MIME encrypt
their reports, I suggest just deleting it.
TLS vs not TLS.
I suppose, but that's not up to the report sender. If I say
"rua=mailto:rep...@cruddy.org;, and the MX for cruddy.org doesn't do
STARTTLS, what are you going to
On Mon, Apr 24, 2023 at 10:18 PM John R. Levine wrote:
> > I removed the small section that faced objections.
> >
> > I updated the ridtxt definition and discovered that mmark was making a
> mess of those asterisks. When there are more than one/some on a single
> line, it believes you would
> As explained in 6.1, that's not actually true if the domains are small enuogh.
> In some of my tiny domains I can often recognize individual messages I've
> sent. I'd just delete these sentences.
I'd argue that you're in a (mostly) unique situation where you're the sender
and the report
22 matches
Mail list logo
