Re: [dmarc-ietf] SP policy compatibility

On Sun 23/Jan/2022 14:00:20 +0100 Douglas Foster wrote: Option 1 The tree walk could duplicate RFC 7489 by specifying that the walk continues until a PSD policy is found or the TLD is reached.    Then the last policy found before the termination point is the organizational policy, and that re

Re: [dmarc-ietf] Tree walk is screwed up

On Sat 22/Jan/2022 16:29:34 +0100 John Levine wrote: Ale said: Mike said: I have previously pointed out that there are organizations that lease/rent or otherwise provide subdomains as part of their commercial offerings. Your assertion is akin to claiming that tenants in an apartment building a

Re: [dmarc-ietf] Tree walk is screwed up

On Fri 21/Jan/2022 18:59:16 +0100 John R Levine wrote: Yes, that is the plan.  Please go back and look at the discussion when we talked about the tree walk in the first place. I don't remember that we ever convene that subdomains cannot override the org domain record. The "org domain record"

Re: [dmarc-ietf] Tree walk is screwed up

On Fri 21/Jan/2022 15:20:17 +0100 Douglas Foster wrote: Your idea is brilliant - search for a policy that applies to both the FROM domain and the other domain name.  If it is not a PSD policy, then the two names are aligned.  It eliminates the PSL while also creating no need for PSD policies.

Re: [dmarc-ietf] Tree walk is screwed up

On Fri 21/Jan/2022 15:28:07 +0100 John R Levine wrote: For the same reason the PSL has a lot of two- and three-label domains. Except that the PSL is somehow vetted; that is, there are no self-appointed PSDs. Sorry, but that is simply false.  The entire "private domains" part of the PSD is s

Re: [dmarc-ietf] Tree walk is screwed up

On Fri 21/Jan/2022 05:29:05 +0100 John Levine wrote: It appears that Alessandro Vesely said: On Wed 19/Jan/2022 19:38:15 +0100 John Levine wrote: What I always intended with the tree walk is that you walk up the tree and if you find a DMARC record that isn't a PSD, that's your

Re: [dmarc-ietf] Tree walk is screwed up

On Wed 19/Jan/2022 19:38:15 +0100 John Levine wrote: What I always intended with the tree walk is that you walk up the tree and if you find a DMARC record that isn't a PSD, that's your org domain. To see if two names are in relaxed alignment, do a tree walk for both and if they end at the same

Re: [dmarc-ietf] in praise of none, was Evaluator reference model

On Wed 19/Jan/2022 16:23:50 +0100 John Levine wrote: It appears that Todd Herr said: A policy of "none" isn't useless to an evaluator; it's communicating to the evaluator that the domain owner isn't yet confident that all mail sent using its domain in the RFC5322.From header is properly authen

Re: [dmarc-ietf] Evaluator reference model

On Tue 18/Jan/2022 16:33:52 +0100 Todd Herr wrote: A policy of "none" isn't useless to an evaluator; it's communicating to the evaluator that the domain owner isn't yet confident that all mail sent using its domain in the RFC5322.From header is properly authenticated, and so messages that fail

Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy

On Thu 06/Jan/2022 22:50:42 +0100 John Levine wrote: It appears that Alessandro Vesely said: On Thu 06/Jan/2022 12:32:17 +0100 Douglas Foster wrote:  I perceive a false assumption that when a sender does not publish p=reject, then his messages cannot be blocked for failure to validate

Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy

On Thu 06/Jan/2022 12:32:17 +0100 Douglas Foster wrote: The point of a specification like this is to understand each participant's best interest and channel that toward the common goal.  I perceive a false assumption that when a sender does not publish p=reject, then his messages cannot be bl

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

On Mon 20/Dec/2021 20:59:45 +0100 John Levine wrote: It appears that Alessandro Vesely said: On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote: I am not doing any root domain lookups.   If that is part of the proposed algorithm, somebody needs to document it.  I am simply looking for a

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

On Mon 20/Dec/2021 18:41:25 +0100 Scott Kitterman wrote: On Monday, December 20, 2021 12:39:15 PM EST Alessandro Vesely wrote: On Sun 19/Dec/2021 21:42:16 +0100 Scott Kitterman wrote: > If the domain owner has suggested that you reject mail from a sub-domain > that has none of A, ,

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

