Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports
On 12/22/20 10:59 AM, Alessandro Vesely wrote: Sorry, having to ask for permission because of laws does not constitute a "severe privacy concern". Except in the sense that they're called privacy laws. Do you have a better wording? I don't know what was wrong with the initial text. But it most certainly is not a "severe privacy concern", especially if it is the originating domain getting the report. It already saw the original message in the first place assuming it wasn't spoofed, and if it was spoofed they are entitled to see it for forensics if the receiving domain is willing to send it to them. That is completely outside of the scope of IETF and we should be pandering to it. Making specifications that cannot be legally abided by is in IETF scope? If the laws are unreasonable? Sure. We're not putting backdoors in for encryption either. It's their laws, let them figure it out. But you said that providers can get people to opt in, so that seem moot. Mike ___ 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 Tue, Dec 22, 2020 at 11:00 AM Alessandro Vesely wrote: > > Making specifications that cannot be legally abided by is in IETF scope? > Sure - RFC 7258. Unless you want to play the semantic card of BCP vs. specification. --Kurt ___ 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 Tue 22/Dec/2020 18:02:10 +0100 Michael Thomas wrote: On 12/22/20 8:50 AM, Alessandro Vesely wrote: On Tue 22/Dec/2020 17:16:05 +0100 Michael Thomas wrote: On 12/22/20 1:22 AM, Alessandro Vesely wrote: NEW Failure reports provide detailed information about the failure of a single message or a group of similar messages failing for the same reason. They are meant to aid extreme cases where a domain owner is unable to detect why failures reported in aggregate form did occur. As an extension of other kinds of failure notifications, these reports can contain either the content of a failed message or just its header. The latter characteristic entails severe privacy concerns. For that reason, and because it turned out not to be important, failure reporting is usually disabled. I'm not understanding what this "severe privacy concerns" are. It looks like a glorified bounce message to me. My messages pass through the originating domain in the clear, but it only becomes a "severe privacy concern" when it is reflected back? How does that work? Unlike bounces, you're delivering PII info to a third party. In Europe, if you setup failure reporting that way, having a third-party handling/ processing meta-data or even mail content requires you to inform your customers about that, and ask permission. If third-party is outside EU, since privacy shield got canceled last July, there is not even a legal basis anymore that would allow you to do so at all. In all cases, you would be held responsible for your customers data unless third-party is signing contracts with you to accept EU privacy laws. EU has severe penalty for companies which break GDPR. Sorry, having to ask for permission because of laws does not constitute a "severe privacy concern". Except in the sense that they're called privacy laws. Do you have a better wording? That is completely outside of the scope of IETF and we should be pandering to it. Making specifications that cannot be legally abided by is in IETF scope? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
On Tue 22/Dec/2020 16:41:43 +0100 Todd Herr wrote: On Mon, Dec 21, 2020 at 12:47 PM Alessandro Vesely wrote: On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote: Lists are a specific instance of the more general case of indirect mail flows. >> How many kinds of indirect mail flows do rewrite From:? Specific methods might prove more effective than general ones. Sender Rewriting Scheme (SRS) exists for the rewriting of the RFC5321.From address, and is sometimes used in mail that is forwarded by rule, say from @alum.institution.edu to @consumerMailboxProvider.com VERP as done by MLMs is more specific (and better thought) than generic SRS. I don't have numbers but off the top of my head I'd reckon MLMs cover a major part of RFC5321.From rewriters. If you additionally select by RFC5322.From rewriting, I'd guess you're left with exactly MLMs. It seems to me that we can either work to find a way to ensure that [forwarding] failures don't happen, or we can work to find a reliable and trustworthy way to record authentication results along the way so that the failures can be mitigated and not result in failed delivery of wanted mail. Actually, people seem to be doing both. Avoiding gratuitous autoconversions, anti-virus results as footers, and the like, have become a must for most modern MTA software. And there are several mailing lists which operate that way as well. OTOH, modifications are sometimes unavoidable and we still need to cope. Since the receiver typically can't perform the same checks under the same conditions that existed when the intermediary performed them (if it could, we wouldn't need something like ARC) then the receiver has to decide if the message is consistent with messages it's previously seen through direct mail flows using that same authenticated identity that was captured by the intermediary in the ARC header set. >> Doesn't that assume some kind of omniscience at the receiver's? Consistency with previous messages by the same source is not straightforward. Using the same selector? Signing more or less the same set of header fields? Choice of vocabulary? HTML vs. plain text style (e.g. line length)? A.I.? > Not omniscience, no, but certainly a method of tracking an authenticated identity's reputation, and consistency of reputation is what I'm speaking of. Allow me to try again to get across the idea that I'm so far failing to make clear. I'm not currently working for a mailbox provider, but I have in the past, and so I will role play as one here. As a mailbox provider, I have a system for authenticating the identity or identities associated with messages that come directly to me. These authenticated identities can include some or all of: - The DKIM signing domain(s) - The DKIM signing domain(s) and selector(s) - The RFC5322.From domain (authenticated using DMARC) - The RFC5321.From domain (SPF) - The IP address of the client that passed the message to me - The domain associated with the PTR record of that IP address - Others as I deem useful Except for PTR records, that's the data I collect to send out aggregate reports. For each of these authenticated identities, I can and will track how my users/customers/mailbox holders engage with the mail they receive, thus over time establishing in my system a reputation to associate with each authenticated identity. If, for example, mail that is DKIM signed using selector S and domain D is mail that my users demonstrate through their actions (opening it, clicking on links in it, etc.) is wanted mail, then that authenticated identity (S._domainkey.D) will be associated with a good reputation (however I define "good") in my system. Lather, rinse, and repeat for other authenticated identities associated with the message, and allow that both good and bad reputations can be earned. That's a delicate job. For one point, 20161025._domainkey.gmail.com is not the kind of identifier you want to associate with users' liking, as it is shared among so many messages with diverging characteristics. For another point, there are domains that change selector very often (taugh.com changes it on every message), so it can identify too narrow a message set. Characterizing by author (a.k.a. RFC5322.From) probably works better. An author authenticated by her submission server (a.k.a. author's domain) looks like a good identifier. You still have to sort out authors having multiple email address and using them interchangeably. However, as forwarding of modified messages settles on From: rewriting, recovering that identifier becomes fuzzy. ARC does not cover that bit. If we want to reliably use the author as an identifier, we need those forwarders who rewrite the From: header field —let's call'em MLMs— to adopt a standard way to convey the original value. In my mlm-transform draft, I propose Original-From:. IETF uses X-Original-From:. Mailman uses Reply-To: or Cc:.
Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports
On 12/22/20 8:50 AM, Alessandro Vesely wrote: On Tue 22/Dec/2020 17:16:05 +0100 Michael Thomas wrote: On 12/22/20 1:22 AM, Alessandro Vesely wrote: NEW Failure reports provide detailed information about the failure of a single message or a group of similar messages failing for the same reason. They are meant to aid extreme cases where a domain owner is unable to detect why failures reported in aggregate form did occur. As an extension of other kinds of failure notifications, these reports can contain either the content of a failed message or just its header. The latter characteristic entails severe privacy concerns. For that reason, and because it turned out not to be important, failure reporting is usually disabled. I'm not understanding what this "severe privacy concerns" are. It looks like a glorified bounce message to me. My messages pass through the originating domain in the clear, but it only becomes a "severe privacy concern" when it is reflected back? How does that work? Unlike bounces, you're delivering PII info to a third party. In Europe, if you setup failure reporting that way, having a third-party handling/ processing meta-data or even mail content requires you to inform your customers about that, and ask permission. If third-party is outside EU, since privacy shield got canceled last July, there is not even a legal basis anymore that would allow you to do so at all. In all cases, you would be held responsible for your customers data unless third-party is signing contracts with you to accept EU privacy laws. EU has severe penalty for companies which breaking GDPR. Sorry, having to ask for permission because of laws does not constitute a "severe privacy concern". That is completely outside of the scope of IETF and we should be pandering to it. Mike ___ 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 Tue 22/Dec/2020 17:16:05 +0100 Michael Thomas wrote: On 12/22/20 1:22 AM, Alessandro Vesely wrote: NEW Failure reports provide detailed information about the failure of a single message or a group of similar messages failing for the same reason. They are meant to aid extreme cases where a domain owner is unable to detect why failures reported in aggregate form did occur. As an extension of other kinds of failure notifications, these reports can contain either the content of a failed message or just its header. The latter characteristic entails severe privacy concerns. For that reason, and because it turned out not to be important, failure reporting is usually disabled. I'm not understanding what this "severe privacy concerns" are. It looks like a glorified bounce message to me. My messages pass through the originating domain in the clear, but it only becomes a "severe privacy concern" when it is reflected back? How does that work? Unlike bounces, you're delivering PII info to a third party. In Europe, if you setup failure reporting that way, having a third-party handling/ processing meta-data or even mail content requires you to inform your customers about that, and ask permission. If third-party is outside EU, since privacy shield got canceled last July, there is not even a legal basis anymore that would allow you to do so at all. In all cases, you would be held responsible for your customers data unless third-party is signing contracts with you to accept EU privacy laws. EU has severe penalty for companies which breaking GDPR. I cannot tell for Canada or Australia. Best Ale -- ___ 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
I think that text is way too long and overspecific but we've already spent too much time on this so I'll stop and see if there are other opinions. On Tue, 22 Dec 2020, Alessandro Vesely wrote: OLD "Failure reports," or "failed message reports," provide diagnostic information about messages that a Mail Receiver has determined do not pass the DMARC mechanism. These reports are generally sent at the time such messages are received and evaluated, to provide the Domain Owner with timely notification that such failures are occurring, and to provide information that may assist in diagnosing the cause of the failures. NEW Failure reports provide detailed information about the failure of a single message or a group of similar messages failing for the same reason. They are meant to aid extreme cases where a domain owner is unable to detect > why failures reported in aggregate form did occur. As an extension of other kinds of failure notifications, these reports can contain either the > content of a failed message or just its header. The latter characteristic entails severe privacy concerns. For that reason, and because it turned out not > to be important, failure reporting is usually disabled. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ 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 12/22/20 1:22 AM, Alessandro Vesely wrote: NEW Failure reports provide detailed information about the failure of a single message or a group of similar messages failing for the same reason. They are meant to aid extreme cases where a domain owner is unable to detect why failures reported in aggregate form did occur. As an extension of other kinds of failure notifications, these reports can contain either the content of a failed message or just its header. The latter characteristic entails severe privacy concerns. For that reason, and because it turned out not to be important, failure reporting is usually disabled. I'm not understanding what this "severe privacy concerns" are. It looks like a glorified bounce message to me. My messages pass through the originating domain in the clear, but it only becomes a "severe privacy concern" when it is reflected back? How does that work? Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
On 12/22/20 7:41 AM, Todd Herr wrote: My conundrum here is "Do I trust A's claim that the message was correctly DKIM signed by domain D with selector S?" which is why ARC brings nothing new to the table. it's not that it was correctly signed by the originator, it's whether i trust the mangler at all. if i do, then i implicitly trust that they handled the dkim verification too. it would be a lot more productive to work on that trust problem than hoping a renamed dkim signature is going to somehow change that. Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
On Mon, Dec 21, 2020 at 12:47 PM Alessandro Vesely wrote: > On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote: > > > > Lists are a specific instance of the more general case of indirect mail > flows. > > > How many kinds of indirect mail flows do rewrite From:? > > Specific methods might prove more effective than general ones. > > Sender Rewriting Scheme (SRS) exists for the rewriting of the RFC5321.From address, and is sometimes used in mail that is forwarded by rule, say from @ alum.institution.edu to @consumerMailboxProvider.com The larger point, though, is that mail that automatically passes through one or more intermediary hosts on its way to its final destination can fail authentication checks at the final destination due to the impact of changes on the message, either in path, or content, or both, as it traverses that journey. It seems to me that we can either work to find a way to ensure that such failures don't happen, or we can work to find a reliable and trustworthy way to record authentication results along the way so that the failures can be mitigated and not result in failed delivery of wanted mail. > > [...] > > > > Since the receiver typically can't perform the same checks under the > same > > conditions that existed when the intermediary performed them (if it > could, we > > wouldn't need something like ARC) then the receiver has to decide if the > > message is consistent with messages it's previously seen through direct > mail > > flows using that same authenticated identity that was captured by the > > intermediary in the ARC header set. > > > Doesn't that assume some kind of omniscience at the receiver's? > Consistency > with previous messages by the same source is not straightforward. Using > the > same selector? Signing more or less the same set of header fields? > Choice of > vocabulary? HTML vs. plain text style (e.g. line length)? A.I.? > > Not omniscience, no, but certainly a method of tracking an authenticated identity's reputation, and consistency of reputation is what I'm speaking of. Allow me to try again to get across the idea that I'm so far failing to make clear. I'm not currently working for a mailbox provider, but I have in the past, and so I will role play as one here. As a mailbox provider, I have a system for authenticating the identity or identities associated with messages that come directly to me. These authenticated identities can include some or all of: - The DKIM signing domain(s) - The DKIM signing domain(s) and selector(s) - The RFC5322.From domain (authenticated using DMARC) - The RFC5321.From domain (SPF) - The IP address of the client that passed the message to me - The domain associated with the PTR record of that IP address - Others as I deem useful For each of these authenticated identities, I can and will track how my users/customers/mailbox holders engage with the mail they receive, thus over time establishing in my system a reputation to associate with each authenticated identity. If, for example, mail that is DKIM signed using selector S and domain D is mail that my users demonstrate through their actions (opening it, clicking on links in it, etc.) is wanted mail, then that authenticated identity (S._domainkey.D) will be associated with a good reputation (however I define "good") in my system. Lather, rinse, and repeat for other authenticated identities associated with the message, and allow that both good and bad reputations can be earned. Now here comes a message that is DKIM-signed by D with selector S, and it fails DKIM validation when I do my checks. However, in scanning the message, I see that there is an ARC header set, one that was signed and sealed by A, and in that ARC header set is an ARC-Authentication-Results header that says that the message passed DKIM validation with signing domain D and selector S when A did its check. My conundrum here is "Do I trust A's claim that the message was correctly DKIM signed by domain D with selector S?" The answer to that question will depend on how my users treat the message and others like it, assuming that I accept it and deliver it. If my users treat such messages in a manner that's consistent with how they treat direct mail flow that is DKIM-signed by D with selector S, then A's reputation as an ARC-sealer/signer will be positive, because A will establish with me a history of being a source of ARC-sealed/signed mail with ARC header sets that can be believed. On the other hand, if my users consistently treat such messages differently than they do direct mail flow that is DKIM-signed by D with selector s, then A's reputation as an ARC-sealer/signer will be negatively impacted with me, because I will not have evidence in hand that this is a path for mail with an authenticated identity of S._domainkey.D to take. The point here is that ARC (or any system designed to capture intermediate authentication results) can only succeed if the downstream recipients of the
Re: [dmarc-ietf] ARC vs p=quarantine
On Tue 22/Dec/2020 03:37:52 +0100 Benny Pedersen wrote: On 2020-12-21 18:27, Alessandro Vesely wrote: On Mon 21/Dec/2020 01:52:11 +0100 Benny Pedersen wrote: For the message I'm replying to, I got: Authentication-Results: wmail.tana.it; spf=pass smtp.mailfrom=ietf.org; dkim=pass reason="Original-From: transformed" (whitelisted) header.d=junc.eu; dkim=pass (whitelisted) header.d=ietf.org header.b=GUNfiCpP; dkim=fail (signature verification failed, whitelisted) header.d=ietf.org header.b=IIMQxhd+ Two out of three is not bad, is it? If IETF only did ARC seals, I'd probably verified no signature at all —since I don't run ARC checks. metacpan Mail::DKIM gives dkim invalid if just one dkim is invalid, so spamassassin says aswell dkim invalid I don't think that's a reasonable choice. A DKIM informative note exemplifies this very case: INFORMATIVE NOTE: The rationale of this requirement is to permit messages that have invalid signatures but also a valid signature to work. For example, a mailing list exploder might opt to leave the original submitter signature in place even though the exploder knows that it is modifying the message in some way that will break that signature, and the exploder inserts its own signature. In this case, the message should succeed even in the presence of the known-broken signature. https://tools.ietf.org/html/rfc6376#section-6.1 what software used above to show this results ? zdkimfilter Best Ale -- ___ 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 Mon 21/Dec/2020 22:01:44 +0100 John R Levine wrote: What is evident is that, as conceived, failure reports break privacy enough to make an admin's skin crawl. Right. I think we should convey the fact that failure reports are (to be) sent in limited circumstances and with due circumspection. Yes, that is more or less what I have been saying, only I'd say you probably don't want to send them at all since they have turned out not to be important. Saying so ourselves would corroborate our credibility. One place to change is the second paragraph in the Introduction. For example: OLD "Failure reports," or "failed message reports," provide diagnostic information about messages that a Mail Receiver has determined do not pass the DMARC mechanism. These reports are generally sent at the time such messages are received and evaluated, to provide the Domain Owner with timely notification that such failures are occurring, and to provide information that may assist in diagnosing the cause of the failures. NEW Failure reports provide detailed information about the failure of a single message or a group of similar messages failing for the same reason. They are meant to aid extreme cases where a domain owner is unable to detect why failures reported in aggregate form did occur. As an extension of other kinds of failure notifications, these reports can contain either the content of a failed message or just its header. The latter characteristic entails severe privacy concerns. For that reason, and because it turned out not to be important, failure reporting is usually disabled. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
