Re: [dmarc-ietf] "psd=" tag early assignment

On Mon, Jul 11, 2022 at 5:57 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > We should talk about "correct results". > > The PSL gets the correct results in 99-dot-something percent of messages, > but we are proposing a new algorithm because it is wrong on some fraction > of a

Re: [dmarc-ietf] what to document about the tree walk

Hatless once again. On Tue, Jul 12, 2022 at 3:08 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > The tree walk solves the problem IF the policy has boundary information > provided by the domain owner. Without that, aren't we substituting one > insufficiently reliable

Re: [dmarc-ietf] "psd=" tag early assignment

Speaking only as a participant: On Thu, Jul 7, 2022 at 4:47 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > So John has confirmed that it is his intent to hide any information about > private registries, because the private registries create complexity for > his algorithm which

Re: [dmarc-ietf] moving past pad=y?

On Wed, Jun 29, 2022 at 7:18 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Based on our psl information, a private registry will be at DNS segment 3 > or 4. If the PSO registration is at DNS segment 2, the private registry > could be either one or two segments thick. > What

Re: [dmarc-ietf] Draft 10 notes: NXDOMAIN

(as participant) Yes, that's clearly a broken implementation. I imagine the DMARC document could say it relies on proper implementations of 8020, but improper ones are known to be in the wild, and results are unpredictable when these are encountered. Given the IETF is a standards organization,

Re: [dmarc-ietf] Are Evaluators motivated to switch to Tree Walk?

On Sat, Jun 18, 2022 at 11:10 AM John Levine wrote: > That seems like a pessimal way to make things interoperate: use one of > an unknown set of algorithms and the other party can't tell which one > you're going to use. If we can't agree that the tree walk is better > than piggybacking on the

Re: [dmarc-ietf] Are Evaluators motivated to switch to Tree Walk?

On Sat, Jun 18, 2022 at 7:49 AM Scott Kitterman wrote: > Given that the mechanism we've defined uses DMARC records to make the > determination, I don't think it would be useful to separate it into a > different document. If we ever get an approach that's not DMARC specific, > then I think it

[dmarc-ietf] DBOUND

Some time back there was an attempt to solve the PSL problem in DNS via a Domain Boundaries (DBOUND) working group. It was not successful, unable to develop consensus among several options, and the working group closed having not produced anything. The WG page:

Re: [dmarc-ietf] Are Evaluators motivated to switch to Tree Walk?

On Sat, Jun 18, 2022 at 6:48 AM Scott Kitterman wrote: > On Saturday, June 18, 2022 8:42:23 AM EDT Douglas Foster wrote: > > Let's talk through the selling process for the Tree Walk algorithm. > ... > > In sum, why should an Evaluator make the switch? > > I think there are some good points in

Re: [dmarc-ietf] Bridging the gap

On Sat, Jun 18, 2022 at 4:26 AM Alessandro Vesely wrote: > Actually sending those messages would sound more credible if done From: > some...@ietf.org. Does such a role exist? > No. We participate here as individuals, so whoever does this will be doing it as herself or himself. You probably

Re: [dmarc-ietf] Next draft concerns

On Mon, Jun 13, 2022 at 3:22 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Because I want this document to succeed and actually reduce email-borne > attacks. > I believe we're all wearing the same team jersey here. Please let's try to keep that in mind. > Because stifling

Re: [dmarc-ietf] Updating ABNF for Next Rev?

On Mon, Jun 6, 2022 at 1:40 PM Les Barstow wrote: > As Barry pointed out, RFC7405 does provide the %s notation. But since your > voice was added on top of mine, I might point out that 7405 is only > proposed, not accepted. > No, it's an RFC that had IETF consensus to publish, and it shows as

Re: [dmarc-ietf] Updating ABNF for Next Rev?

Speaking as a participant: On Mon, Jun 6, 2022 at 10:12 AM Alessandro Vesely wrote: > > dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31 > > > Can we use RFC 7405? It is more readable: > > dmarc-version = "v" *WSP "=" *WSP %s"DMARC1" ; case sensitive > +1 to

Re: [dmarc-ietf] What bad stuff can a broken DMARC record cause?

On Sun, Apr 24, 2022 at 11:38 AM John R Levine wrote: > Someone I know asked me what sort of bad things could happen if one > published a broken DMARC record. Obviously, if your record is bad people > won't follow your policies and you won't get your reports, but anything > else? Have you ever

Re: [dmarc-ietf] BATV

