[dmarc-ietf] Re: Review of the dmarc draft documents

On Tue, Sep 10, 2024 at 11:16 AM John Levine wrote: > As a native speaker who has written a lot of books, I can say that no > matter how hard I try to get the grammar and spelling right, I always > miss stuff that they find and fix. > I once told the RFC Editor that my goal in life is to get one

[dmarc-ietf] Re: DMARCbis version -33 is ready for document shepherd and AD processing

On Thu, Aug 8, 2024 at 11:14 PM Murray S. Kucherawy wrote: > On Thu, Aug 8, 2024 at 11:58 AM Barry Leiba > wrote: > >> I've asked the document shepherd (Tim Wicinski, and thanks for >> volunteering to handle this!) to do his final review and get the >> writeup do

[dmarc-ietf] Re: DMARCbis version -33 is ready for document shepherd and AD processing

On Thu, Aug 8, 2024 at 11:58 AM Barry Leiba wrote: > I've asked the document shepherd (Tim Wicinski, and thanks for > volunteering to handle this!) to do his final review and get the > writeup done, and I've alerted Murray that it's coming soon. I hope > those next steps will happen very soon. >

[dmarc-ietf] Re: Proxy signatures to combat SPF upgrade?

On Fri, Jun 7, 2024 at 1:14 AM Richard Clayton wrote: > >Is this worth standardizing as a best practice (in a future document)? > > Since the WG declined to provide an indicator for "ignore SPF when there > is a valid aligned DKIM signature" I doubt this has much chance of > widespread approval,

[dmarc-ietf] Fwd: WG Action: Formed Mail Maintenance (mailmaint)

FYI -- Forwarded message - From: IESG Secretary Date: Thu, May 9, 2024 at 1:01 PM Subject: WG Action: Formed Mail Maintenance (mailmaint) To: IETF Announcement List Cc: , , A new IETF WG has been formed in the Applications and Real-Time Area. For additional information, please

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

I have a slightly different viewpoint: On Mon, Apr 22, 2024 at 4:31 PM John R. Levine wrote: > Since nobody else responded, here's my tl;dr -- interesting proposal, but > no. > > The first problem is that there is no appetite to change ARC at this point. > Agreed. That was a long list of sugge

[dmarc-ietf] Fwd: WG Review: Mail Maintenance (mailmaint)

FYI only. Please don't discuss this here; send feedback to me directly or to i...@ietf.org. -MSK, ART AD -- Forwarded message - From: The IESG Date: Fri, Apr 19, 2024 at 10:25 AM Subject: WG Review: Mail Maintenance (mailmaint) To: IETF-Announce A new IETF WG has been propose

Re: [dmarc-ietf] Thoughts on choosing N

On Mon, Apr 15, 2024 at 7:02 AM Todd Herr wrote: > > I would propose the following first draft of expository text regarding > setting N at 8: > > The point of the Tree Walk is to allow for the publishing and discovery of > DMARC policy records at any level in the DNS hierarchy that strikes a > ba

Re: [dmarc-ietf] the long march, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

On Sun, Apr 7, 2024 at 10:33 AM Scott Kitterman wrote: > >Seth says there are people who need N=8 but for business reasons he can't > tell us who they are. I'm not thrilled about that but I see little > downside to bumping the number up to 8. > > I expect that's where we end up, but I think we n

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

On Thu, Apr 4, 2024 at 12:02 PM Dotzero wrote: > > >> >> My overall point is that this thread makes it seem like we're not putting >> forward a complete solution. It feels a lot more like a proposed standard >> that for its clear success depends on a bunch of other things that range >> from expe

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

On Thu, Apr 4, 2024 at 10:21 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Murray, I was hoping your proposal to advance ARC was serious. > If people think (and have evidence that) ARC is ready, then why would I not be serious? The WG needs to resolve that "if" though. > To

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

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, is vague and I don't think many operators will know > what > >

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

