On Fri, Jun 30, 2023 at 11:22 AM Todd Herr wrote:
> Why is the mechanism called "Domain-based Message Authentication,
> Reporting, and Conformance" and not "Domain-based Message Authentication,
> Reporting, and Disposition"? Perhaps a better question, why is
> "conformance" in the name of the
On Thu, Jun 29, 2023 at 4:18 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> But I don't have a solution for ESP messages that use DKIM to authorize
> the From, but use their own domain for SPF Pas on Mail From. That
> requires tying the signature to the server and/or Mail
Just to clarify something:
On Mon, Jun 26, 2023 at 5:52 AM Barry Leiba wrote:
> I can accept some mechanism for the sender to say "SPF only", "DKIM
> only", or "either SPF or DKIM". I cannot except a version of DMARC
> where *both* must pass.
>
I think the proposal before us is to allow the
On Thu, Jun 22, 2023 at 6:32 AM Todd Herr wrote:
> Marty also has the right to engage a third party to send the mail (again,
> as conveyed by their employer), mail that Marty and others at Marty's
> company will create. The third party here is most commonly referred to, in
> my experience, as an
On Sat, Jun 17, 2023 at 2:40 PM Ken Simpson
wrote:
> FWIW, I'd like to chuck my hat in the ring on the side of removing SPF
> from the next iteration of DMARC. As the operator of an email delivery
> service with tens of millions of primarily uncontrolled senders on web
> hosting servers, it
On Thu, Jun 15, 2023 at 6:34 AM Tero Kivinen wrote:
> Murray S. Kucherawy writes:
> > On Tue, Jun 13, 2023 at 10:34 PM Tero Kivinen wrote:
> >
> > DKIM failures
> >
>
> >
On Tue, Jun 13, 2023 at 10:34 PM Tero Kivinen wrote:
> DKIM failures
>
> 36.34% 26619 invalid DKIM record
>
This is staggering. Can you characterize what the most common
malformations are?
-MSK
On Fri, Jun 9, 2023 at 8:49 AM Alessandro Vesely wrote:
> On Fri 09/Jun/2023 16:07:07 +0200 Murray S. Kucherawy wrote:
> > And signing software shouldn't be mutating messages ever (other than
> adding
> > signatures, of course).
>
> Section 5.3, Normalize the Mess
On Fri, Jun 9, 2023 at 2:14 AM Barry Leiba wrote:
> > One case I saw multiple times where DKIM fails while SPF verifies is
> when the
> > message contains a line starting with "from " which some agent changes to
> > ">from ". Some signing software eliminates such lines before signing,
> but
> >
On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula wrote:
> My team recently concluded an extensive study on the current use and
> performance of DMARC. We analyzed a staggering 3.2 billion emails, and the
> insights drawn are quite enlightening. Of these, 2.2 billion emails
> (approximately 69%)
On Thu, Jun 1, 2023 at 4:03 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I cannot support the current draft because it creates new problems without
> sufficiently solving the old ones.
>
> The PSL is subject to two types of errors:
> - Landing too high, causing False Pass on
On Tue, May 2, 2023 at 10:06 AM John Levine wrote:
> No large provider has ever expressed any interest in either so I cannot
> see any reason to spend more time on either one.
>
I believe Wei has expressed interest in the transforms stuff, but I don't
recall whether that was a commitment to
Replying to something almost two weeks old, apologies:
On Tue, Apr 18, 2023 at 7:10 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> When John says that list members plead their case, but their pleas are
> dismissed unsympathetically, it is evidence that mailing lists have a
>
Some thoughts about the third party signature discussion that happened over
the last couple of weeks while I was away:
I wrote ATPS as an experiment in 2012. At the time we were still finishing
DKIM (RFC 6376 was only five months earlier), and still talking about
whether a third party signing
On Sat, Apr 15, 2023 at 3:58 PM Neil Anuskiewicz wrote:
> 1. Cousin domains. We all get that dmarc doesn’t touch those. Dmarc is to
> stop spoofing of exact domains. There are other technologies and methods
> whose responsibility it is to track down and take down fraudsters.
>
The claim was
On Fri, Apr 14, 2023 at 7:32 PM Jesse Thompson wrote:
> On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:
>
> The Sender's users being denied the ability to participate in a list due
> to its policies seems to me like it puts this customer service problem
> w
On Fri, Apr 14, 2023 at 6:47 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Unless a mailing list has controls in place to ensure that EVERY post
> comes from the asserted participant, it is the height of hypocrisy to ask
> an evaluator to assume that the post is from the
On Fri, Apr 14, 2023 at 12:37 PM Dotzero wrote:
> While the you part of "we" may not see any advantages, quite a few
> financials, greeting card sites, retailers AND many receivers have seen the
> advantages, including p=reject. One thing I've learned over the years is
> that it is presumptuous
On Fri, Apr 14, 2023, 14:51 Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Interoperability problems occur because MLMs believe they are exempt from
> the security problems that lesser mortals face.
>
This isn't true. Interoperability problems started when senders posted a
On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely wrote:
> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" <
> superu...@gmail.com> wrote:
> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro V
On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely wrote:
> Heck, MLMs should start rejecting messages sent from domains that publish
> a
> blocking policy *when they fail authentication on entry*!!
>
That's not enough to avoid the damage we're talking about.
> From: rewriting is the de-facto
On Thu, Apr 13, 2023 at 9:11 AM Dotzero wrote:
> On Wed, Apr 12, 2023 at 1:57 PM Murray S. Kucherawy
> wrote:
>
>> On Wed, Apr 12, 2023 at 8:27 AM Brotman, Alex
>> wrote:
>>
>>> In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and
>
On Thu, Apr 13, 2023 at 8:14 AM Barry Leiba wrote:
> There's no need for a signal here: the MLM can simply check the
> sending domain's DMARC policy when a new post comes in, and
> preemptively reject it if the policy is "reject". The IETF considered
> doing that and ruled it out because it
On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones wrote:
> This puts me in mind of Section 8.5, which calls out some potential
> impacts of blocking policies to "Mediators," which role doesn't otherwise
> appear very often in this document. Is there any need to add Mediator
>
On Wed, Apr 12, 2023 at 11:41 AM Todd Herr wrote:
> On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy
> wrote:
>
>> I've been thinking about the point a few people have made now that DMARC
>> has two actors that cause the problem: Those who "blindly" app
I've been thinking about the point a few people have made now that DMARC
has two actors that cause the problem: Those who "blindly" apply
"p=reject", and those who advertise "p=reject". You do, indeed, need two
to tango; enforcement doesn't happen without an advertising sender and a
participating
On Wed, Apr 12, 2023 at 8:27 AM Brotman, Alex
wrote:
> In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and
> the website signs records via DNSSEC. The website I want to go to breaks
> their DNSSEC. My ISP cannot retrieve a record to return to my browser that
> can be used.
On Wed, Apr 12, 2023 at 6:31 AM Murray S. Kucherawy
wrote:
> To my mind, there's a substantial difference between something like TLSv1
> or HTTP whose deprecation excludes you from participating in something
> until you upgrade, versus the DMARC situation where because of an
>
On Wed, Apr 12, 2023 at 5:20 AM Brotman, Alex wrote:
> There is a non-zero set of cases where the IETF prefers security over
> interoperability. A document like RFC8997/8996 where we've deprecated
> TLSv1 in because it was no longer secure. I assure you there are still
> systems/users who have
On Tue, Apr 11, 2023 at 8:25 PM Neil Anuskiewicz wrote:
> The standard and the document should reflect that it’s already making a
> massive difference and could do even more. I don’t think it’s unreasonable
> to expect ml managers to adapt. If cyber crime was street crime people
> would be
On Sun, Apr 9, 2023 at 3:27 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> All of which is why I sketched out a very different mailing list design.
> It's not my job or my agenda to sell it to people, not my job to build
> the product, and not my job to deal with hurt
On Mon, Apr 10, 2023 at 8:15 AM John Levine wrote:
> > For certain
> >constrained but hopefully reasonable scenarios of mailing list
> >modifications, we might be able to distinguish the sources of content.
>
> People have been suggesting this forwver, but it really doesn't scale.
> There are a
On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> As an evaluator, what I can accept is that "Some intermediaries could be
> allowed to make some changes y do want unrestricto messages, if I have a
> list of intermediaries that should be allowed,
On Sat, Apr 8, 2023 at 2:13 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> It becomes a simple choice: Lists can adapt to operate the way AOL and
> others want them to work, or they can keep to the old ways and live with
> the consequences.When the old ways cause damage,
On Sun, Apr 9, 2023 at 6:33 AM Jesse Thompson wrote:
> As Todd previously stated, my preference is for language that acknowledges
> the primacy of the domain owner over interoperability. CISOs have been sold
> (arguably, by the DMARC deployment companies' marketing) on the idea that
> there are
Emphatically "wearing no hat" here, just speaking as a long-time
participant:
On Sat, Apr 8, 2023 at 2:13 PM Mark Alley wrote:
> Re-looking at the definition of "SHOULD NOT", I don't see why it can't be
> considered.
>
> "SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there
On Sat, Apr 1, 2023 at 3:13 PM Jesse Thompson wrote:
> I just read https://datatracker.ietf.org/doc/rfc6541/ (or, re-read, I
> can't remember)
>
> I'm struggling to understand how ATPS is significantly better than
> delegation via DKIM CNAME records. I can see that it's simpler for a domain
>
On Fri, Mar 31, 2023 at 5:48 PM Dotzero wrote:
>
>
>
>>
>>
>> But when you deploy DMARC and force lists to change the way they work,
>> the experience is altered in a way users perceive as a degradation. We're
>> taking something significant away, and the benefit is not perceived to be
>>
On Thu, Mar 30, 2023 at 8:34 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> The world has changed. Insecure mailing lists did not matter in the days
> before email became a weapon.
>
A comparison was made to the global deployment of HTTPS to replace HTTP.
There have been
On Fri, Mar 31, 2023 at 12:22 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> My point was to only restate that "signed" is the only truth that the
> DMARC policy can assert.The new prose needs to fix the false certainty
> that the old prose created. But until this week,
On Fri, Mar 31, 2023 at 2:28 AM Alessandro Vesely wrote:
> > I think we've had this discussion before. This argument reduces to: "I
> do
> > not like what structured mailing lists, which have been around since the
> > '90s at least, do with messages, and I now insist that they change their
> >
On Thu, Mar 30, 2023 at 7:51 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I would be happy with p=signed, because that is what p=reject means, and
> it is our job is to ensure that people interpret the signal correctly.
>
Quoting the charter:
"The working group will seek to
On Thu, Mar 30, 2023 at 8:41 PM Alessandro Vesely wrote:
> Does that mean that instead of "non-transactional mail flows" we could say
> "mail flows involving decades old software"?
>
If you're going to put that label on MLMs, we need to add it to MTAs too.
Oh and most of the protocols we're
On Thu, Mar 30, 2023 at 11:01 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Someone please explain to me why everyone should make themselves more
> vulnerable to ransomware and other attacks so that mailing lists can avoid
> being inconvenienced and avoid having secure
On Thu, Mar 30, 2023 at 7:30 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> There is no interoperability problem.
>
How are you defining interoperability?
"p=reject" when used on domains that send non-transactional messages
disrupts interoperability of the email ecosystem in
On Thu, Mar 30, 2023 at 8:56 AM Barry Leiba wrote:
> 2. Without the workaround, the real pain is not that a message from
> Comcast posted to the list doesn't get to you (though that's true): the
> real pain is that if Valimail rejects (bounces) those messages, the Mailman
> software will
On Wed, Mar 29, 2023 at 7:18 PM Alessandro Vesely wrote:
> I'd mention indirect mail flows explicitly, rather than referring to
> generic
> interoperability problems. But several mailing list adopted expedients in
> order to overcome those problems. Furthermore, there are experimental
>
On Wed, Mar 29, 2023 at 8:59 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> MUST seems to take us back to the unfinished debate of 3 years ago, where
> some asserted that DMARC did more harm than good and should only be used
> for transactional mail, which seemed to mean PayPal
On Wed, Mar 29, 2023 at 5:30 AM Trent Adams wrote:
> Regardless of the outcome of that analysis, though, it does seem
> reasonable to ask the reporter to include a tag indicating the method they
> employed to discover the policy. They will know which method they use,
> it's reasonable to
On Tue, Feb 28, 2023 at 5:13 PM Mark Alley wrote:
> It does vary widely, agreed; I believe knowing how the behavior changes
> can affect existing implementation and common usage scenarios may be useful
> for at least consideration of its effects on domain owners.
>
What do you propose? It
On Tue, Feb 28, 2023 at 3:53 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Murray, I think we need to acknowledge that we are already in a long
> tail.A small percentage of domain owners publish DMARC policies, a
> still smaller percentage publish "reject", and evaluators
On Tue, Feb 28, 2023 at 9:51 AM Alessandro Vesely wrote:
> What are subdomains being used for?
>
> Is that more often done for email reasons (MX) or for something else?
>
> What changes when there is a zone cut (delegation) rather than having
> sub-subdomains all in the same zone? Controlling
On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> The current text has an incentive problem. For an evaluator, the PSL
> works fine. Unless an evaluator is Google-class, receiving mail from
> everywhere in the world, most of the PSL entries will
On Mon, Feb 27, 2023 at 2:29 AM Tõnu Tammer
wrote:
> I am curious to know what the stance is on trailing whitespace within
> DMARC records.
>
> Strictly following the RFC 7489 and the formal specification in section
> 6.4, if there is no trailing dmarc-sep with the associated semicolon,
>
On Sat, Feb 18, 2023 at 5:07 AM Alessandro Vesely wrote:
> I was thinking of current time minus t=, which should be the real flight
> time
> from signature to verification. Thinking twice, it may also make sense to
> report how much time was left (or beyond) w.r.t x=, that is x= minus
> current
On Sun, Dec 11, 2022 at 12:21 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> 2) What to include in reports
> I have one reporting source that always reports a message count of 1,
> without regard to the number of messages that I sent and he received.
>
Perhaps I'm
On Fri, Nov 25, 2022 at 5:53 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> DMARC requires an evaluator to trust the design, but we lack a cogent
> statement of the theoretical basis for doing so. Here is my proposed
> language:
>
> "The RFC5322.From address is not directly
On Sun, Nov 20, 2022 at 11:33 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> That is helpful, thank you. It says to me that their non-participation
> does not have any direct implications for what we are trying to do.
>
> Specifically, it is not that DMARC has too many false
On Tue, Nov 15, 2022 at 2:22 PM Tobias Herkula wrote:
> Why not state that, if there are multiple mailboxes mentioned inside the
> “From”-Header that DMARC should then use the “Sender”-Header? And if that
> does not exists it’s a FAIL
>
Does that mean I can put anything I want in From,
On Thu, Nov 10, 2022 at 4:43 PM Alessandro Vesely wrote:
> On Thu 10/Nov/2022 17:14:32 +0100 John R Levine wrote:
> >> It says:
> >>
> >>Multi-valued RFC5322.From header fields with multiple domains
> >>MUST be exempt from DMARC checking.
> >>
> >> Does it mean that it is enough to add a
On Mon, Nov 7, 2022 at 9:24 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> To Murray's question, there is no "layer" boundary that limits the ability
> of an evaluator to choose which signatures are evaluated and which are not.
>
If by "evaluator" you mean an operator (say,
On Sat, Nov 5, 2022 at 6:21 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I only know about one configuration, my own. I was respond to Murray,
> who suggested escalation might be performed in some context. Maybe so,
> but it does not matter. Evaluators are free to
On Fri, Nov 4, 2022 at 4:18 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Maybe the problem is that John has trademarked "weak" to mean "L=0", so I
> will use "poorly constructed". DKIM "works" because malicious actors have
> found easier ways to attack than using an
On Fri, Oct 28, 2022 at 3:31 AM Alessandro Vesely wrote:
> I beg to disagree. DMARC reporting is all about acceptance of a site's
> cryptographic settings by remote receivers. Domain owners configure their
> MTAs
> trying to follow the prevailing trend. Doing so without feedback can
> cause
>
On Thu, Oct 27, 2022 at 4:16 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Murray raised the issue of a signature which produces PASS, but lacks
> trust because it is constructed with weak coverage, such as omitting the
> Subject or including an L=valuie clause.
>
> DKIM was
On Sun, Oct 23, 2022 at 2:30 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I tried to lay out why I believe reports with server identity would be
> important to domain owners. In this context, verification reduces
> ambiguity about whether the HELO name accurately identifies
On Thu, Oct 27, 2022 at 7:45 AM Dotzero wrote:
> This is why I don't believe "weak" should be included in any normative
> manner. I'm not sure that it should be defined for reporting. I think a
> better approach is some verbiage about weak signatures as a problem.
> Perhaps for reporting
No hat, as usual.
On Sun, Oct 23, 2022 at 7:03 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Is it not a violation of GDPR to require DMARC participants to collect and
> transmit data that is not essential to DMARC?
>
I am not a lawyer, but my understanding of GDPR is that
Can you explain what this would provide? Section 4.1.4 of RFC 5321 says of
the EHLO parameter:
An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse
On Mon, Oct 10, 2022 at 6:56 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Signatures not Evaluated
> --
> Based on the above, a message may have signatures which lack reported
> results for any of these reasons:
> - The verifier evaluated
On Mon, Oct 3, 2022 at 10:26 AM Brotman, Alex
wrote:
> So we would likely need a section in the core document with a SHOULD for
> evaluation (if it’s not already there), and then a section in the aggregate
> reporting for a MUST for reporting on evaluated information (if they choose
> to send
On Mon, Oct 3, 2022 at 9:03 AM Todd Herr wrote:
> On Sun, Oct 2, 2022 at 10:34 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> I am starting from the viewpoint that (a) reporting is a courtesy
>> provided by the evaluator to the domain owner, and (b) the evaluator will
>>
On Fri, Aug 26, 2022 at 8:52 AM Alessandro Vesely wrote:
> > NEW
> > 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
> > transient DNS error), then the DMARC mechanism does not apply to this
> >
On Wed, Aug 24, 2022 at 4:25 AM Alessandro Vesely wrote:
> On Wed 24/Aug/2022 07:56:41 +0200 Murray S. Kucherawy wrote:
> > I believe your "policy is useful when present but not required" remark
> is a
> > re-statement of your claim that DMARC should yiel
On Tue, Aug 23, 2022 at 4:52 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> As best I understand the chair position, DMARC supports domain owners:
> - via PASS, which might improve delivery rates, and more importantly
> - via FAIL, by providing a way to deflect blame and
On Wed, Aug 17, 2022 at 5:02 PM John Levine wrote:
> It appears that Murray S. Kucherawy said:
> >-=-=-=-=-=-
> >
> >Still no hat!
>
> I was under the impression that we all agreed that we're not going to
> change
> the failure reporting spec other than by p
Still no hat!
On Wed, Aug 17, 2022 at 1:50 AM Alessandro Vesely wrote:
> In particular, IANA considerations has two subsections which may neew the
> chairs approval.
>
Just on the IANA stuff:
4.1 is fine, though it can be simplified to include just a sentence that
says "Entry X in registry Y
On Thu, Aug 11, 2022 at 3:16 AM Alessandro Vesely wrote:
> That's the /complicated/ de-munging strategy. The much simpler approach I
> described upthread would work 100% of cases for lists that add the Author:
> field. It is a little less secure, as you need to trust the mailing list
>
On Thu, Aug 11, 2022 at 6:25 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> The solution is within the evaluators control, which eliminates the
> dubious strategy of waiting for everyone else to behave the way the
> evaluator or MLM thinks they should.
>
> But there has been a
On Thu, Aug 11, 2022 at 4:50 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> You say we need to preach at domain owners to lower defenses on 100% of
> their mail because one or more unthinking evaluators may do something
> foolish with a small percentage of their mail.
>
> I say
On Wed, Aug 10, 2022 at 10:44 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> "Breaking long-standing practice" is not the fault of the domain owner
> policy, it is the fault of DMARC being oversold and the DMARC result being
> applied by the evaluator in a way that undermines
On Tue, Aug 9, 2022 at 2:01 AM Alessandro Vesely wrote:
> > Because there are more ways for a forwarder to change a message than you
> or
> > I can describe.
>
> That critic applies to my draft, not to unmunging in general. The only
> change we care about here is the From: field. While there
On Tue, Aug 9, 2022 at 7:54 AM Dotzero wrote:
> When "we" (dmarc.org team) originally came up with DMARC, the goal was to
> take what was in essence a private club to an open standard that anyone
> could benefit from. My personal take is that validators choose not to
> provide failure reporting
On Sun, Aug 7, 2022 at 4:07 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Evaluators need to use much more sophistication, when applying DMARC, than
> simply applying the formula and doing whatever the policy suggests.
>
I think that's common practice. The people on this
On Fri, Aug 5, 2022 at 5:02 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> The second principle in my discussion about NP is that an unregistered
> organization is by definition an unacceptable impersonation. When
> organization existence has not been demonstrated by
On Tue, Aug 2, 2022 at 4:34 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> [...]
>
> What is the plan for initial PSD=Y?
>
Do you have specific text to propose?
-MSK
___
dmarc mailing list
dmarc@ietf.org
On Thu, Aug 4, 2022 at 7:04 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Sorry, Barry. I should have included the problematic text. here it is:
>
> 4.7. DMARC Policy Discovery
>
>
> If the set produced by the DNS Tree Walk contains no DMARC policy
> record (i.e., any
On Thu, Aug 4, 2022 at 10:56 AM Todd Herr wrote:
> I'm struggling to understand what you're trying to say here.
>
> Below is section 4.7 from
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-15.txt. Can you
> please highlight the specific text you're taking issue with and help me
>
On Wed, Aug 3, 2022 at 8:42 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Consider: A message has a verified DKIM or SPF domain which exactly
> matches the RFC5322.From domain.
>
> In this case, the only applicable information in a policy record is the
> reporting
On Tue, Aug 2, 2022 at 9:06 AM Ken O'Driscoll wrote:
> > I'm with Barry. I see no reason to mention zone cuts or anything like
> > zone cuts at all.
> >
> > They are not relevant to DMARC. It would just confuse people.
>
> +1
>
> I also believe it to be unnecessarily confusing and distracting.
On Sat, Jul 30, 2022 at 4:29 AM Alessandro Vesely wrote:
> On Fri 29/Jul/2022 19:44:28 +0200 John Levine wrote:
> > It appears that Alessandro Vesely said:
> >> In general, it is not possible to determine DNS zone cuts by
> querying
> >> various subdomains. However, DMARC users
On Fri, Jul 29, 2022 at 8:23 AM Andreas Niedermann wrote:
> My question is at which time rfc8617 will move from the experimental
> cathegory...
>
Whenever the community decides it's mature enough to do so, and the energy
exists to do the work to advance it.
> Microsoft uses ARC and many
On Fri, Jul 29, 2022 at 8:43 AM Ken O'Driscoll wrote:
> The ARC WG may be a better place to ask about the development status of
> the protocol - https://www.ietf.org/mailman/listinfo/arc
>
Just to pick nits a bit, that's just a mailing list; there's no ARC working
group. DMARC (this working
A couple of tweaks to suggest, edited in-place:
On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman
wrote:
> For Organizational Domain discovery, it will be necessary to perform one
> or
> more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are
> in
> alignment. This means that
On Mon, Jul 18, 2022 at 4:06 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> [...]
>
> Does our document really handle all 15 of these combinations?
>
I think the answer is "yes". Do you see something different?
> One thing that falls out of this recap is that when the
On Sat, Jul 16, 2022 at 7:20 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> SIBLING: One part of an organization validates a message for a domain in a
> different part of the organization. This is a very weak authentication
> method and has multiple risks. The primary risks
On Thu, Jul 14, 2022 at 6:13 AM Scott Kitterman
wrote:
> >> I think a choice within DMARCbis is a bad idea. Effectively the choice
> exists. Evaluators will have the choice to stay with an RFC 7489 design or
> to upgrade to DMARCbis.
> >
> >The incentive to upgrade is not clear. DMARC filters
Once again, participating only:
On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> [...]
>
> 2) I believe that the document needs a vigorous explanation of why the PSL
> needs to be replaced. I made a stab at the effort in the text that I sent
>
On Wed, Jul 13, 2022 at 3:05 AM Alessandro Vesely wrote:
> Uh? manuals recommend to look up WHOIS to determine the owner of
> domains reported to suffer lame delegation and contact them...
> Nowadays, contacts for domain names are not available that way.
>
> We could hijack reporting addresses,
On Wed, Jul 6, 2022 at 7:34 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 : Domain-based Message
101 - 200 of 838 matches
Mail list logo