On Sat, Apr 16, 2022 at 5:35 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I would like to see John Levine's BATV document revived from expired draft > status > https://datatracker.ietf.org/doc/html/draft-levine-smtp-batv > > BATV is in use within the current mail stream, and

Re: [dmarc-ietf] Exception management

On Fri, Mar 25, 2022 at 3:51 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Exception management is straightforward when using the PSL. The system > administrator simply maintains an errata file that is used to add entries > to, or remove entries from the downloaded PSL file.

Re: [dmarc-ietf] Tree walk in -06

On Tue, Mar 22, 2022 at 10:35 AM Ken O'Driscoll wrote: > Having different behaviour for the absence of the tag and the default > value will be unnecessarily confusing and not intuitive. > I'm confused. In the absence of the tag, don't you apply the default? That is, aren't these necessarily

Re: [dmarc-ietf] DMARCbis and Standard Track

Sigh... On Thu, Mar 17, 2022 at 2:50 PM Murray S. Kucherawy wrote: > The status we're going for is "Proposed Standard". Note the word > "Proposed"; a document seeking this status doesn't need to be bulletproof > out the door, as some evolution based on experience

Re: [dmarc-ietf] DMARCbis and Standard Track

On Thu, Mar 17, 2022 at 1:13 PM Dotzero wrote: > My understanding when the DMARCbis effort was spun up was that we were > trying to move it to Standard Track. Is this still the goal? A number of > experimental things are currently being included. This would seem to > preclude DMARC being on

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

On Wed, Jan 26, 2022 at 9:56 AM John Levine wrote: > More saliently, we had an entire working group called DBOUND that tried > and failed > to come up with a way to publish boundary info about the DNS: > > https://datatracker.ietf.org/wg/dbound/about/ > DBOUND came up with two ways to deal with

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

On Tue, Jan 25, 2022 at 3:31 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Overall, I doubt that we can replace the PSL without moving to DMARCv2, > and I don't think we have a standards-worthy document unless the PSL is > replaced. > I don't think such an opinion is going to

Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up

On Tue, Jan 25, 2022 at 11:26 AM John R Levine wrote: > On Tue, 25 Jan 2022, Murray S. Kucherawy wrote: > >> will get the same result. It also occurs to me that in the absence of > >> a PSL-like thing, the idea of an organizational domain is no longer > >> usefu

Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up

On Tue, Jan 25, 2022 at 9:40 AM John Levine wrote: > It appears that Scott Kitterman said: > >My impression is that the group is generally okay with PSD=y. I prefer > it over your suggestion. My strongest preference is that we pick > something, stick with it, and move on. > > I think I see

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

On Thu, Jan 6, 2022 at 8:12 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Protocols are created to solve a problem, and solution design should > include both normal operation and failure management.That’s why > electrical panels use circuit breakers instead of simple

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

On Thu, Jan 6, 2022 at 3:32 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > There are good reasons for talking about a default DMARC policy. It is > certainly not to give evaluators permission, because we know that > evaluators can do whatever they want, and they will do what

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

On Tue, Jan 4, 2022 at 4:53 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > [...] > The PASS-centric approach is the only one that makes sense to me. This is > why I have lobbied for changes to the introduction to explicitly state that > FAIL is an ambiguous result. If you

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