On Wed, Apr 3, 2024 at 4:16 AM Alessandro Vesely wrote: > > So what are you suggesting should go in this document that's in WGLC? > > Section 8.6 states the ML problem very well, but it says nothing about the > way forward. Here, we agree. And I'm saying: If we have anything concrete we can sa

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

On Tue, Apr 2, 2024 at 9:03 AM Seth Blank wrote: > > I think details about the technique to which you're alluding, especially >> with real world examples, anecdotes, or other data, would be really >> valuable to publish somewhere, be that in this document or elsewhere. Even >> just a paragraph t

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

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 time scales that have > already > >>> pa

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

On Tue, Apr 2, 2024 at 8:49 AM John Levine wrote: > It appears that Murray S. Kucherawy said: > >Can you give an example, even if only a hypothetical one? > > I'm not Emmanuel but people at large mail systems have told me that > the biggest value of ARC is to deal wit

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

Hi Emanuel, On Tue, Apr 2, 2024 at 1:02 AM Emanuel Schorsch wrote: > Just to chime in, Gmail is using ARC and it has already provided a large > amount of value for the indirect flow problem. Especially, since other > major providers and a number of forwarders are adding ARC headers that > provid

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

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", given the time scales that have already > > passed since

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

On Mon, Apr 1, 2024 at 4:05 PM John Levine wrote: > >"One possible mitigation to problem X is [ARC], which provides for a > >mechanism to demonstrate 'chain-of-custody' of a message. However, use of > >ARC is nascent, as is industry experience with it in connection with > DMARC." > > Generally OK

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

On Mon, Apr 1, 2024 at 11:33 AM Todd Herr wrote: > The second document also recommends that receivers "Make use of ARC > headers", but I do not believe that ARC header consumption is yet > widespread enough to consider that recommendation to be commonly > implemented. I myself am not a receiver,

