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 mail
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 appropr
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 ch
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 descripti
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 interoperabili
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, Anti-Abus
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
Filen
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 reason
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 sende
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.
Otherwi
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 sp
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 a
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 repo
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. E
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 d
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 ques
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 s
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 like
> 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 review
22 matches
Mail list logo