Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

In article you write: >For this ticket in particular-- the simplified failure report with only >from: and to: addresses speaks to Jesse's exact use case, without any of >the other PII that tends to get failure reports in privacy trouble (like >body content and attachments). This approach to

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

On Wed, Dec 9, 2020 at 8:19 PM Murray S. Kucherawy wrote: > On Wed, Dec 9, 2020 at 1:29 PM Brandon Long 40google@dmarc.ietf.org> wrote: > >> In today's much more privacy conscious world, should we have RUF reports >> in DMARC >> at all? >> > > Forensic reports in DMARC are akin to the DKIM

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

On Wed, Dec 9, 2020 at 1:29 PM Brandon Long wrote: > In today's much more privacy conscious world, should we have RUF reports > in DMARC > at all? > Forensic reports in DMARC are akin to the DKIM failure reporting we added to ARF back in the MARF working group. In fact if you go back and read

Re: [dmarc-ietf] Domains and tree walk

In article you write: >I would hesitate to assume that seeing p=none on a domain as an indicator that >they are serious about deploying DMARC and reconciling their >own Holy Roman Empire conundrums; rather it's there just to not be seen as >lagging behind their peers, justifying funding for

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

On 12/9/20 4:04 PM, Brandon Long wrote: When you switch to p=quarantine pct=0, no one should apply quarantine (so it's equivalent to p=none), but Groups will start rewriting, thereby removing all of those failures from your reports.  Yes, you won't see those messages in the reports at all

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

On 12/9/20 11:07 AM, Alessandro Vesely wrote: > We would like to close this ticket by Dec 23, two weeks from now, so please > get on it. > > The ticket text is: > >     It has been asked for a new report type (perhaps a subset of failure >     reports) that provides minimal data from the email

Re: [dmarc-ietf] A-R results for DMARC

On Wed, Dec 9, 2020 at 2:27 PM Michael Thomas wrote: > > On 12/8/20 4:51 PM, Brandon Long wrote: > > > > On Mon, Dec 7, 2020 at 8:31 PM John R Levine wrote: > >> On Mon, 7 Dec 2020, Murray S. Kucherawy wrote: >> > The original intent back in RFC 5451 was to relay only those details >> that >> >

[dmarc-ietf] are mailing lists worth saving?

I know it's heresy on an ietf list to suggest it, but we know that amount of traffic going through mailing lists is tiny -- like a couple percent. The amount of traffic going through other forms of manglers has to be even farther down in the long tail of traffic. Mailing lists arose because

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

On 12/3/20 8:21 AM, Todd Herr wrote: > On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins > wrote: > > > >> On 3 Dec 2020, at 06:03, Jim Fenton > > wrote: >> >> On 2 Dec 2020, at 1:47, Laura Atkins wrote: >> >>> p=quarantine

Re: [dmarc-ietf] A-R results for DMARC

On 12/8/20 4:51 PM, Brandon Long wrote: On Mon, Dec 7, 2020 at 8:31 PM John R Levine > wrote: On Mon, 7 Dec 2020, Murray S. Kucherawy wrote: > The original intent back in RFC 5451 was to relay only those details that > an MUA might care about, such as

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

yOn Wed, 9 Dec 2020, Brandon Long wrote: I think that if a reporter isn't willing to provide the headers it's unlikely to provide anything. In today's much more privacy conscious world, should we have RUF reports in DMARC at all? It's a reasonable question, but a company in Redmond WA is

Re: [dmarc-ietf] Domains and tree walk

On 12/1/20 8:50 PM, John Levine wrote: > On the other hand, I observe that Brown, Cornell, Dartmouth, U Penn, > and Yale, whose situations are not altogether unlike Columbia's, all > publish DMARC records. Closer to home so do NYU and CUNY. They all say > p=none with rua= to collect reports. You

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

On Wed, Dec 9, 2020 at 10:53 AM John Levine wrote: > In article <609e1c9b-cc4d-d7d1-0fa8-79f515c1e...@tana.it> you write: > > It has been asked for a new report type (perhaps a subset of failure > > reports) that provides minimal data from the email (specifically, the > > initial ask

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

In article <609e1c9b-cc4d-d7d1-0fa8-79f515c1e...@tana.it> you write: > It has been asked for a new report type (perhaps a subset of failure > reports) that provides minimal data from the email (specifically, the > initial ask is for the to: and from: email addresses only) in order to

Re: [dmarc-ietf] p=quarantine

On 12/9/2020 9:52 AM, tjw ietf wrote: Obviously the domain owner has no 'authority' over those using the domain without authorization.  For this latter set of folk, the most the domain owner can do is provide information to receivers of unauthorized use. It might be worth a bit of thinking

Re: [dmarc-ietf] p=quarantine

I agree strongly with Dave on creating boring and precise terminology/references, and they are used over and over. Tim Sent from my iPhone > On Dec 9, 2020, at 12:40, Dave Crocker wrote: >  > On 12/8/2020 12:11 PM, Dotzero wrote: >> Note that I asked Two questions. Your answer appears

Re: [dmarc-ietf] p=quarantine

On 12/8/2020 12:11 PM, Dotzero wrote: Note that I asked Two questions. Your answer appears directed to the second question. The answer to the first question appears fairly clear to me. Administrators of a system can restrict or delete a user account. It really is as simple as that. So in that

Re: [dmarc-ietf] Ticket #28 - Failure report mail loops

On 12/9/2020 7:23 AM, John R Levine wrote: No.  This is not a problem.  There is nothing to fix.  Please close this ticket. +1 d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org

[dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

We would like to close this ticket by Dec 23, two weeks from now, so please get on it. The ticket text is: It has been asked for a new report type (perhaps a subset of failure reports) that provides minimal data from the email (specifically, the initial ask is for the to: and from:

Re: [dmarc-ietf] Ticket #28 - Failure report mail loops

On Wed, 9 Dec 2020, Alessandro Vesely wrote: It seems better than the other three bullets, so I'd prepend it. Does the WG agree? No. This is not a problem. There is nothing to fix. Please close this ticket. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY

Re: [dmarc-ietf] Ticket #28 - Failure report mail loops

On Wed 09/Dec/2020 01:04:46 +0100 John Levine wrote: In article <62b7d80e-2c39-4d02-0b5a-bd6ede7d5...@tana.it> you write: When dmarc authentication method fails on a message, an MTA may decide to send a failure report. If the message is itself a failure report, however, no failure report

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

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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On Mon 07/Dec/2020 23:13:44 +0100 John Levine wrote: In article you write: I have a slight preference for the first option. HELO is too arbitrary in the protocol for me to put much value in using it in any of these systems. There's a bit of an implementation detail though. If one is