Re: [dmarc-ietf] WGLC contentious topics (I'm in the rough and I know it) in draft-ietf-dmarc-dmarcbis-30

On Sun, Mar 31, 2024 at 6:37 PM Seth Blank wrote: > "It is therefore critical that domains that host users who might post > messages to mailing lists SHOULD NOT publish p=reject." > > [...] > > More accurate language that alleviates the concern would be "It is > therefore critical that domains th

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

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@dmarc.ietf.org when a p=strict or p=quarantine > policy is in >

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

On Sun, Mar 31, 2024 at 3:28 PM Richard Clayton wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > In message 7...@mail.gmail.com>, Seth Blank > writes > > >Some Mail Receiver architectures implement SPF in advance of any > >DMARC operations. This means that an SPF hard fail (

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

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 > result, > > prior to receiving the Data section and checking f

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

On Sun, Mar 31, 2024 at 5:22 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> 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 sig

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

On only the charter point: On Sat, Mar 30, 2024 at 2:27 PM Jim Fenton wrote: > > >> ??? Not Found > >> - > >> > >> I expected to find some text at least recommending a rewriting strategy > for From addresses to be used by mailing lists and the like. > > > > That would be extremely ou

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

This seems like it's probably legitimate. Does it need to be fixed in the -bis document? -MSK -- Forwarded message - From: RFC Errata System Date: Sat, Mar 23, 2024 at 8:04 AM Subject: [Technical Errata Reported] RFC7489 (7865) To: , , Cc: , The following errata report has b

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

On Fri, Mar 22, 2024 at 12:59 AM Scott Kitterman wrote: > >> For t=y, DKIM says: > >> > >>y This domain is testing DKIM. Verifiers MUST NOT treat > messages > >> from Signers in testing mode differently from unsigned email, > >> even should the signature fail to veri

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

On Mon, Mar 18, 2024 at 1:08 PM Dotzero wrote: > > Add this to 11.1 Authentication Methods >> >> >> Both of the email authentication methods that underlie DMARC provide >> some assurance that an email was transmitted by an MTA which is >> authorized to do so. SPF policies map domain names to sets

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

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 records, > people are to say uh oh, is there something special

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

On Fri, Mar 15, 2024 at 12: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. > >> > >> It has been re

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

On Fri, Mar 15, 2024 at 3:20 AM John Levine wrote: > As an author of the ADSP RFC, I enthusiastically support dropping it > into the memory hole. It was a bad idea then and time has not improved > it. I tend to agree. That appendix was meant to answer the question "Why DMARC and not ADSP?" but

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

On Thu, Mar 14, 2024 at 9:17 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > All of this is based on my slightly confrontational comment that "Tree > Walk is inefficient and unreliable", which maybe needs elaboration. My > approach to the problem changed dramatically when I dis

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

On Tue, Mar 12, 2024 at 6:23 AM Tobias Herkula wrote: > The DMARC Record on the DKIM signing domain is not relevant for DMARC > evaluation, so if the 5322.From header domain is “example.com” the > “adkim:r” is relevant for evaluation regarding your example setup and would > consider a DKIM signat

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

On Sat, Mar 9, 2024 at 4:00 PM Tim Wicinski wrote: > Just picking over the ABNF with my checks, some Qs > > dmarc-version = "v" equals %s"DMARC1 > > > I believe the "%s" should be dropped > I think this was intentional; we want "v=DMARC1" to be valid and "v=dmarc1" to be not valid. Unless I'm r

Re: [dmarc-ietf] Section 9.5 DMARC Report Format Registry

On Fri, Mar 8, 2024 at 6:49 AM Alessandro Vesely wrote: > 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 obsole

[dmarc-ietf] SHOULD (was Re: Another point for SPF advice)

Heads up that I'm going to be looking carefully at use of "SHOULD" throughout the document when it comes to AD Evaluation. An example that gave me pause: On Tue, Mar 5, 2024 at 6:30 AM Alessandro Vesely wrote: > in section 5.5.1, Publish an SPF Policy for an Aligned Domain, the last > sentence

Re: [dmarc-ietf] Fwd: [Editorial Errata Reported] RFC7489 (7835)

On Wed, Mar 6, 2024 at 11:42 AM Todd Herr wrote: > The text reported in the erratum doesn't really exist in DMARCbis; it's > been replaced by the DNS Tree Walk ( > https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-dns-tree-walk > ) > > Are we to issue an actual update to RFC

[dmarc-ietf] Fwd: [Editorial Errata Reported] RFC7489 (7835)

Since we're in WGLC here, this erratum is worth consideration. I've recommended "Held For Document Update" as the disposition. My reply to the erratum was: === The algorithm as presented is correct, but I understand this report. The steps are, paraphrased: (1) Go get a set of things. (2) Fil

Re: [dmarc-ietf] DMARCbis WGLC Issue - Description of rua and ruf Tags

On Fri, Mar 1, 2024 at 5:20 PM Seth Blank wrote: > mailto: is the only function that's ever been used. We even discussed > exploring other mechanisms, and consensus was to drop that exploration. I > can't find the ticket quickly, but I know it was covered early on during > the bis work. > > Do we

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

On Thu, Feb 29, 2024 at 2:14 PM Seth Blank wrote: > As Chair: Consensus was already called. Todd just wants the wording > consistent in the document. There's no need for another decision here. > This is my understanding as well. Mike Hammer summarized it neatly. -MSK __

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

On Sat, Feb 10, 2024 at 12:34 PM Jim Fenton wrote: > > No, it's perfectly fine to declare that DMARC only applies to certain > > classes of messages. > > This actually concerns me a bit. If having multiple From: addresses causes > a message to be out of scope for DMARC and therefore bypass a p=re

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

icating that when a DKIM > Signature is missing it should be treated as an error. > > There is currently no way to indicate that. > Why is DMARC the right place to fix that problem? It seems like you want a way to assert this even if the receiver isn't. using DMARC. >

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

On Tue, Feb 6, 2024 at 2:33 AM Jeroen Massar wrote: > `req=dkim`: requires DKIM, messages not properly signed are then to be > rejected/quarantined based on 'p' policy. > This sounds like what RFC 5617 tried to do, minus the constraint that the signing domain be equal to the author domain, which

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

On Mon, Feb 5, 2024 at 10:56 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > The evidence from Google is that multi-valued From DOES have usage and is > usually malicious. That should be sufficient evidence to conclude l that > the security hole must be plugged, not ignored. >

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

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: > > > >>> What do we think has changed since then that warrants reconsidering > that > >

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

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 a multi-value From:. Why? It hasn't so far (i

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

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 that the community has previously rejected the idea of involving Sender

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

On Wed, Jan 17, 2024 at 2:56 AM Alessandro Vesely wrote: > Since email format allows multi-valued From:, its meaning is > straightforward. > Syntax, yes, but meaning? That seems debatable. Does the order of values matter, for example? As John says, it can also be the result of some kind of mi

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

On Tue, Jan 16, 2024 at 10:24 AM Murray S. Kucherawy wrote: > As I recall, with milter in particular, the MTA will add a missing Date > field, which the filter never actually sees and thus cannot sign. The > filter only sees the message exactly as it was presented to the MTA. As a >

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

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 to modify the message. > > A signing filter, as part of a

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

In addition to what Todd offered: On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre wrote: > The RFC first states: > > "Messages bearing a single RFC5322.From field containing multiple > addresses (and, thus, multiple domain names to be evaluated) are > typically rejected because the sorts of ma

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

On Tue, Jan 9, 2024 at 8:07 AM Benny Pedersen wrote: > dkim spec should not allow reject of failed dkim, this is a job for > dmarc, but this have to be solved first > It doesn't (or at least it's a "SHOULD NOT")[1]. -MSK [1] RFC 6376, Section 6.3, paragraph 2 __

Re: [dmarc-ietf] DMARC marketing on NPR

On Thu, Nov 23, 2023 at 9:19 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > The gap between what is being attempted and what is needed is a huge > personal disappointment. > You have made your disappointment plain more times than I can remember. It's on the record each of those

Re: [dmarc-ietf] Server Controls

On Tue, Nov 14, 2023 at 5:33 AM Seth Blank wrote: > As Chair, Douglas, again, what operational issue per charter are you > trying to address, and where is your suggested text to address? > I agree, this far exceeds DMARC's charter. None of this to say the topic is not one worth exploring, but i

Re: [dmarc-ietf] The mailing list catch-22

On Wed, Nov 8, 2023 at 7:04 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Charter Goal: The protocol will cause Evaluators to accept mailing list > posts without From munging (as long as the list is a legitimate operator) > Can you please point to the place in the charter that

[dmarc-ietf] No DMARC meeting at IETF 118

At the chairs' request, the DMARC meeting at IETF 118 has been canceled. -MSK, ART AD ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > By contrast, the new tag cannot be effective until DMARCbis is published > and filtering software updated. This involves years. Even then, domain > owners will never have confidence that the new token

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

On Sat, Oct 28, 2023 at 8:28 AM Richard Clayton wrote: > Paying attention to the (sometimes inferred) age of a signature is also > important for reducing the opportunity for replay, viz: it would be a > Good Thing for senders to set appropriately short expire times. > Why does it have to be infe

Re: [dmarc-ietf] Dmarcbis way forward

On Wed, Oct 25, 2023 at 9:33 AM Richard Clayton wrote: > >The operator is making the decision to publish or enforce, not the > >user. > > Looking at $DAYJOB$ logs for this week I see a shade under 300 people > who are participating in IETF working groups using p=reject addresses. > > I be

Re: [dmarc-ietf] Dmarcbis way forward

On Wed, Oct 25, 2023 at 8:17 AM Richard Clayton wrote: > So might I suggest a wording that captures what will actually happen in > the real world > > Domains that choose to publish p=reject SHOULD inform the people > using those domains of the issues that may arise if theu post to >

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

On Tue, Oct 24, 2023 at 11:11 PM Steven M Jones wrote: > On 10/20/23 12:35 PM, Murray S. Kucherawy wrote: > > (1) As written, the text says (to me) that the handling of a message might > change depending on this mapping of a broken value to "none", but only if > &quo

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

On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba wrote: > Now that we have a consensus call on the main issue that has remained open: > > 1. Do we need to retain our session at IETF 118 and discuss this (or > something else) further? > > ...or... > > 2. Do we have what we need to finish up the DMARCb

Re: [dmarc-ietf] Best of all possible documents?

On Tue, Oct 24, 2023 at 5:34 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > In short, I am not part of the presumed consensus on this document. I will > vigorously oppose any document which does not discuss malicious > impersonation defenses for every domain. > Doug, A working

Re: [dmarc-ietf] Dmarcbis way forward

[trimming redundant Ccs] On Tue, Oct 24, 2023 at 9:41 AM Dotzero wrote: > I'd like to first thank Francesca for taking the time to review where the > working group is as far as consensus. > +1, that was a lot to sift through. The short version of the non-normative language should be in the doc

Re: [dmarc-ietf] Dmarcbis way forward

On Tue, Oct 24, 2023 at 8:57 AM Scott Kitterman wrote: > My understanding of IETF consensus is that technical objections have been > addressed. I think this is critical to the difference between IETF > consensus and voting. It's not just 'most people think X'. I don't think > that the technica

Re: [dmarc-ietf] Dmarcbis way forward

On Mon, Oct 23, 2023 at 9:07 PM Scott Kitterman wrote: > I don't think this is consistent with the IETF's mandate to provide > documents > which promote interoperability. I do not, however, plan to file an appeal > about it. > Two things to say about that: (1) This is Francesca's determination

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

On Mon, Oct 23, 2023 at 12:04 PM Brotman, Alex wrote: > I should note that generally, while there's an "error" field available, > there's no guidance about what should go in there. (not in 7489 either that > I could find in a brief search) > Has there ever been any push for structured content th

Re: [dmarc-ietf] DBOUND

On Mon, Oct 16, 2023 at 8:35 PM Neil Anuskiewicz wrote: > The reference to DBOUND was sparked by looking around at what w3aawg was > saying as I generally think they have some good papers and a great video > series on email authentication. But what I found on DBOUND isn’t > endorsement. They fram

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

On Fri, Oct 20, 2023 at 12:05 AM OLIVIER HUREAU < olivier.hur...@univ-grenoble-alpes.fr> wrote: > I don't understand the choice made when writing the point 6. of the policy > discovery mechanism (Dmarcbis : > https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-28.html#section-4.7 > ) > > ```

Re: [dmarc-ietf] Why Relaxed Alignment?

On Tue, Oct 17, 2023 at 6:51 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Why do we need to support relaxed alignment at all? > Because the charter says: The working group will seek to preserve interoperability with the installed base of DMARC systems, and provide deta

Re: [dmarc-ietf] Policy Enforcement Considerations

On Tue, Sep 19, 2023 at 8:24 AM Alessandro Vesely wrote: > My wording can certainly be improved. Before denying the idea, please > consider > a couple of facts: > > 1) We want ARC to override DMARC, yet we don't say so. Not in such a way > that, > when a receivers does so, he can say he's follo

