Re: [dmarc-ietf] ARC vs p=quarantine
On Sat, Dec 19, 2020 at 2:50 PM John Levine wrote: > In article <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1...@tana.it> you write: > >Now my tiny MX stores 115,225 domains total. And I have no idea how I > could > >add a trust-ARC-seals boolean field to each domain record. > > You wouldn't. Only a small fraction of those domains send enough forwarded > mail to be worth worrying about. We know we need some sort of shared list > of plausible forwarders but I would be amazed if it were anything like 115K > domains. > > R's, > John > So the need for a shared list has been expressed a number of times. The real question is who steps up to provide such shared lists. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports
In article <754690b7-6624-4cc6-66e1-62438b32c...@tana.it> you write: >On Sat 19/Dec/2020 01:03:58 +0100 Seth Blank wrote: >> >> A privacy consideration should say such a thing, specifically clarify what >> may be in a report that could be categorized as PII even after intended >> redaction, but refrain from legal advice. Given how few failure reports we're seeing, perhaps we should just take out the advice and say something like you can send these as is or redacted if you want and your policies permit, but most people don't. It's kind of amusing to know the exact names and e-mail addresses of everyone at Linkedin who subscribes to the same lists I do, but I could live without it. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC vs p=quarantine
In article <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1...@tana.it> you write: >Now my tiny MX stores 115,225 domains total. And I have no idea how I could >add a trust-ARC-seals boolean field to each domain record. You wouldn't. Only a small fraction of those domains send enough forwarded mail to be worth worrying about. We know we need some sort of shared list of plausible forwarders but I would be amazed if it were anything like 115K domains. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports
On Sat 19/Dec/2020 01:03:58 +0100 Seth Blank wrote: > > A privacy consideration should say such a thing, specifically clarify what > may be in a report that could be categorized as PII even after intended > redaction, but refrain from legal advice. As John pointed out, an IP address can be classed as personal data in a country and not in another. It is hard to tell what data could be PII while refraining from legal considerations. Anyway, email addresses seem to be PII under any legislation. Indeed, that's the only piece of data mentioned by RFC 6590. (Hence I guess one should redact also From:, Jesse's point for ticket #61 notwithstanding.) Yet, spam complaints seem to be sent w/o redaction. I confess I wouldn't know how to carry out an "intended redaction". I cannot recall any useful redacting recommendation for email messages. Most "practical" guides recommend to print them, carefully redact addresses, phone numbers and the like, then scan the result and send the image. Non so practical for a mail filter daemon. I read Outlook has a message redaction feature. I'd be curious about what does that deliver. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
On Fri 18/Dec/2020 22:54:54 +0100 Michael Thomas wrote: In my opinion, ARC has promise, because if a message reaches me as a receiver or even intermediary and fails the authentication checks I perform, ARC header sets in the message can tell me whether or not such checks passed at previous hops *if I trust the entities that inserted those ARC header sets*. In an earlier thread, I floated an idea about ARC sealer reputation, but it didn't draw much response, so I'll float it here again in the hopes that it does. We've always been able to check the reputation of lists that resign the message. The reputation is the previously (un)solved problem. Yesterday 34 new domains —domains I never heard of before— sent 35 messages to my MX. I count identifiers. Some of them are subdomains of known domains, so they might inherit their parent's reputation. Several others, however, are new organizational domains. I'm just looking at the first 8, and none of them looks like a throw-away, freshly registered domain. Now my tiny MX stores 115,225 domains total. And I have no idea how I could add a trust-ARC-seals boolean field to each domain record. Except for a few gigantic mailbox providers, I'd say the reputation problem is not quite solved. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
