[dmarc-ietf] Re: PSOs sending mail from their PSD

On Mon 13/May/2024 12:53:14 +0200 Scott Kitterman wrote: On May 13, 2024 7:59:20 AM UTC, Alessandro Vesely wrote: Hi, someone objected to PSDs being unable to receive failure reports even if the PSD is the From: domain. For example: _dmarc.psd.example IN TXT "p=none psd=y ruf=re

[dmarc-ietf] PSOs sending mail from their PSD

Hi, someone objected to PSDs being unable to receive failure reports even if the PSD is the From: domain. For example: _dmarc.psd.example IN TXT "p=none psd=y ruf=reports@psd.example In case a mail having "From: user@psd.example" fails DMARC, couldn't the receiver generate a failure

Re: [dmarc-ietf] Proposal to Enhance Email Trustworthiness via RFC 8617 Modification - ARC

On Tue 23/Apr/2024 17:03:38 +0200 Murray S. Kucherawy wrote: On Mon, Apr 22, 2024 at 4:31 PM John R. Levine wrote: [...] Ale has been proposing ways to undo list modifications for ages, again no interest. > I still think the modification reversal idea is worth investigating, and I've posted

Re: [dmarc-ietf] Thoughts on choosing N

On Sun 21/Apr/2024 16:28:41 +0200 Douglas Foster wrote: Huh? The design is fine: check the exact match domain and then move up to N if more than N labels. The N applies to both original and secondary walks I have legitimate messages with exact match on 6 labels, so there is no reason to