Re: [dmarc-ietf] Policy Enforcement Considerations

On Tue, Sep 19, 2023 at 6:13 AM Dotzero wrote: > > >> No. I think this section is currently, correctly, focused on what to do >> with only references to why. I don't think we should change that. If the >> current references are inadequate, then we should improve them, not attempt >> to restate

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Sun, Sep 17, 2023 at 2:47 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > We have established that the normative implementation of DMARC is > (unfortunately) a fully-automated solution which implements RFC 7489 > exactly and nothing more. > Sure, but why would you do that, es

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Sun, Sep 17, 2023 at 11:04 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > You misunderstsnd my position. I don't expect a world where perfect > information is dropped in my lap without any effort on my part. Not now, > not ever. > > I have determined, by measurement, that u

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Let's analyze the problem Jim raises, using it to answer Hector's question > about where responsibility lies. > > Our assumed reference model is a fully automated, by-the-spec > implementation of RFC 748

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

One thing I forgot to mention: On Thu, Sep 7, 2023 at 9:29 AM Wei Chuang wrote: > Our suggestion is that there is not a lot of value in including this > language in the bis document if the likely outcome is that it will be > ignored, and rather more effort should be placed with a technical solut

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Sat, Sep 9, 2023 at 11:16 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I understand the phased roll-out goal, but phased rollout and percentages > are not applicable to the evaluator's task. > > I start with an assumption that message sources reflect the character of > the

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