On Mon, Dec 27, 2021 at 8:33 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I suggest the language should be more like this: > > If the set produced by the DNS Tree Walk contains no DMARC policy record > (i.e., any indication that there is no such record as opposed to a >

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

On Tue, Dec 21, 2021 at 11:32 AM John Levine wrote: > The DNS has had a formal definition of non-existence for over 30 > years. You look up a name, if it returns records or NOERROR it exists, > if it returns NXDOMAIN it doesn't. There is no reason for us to invent > something new and

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

On Tue, Dec 21, 2021 at 4:31 AM Scott Kitterman wrote: > I don't remember exactly why we settled on A/ / MX, but the lack of a > clear, actionable definition is why we included one. Lack of DNS records > related to email authentication only means lack of email authentication, > which is in

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

On Thu, Dec 16, 2021 at 3:52 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > We both know exactly what causes messages to lose credentials: > - A record that is only SMTP validated, which is then forwarded without > SMTP rewrite > - A message which is forwarded after

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

On Wed, Dec 15, 2021 at 9:58 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Yes, this is important stuff. > > This is one of my problem scenarios: > > A record arrives at the first hop and obtains DMARC PASS, based on SPF > and/or DKIM interpreted by a DMARC policy. Based on

Re: [dmarc-ietf] 5.7.1 - Mulitple FROM

On Thu, Dec 9, 2021 at 3:27 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I have trouble with this statement in section 5.7.1: > > "Multi-valued RFC5322.From header fields with multiple domains MUST be > exempt from DMARC checking." > > This language will serve as an invite

Re: [dmarc-ietf] Experiments

ings. > > Random thing while looking at some data just now .. At least one message > apparently came through with seven ARC sets. > > > > Let me know if there’s anything I can answer at this point. > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abu

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

On Sun, Dec 5, 2021 at 12:24 PM John R Levine wrote: > I'm pretty sure that changing DKIM is very out of scope for this working > group. > As I read the charter, I don't agree. It says in at least two places that this could be in scope. Whether the chairs want the WG to engage in such work

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

On Fri, Dec 3, 2021 at 9:37 AM Alessandro Vesely wrote: > 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

Re: [dmarc-ietf] draft-ietf-dmarc-dmarcbis-04 Release Notes

On Thu, Dec 2, 2021 at 12:51 PM Todd Herr wrote: > The change log (Appendix C) has been removed, because even though there > are only two new ideas introduced, there is enough shifting of text to make > this revision effectively a reboot. > No objection to that change, but this leads me to a

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

On Sat, Dec 4, 2021 at 4:51 PM Dave Crocker wrote: > I'm going to suggest that that analysis is not formally correct. > > The DKIM specification precisely defines validation for the signature > and it precisely defines what coverage is 'required'. > > A receiver can indeed choose to apply

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

On Sat, Dec 4, 2021 at 2:35 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I think this text was inserted because of an open ticket when discussion > was going nowhere and a new draft was created. Perhaps the originator of > that ticket can elaborate on his thinking. > I

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

Argh: On Sat, Dec 4, 2021 at 1:30 PM Murray S. Kucherawy wrote: > > I'd be happy with either of these two definitions: > > (a) All messages are subjected to DMARC checking, and "pct" identifies the > percentage of messages failing the check that should be subjected to t

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

On Fri, Dec 3, 2021 at 10:38 AM Todd Herr wrote: > We can have this conversation too. I will promise, however, that if the > group decides to keep 'pct', I will absolutely insist that the first > sentence in its definition be changed. Somehow, RFC 7489 got released with > this text: > >pct:

Re: [dmarc-ietf] Additions to introduction

On Sat, Dec 4, 2021 at 9:55 AM John Levine wrote: > The point of a spec is to tell people how to interpoerate. I don't see > how this > contributes to that. > Lots of specifications include informative guidance or best practices advice as well as normative specification. DKIM has loads of it.

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

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" or "Verified"? -MSK -- Forwarded message - From: RFC Errata System Date: Mon, Nov 1, 2021 at 4:31 PM Subject: [Technical Errata

Re: [dmarc-ietf] Additions to introduction

On Fri, Dec 3, 2021 at 6:16 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I propose that a paragraph along these lines be inserted into the > introduction: > > The DMARC test is characterized by a one-tailed error distribution: > Messages which pass verification have a low

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

On Sun, Nov 28, 2021 at 3:31 PM Wei Chuang wrote: > > This approach and benefit was what I was thinking could be feasible as > well. The cited draft-kucherawy-dkim-list-canon > draft > notes > your contribution to the

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

On Thu, Nov 25, 2021 at 12:07 AM Wei Chuang wrote: > Sorry I wasn't too clear here. It's largely the same idea as the DKIM > body length "l=" field above except for reformulated for the Subject header > and its mailing list mutations. The original sender would encode a length > of the original

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

On Tue, Oct 12, 2021 at 4:42 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Under a collaboration solution, the subscriber goes to her email support > and says,"I joined list X, and they say that for the best user experience, > we need to configure a whitelist entry to bypass

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

On Thu, Oct 7, 2021 at 7:57 AM Dave Crocker wrote: > Sorry, but I've lost track of which document would informationally > document this issue. > > The re-writing hack is an operational one that might or might not prove > the be transient. Having a spec note the effect of what it does, in > terms

Re: [dmarc-ietf] Experiments

On Wed, Sep 22, 2021 at 1:59 PM Scott Kitterman wrote: > I can comment on the status of PSD. > Please do! ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Experiments

Is anyone in a position to comment on the ARC and PSD experiments and how they're progressing? Deployment status? Data acquired thus far? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

On Thu, Aug 19, 2021 at 4:19 AM Alessandro Vesely wrote: > 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

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

On Thu, Aug 19, 2021 at 1:50 PM Dotzero wrote: > I'm troubled by this whole section. Unless IETF is getting into the > certification or enforcement business, documenting anything about > "implementation claims" would seem to be a non-starter. Do we have any > similar requirements for "claims"

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

On Thu, Aug 19, 2021 at 5:53 AM 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

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

On Thu, Aug 19, 2021 at 11:24 AM Todd Herr wrote: > >Mail Receiver: To implement DMARC, a mail receiver MUST do the > >following: > > >* Perform DMARC validation checks on inbound mail > > >* Perform validation checks on any authentication check results > > recorded by

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

On Thu, Aug 5, 2021 at 4:22 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > PCT could work IF evaluators are willing and able to send a Temporary > Error result (probably 451), instead of a permanent error, when > - a DMARC verification fails, > - the message is not

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

On Mon, Aug 2, 2021 at 12:49 PM Todd Herr wrote: > And this: > > > 6.7.4. History of the "pct" Tag > > [...] > I suggest making this an appendix instead of leaving it up in the normative area, with an appropriate forward reference. And +1 to Michael's point about "experimental". -MSK

Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

On Fri, Jul 30, 2021 at 5:13 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Unfortunately, it seems the extended status codes have very limited > deployment. When I searched my recent history, I could only find codes > 2.0.0 and 2.6.0, which communicate nothing incremental. >

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

On Thu, Jun 17, 2021 at 9:18 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > This is frustrating. NP is a new design and the design issues should > have been discussed before we got to this point. I don't know why so many > people are eager to not define the new technology.

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

I continue to not understand the defect you're highlighting here. I think you've expressed yourself primarily in the abstract. Could you craft a sample message, sample envelope, and sample DNS context that highlights the problem you're talking about? Maybe then it'll snap into focus. On Wed,

Re: [dmarc-ietf] Consensus Sought - Ticket #47 (Removal of "pct" tag) - With Interim Notes

I don't understand what "demeaning a domain's policy" means. On Fri, May 28, 2021 at 10:20 AM Alessandro Vesely wrote: > On Fri 28/May/2021 17:43:37 +0200 Todd Herr wrote: > > > > Consensus on Ticket #47 > (Removal > > of "pct" tag) was reached

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

On Sun, May 23, 2021 at 12:25 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > [...] > 145 of 169 (86%) of non-verified domains had MX or A records, > Of the 24 without MX or A records, 23 were spam and 1 was legitimate > For 20 of the 24 , SPF on the From address returned

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

On Mon, May 17, 2021 at 10:19 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Fatal flaws with the MX/A/ test > >- During DMARC policy evaluation, the process may have retrieved an >SPF policy or a DKIM public key which is associated with the RFC5322.From >domain

Re: [dmarc-ietf] https reports, or nits in draft-ietf-dmarc-aggregate-reporting-02

On Fri, May 7, 2021 at 12:22 PM John R Levine wrote: > On Fri, 7 May 2021, Murray S. Kucherawy wrote: > > [ mail and web departments don't talk to each other ] > > If that logic also holds for mail people and web people, > > I imagine the lack of interest here has a similar

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

On Sat, May 8, 2021 at 7:31 AM Alessandro Vesely wrote: > > - #62 makes reporting mandatory, which leaves the mail receiver with no > > means to mitigate the privacy threat. > #62 (assuming it has WG consensus) makes it clear we really want reporting to be mandatory, but at a glance I don't see

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

On Fri, Apr 23, 2021 at 11:21 AM wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance WG of the IETF. > > Title : DMARC Aggregate Reporting >

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

On Fri, May 7, 2021 at 7:53 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > My problem with MX/A/AAA is that it IS a "mail enabled" test, which is > exactly the concept that you rejected in a recent previous post. > I don't know how to answer that, since I don't know what "mail

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

On Fri, May 7, 2021 at 1:25 PM John Levine wrote: > It appears that Murray S. Kucherawy said: > >-=-=-=-=-=- > > > >I think it's an IETF tools problem. The URL is theirs, not yours. > > tools.ietf.org is running on fumes and will be going away. The >

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

On Thu, May 6, 2021 at 8:14 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > My argument is that that A//MX has no useful relevance to determining > whether the RFC5322.FROM address of a message should be evaluated based on > SP or NP. NP is described as testing

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

On Thu, May 6, 2021 at 4:19 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I was referring to this section of RFC 7208, which I have interpreted as a > replacement for the older language of RFC 5321. > Perhaps I overgeneralized, and it is acceptable/desirable to send NDRs if >

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

On Fri, May 7, 2021 at 1:03 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > *The existence / non-existence test:* > > Given an identifier which is presumed to be a DNS domain name, perfrom a > DNS lookup based on that name. > The query may: > [...] > - return results using data

Re: [dmarc-ietf] nits in draft-ietf-dmarc-aggregate-reporting-02

On Fri, May 7, 2021 at 9:46 AM John Levine wrote: > > 2. I’d welcome other inputs here on the original idea for this > option. I would imagine modern systems would be able to deal with rather > >large XML files, though MTAs routinely set limits under 50M for accepting > messages. > > I

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

On Fri, May 7, 2021 at 9:06 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I objected vigorously during the PSD review, but the Area Director > directed me to defer the discussion so the experiment could move forward. > Can you please cite what I said to give you this

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

On Thu, May 6, 2021 at 5:02 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I have begun data collection on the effectiveness of the MX and A tests. > Wildcard DNS entries increase the frequency of false positives and reduce > the usability of the test. For example,

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

& Messaging Policy > > Comcast > > > > *From:* Murray S. Kucherawy > *Sent:* Monday, May 3, 2021 8:03 PM > *To:* Brotman, Alex > *Cc:* Alessandro Vesely ; IETF DMARC WG > *Subject:* Re: [dmarc-ietf] I-D Action: > draft-ietf-dmarc-aggregate-reporting-02.t

Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

On Wed, May 5, 2021 at 9:27 PM Seth Blank wrote: > The Chairs ask group participants to explicitly speak up if: > 1) they intend to participate in the interim > I'll be there. -MSK ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

On Mon, May 3, 2021 at 5:26 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I meant to say that we need N unique (and valid) smtp TO addresses, so > that an attacker cannot send a single email address and wait for an rua > report to know where it lands. > > Valid addresses are

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

On Mon, May 3, 2021 at 11:49 AM Brotman, Alex wrote: > I apologize, corporate mail gateway does that (I've asked them to exempt > ietf.org now). The links have an expiration of a few days. > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/ > One of the URLs that came

[dmarc-ietf] Chair rotation

Colleagues, As Barry has stepped down from the IESG, he's available to re-engage in other roles. He has generously volunteered to invest time and energy in the DMARC WG to carry the torch once the design teams complete their work in the near future. With much gratitude to all of the current

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-12.txt

On Mon, Apr 12, 2021 at 3:25 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance WG of the IETF. > > Title : Experimental DMARC

Re: [dmarc-ietf] NXDOMAIN

On Thu, Apr 8, 2021 at 9:50 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Why is it problematic to document this risk, and indicate that when "No > Policy detected" occurs, it is recommended to check whether the domain > exists, and if it does not exist then local policy for

Re: [dmarc-ietf] NXDOMAIN

Further to what Todd said: On Wed, Apr 7, 2021 at 5:04 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I am hearing that we have a defacto standard to check return-path using > MX/A/. It is implemented with sufficient breadth,that (unlike SPF) > senders should consider it

Re: [dmarc-ietf] NXDOMAIN

On Tue, Apr 6, 2021 at 4:54 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > If the SPF Policy lookup returns NXDOMAIN, then we are at a full stop with > all the information needed to make a decision. (The sender is violating > ICANN name registration policies). Ignoring

Re: [dmarc-ietf] NXDOMAIN

On Mon, Apr 5, 2021 at 2:02 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > As a result of earlier discussions, I have been investigating NXDOMAIN as > an email filtering criteria. > > One question from those discussions was the best way to detect NXDOMAIN. > I realized that I

Re: [dmarc-ietf] NXDOMAIN

On Mon, Apr 5, 2021 at 3:08 PM Todd Herr wrote: > I did not require an MX record, per se; the requirement was that there be > either an MX record or, failing that, an A/ record. > Given that this is what RFC 5321 Section 5.1 prescribes in terms of answering the question "Where should I try

Re: [dmarc-ietf] AD Evaluation: draft-ietf-dmarc-psd

On Fri, Mar 19, 2021 at 9:35 AM Murray S. Kucherawy wrote: > And with that, I'll set up the Last Call. > Last Call has ended. Scott/Tim, please make whatever resulting edits are appropriate and let me know when it's ready for a telechat. I've marked it as "Revised I-D Nee

Re: [dmarc-ietf] Sender vs From Addresses

On Thu, Mar 25, 2021 at 2:39 PM Charles Gregory wrote: > I DO think this is an unnecessary problem that CAN be fixed/improved in > one of two fairly straightforward manners through DNS (behavior switch or > list authorized alternate domains). And I can't see anything but upside in > doing so;

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt

Just to nit-pick: On Fri, Mar 19, 2021 at 9:28 AM Alessandro Vesely wrote: > There's still a few style points that I'd propose. They can be dealt with > in > auth48. > After Last Call, please. Don't wait for AUTH48 to process this feedback. -MSK

[dmarc-ietf] AD Evaluation: draft-ietf-dmarc-psd

Happy to see this in my inbox this morning. Thanks to all that contributed to getting this final text to where we want it. A couple of minor points, which you can deal with after any Last Call comments come in rather than cranking a new version now: In the Introduction where you say "Public

Re: [dmarc-ietf] Using CNAME records to DMARC templates causes issues

On Tue, Mar 2, 2021 at 3:51 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Because CNAME usage was not mentioned in the previous DMARC document, > existing implementations may not have tested this configuration. For the > policy publishing organization, this increases the

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

These all work for me. Thanks for the contributions. Scott, please work your magic with a revision so the chairs can request publication and we can get this on its way. -MSK On Thu, Feb 25, 2021 at 9:13 AM Dave Crocker wrote: > On 2/25/2021 8:41 AM, Kurt Andersen (b) wrote: > > Especially in

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

On Fri, Feb 19, 2021 at 3:02 PM Barry Leiba wrote: > I agree that the abstract is unclear. This makes no sense to me: > >domain names represent either nodes in the tree below >which registrations occur, or nodes where registrations have >occurred; it does not permit a domain name to

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

Circling back to this: On Fri, Jan 29, 2021 at 12:56 PM Dave Crocker wrote: > On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote: > > On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker wrote: > >> >> Abstract >> >>DMARC (Domain-based Message Authenticati

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On Fri, Jan 29, 2021 at 3:02 AM Alessandro Vesely wrote: > I just run a quick test on my current folder. Out of 3879 messages I > extracted > 944 unique helo names. 721 of these matched the reverse lookup exactly. > Out > of the 223 remaining, 127 had an SPF pass for the helo identity anyway.

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker wrote: > > Abstract > >DMARC (Domain-based Message Authentication, Reporting, and >Conformance) is a scalable mechanism by which a mail-originating >organization can express domain-level policies and preferences for >message

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

ted above, in an attempt to mitigate this abuse. >> > > update to DMARC = yes; update to PSL = no > Why? > >> On Fri, Jan 29, 2021 at 1:44 AM Murray S. Kucherawy >> wrote: >> >>> On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski wrote: >>> >>>&

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski wrote: > Since this is an experiment, Appendix A discusses the updates that > happen. we don't actually say explicitly "if the experiment is a success, > the following changes will be made" and perhaps I should add some wording > like that. >

Re: [dmarc-ietf] Forensic report loops are a problem

On Thu, Jan 28, 2021 at 1:42 PM John R Levine wrote: > > This to me is almost exactly the same thing as saying "Don't generate a > > bounce about a bounce", > > Because these are not bounces. They are not even a little bit like > bounces. Bounces are about invalid recipient addresses, but

Re: [dmarc-ietf] Forensic report loops are a problem

On Wed, Jan 27, 2021 at 7:08 PM John R Levine wrote: > Which of these should we do: > > A) Everyone in the world who produces failure reports adds special cases > to look for incoming failure reports, and heuristics to try and recognize > failure reports in the wrong format, and when it finds

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On Thu, Jan 28, 2021 at 4:13 AM Alessandro Vesely wrote: > > DKIM (in its simplest form) returns N tuples of the form (d= domain, > > pass/fail). All of them were run through exactly the same check; all of > > them were attached to the message in exactly the same way; all of them > have > >

Re: [dmarc-ietf] Forensic report loops are a problem

On Wed, Jan 27, 2021 at 12:37 PM John Levine wrote: > I still don't understand why failure reports about messages that > happen to be failure reports are in any way special. > Loop detection in RFC 5321 is a normative MUST because of the obvious operational problems it creates. Maybe I'm being

Re: [dmarc-ietf] understanding section 7.2

The schema's already pretty large, and probably has to be, but maybe a trivial example report would be reasonable to craft and include? On Tue, Jan 26, 2021 at 11:05 AM Michael Thomas wrote: > > So I'm an outsider who has not tried to digest what's going on in the > reports until recently so my

<    1   2   3   4   5   6   7   8   9   >