On Sun 19/Dec/2021 21:42:16 +0100 Scott Kitterman wrote: If the domain owner has suggested that you reject mail from a sub-domain that has none of A, , or MX records, why would you not do that? Are we sure that's what the domain owner meant to suggest? An organization can use sp= on its

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote: I am not doing any root domain lookups.   If that is part of the proposed algorithm, somebody needs to document it.  I am simply looking for a resource record matching the FROM domain name. Oops, yes, you're right. Dunno why I looked up

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

On Mon 20/Dec/2021 00:42:27 +0100 Douglas Foster wrote: I detected 52 messages, from 10 unique domains, which failed the MX/A test. [...] 7 of 10 had DMARC PASS based on both SPF and DKIM: bc.qvcemail.com doctors-digest.com email.nutricia-na.com mail.foodnetwork.com mail.medscape.org mktg.daily

Re: [dmarc-ietf] 3.2.6 The lack of meaning of non-existence

On Fri 17/Dec/2021 21:05:39 +0100 John Levine wrote: It appears that Alessandro Vesely said: Of course, if the From: domain doesn't exist at all, it cannot have a DMARC record. However, according to the formal definition of Section 3.6.2, a non-existing domain can pass all DMARC

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

On Fri 17/Dec/2021 18:38:54 +0100 Tim Wicinski wrote: On Fri, Dec 17, 2021 at 12:30 PM Dotzero wrote: DMARC does not assess "honesty" nor does it assess "fraudulence". It only determines whether something passes or fails the validation check. You are apparently trying to overload your value in

Re: [dmarc-ietf] 5.7.1 - Mulitple FROM

Hi Doug, On Sat 11/Dec/2021 05:29:22 +0100 Douglas Foster wrote: I suggest that it is time to propose that RFC 5322 section 3.6.2 be revised to drop support for multiple From fields. As Scott noted, Emailcore mailing list is next door. The market has clearly spoken that there the feature i

Re: [dmarc-ietf] 5.7.1 - Mulitple FROM

On Fri 10/Dec/2021 19:58:48 +0100 Scott Kitterman wrote: On Friday, December 10, 2021 1:46:34 PM EST Alessandro Vesely wrote: RFC5322 explicitly allows multiple mailboxes: from= "From:" mailbox-list CRLF sender = "Sender:" mailbox CRLF To

Re: [dmarc-ietf] 5.7.1 - Mulitple FROM

On Fri 10/Dec/2021 05:11:28 +0100 Douglas Foster wrote: The language in the quoted document about "multiple from messages are usually rejected" was interesting.   It reflects what I would intend to do, and what I think others should do, but I assumed that we could not explicitly advocate for

Re: [dmarc-ietf] dmarcbis-04, 4.7.1 and 4.7.2 Relaxed Alignment and Domain Hierarchy

Hi, I don't think alignment definitions should be modified. We can add, for example, adkim=h, for hierarchical, if we want to restrict DKIM signers to be super or sub domains of the From: domain. The advantage of this definition is that it doesn't require to determine the org domain, until

Re: [dmarc-ietf] PSD Flag

On Mon 06/Dec/2021 23:23:37 +0100 Tim Wicinski wrote: On Mon, Dec 6, 2021 at 8:57 AM Scott Kitterman > wrote: Unless there's a valid reason for someone to publish PSD=no, I don't think it should exist and I can't think of a reason.  If you give people a knob

Re: [dmarc-ietf] Ticket #120 - Unique IDs

On Mon 06/Dec/2021 20:57:22 +0100 Brotman, Alex wrote: Hello folks, We received a ticket about the unique IDs that are included with reporting: -- unique-id, msg-id, and report_id are loosely defined. The spec needs to say that they are semantically the same thing and m

[dmarc-ietf] ARC's role, was Best Guess SPF should not be deprecated.