I'm not looking to change the WG's mind on this matter, but: On Sat, Sep 9, 2023 at 3:54 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > There are many percentages mixed up together in this issue: > >- The percentage of domain message sources which provide proper >authen

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Thu, Sep 7, 2023 at 9:29 AM Wei Chuang wrote: > Regarding the languages in section 8.6 "It is therefore critical that > domains that host users who might post messages to mailing lists SHOULD NOT > publish p=reject. Domains that choose to publish p=reject SHOULD implement > policies that thei

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

cott Kitterman > wrote: > > > > > > > > On August 7, 2023 7:47:03 PM UTC, "Murray S. Kucherawy" < > superu...@gmail.com> wrote: > > >On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski wrote: > > > > > >> Based on the ABNF in -28, ho

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski wrote: > Based on the ABNF in -28, how about something like this: > > > dmarc-method = "dkim" / "spf" > > dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method) > > > I think this "should"(*) allow for all permutations but also simplifie

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

On Fri, Aug 4, 2023 at 2:28 AM Alessandro Vesely wrote: > > Collecting some data and doing some experimentation would be really > helpful > > toward determining the right path here, if any. > > Evaluating Sender: doesn't help whitelisting rejection before DATA. > Huh? I didn't say anything abou

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

On Thu, Aug 3, 2023 at 10:39 AM Hector Santos wrote: > [...] > > However, at present, the most plausible use-case appears to be the > addition of delayed SPF rejection scenarios through DMARC evaluation. > Essentially, SUBMITTER/PRA serves as an optimizer and a mechanism to > soften the impact of

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