Re: [dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk

On Tue 16/Apr/2024 23:17:44 +0200 Todd Herr wrote: Colleagues, DMARCbis currently describes the value of 'n' for the 'psd' tag in a policy record as follows: The DMARC policy record is published for a PSD, but it is not the Organizational Domain for itself and its subdomain. There is

Re: [dmarc-ietf] Thoughts on choosing N

On Wed 17/Apr/2024 15:42:23 +0200 Todd Herr wrote: On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman wrote: I am confused. Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be found either in this case. Why do we need to support something that is currently unsupported? >>

Re: [dmarc-ietf] Thoughts on choosing N

On Mon 15/Apr/2024 13:16:50 +0200 Douglas Foster wrote: Our original choice of N was based on the PSL.    The PSL could not detect organizational boundaries could not boundaries below level 5, because it had no entries longer than 5 labels, and we determined that the 5-label entries were not

Re: [dmarc-ietf] Overall last-call comments on DMARC

On Thu 04/Apr/2024 18:13:37 +0200 Murray S. Kucherawy wrote: On Thu, Apr 4, 2024 at 8:50 AM Alessandro Vesely wrote: I know what "contract" means abstractly, but what does this actually look like to someone that's looking for specific guidance? The text you have here, by itself

Re: [dmarc-ietf] Overall last-call comments on DMARC

On Wed 03/Apr/2024 18:49:50 +0200 Murray S. Kucherawy wrote: On Wed, Apr 3, 2024 at 4:16 AM Alessandro Vesely wrote: Some sort of contract or agreement between sender and receiver seems to me to be unavoidable if we want to leverage ARC without having a global domain reputation system. We

Re: [dmarc-ietf] Overall last-call comments on DMARC

On 02/04/2024 20:16, Murray S. Kucherawy wrote: On Tue, Apr 2, 2024 at 9:01 AM Alessandro Vesely wrote: By now, most mailing lists arranged to either rewrite From: or not break DKIM signatures. We all hope those hacks are temporary. What do you mean by "temporary", given the t

Re: [dmarc-ietf] RUA XML : maxOccurs="unbounded" not allowed

On Tue 02/Apr/2024 18:41:50 +0200 OLIVIER HUREAU wrote: Hi, I have tried to run some measurements with the new XSD but it seems that it is not valid : ``` xmlschema.validators.exceptions.XMLSchemaParseError: attribute maxOccurs='unbounded': value must be one of [0, 1]: ``` The complex

Re: [dmarc-ietf] Overall last-call comments on DMARC

On Tue 02/Apr/2024 15:35:05 +0200 Murray S. Kucherawy wrote: On Tue, Apr 2, 2024 at 3:01 AM Alessandro Vesely wrote: By now, most mailing lists arranged to either rewrite From: or not break DKIM signatures. We all hope those hacks are temporary. What do you mean by "temporary&qu

Re: [dmarc-ietf] ARC, was WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

On Mon 01/Apr/2024 22:01:22 +0200 Murray S. Kucherawy wrote: On Mon, Apr 1, 2024 at 11:33 AM Todd Herr wrote: [...] Should DMARC-bis reference ARC? I don't know; can it? What I mean by that is that some of us have an interest in DMARC-bis being published as Standards track, and ARC is

Re: [dmarc-ietf] DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

On Tue 02/Apr/2024 10:11:08 +0200 Emanuel Schorsch wrote: Just to add some specifics, since August of 2023 we've gone from seeing ~100 ARC sealers of meaningful volume to over 300 as of yesterday. It is extremely important in our experience to have standard ways of identifying indirect flows.

Re: [dmarc-ietf] Standards Track? Yes or No.

On Tue 02/Apr/2024 07:13:16 +0200 Douglas Foster wrote: Standards track?   Not until we fix the failure inherited from RFC 7489: the untutored evaluator who does not know how to use DMARC results wisely. Doing it all-at-once would expand the time scale unbearably. In addition, we'd need to

Re: [dmarc-ietf] Overall last-call comments on DMARC

On Mon 01/Apr/2024 16:35:28 +0200 Murray S. Kucherawy wrote: On Mon, Apr 1, 2024 at 4:44 AM Alessandro Vesely wrote: * Mailing lists — Mailing list operators, including ietf.org, have had to implement rewriting of From addresses such as u...@example.com becomes user=40example

Re: [dmarc-ietf] Overall last-call comments on DMARC

Let me add a few comments that seem obvious to me. On Mon 01/Apr/2024 04:00:03 +0200 Jim Fenton wrote: In addition to the editorial review I have provided, I have significant concerns regarding the standardization of DMARC-bis. I do not expect that the working group rough consensus will

Re: [dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

On Mon 01/Apr/2024 11:20:06 +0200 Tero Kivinen wrote: Alessandro Vesely writes: On Sun 31/Mar/2024 14:22:04 +0200 Douglas Foster wrote: On SPF, our document should say simply, " a DMARC-compliant evaluator MUST NOT reject a message, based on SPF result, prior to receiving the Data se

Re: [dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

On Sun 31/Mar/2024 22:33:10 +0200 Murray S. Kucherawy wrote: On Sun, Mar 31, 2024 at 9:32 AM Alessandro Vesely wrote: On Sun 31/Mar/2024 14:22:04 +0200 Douglas Foster wrote: On SPF, our document should say simply, " a DMARC-compliant evaluator MUST NOT reject a message, based on SPF r

Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30

On Sun 31/Mar/2024 22:27:21 +0200 Seth Blank wrote: I’m saying, as an individual, that there was a thread where we discussed a new N for the tree walk. There was appetite, but no new N was settled on. Maybe we just need to leave some leeway to implementers. Another doubt when going to

Re: [dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

On Sun 31/Mar/2024 18:50:16 +0200 Mark Alley wrote: On 3/31/2024 11:32 AM, Alessandro Vesely wrote:   People who publish -all know what they do. I posit that there is a non-insignificant amount of domain owners that don't know what the consequences of -all are other than that they've been

Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30

On Sun 31/Mar/2024 18:43:53 +0200 Scott Kitterman wrote: On March 31, 2024 3:20:41 PM UTC, Jim Fenton wrote: On 30 Mar 2024, at 17:22, John R. Levine wrote: Mine wasn’t a good example. There are a few public suffixes that have more than 5 labels. Presumably that means there are registered

Re: [dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

On Sun 31/Mar/2024 14:22:04 +0200 Douglas Foster wrote: On SPF, our document should say simply, " a DMARC-compliant evaluator MUST NOT reject a message, based on SPF result, prior to receiving the Data section and checking for aligned and verifiable signatures." Nonsense. Rejecting at RCPT

Re: [dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

On Sat 30/Mar/2024 21:05:17 +0100 Seth Blank wrote: This is a real operational problem, so I wanted to expand guidance. The note about best practice may or may not be appropriate here, but I think it works. There are multiple M3AAWG documents which cover this use case, and we can also link

Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30

On Sat 30/Mar/2024 17:56:53 +0100 Jim Fenton wrote: On 30 Mar 2024, at 7:43, Alessandro Vesely wrote: On Sat 30/Mar/2024 04:09:10 +0100 Jim Fenton wrote: I’m concerned that some (admittedly rare) public suffixes with multiple components are not well served by this algorithm, such as pvt.k12

Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30

On Sat 30/Mar/2024 04:09:10 +0100 Jim Fenton wrote: [...] I’m concerned that some (admittedly rare) public suffixes with multiple components are not well served by this algorithm, such as pvt.k12.ma.us. Is there something peculiar with this domain? Please expand. What happens if a

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

On Wed 27/Mar/2024 13:17:57 +0100 Matthäus Wander wrote: Alessandro Vesely wrote on 2024-03-27 10:00: I'm not clear what will that schema be used for, if at all.  Personally, the only reason why I'd prefer the long regex is because it might have some value by itself.  The short one is cleaner

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

On Tue 26/Mar/2024 21:57:46 +0100 Matthäus Wander wrote: Alessandro Vesely wrote on 2024-03-26 19:30: No.  To take several years and come up with a syntax which does not cover all valid addresses is a sign of incompetence that this WG doesn't deserve, IMHO. What do others think? Let's rather

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

On Tue 26/Mar/2024 16:18:31 +0100 John R Levine wrote:   ::00::12.34.56.78   0:0:0:0:0:0::012.034.056.078 The latter yields failure running the example program in the inet_pton(3) man page.  See e.g. https://www.man7.org/linux/man-pages/man3/inet_pton.3.html#EXAMPLES My bad.

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

On Mon 25/Mar/2024 18:54:14 +0100 John R Levine wrote: On Mon, 25 Mar 2024, Alessandro Vesely wrote: How about: "(:::)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/> Testing yielded a correct fix:   "(::[Ff]{4}:)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3

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

On Sun 24/Mar/2024 13:33:22 +0100 Alessandro Vesely wrote: On Sat 23/Mar/2024 19:53:39 +0100 John Levine wrote: It appears that Murray S. Kucherawy  said: -=-=-=-=-=- This seems like it's probably legitimate.  Does it need to be fixed in the -bis document? It's already fixed in the current

Re: [dmarc-ietf] Errata for Aggregate Reporting

On Sun 24/Mar/2024 18:06:53 +0100 John Levine wrote: It appears that Brotman, Alex said: https://www.rfc-editor.org/errata/eid5774 :: There were a number of edits for clarification to this portion of the document. The "otherwise specified" language is no longer there, and I believe all

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

On Sat 23/Mar/2024 19:53:39 +0100 John Levine wrote: It appears that Murray S. Kucherawy said: -=-=-=-=-=- This seems like it's probably legitimate. Does it need to be fixed in the -bis document? It's already fixed in the current markdown. FYI, the XML pattern is silly. It forbids

Re: [dmarc-ietf] of course no DMARC result for DKIM testing and policy

On Fri 22/Mar/2024 19:22:10 +0100 John R. Levine wrote: While I generally agree, DMARC for the last decade didn't have a testing flag.  That's new in DMARCbis, so I don't think that's really germane. This particular thing is on us as a working group. RFC 6376 makes it quite clear on page 28

Re: [dmarc-ietf] Policy Override in aggregate-reporting

On Fri 22/Mar/2024 23:23:55 +0100 Matthäus Wander wrote: RFC7489 contains a description of the possible PolicyOverrideType values: While aggregate-reporting-14 uses the same set of values, the description is missing. I suggest to add it

Re: [dmarc-ietf] DMARC result for DKIM testing and policy

On Wed 20/Mar/2024 23:11:20 +0100 Matthäus Wander wrote: Alessandro Vesely wrote on 2024-03-20 15:42: what is the result of DMARC on having, say dkim=pass (testing key) or dkim=policy (512 byte key) is that akin to SPF neutral, i.e. dmarc=fail? dkim=pass results in dmarc=pass

[dmarc-ietf] DMARC result for DKIM testing and policy

Hi, what is the result of DMARC on having, say dkim=pass (testing key) or dkim=policy (512 byte key) is that akin to SPF neutral, i.e. dmarc=fail? Best Ale -- ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

On Tue 19/Mar/2024 12:33:07 +0100 Scott Kitterman wrote: On Tuesday, March 19, 2024 5:23:52 AM EDT Alessandro Vesely wrote: On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote: > On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote: On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wr

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote: On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote: On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote: On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote: On Sun, 17 Mar 2024, Dotzero wrote: Whenever mail is sent

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote: On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote: On Sun, 17 Mar 2024, Dotzero wrote: Whenever mail is sent, there is a risk that an overly permissive source may send mail which will receive a DMARC pass result that was not, in fact,

Re: [dmarc-ietf] General Purpose Domain

On Mon 18/Mar/2024 15:24:34 +0100 Todd Herr wrote: Issue 137 has been opened for this. On Mon, Mar 18, 2024 at 9:50 AM Todd Herr wrote: On Sun, Mar 17, 2024 at 7:17 AM Alessandro Vesely wrote: On Sat 16/Mar/2024 21:07:53 +0100 Neil Anuskiewicz wrote: Unless I’m misunderstanding, a General

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

tion, Reporting, and Conformance (DMARC) Failure Reporting Authors: Steven M Jones Alessandro Vesely Name:draft-ietf-dmarc-failure-reporting-10.txt Pages: 16 Dates: 2024-03-17 However we close the fifth point of issue 133[*], I added a new paragraph to del

Re: [dmarc-ietf] General Purpose Domain

On Sat 16/Mar/2024 21:07:53 +0100 Neil Anuskiewicz wrote: Unless I’m misunderstanding, a General Purpose Domain is a separate domain or at least subdomain: Doesn't have to be a subdomain. It is a domain which has human mail users. Best Ale --

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

On Sat 16/Mar/2024 20:01:22 +0100 Scott Kitterman wrote: On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote: On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote: Issue 135 is open for the subject topic. Please add your thoughts to this thread and/or to the issue in

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

On Fri 15/Mar/2024 02:34:15 +0100 Murray S. Kucherawy wrote: On Fri, Mar 15, 2024 at 9:11 AM John Levine wrote: It appears that Todd Herr said: >I agree that clarifying it can't hurt, obviously, ... I disagree, it does hurt. If we say you're allowed to use CNAMEs to point to DMARC

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thu 14/Mar/2024 20:23:01 +0100 John Levine wrote: It appears that Scott Kitterman said: SPF it treated in multiple places. We cannot warn against a bad practice in one place (135) and recommend it unconditionally in another (132). That is exactly how one handles Security Considerations.

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

On 14/03/2024 19:06, Matt V wrote: On Thu, Mar 14, 2024 at 10:55 AM Alessandro Vesely wrote: On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote: On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely wrote: On 12/03/2024 03:18, Neil Anuskiewicz wrote: Please remove the pct tag from the spec

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thu 14/Mar/2024 18:35:05 +0100 Scott Kitterman wrote: On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote: On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote: [...] In the ticket, I propose the following replacement text

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

On Thu 14/Mar/2024 16:44:22 +0100 Todd Herr wrote: Issue 135 is open for the subject topic. Please add your thoughts to this thread and/or to the issue in Github. I proposed an alternative text for section 5, Policy[*]. I repeat it here with an added sentence: OLD A Domain Owner or

Re: [dmarc-ietf] Problem with multiple policies, different alignment

On Thu 14/Mar/2024 12:17:17 +0100 Douglas Foster wrote: Your latter questions were similar to Ale's - If the SPF/DKIM domain is a parent of the From domain, then we check its relationship to the organizational domain. If it is a parent of the organizational domain, the result is unaligned.

Re: [dmarc-ietf] DMARCbis WGLC Issue 134 - What To Do With Appendix A.5?

On Thu 14/Mar/2024 15:53:30 +0100 Todd Herr wrote: Colleagues, Two people have spoken up on list asking for removal of this section (thread subject is "A.5 Issues with ADSP in Operation") while one person has registered opposition to the idea. I don't believe this is anywhere close to critical

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote: [...] In the ticket, I propose the following replacement text: == Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to take full advantage of DMARC, a Domain Owner MUST first

Re: [dmarc-ietf] picking nits with the ABNF

On Thu 14/Mar/2024 15:38:23 +0100 Todd Herr wrote: To summarize this thread, I see three nits, all of which have been added to issue 133: 1. Section 5.4, Formal Definition, reword the comments for dmarc-uri to be: ; "URI" is imported from [RFC3986]; ; commas (ASCII

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote: On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely wrote: On 12/03/2024 03:18, Neil Anuskiewicz wrote: > Please remove the pct tag from the spec. It has been removed already, which is incompatible with current records. I don't believe y

Re: [dmarc-ietf] Problem with multiple policies, different alignment

On Wed 13/Mar/2024 11:23:43 +0100 Douglas Foster wrote: The reality is that the Tree Walk is an inefficient and unreliable way of obtaining an answer, particularly because of the risk of DNS timeouts. As a result, the Tree Walk should be avoided whenever possible. In fact, the secondary

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

On 12/03/2024 03:18, Neil Anuskiewicz wrote: Please remove the pct tag from the spec. It has been removed already, which is incompatible with current records. Best Ale -- ___ dmarc mailing list dmarc@ietf.org

[dmarc-ietf] Appendix B.2.3. Per-Message Failure Reports Directed to Third Party

Hi, it would be much more real-life to exemplify directing /aggregate/ reports to third parties, which is quite common. Directing failure reports to third parties would be a privacy nightmare. I'd suggest turning the subsection from ruf= to rua=. Indeed, the spec for Verifying External

[dmarc-ietf] Nit: Appendix B.1, examples parallelism and typo

Hi, first the typo. Example 3 in appendix B.1.2 uses sample.net (an existing domain) instead of example.net: DKIM-Signature: v=1; ...; d=sample.net; ... Second, Example 2 is labelled "parent" in both SPF and DKIM subsections. However, for SPF the identifier is a child of the From:

Re: [dmarc-ietf] picking nits with the ABNF

On 10/03/2024 05:34, Tim Wicinski wrote: On Sat, Mar 9, 2024 at 10:33 PM OLIVIER HUREAU wrote: [...] I would also add comment about the dmarc-fo ABNF : dmarc-fo = "0" / "1" / "d" / "s" / "d:s" / "s:d" The FO paragraph (

[dmarc-ietf] A.5 Issues with ADSP in Operation

Hi, as ADSP is historical, perhaps we can strike A5 entirely. If not, we should at least eliminate bullet 5: 5. ADSP has no support for a slow rollout, i.e., no way to configure a percentage of email on which the Mail Receiver should apply the policy. This is important for

[dmarc-ietf] Nit: missing angle brackets

Hi, this is section 11.4, Display Name Attacks. It has: From: "u...@example.org via Bug Tracker" supp...@example.com (mailto:supp...@example.com) Should be: From: "u...@example.org via Bug Tracker" (mailto:supp...@example.com) Or even From: " via Bug Tracker"

Re: [dmarc-ietf] Another point for SPF advice

On 08/03/2024 18:45, Hector Santos wrote: I believe it is correct, SHOULD strive to trusted known sources. The final mechanism SHOULD be one of (hard) failure. This is what we (ideally) strive for. I believe anything weaker is a waste of computational resources, causes confusion using

[dmarc-ietf] Section 9.5 DMARC Report Format Registry

Hi, since we removed the rf= tag (format of failure reports), do we still need to tackle the IANA registry? Since we only use one format, it makes little sense. However, the registry actually exists. Is it possible to delete or obsolete it, or does it have to stay there as a relict for

Re: [dmarc-ietf] Another point for SPF advice

On 05/03/2024 17:07, Scott Kitterman wrote: On March 5, 2024 3:46:39 PM UTC, Alessandro Vesely wrote: Todd Herr writes: On Tue, Mar 5, 2024 at 9:30 AM Alessandro Vesely wrote: in section 5.5.1, Publish an SPF Policy for an Aligned Domain, the last sentence says

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

On 06/03/2024 15:42, Todd Herr wrote: On Tue, Mar 5, 2024 at 10:45 PM Barry Leiba wrote: SHOULD NOT was the consensus call, and the correction Todd proposes is just making that sentence consistent with that. Yet, Section 7.6 still has: In particular, this document makes explicit that

Re: [dmarc-ietf] DMARCbis WGLC Issue - Clarify When Tree Walk Starts?

On 06/03/2024 21:00, Todd Herr wrote: Section 4.7, DMARC Policy Discovery, starts with the following sentence: For policy discovery, a DNS Tree Walk starts at the domain found in the RFC5322.From header of the message being evaluated. I think the above is muddy, [...] When it comes

Re: [dmarc-ietf] The description of psd=n

On 05/03/2024 21:47, Scott Kitterman wrote: On March 5, 2024 8:10:46 PM UTC, Todd Herr wrote: On Tue, Mar 5, 2024 at 1:30 PM Scott Kitterman wrote: On March 5, 2024 2:47:47 PM UTC, Todd Herr wrote: On Tue, Mar 5, 2024 at 6:12 AM Alessandro Vesely wrote: Section 5.3, in the format

Re: [dmarc-ietf] Another point for SPF advice

Todd Herr writes: On Tue, Mar 5, 2024 at 9:30 AM Alessandro Vesely wrote: in section 5.5.1, Publish an SPF Policy for an Aligned Domain, the last sentence says: The SPF record SHOULD be constructed at a minimum to ensure an SPF pass verdict for all

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

Todd Herr writes: On Tue, Mar 5, 2024 at 10:12 AM Alessandro Vesely wrote: Hey, Section 5.5 misses a subsection about /creating/ reports. [...] I don't see a role for Domain Owners in creating reports. Domain Owners are the ones publishing DMARC policy records and sending mail

[dmarc-ietf] 5.5. Domain Owner Actions

Hey, Section 5.5 misses a subsection about /creating/ reports. We want DMARC to be a cooperative tool, don't we? I'd insert such a subsection before "5.5.6 Decide Whether to Update DMARC Policy", as a typical timeline may see the policy updates quite late, given the mailing list

[dmarc-ietf] Another point for SPF advice

Hi, in section 5.5.1, Publish an SPF Policy for an Aligned Domain, the last sentence says: The SPF record SHOULD be constructed at a minimum to ensure an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom domain. As we learnt, an

[dmarc-ietf] The description of psd=n

Hi, Section 5.3, in the format description of psd: n: The DMARC policy record is published for a PSD, but it is the Organizational Domain for itself and its subdomain. There is no need to put psd=n in a DMARC record, except in the very unusual case of a parent

[dmarc-ietf] A possible point for SPF advice

Hi, Section 5 has a paragraph that can fit Scott's solution to SPF spoofing. Here's a possible change: OLD 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

Re: [dmarc-ietf] DISCARD: 4.3. Authentication Mechanisms

Sorry, I've been fooled by the page break. Alessandro Vesely writes: Hi, it is not true that DMARC relies solely on SPF authentication. OLD * SPF, [RFC7208], which can authenticate both the domain found in an SMTP [RFC5321] HELO/EHLO command (the HELO identity

[dmarc-ietf] 4.3. Authentication Mechanisms

Hi, it is not true that DMARC relies solely on SPF authentication. OLD * SPF, [RFC7208], which can authenticate both the domain found in an SMTP [RFC5321] HELO/EHLO command (the HELO identity) and the domain found in an SMTP MAIL command (the MAIL FROM identity). As noted

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

On Sun 11/Feb/2024 01:47:12 +0100 Scott Kitterman wrote: On Saturday, February 10, 2024 7:39:37 PM EST Murray S. Kucherawy wrote: On Sat, Feb 10, 2024 at 12:34 PM Jim Fenton wrote: This actually concerns me a bit. If having multiple From: addresses causes a message to be out of scope for

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

On Tue 06/Feb/2024 07:22:49 +0100 Murray S. Kucherawy wrote: On Mon, Feb 5, 2024 at 10:22 AM Alessandro Vesely wrote: On 05/02/2024 00:29, Murray S. Kucherawy wrote: On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely wrote: RFC 7489 says this: In order to be processed by DMARC

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

On 05/02/2024 00:29, Murray S. Kucherawy wrote: On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely wrote: What do we think has changed since then that warrants reconsidering that position? Have we started to see multi-value From attacks? A DMARC filter has to do something when it sees

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

On Sat 03/Feb/2024 21:44:42 +0100 Murray S. Kucherawy wrote: On Sun, Jan 28, 2024 at 5:40 AM Alessandro Vesely wrote: I think this point about alignment of Sender is definitely correct, Let's also recall there was a proposal to consider Sender: anyway. And also let's recall

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

. On Sat, Feb 3, 2024 at 8:08 AM Alessandro Vesely wrote: On Sun 28/Jan/2024 14:39:55 +0100 I wrote: [...] To handle appropriately means receivers are on their own w.r.t DMARC.) It is a hole: > From: presid...@whitehouse.gov , user@attackdomain [...] For Sender:, instead, we need to a

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

On Sun 28/Jan/2024 14:39:55 +0100 I wrote: [...] To handle appropriately means receivers are on their own w.r.t DMARC.) It is a hole: >     From: presid...@whitehouse.gov , user@attackdomain [...] For Sender:, instead, we need to also require that the aligned domain be the one of the _first_

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

On Sat 27/Jan/2024 16:13:08 +0100 Scott Kitterman wrote: On Saturday, January 27, 2024 8:00:24 AM EST Alessandro Vesely wrote: Ignoring, as Section 11.5 points out, exposes an attack vector that must be taken into consideration. That section says: [C]are must be taken by the receiving

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

On Fri 19/Jan/2024 18:00:35 +0100 Hector Santos wrote: On Jan 19, 2024, at 10:19 AM, Todd Herr wrote: Perhaps the way forward for DMARC is to look for a Sender header when there is more than one RFC5322.From domain and use that for DMARC processing, with the stipulation that messages that

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

On Tue 16/Jan/2024 19:24:29 +0100 Murray S. Kucherawy wrote: On Tue, Jan 16, 2024 at 2:03 AM Alessandro Vesely wrote: On Mon 15/Jan/2024 20:49:35 +0100 John Levine wrote: It appears that Scott Kitterman said: I don't think that's sensible at all. It's not the place of a signing filter

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

On Mon 15/Jan/2024 20:49:35 +0100 John Levine wrote: It appears that Scott Kitterman said: I don't think that's sensible at all. It's not the place of a signing filter to modify the message. A signing filter, as part of an MSA _has to_ modify the message in order to enhance the

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

On 11/01/2024 18:15, Todd Herr wrote: On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre wrote: https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1 "The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. The process in this case is to apply

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

On 02/01/2024 21:47, Mark Alley wrote: Actually, thinking about it some more, simply inserting the word "aligned" between "valid" and "DKIM" would address it. "/It is therefore critical that domains that publish p=reject *MUST NOT* rely solely on SPF to secure a DMARC pass, and *MUST *apply

Re: [dmarc-ietf] DMARCbis rev 29

On Fri 01/Dec/2023 21:06:24 +0100 Steven M Jones wrote: There are only four open items on the issue tracker - though I think the SPF question (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/116) was resolved. But is that really all there is to do? I'd hope most of the

Re: [dmarc-ietf] DMARC marketing on NPR

On Thu 23/Nov/2023 16:41:11 +0100 Dotzero wrote: On Thu, Nov 23, 2023 at 10:19 AM Douglas Foster wrote: The gap between what is being attempted and what is needed is a huge personal disappointment. [...] This is from a real-world conversation with a product support tech: Me: I cannot use

Re: [dmarc-ietf] DMARC marketing on NPR

itions. That silence leads product developers and mail administrators to conclude that the algorithm can be implemented without allowing for exceptions. Why would we expect a different result? Withheld information can deceive. On Wed, Nov 22, 2023, 5:14 AM Alessandro Vesely wrote: On Wed 22/Nov/2

Re: [dmarc-ietf] DMARC marketing on NPR

On Wed 22/Nov/2023 00:51:24 +0100 Jim Fenton wrote: I see that the DMARC marketing machine is hard at work. There was an item on NPR (National Public Radio) “All Things Considered” this afternoon heavily promoting DMARC:

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

On Thu 16/Nov/2023 16:47:48 +0100 Olivier Hureau wrote: On 15/11/2023 14:22, Alessandro Vesely wrote: We've had quite some discussion on that scheme, which resulted in https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/blob/main/dmarc-xml-0.2.xsd included in the current

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

On Tue 14/Nov/2023 20:09:52 +0100 John Levine wrote: Thanks for doing this work. It cleans up a messy corner of DMARC. It appears that OLIVIER HUREAU said: I was personally thinking about the following options: 1) Specify Version "2" ... 2) Explore a JSON Format for Aggregated Reports:

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

On Sun 12/Nov/2023 09:26:32 +0100 Richard Clayton wrote: In message <55dc7b67-e48a-4eb3-9cdc-4e4319cc7...@marmot-tech.com>, Neil Anuskiewicz writes I have a feeling the die is cast for failure reports from MBPs. I’m curious to learn if they sent legit failures, which has scared off

Re: [dmarc-ietf] Dmarcbis way forward

On Sat 11/Nov/2023 14:57:12 +0100 Neil Anuskiewicz wrote: On Oct 23, 2023, at 11:00 AM, Alessandro Vesely wrote: My opinion is that Barry's text is good as is. As far as delimiting a SHOULD NOT with another SHOULD is legit, this sentence sounds clear to me: It is therefore critical

Re: [dmarc-ietf] Codifying "Apex Domain"?

On Thu 09/Nov/2023 15:39:50 +0100 Todd Herr wrote: My question here is, should DMARCbis at least mention the term "apex domain", perhaps in section 3.2.9, Organizational Domain. The entirety of that section currently reads: The Organizational Domain for any domain is determined by

Re: [dmarc-ietf] Well, that was amusing

On Wed 08/Nov/2023 13:59:14 +0100 Damian Lukowski wrote: How is iecc.com affiliated with this mailing list? Can its Authentication-Results header be trusted? It's my own server so it depends on how much you trust me. If the Authentication-Results header is trustworthy, one could notify

Re: [dmarc-ietf] Well, that was amusing

On Mon 06/Nov/2023 21:48:53 +0100 John R Levine wrote: Low budget spam to the DMARC list that happened to fake my name and address on the From: line. If this happened more than once every five years, I might consider publishing a DMARC policy. That message had an AMSL Received: line which

Re: [dmarc-ietf] Question on RFC7489: trailing whitespaces

On Thu 02/Nov/2023 12:17:30 +0100 Olivier Hureau wrote: It is also related to one of the discussion I opened about duplicate tag : https://mailarchive.ietf.org/arch/msg/dmarc/NAWZlMNnXt9m_MCvuou9IiYxSrA/ Murray pointed out that a parser is also supposed to follow the DKIM specifications.

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

On Sun 29/Oct/2023 21:03:17 +0100 Mark Alley wrote: Giving this some more thought from the opposite point of view... the benefits to an auth=DKIM method in DMARC itself would remove the need for domain owners to do SPF tinkering for any upgrade mitigation, and shared mail infrastructure where

  1   2   3   4   5   6   7   8   9   10   >