On Mon 06/Dec/2021 21:04:37 +0100 Dave Crocker wrote: On 12/6/2021 11:56 AM, Scott Kitterman wrote: Somewhere we need to explain about how ARC related to DMARC.  If it's going to be in the protocol specification, this is the place.  Otherwise it would go in the appendix I keep mentioning that w

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On Mon 06/Dec/2021 14:29:02 +0100 Scott Kitterman wrote: On December 6, 2021 1:04:44 PM UTC, Todd Herr wrote: On Sat, Dec 4, 2021 at 5:35 PM Douglas Foster wrote: I have multiple objections to this paragraph in section 5.7.2 "Heuristics applied in the absence of use by a Domain Owner of ei

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

On Mon 06/Dec/2021 17:40:47 +0100 Todd Herr wrote: On Mon, Dec 6, 2021 at 9:08 AM Scott Kitterman wrote: On December 6, 2021 1:35:10 PM UTC, Todd Herr wrote: On Mon, Dec 6, 2021 at 7:45 AM Alessandro Vesely wrote: ... Should any overlooked systems be found in the

[dmarc-ietf] dmarcbis-04, 5.7.1. Extract Author Domain

Hi, The domain in the RFC5322.From header field is extracted as the domain to be evaluated by DMARC. If the domain is encoded with UTF- 8, the domain name must be converted to an A-label, as described in Section 2.3 of [RFC5890], for further processing. Why? That paragraph is almos

[dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

Hi, I have a few nits about this section: This section describes Domain Owner actions to fully implement the DMARC mechanism. Actually, the section doesn't mention DMARC checking, adhering to policies found in DMARC records, and sending feedback reports. Hence I'd strike "fully". It d

Re: [dmarc-ietf] Reversing modifications from mailing lists

On Sun 05/Dec/2021 20:55:30 +0100 Wei Chuang wrote: On Wed, Dec 1, 2021 at 3:45 AM Alessandro Vesely wrote: On Tue 30/Nov/2021 18:30:39 +0100 John R Levine wrote: On Tue, 30 Nov 2021, Wei Chuang wrote: What about adding a footer to some html mime part is poorly handled when using &q

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

On Sat 04/Dec/2021 22:30:30 +0100 Murray S. Kucherawy wrote: On Fri, Dec 3, 2021 at 10:38 AM Todd Herr The sentence should read something like this: Percentage of messages using the Domain Owner's domain and failing DMARC authentication checks to which the DMARC policy is to be applied. I'd b

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

On Sat 04/Dec/2021 22:01:50 +0100 Tim Wicinski wrote: On Sat, Dec 4, 2021 at 6:20 AM Alessandro Vesely wrote: On Fri 03/Dec/2021 19:38:26 +0100 Todd Herr wrote: On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely wrote: That's the only part which breaks existing records. According t

Re: [dmarc-ietf] Additions to introduction

On Sun 05/Dec/2021 04:23:45 +0100 Scott Kitterman wrote: On December 4, 2021 10:09:48 PM UTC, Seth Blank wrote: On Sat, Dec 4, 2021 at 1:34 PM Tim Wicinski wrote: I am Ok with adding text of this nature, and I think it's helpful in explaining to folks approaching DMARC for the first time. B

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

On Sat 04/Dec/2021 23:02:50 +0100 Seth Blank wrote: On Sat, Dec 4, 2021 at 10:00 AM John Levine wrote: It appears that Murray S. Kucherawy said: This was reported but not sent to the WG. I believe the right disposition is "Hold for Document Update". Does anyone want to argue for "Rejected

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

On Fri 03/Dec/2021 19:38:26 +0100 Todd Herr wrote: On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely wrote: last message for today: the "t" tag instead of "pct". That's the only part which breaks existing records. According to the last paragraph of this section, d

[dmarc-ietf] dmarcbis-04, 5.3. General Record Format 3/5

Hi, we have: p: Domain Owner Assessment Policy (plain-text; RECOMMENDED for policy records). Indicates the message handling preference the Domain Owner or PSO has for mail using its domain but not passing DMARC verification. Policy applies to the domain queried and to

[dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

Hi, last message for today: the "t" tag instead of "pct". That's the only part which breaks existing records. According to the last paragraph of this section, doing so requires v=DMARC2. Given also that we discovered use cases that were not considered during the hasty discussion that resul

[dmarc-ietf] dmarcbis-04, 5.3. General Record Format 4/5

Hi, for psd: [...] This information will be used during policy discovery to determine how to apply any DMARC policy records that are discovered during the tree walk. It is not yet clear /how/ that information will be used. In general, what information do

[dmarc-ietf] dmarcbis-04, 5.3. General Record Format 2/5

Hi. The np tag definition looks identical to that of rfc9091, except for the last sentence: Note that "np" will be ignored for DMARC records published on subdomains of Organizational Domains and PSDs due to the effect of t

[dmarc-ietf] dmarcbis-04, 5.3. General Record Format 1/5

Hi, I have five issues on this section. The second paragraph says: Section 8 creates a registry for known DMARC tags and registers the initial set defined in this document. Only tags defined in this document or in later extensions, and thus added to that registry, are to be process

[dmarc-ietf] dmarcbis-04, 5. Policy

Hi, I don't understand the second paragraph: A Domain Owner or PSO may choose not to participate in DMARC evaluation by Mail Receivers simply by not publishing an appropriate DNS TXT record for its domain(s). A Domain Owner can also choose to not have some underlying authentication

[dmarc-ietf] dmarcbis-04, 4.7.1. DKIM-Authenticated Identifiers

Hi, this paragraph is fine: To illustrate, in relaxed mode, if a verified DKIM signature successfully verifies with a "d=" domain of "example.com", and the RFC5322.From address is "ale...@news.example.com", the DKIM "d=" domain and the RFC5322.From domain are considered to be "in

[dmarc-ietf] dmarcbis-04, 4.6. Determining the Organizational Domain

Hi, I looked up _dmarc.com and got no data, looked up _dmarc.gov.uk and got a DMARC record without a psd= tag. The spec says: Once such a record has been found, [...] That would be a goof place to say: If no labels remain and no record with a psd tag with a value of 'y' was found, th

[dmarc-ietf] dmarcbis-04, 3.2.11. Report Receiver (nit)

Hi, could we stick to the term *Report Consumer*, please? The Producer/ Consumer terminology is used in Authentication-Results parlance. It is convenient because the term receiver is inevitably used without qualification in several sentences where it is clear from the context (to the writer)

[dmarc-ietf] dmarcbis-04 Abstract, domain controller?

Hi, the adoption of the PSD extension experiment brought some heavy-handed wording. On Thu 02/Dec/2021 21:54:56 +0100 internet-drafts wrote: Abstract: This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the own

Re: [dmarc-ietf] Reversing modifications from mailing lists

On Wed 01/Dec/2021 20:10:30 +0100 John Levine wrote: It appears that Alessandro Vesely said: I'm not clear about the last but one paragraph of that section: An example of such an attack includes altering the MIME structure, exploiting lax HTML parsing in the MUA, and defe

Re: [dmarc-ietf] Reversing modifications from mailing lists

On Tue 30/Nov/2021 18:30:39 +0100 John R Levine wrote: On Tue, 30 Nov 2021, Wei Chuang wrote: What about adding a footer to some html mime part is poorly handled when using "l="?  Multipart bodies could be handled by other techniques. See section 8.2 in the DKIM spec which says if you use l= y

Re: [dmarc-ietf] Reversing modifications from mailing lists

On Mon 29/Nov/2021 15:17:45 +0100 John R Levine wrote: On Mon 29/Nov/2021 04:03:57 +0100 John Levine wrote: This was part of the discussion about what sort of body modifications to allow. We ended up with optionally ignoring white space changes, and l= to ignore added text. My impression is that

Re: [dmarc-ietf] Reversing modifications from mailing lists

On Mon 29/Nov/2021 04:03:57 +0100 John Levine wrote: It appears that said: It appears that Wei Chuang said: If the RFC2045 canonical representation at the final destination can be the same as the canonical representation at the original sender, ... When we were working on DKIM canonicali

Re: [dmarc-ietf] Reversing modifications from mailing lists

On Thu 25/Nov/2021 09:07:36 +0100 Wei Chuang wrote: Thanks for the feedback and answers. You're welcome On Wed, Nov 24, 2021 at 3:01 AM Alessandro Vesely wrote: On Tue 23/Nov/2021 00:28:01 +0100 Wei Chuang wrote: [...] 6. Subject * Agreed that some simple heuristic as proposed i

Re: [dmarc-ietf] Reversing modifications from mailing lists

On Wed 24/Nov/2021 17:30:08 +0100 John Levine wrote: It appears that Alessandro Vesely said: Sure. Note that if the receiver trusts the MLM, simply recognizing it would be enough to pass DMARC per the "mailing_list" policy override. ARC additionally provides the ability to

Re: [dmarc-ietf] UNCOL and Reversing modifications from mailing lists

On Wed 24/Nov/2021 17:22:51 +0100 John Levine wrote: It appears that Alessandro Vesely said: This proposal is UNCOL for mailing lists. ... Without going beyond Mailman lists, some of them remove DKIM signatures altogether, so there is no chance to recover anything. I don't under

Re: [dmarc-ietf] Reversing modifications from mailing lists

Hi, On Tue 23/Nov/2021 00:28:01 +0100 Wei Chuang wrote: 1. Ale's draft suggests not reversing all possible transforms, and rather focuses on a subset caused by mailing lists that are reversible   * Could ARC be suitable for those other scenarios? Could we expect that forwarders that do more

Re: [dmarc-ietf] UNCOL and Reversing modifications from mailing lists

On Tue 23/Nov/2021 21:34:05 +0100 John Levine wrote: It appears that Wei Chuang said: I saw Ale's draft draft-vesely-dmarc-mlm-transform in the ARC list, and wanted to discuss some of the ideas. ... Please humor me for

Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy Discovery

On Mon 01/Nov/2021 23:25:30 +0100 Scott Kitterman wrote: Could you perhaps do an assessment of the percentages of email you see where 5322.From == Org domain 5322.From is a sub-domain of Org domain 5321.MailFrom == 5322.From 5321.MailFrom is a sub-domain of 5322.From 5322.From is a sub-domain

Re: [dmarc-ietf] Organizational Alignment Options

On Thu 04/Nov/2021 04:09:37 +0100 Douglas Foster wrote: Ale asks: Hm... but PSDs don't seem to gain any extras by letting receivers know they're a PSD, do they? I think they do.   They get the benefits of name protection which DMARC previously afforded only to organizational domains and su

Re: [dmarc-ietf] Organizational Alignment Options

On Wed 03/Nov/2021 04:04:38 +0100 Scott Kitterman wrote: On November 3, 2021 2:09:04 AM UTC, John Levine wrote: It appears that Scott Kitterman said: 4. Common parent domain not marked PSD. We could add a new tag to the DMARC records for PSDs to indicate it's a PSD, so it's record shouldn

Re: [dmarc-ietf] DMARC agenda for the IETF 112 session

On Mon 01/Nov/2021 20:53:11 +0100 Barry Leiba wrote: I have uploaded a session agenda here: https://datatracker.ietf.org/meeting/112/session/dmarc _ From the agenda: 3. Bring discussion of indirect email flows to a close. Tracking tickets 79, 92, 94, 100, and 122 We will get to thi

Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy Discovery

On Mon 01/Nov/2021 21:35:07 +0100 John R Levine wrote: On Mon, 1 Nov 2021, Alessandro Vesely wrote: On Sun 31/Oct/2021 16:01:03 +0100 John Levine wrote: It appears that Alessandro Vesely  said: Another criterion, beside tree-walk and PSL, could be to look at the d= tag of the DKIM signatures

Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy Discovery

On Sun 31/Oct/2021 16:01:03 +0100 John Levine wrote: It appears that Alessandro Vesely said: >> Another criterion, beside tree-walk and PSL, could be to look at the d= tag of the DKIM signatures that are aligned with the From: domain. Would that be semantically equivalent to the pro

Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy Discovery

On Sun 31/Oct/2021 16:27:14 +0100 Scott Kitterman wrote: On October 31, 2021 11:29:41 AM UTC, Alessandro Vesely wrote: On Sat 30/Oct/2021 22:56:00 +0200 Scott Kitterman wrote: On October 30, 2021 8:47:51 PM UTC, John Levine wrote: According to Scott Kitterman : That usage has proven to

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery -- PSL Replacement using DNS Flags

On Sat 30/Oct/2021 05:15:14 +0200 Scott Kitterman wrote: On October 30, 2021 1:58:00 AM UTC, Douglas Foster wrote: I enthusiastically endorse John's proposal for policy discovery. PSL replacement using DNS Flags This proposal specifies a resource record that can be used to distinguish betwee

Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy Discovery

On Sat 30/Oct/2021 22:56:00 +0200 Scott Kitterman wrote: On October 30, 2021 8:47:51 PM UTC, John Levine wrote: According to Scott Kitterman : That usage has proven to work quite well. And some respect for the installed base wouldn't hurt. The alternative I suggested is 100% compatible wit

Re: [dmarc-ietf] let a hundred org domains blossom, not, was Topic for IETF 112 - Policy Discovery

On Sat 30/Oct/2021 19:42:01 +0200 John Levine wrote: It appears that Alessandro Vesely said: IMHO, we shouldn't throw away the PSL. Most importantly, we should stick to the concept of Organizational Domain. We can give an abstract definition of the latter in terms of affiliation of

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

On Fri 29/Oct/2021 23:29:13 +0200 Scott Kitterman wrote: On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: It appears that Scott Kitterman said: Until we understand what we want, overall, selecting a specific design to achieve that goal is premature. Both of those approaches w

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

On Fri 29/Oct/2021 03:15:10 +0200 Scott Kitterman wrote: On October 29, 2021 12:58:12 AM UTC, John Levine wrote: It appears that Scott Kitterman said: The key is to get the security and privacy considerations documented so that ICANN and ccTLD operators are informed and can set their own ru

[dmarc-ietf] DMARC variations

Hi all, this proposal by some German mailbox providers sounds interesting: https://docs.google.com/document/d/e/2PACX-1vQeodijKJJJPX6fCma3tm00n8m0aJI0VyuO17hKXTy0y7JYUzIxd5Cqh2VSttvJkw-yxWK5fT8NFDcO/pub Note that it "is not directly referencing DMARC as a technology with similar functionalitie

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Tue 19/Oct/2021 02:33:09 +0200 Benny Pedersen wrote: On 2021-10-18 14:11, Alessandro Vesely wrote: Perhaps an RFC could improve the way average MLMs rewrite From:? what is the point of dkim then ? In general, DKIM can pass across simple forwarding, where SPF fails. If used properly

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Sun 17/Oct/2021 20:59:35 +0200 John Levine wrote: According to Baptiste Carvello : Users care about who authored the content, not which machines it was relayed over. A MLM is not just a machine. It is also a context, and often an active filter. If you rewrite From, all you do is bring

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Sun 17/Oct/2021 03:10:21 +0200 Joseph Brennan wrote: Telling mailing list owners and mailing list software designers to violate RFC 5322 Internet message format's description of the From header line to make you happy is abusive. There is no abuse. MLMs act as submitters. Setting From: sh

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Fri 15/Oct/2021 21:33:30 +0200 John Levine wrote: It appears that Baptiste Carvello said: Now, I'm skeptical of your solution. First, I don't think 100% deliverability at all times is a hard requirement. ... Since 100% deliverability at all times does not and cannot exist, it's just as w

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

Hi, On Wed 13/Oct/2021 15:35:52 +0200 Baptiste Carvello wrote: First, I don't think 100% deliverability at all times is a hard requirement. That statement is wrong. I experienced random deliverability when I thoughtlessly enabled ADSP in August 2010[*]. I can testify that deliverability

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Tue 12/Oct/2021 13:42:06 +0200 Douglas Foster wrote: From a security perspective, Ale's proposal is flawless. But I don't like solutions that make the recipient bear most of the costs of the list's actions. Consider sites using p=quarantine; pct=0;. Their mail admin chose to have From:

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

From: rewriting confers 100% deliverability on messages, but has a bad impact on the end user. If we consider collaborative solutions, we see that, because of their very nature, they cannot cover all cases. So, it is safer to look for collaborative solutions that allow unmunging than to solut

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Sun 10/Oct/2021 19:11:34 +0200 Douglas Foster wrote: In opposition, we have mailing lists that claim an unrestricted right to alter messages in transit. A MLM activity is rather akin to publishing than forwarding. There was a time when a pointer to IETF's Note well was added in the footer.

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

It appears that Alessandro Vesely said: >Would it make sense to extend DMARC commitment to the whole From: field? For >example, assert that the local part and the display name have been set by an >authenticated user? (Rather than automatically munged.) All of the mail that comes

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Fri 08/Oct/2021 19:57:59 +0200 Dave Crocker wrote: On 10/8/2021 10:44 AM, Alessandro Vesely wrote: On Fri 08/Oct/2021 18:18:45 +0200 Dave Crocker wrote: Whether signed fields are validated depends on the signing domain's policy. That statement is both true and misleading. DKIM

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Fri 08/Oct/2021 18:18:45 +0200 Dave Crocker wrote: On 10/8/2021 9:09 AM, Scott Kitterman wrote: So originator includes From and Author and signs both.  Then the mediator (e.g. MLM) minges From and signs again.  Receiver checks DMARC and it passes.  Then receiver sends feedback to both Author

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Fri 08/Oct/2021 17:41:58 +0200 Scott Kitterman wrote: On Friday, October 8, 2021 7:59:39 AM EDT Alessandro Vesely wrote: >>> Any mechanism that rewrites the address alone gives a wrong idea of the >>> contact point and thus possibly "hijacks" communication attemp

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Thu 07/Oct/2021 15:58:55 +0200 Baptiste Carvello wrote: (I'm trimming my own message severely to avoid overwhelming the list) Trimming even more, but it's still too long... Mailing list stem from a time where not everything had to be moderated and sanitized. This old Internet with weak

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Thu 07/Oct/2021 11:56:19 +0200 Laura Atkins wrote: On 7 Oct 2021, at 10:37, Alessandro Vesely wrote: On Thu 07/Oct/2021 09:48:12 +0200 Laura Atkins wrote: On 7 Oct 2021, at 01:08, Scott Kitterman wrote: On October 6, 2021 11:37:26 PM UTC, John Levine wrote: It appears that Alessandro

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Thu 07/Oct/2021 09:48:12 +0200 Laura Atkins wrote: On 7 Oct 2021, at 01:08, Scott Kitterman wrote: On October 6, 2021 11:37:26 PM UTC, John Levine wrote: It appears that Alessandro Vesely said: Doug's emphasis on aliases tends to give that impression. Otherwise it can finally be a

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Thu 07/Oct/2021 00:32:30 +0200 Douglas Foster wrote: I can define three ways that a list can be reliably identified. The list bounce address is known to the evaluator, and: - The list bounce address is known to the evaluator and the message is DKIM-signed by the list bounce address. - The lis

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Tue 05/Oct/2021 16:17:28 +0200 Baptiste Carvello wrote: another season, another "From rewriting" proposal. Doug's emphasis on aliases tends to give that impression. Otherwise it can finally be a much needed attempt at formalizing the old, known From: rewriting. A) The From field

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

On Mon 04/Oct/2021 02:17:01 +0200 Douglas Foster wrote: As I hinted in a recent message, I believe that DMARC-compliant mailing lists are possible.   I have posted a draft which explicates how this can be done. Explaining From: rewriting is a good task by itself. Perhaps the draft would be e

Re: [dmarc-ietf] Experiments

On Tue 28/Sep/2021 13:04:19 +0200 Douglas Foster wrote: Stated another way, the problem with ARC is that it requires the evaluator to attribute a positive reputation to the forwarder, in a context where even identifying the forwarder can be difficult. Exactly. To use ARC you need to be a glo

Re: [dmarc-ietf] Experiments

On Mon 27/Sep/2021 21:42:48 +0200 John Levine wrote: It appears that Alessandro Vesely said: There is a case (d) final receiver enforcea DMARC and ARC, but the forwarder is not among its ARC-trusted senders. The simple solution if From: rewriting. I think you misspelled "ugly kludge&q

Re: [dmarc-ietf] Experiments

On Fri 24/Sep/2021 14:57:59 +0200 Douglas Foster wrote: It also highlights the difficulty of being a forwarder.    What to do if a message from a DMARC-enforcing domain sends you a message, does not sign it, and it needs to be forwarded?   If you forward anyway, the final recipient may block th

Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows

On Fri 17/Sep/2021 15:42:12 +0200 Scott Kitterman wrote: On September 17, 2021 1:15:40 PM UTC, Benny Lyne Amorsen wrote: Scott Kitterman writes: How do you define "First Hop" without enabling spoofers to trivially bypass DMARC checks by forging more than one hop of headers? It wouldn't ma

[dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows

TL;DR: p=validate: reject on fail, but only on first hop. New ticket: https://trac.ietf.org/trac/dmarc/ticket/122 It appears that John Levine via Arc wrote: (Yes, it appears, because I cannot be sure --see below) One time I asked one of the authors of ARC why they don't just whitelist mail f

Re: [dmarc-ietf] Round Two: Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

On Fri 10/Sep/2021 04:36:28 +0200 Douglas Foster wrote: - Limited sharing:  Recipient returns SMTP extended status codes related to sender authentication. For those who don't use extended status codes, would it make sense to require the text "DMARC" in the responses that reject according to t

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt

On Wed 01/Sep/2021 14:34:52 +0200 Brotman, Alex wrote: It feels like folks would prefer that the subject be required to be of a specific format to better enable duplicate report processing. Do I understand that correctly? So that would be: If a report generator needs to re-send a repor

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-failure-reporting-02.txt

: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting Authors : Steven M Jones Alessandro Vesely Filename: draft-ietf-dmarc-failure-reporting-02.txt Pages : 11 Date: 2

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-03.txt

On Thu 19/Aug/2021 20:36:08 +0200 Alessandro Vesely wrote: Now it's about dinner time and I'm not willing to program a binary distribution for a decently high number of trials. Today I took the time to compute it. Consider the values of k that are acceptable up to a rounding error

Re: [dmarc-ietf] Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

On Thu 19/Aug/2021 20:23:50 +0200 Todd Herr wrote: Greetings. Opening a discussion on two tickets at once, because I think they're related, especially as presented in the current revision of DMARCbis. Both topics are addressed in Section 8, Minimum Implementations, which currently reads in its

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-03.txt

On Thu 19/Aug/2021 21:37:06 +0200 Todd Herr wrote: On Thu, Aug 19, 2021 at 3:22 PM Murray S. Kucherawy wrote: I agree the parsers won't break from this change, but an operator currently advertising "pct=33" will suddenly stop getting what it thought it was asking for. One could argue that this

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-03.txt

On Thu 19/Aug/2021 14:52:41 +0200 Todd Herr wrote: On Thu, Aug 19, 2021 at 7:19 AM Alessandro Vesely wrote: On Wed 18/Aug/2021 22:17:57 +0200 Todd Herr wrote: The main update in this draft is removal of the "pct" tag, with an explanation as to why, and an introduction of the &qu

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-03.txt

On Wed 18/Aug/2021 22:17:57 +0200 Todd Herr wrote: The main update in this draft is removal of the "pct" tag, with an explanation as to why, and an introduction of the "t" tag in an effort to maintain the functionality provided today by "pct=0" and "pct=100". As held earlier, I disagree wit

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt

On Wed 18/Aug/2021 22:30:06 +0200 Brotman, Alex wrote: If you feel as though something is amiss, or I've misinterpreted the consensus, please let me know. I'd swap SHOULD and MUST between the following sentences: If a report generator needs to re-send a report, the system SHOULD use

Re: [dmarc-ietf] Trac #117

On Sat 14/Aug/2021 16:10:45 +0200 Brotman, Alex wrote: Folks, A ticket was opened to add a "human_result" to the SPF results in the report. As DKIM has similar, I don't necessarily see an issue here. That field addition seems to me to be a due fix. Best Ale -- ___

<    1   2   3   4   5   6   7   8   9   10   >