On Mon, Jul 31, 2023 at 9:47 AM Hector Santos wrote: >- I mentioned using the deprecated SUBMITTER/PRA (RFC4405/RFC4407) > protocols as an implementation detail to access the author's DMARC > policy at the SMTP "MAIL FROM" stage. Wei expressed interest in this > idea. This could also enhance

Re: [dmarc-ietf] Interoperability sections

On Mon, Jul 31, 2023 at 11:59 AM Murray S. Kucherawy wrote: > [...] the idea of demanding all lists the world over start munging From > fields (or whatever mutation we claim is now mandatory) will not happen in > short order no matter how much we wish it would. > Just to be clear, m

Re: [dmarc-ietf] Interoperability sections

On Mon, Jul 31, 2023 at 4:27 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Murray has said that we cannot impose obligations on mailing lists, > because he does not perceive them as DMARC participants. > I don't recall saying that. My perspective is that the "lists are misbeh

Re: [dmarc-ietf] What happens when the DMARC record contains two identical tags?

On Mon, Jul 24, 2023 at 9:13 AM OLIVIER HUREAU < olivier.hur...@univ-grenoble-alpes.fr> wrote: > > Correct, the ABNF doesn't allow this construction, so it's a syntax > error. > > DMARCbis ABNF is not as restrictive as RFC 7489 : > > > dmarc-record = dmarc-version *(dmarc-sep dmarc-tag) [dmarc-se

Re: [dmarc-ietf] What happens when the DMARC record contains two identical tags?

On Mon, Jul 24, 2023 at 8:37 AM Mark Alley wrote: > From my understanding, that would most likely result in a permerror code > for evaluation, given that's not syntactically valid per the ABNF for the > dmarc-record, see below where it only shows each tag once from section 6.4 >

Re: [dmarc-ietf] Why does DKIM fail when SPF succeeds (was: DMARC2 & SPF Dependency Removal)

On Sun, Jul 23, 2023 at 1:06 PM Matthäus Wander wrote: > b) Messages are generated by an automated system without a Date header > and signed by a central MTA. An outgoing mail gateway then adds the > missing Date header (Postfix option 'always_add_missing_headers'), thus > invalidating the DKIM s

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

On Wed, Jul 19, 2023 at 6:31 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I don't take DMARC as a certain result to be used in isolation, but > clearly a quorum evaluators do, and hence the mailing list problem that has > caused such consternation. > > If we want to diminish t

Re: [dmarc-ietf] Another p=reject text proposal

On Fri, Jul 21, 2023 at 1:22 AM Matthäus Wander wrote: > > "SHOULD" leaves the implementer with a choice. You really ought to do > > what it says in the general case, but there might be circumstances where > > you could deviate from that advice, with some possible effect on > > interoperability.

Re: [dmarc-ietf] Eliminating From Munging from this list

On Wed, Jul 19, 2023 at 12:27 AM Alessandro Vesely wrote: > > How do you determine that an evaluator is enforcing DMARC "against > lists"? > > That assumes there are lists that don't munge From:. Is that real today? > I wasn't aware that this munging had become a standard, or even common. It's

Re: [dmarc-ietf] Eliminating From Munging from this list

On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > 1) For evaluators that enforce DMARC against lists, are they willing to > consider any concessions to list traffic? If so, do they favor an > exemption process where the list avoids munging, or an unmu

Re: [dmarc-ietf] Another p=reject text proposal

On Thu, Jul 13, 2023 at 6:11 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I did not say "life isn't fair" to be rude, but as a call to acknowledge > the reality that exists rather than the reality you wish you had. > So what I'm hearing, again, is "Lists should get with the t

Re: [dmarc-ietf] SMTP Result Codes was -Re: Another p=reject text proposal

On Thu, Jul 13, 2023 at 3:40 AM Scott Kitterman wrote: > >Google uses 5.7.26 for the purpose (and for SPF and DKIM rejects): > > > >https://support.google.com/a/answer/3726730?sjid=16541570162287939258-NA > > > >Their use of 5.7.26 seems in keeping with IANA - Multiple authentication > >checks fa

Re: [dmarc-ietf] Another p=reject text proposal

On Wed, Jul 12, 2023 at 6:20 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Does anyone believe that things will change if we publish an RFC which > says "Verizon Media MUST change to p=none"? I don't. > It would be absurd to make such a directed statement. I trust you're sim

Re: [dmarc-ietf] Another p=reject text proposal

On Fri, Jul 7, 2023 at 6:14 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Malicious impersonation creates a need for authentication. If the list > makes changes that disable the originator's authentication, then it is the > list's problem to find a way to convince the recipie

Re: [dmarc-ietf] Another p=reject text proposal

On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Consequently, the problem remains: How does an evaluator distinguish > between a legitimate list and a malicious attack? > If we had a reliable answer to that, this would've been over ages ago. Unfortuna

Re: [dmarc-ietf] Another p=reject text proposal

Still no hat on. I can see the compromise in language that's been proposed here, and I appreciate the effort by the chairs. Two things I'd like to raise. First: On Thu, Jul 6, 2023 at 7:55 AM Barry Leiba wrote: > It is therefore critical that domains that host users who might > po

  1   2   3   4   5   6   7   8   9   10   >