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.
The other is that most if not all of the things you propose are not new.
I proposed a chained DKIM signaure that lets the signer say who's
On Sun, 7 Apr 2024, Neil Anuskiewicz wrote:
This WG should have finished a year ago. Unless you think something is so
broken that it's worth more months of delay, forget it.
To be clear I was suggesting considering deprecating the hardfail modifier only
as it’s archaic. I was not saying
On Sat, 6 Apr 2024, Scott Kitterman wrote:
As a side effect of the switch to the tree walk approach in DMARCbis, this is
no longer true. For any subdomain without a DMARC record, the domains above
it in the tree are also checked, so you can specify a different policy/
reporting address for
On Sun, 7 Apr 2024, Neil Anuskiewicz wrote:
I think clear statement and supporting text explaining clearly that SPF is no
longer the policy layer would be a good idea. While it might be slightly out of
scope, I have encountered people who think best practice is to enforce with
-ALL.
We had
No might about it -- ARC is only useful with domain reputation. Of course, DKIM
is only useful with domain reputation, as were Domainkeys and IIM, so I don't
see why it's a problem now.
Much of the objective of DomainKeys/IIM/DKIM was to provide a reliable
domain identifier that could be
I don’t think it’s scope creep at all. The WG charter puts “Review and
refinement of the DMARC specification” in phase III, after “Specification of
DMARC improvements to support indirect mail flows”. It seems clear to me that
standards-track DMARC needs to incorporate those improvements.
IESG
On Sun, 31 Mar 2024, Jim Fenton wrote:
Based on the above problems, I do not think DMARC-bis should be published as
a standards track document by IETF.
This reminds me of the NAT wars in the 1990s. We all understand that
DMARC has a lot of problems, but it's far more widely used than many of
I’m probably being pedantic here: is “gov” a domain?
Yup, it's a domain.
I stand corrected on that.
Anything that meets the DNS spec is a domain namen, e.g.,
argle.bargle.parp is a domain name. If and how particular names might be
resolved is a topic to which the IETF and ICANN have given
Our advice is not to publish a DMARC policy if you want to use mailing lists.
We have a lot of experience with message rewriting and I think we have all
found that the options range from pretty bad to really bad, so there's nothing
to recommend.
“Our advice” seems not to be followed by many
Entities other than domains: Public suffixes aren’t (necessarily) domains,
Of course they're domains. What else could they be? The things that are out
of scope are IP addresses, ASNs, magic tokens in the messages, stuff like that.
I’m probably being pedantic here: is “gov” a domain?
I concur with Jim that rewriting strategies are in scope for the WG
according to its charter, especially if we have something to recommend
going forward.
Our advice is not to publish a DMARC policy if you want to use mailing
lists. We have a lot of experience with message rewriting and I
Below is a number of “minor issues and editorial comments” on dmarcbis-30. I
have a larger issue regarding the draft as a whole that I have yet to write
up and will post separately.
Thanks for the review even though I disagree with a fair amount of it.
2.1 High level goals
::00::12.34.56.78
0:0:0:0:0:0::012.034.056.078
The latter yields failure running the example program in the inet_pton(3) man
page. See e.g.
https://www.man7.org/linux/man-pages/man3/inet_pton.3.html#EXAMPLES
That's yet another reason not to change the XML spec. Please stop.
Apologies, which format should be used. I'm not sure if I should revert to the
one from 7489, or some other prior version.
The one that's in the draft now is fine. Don't add the line with f{4}
which is an insufficiently general special case.
Regards,
John Levine, jo...@taugh.com,
On Mon, 25 Mar 2024, Alessandro Vesely wrote:
How about:
"(:::)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>
Testing yielded a correct fix:
"(::[Ff]{4}:)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>
There are lots of other ways to write
On Fri, 22 Mar 2024, Benny Pedersen wrote:
to confusion about DMARC and DKIM test flags. This document is already too
long and too late.
Unless there is an actual problem to solve here, let's close the issue and
finish up.
why is dkim fail here
Because the mailing list modified the
While I generally agree, DMARC for the last decade didn't have a testing
flag. That's new in DMARCbis, so I don't think that's really germane.
This particular thing is on us as a working group.
RFC 6376 makes it quite clear on page 28 that DKIM verifiers ignore
signatures with a t=y flag,
Now with Mike's tweak:
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 of authorized MTAs [ref to
RFC 7208,
On Mon, 18 Mar 2024, Alessandro Vesely wrote:
The text should be terser and clearer, possibly with an example.
I would be happy to remove the whole thing, since it's only distantly
related to defining or implementing DMARC.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks,
On Sun, 17 Mar 2024, Dotzero wrote:
Whenever mail is sent, there is a risk that an overly permissive source
may send mail which will receive a DMARC pass result that was not, in
fact, authorized by the Domain Owner. These false positives may lead
to issues when systems interpret DMARC pass
Some universities' resolvers return NOERROR instead of NXDOMAIN (samba4 server
used as AD, and resolvers)
They still do that? Wow. At least that won't screw up DMARC evaluators
too much.
In any event, I don't think it's our job to redesign our specs for the
benefit of people who've
On Fri, 1 Mar 2024, Seth Blank wrote:
It seems OK but I would say that at this point that mailto: URI are the
only ones currently defined.
Participating, to this point. Throwing out an idea, that may be
spectacularly bad:
mailto: is the only function that's ever been used. We even discussed
Together with DMARC p=none as DKIM signature-presence is ignored and thus
any email can pass.
I don't understand.
Me neither. I still don't see any reason to revisit this issue. Nothing
has changed since the last time we argued about it.
R's,
John
PS:
About RFC 5617
At that time,
On Mon, 6 Nov 2023, Douglas Foster wrote:
Since IETF cannot protect its own lists from conspicuous impersonation, it
seems poorly qualified to tell anyone else how to do so.
Actually, that message had nothing whatsoever to do with impersonation,
and everything to do with an obscure
Please, no. This WG has already run a year past its sell-by date. Stuff
like this will just tell the world that we'll never finish.
Apologies. I wasn't trying to disrupt dmarcbis finishing. Ever since I saw
consensus start to form, I started citing dmarcbis whenever explaining how
DMARC
1) a receiver that will forward quarantined messages, and
do so without changing the bounce address. Solution: Don't Do That.
That's a confounding issue but not the root problem I think. Even if
Microsoft were to implement keeping the bounce address, it just means that
the spammer has to
I do like your suggestion of silent discard rather than bounce, and I
would want to see that change made -- perhaps with a note that
aggregate reports will still include information about those discards.
Having thought about it for a minute, I have a better question.
We already know that sites
ig
fuzzy SPF record.
R's,
John
Barry
On Fri, Jun 23, 2023 at 1:54 PM John R Levine wrote:
My understanding is that if `auth=dkim` then SPF would be ignored from the
perspective of DMARC. So if a receiver sees DKIM is not DMARC aligned and
only SPF is DMARC aligned then it would still be tre
My understanding is that if `auth=dkim` then SPF would be ignored from the
perspective of DMARC. So if a receiver sees DKIM is not DMARC aligned and
only SPF is DMARC aligned then it would still be treated as a DMARC fail.
That's my understanding.
It would be a way for senders to say "yes I
On Thu, 22 Jun 2023, Emanuel Schorsch wrote:
I agree with John's point that dkim+spf doesn't make sense in the context
of strict DMARC enforcement (I think it provides value for p=none domains
Since the aggregate reports tell you what authentication worked, I don't
even see that as a benefit.
On Mon, 19 Jun 2023, Patrick Ben Koetter wrote:
I suggest that we do not only drop SPF, but also come up with better ways
(simplification, tools, exchange formats) to implement DKIM in order to allow
for a smooth transition.
I'm scratching my head here. On my system I publish and rotate DKIM
Why not say "SHOULD use tree walk", and then document, as explanation
for "SHOULD" instead of "MUST", non-normative reasons why you might
not?
I don't think that will fly with the VLMPs. The mandatory PSD seems
relatively easy to implement, just add it to the template you use for
everything.
It is not a commitment at this time. That said, we are interested in
solving this problem and welcome collaboratively figuring out the right way
to do this.
It seems to me that ARC provides the useful parts of third party
signatures and, while rather complicated, has the benefit of actually
6.1. Data Exposure Considerations
Aggregate reports are limited in scope to DMARC policy and
disposition results, to information pertaining to the underlying
authentication mechanisms, and to the domain-level identifiers
involved in DMARC validation.
Aggregate reports may expose
Since the only mechanism is mail and nobody's going to S/MIME encrypt
their reports, I suggest just deleting it.
TLS vs not TLS.
I suppose, but that's not up to the report sender. If I say
"rua=mailto:rep...@cruddy.org;, and the MX for cruddy.org doesn't do
STARTTLS, what are you going to
I removed the small section that faced objections.
I updated the ridtxt definition and discovered that mmark was making a mess of those asterisks.
When there are more than one/some on a single line, it believes you would like some subset to
be defined as "" things.
Looks pretty good. Minor
I'm assuming that the "long list of stinky possible workarounds" are the
existing "whatever" mitigations, and rewriting seems to be acceptable
enough as a mitigation to convince large [enterprise] mail systems to
move forward with restrictive policies. ...
I think you are greatly
I’ve talked about this before. I ran into a utility company that I conversed
with that explicitly didn’t want to use DKIM because they felt their messages
should not be forwarded to another provider. I didn’t quite understand the
logic, but it was their decision.
I believe it, but needless
On Thu, 13 Apr 2023, Dotzero wrote:
It also isn't that " IT DOES NOT MATTER IF YOUR MAIL GETS LOST". It matters
but there is a calculus regarding the tradeoffs of a very small percentage
(in the case of my former a very small fraction of a percent) of email not
getting delivered vs the damage
Anyone who does forwarding is damaged by DMARC because there are a lot of
people who do DMARC on the cheap with SPF only.
This brings up another issue, I think: that there should also be
stronger advice that using DKIM is critical to DMARC reliability, and
using SPF only, without DKIM, is
On Wed, 12 Apr 2023, Eric D. Williams wrote:
No, it's a DMARC problem. DKIM didn't cause any problems for mailing
lists ...
mailing lists the real answer is ARC not DMARC, that's what I'm saying. It's
a failure with DKIM signature invalidation as a result of relaying via
mailing lists.
My
I note that you didn't write "MUST NOT". I heartily concur with "shouldn't"
or SHOULD NOT. I still have issues with "MUST NOT".
Keep in mind that MUST NOT doesn't mean "do this and you will die", it
means "do this and you won't interoperate" which seems exactly correct
here.
SHOULD NOT
On Tue, 11 Apr 2023, Neil Anuskiewicz wrote:
If DMARC can protect domains from spoofing which I believe ends up
costing over $14 billion per year. Forget about the $14 billion and
think how this crime spree affects people’s view
But it obviously can't do that, and what it does do happens
On Mon, 10 Apr 2023, Alessandro Vesely wrote:
On Sat 08/Apr/2023 15:59:30 +0200 John Levine wrote:
It appears that Eric D. Williams said:
-=-=-=-=-=-
I think the reliance upon list operators is properly placed on that role.
It's not a DMARC problem, it's a DKIM problem, I think.
No, it's
I haven’t done extensive research but here is a live example where treewalk will cause a result change.
From: is in the domain Ret.bmcc.cuny.edu which has no DMARC record.
_dmarc.bmcc.cuny.edu.300INTXT"v=DMARC1; p=quarantine; fo=1;
On Tue, 15 Nov 2022, Douglas Foster wrote:
If a server farm hosts DomainA and DomainB, and I only get DMARC aggregate
reports when I send to DomainA, then I can conclude that DomainB is not
evaluating DMARC and is therefore more vulnerable to impersonation attacks
than DomainA.
You can
I will agree with Ale somewhat. While we should say that PSDs MUST NOT
publish a ruf= tag, it would be prudent also to say that reporters MUST
ignore a PSD's ruf= tag in case one is there anyway. Belt and suspenders.
How about SHOULD NOT?
No. We have already wasted too much time on this
So the question: Does anyone *really* think we *do* have to close out
these edge cases at the risk of complexity, incompatibility, or other
down-sides? ...
It can be worse, as in this case where trying to fix the corner case makes
things worse for everyone else.
I will agree with Ale
I took a look and it looks to me like all the section references are
there. Which ones are missing?
According to the diff provided on the web site [1], quite a few in the
following hunks of the diff:
The section numbers are all there in the markdown and the XML, so it's a
rendering problem
Why did you remove the specific paragraph pointers for the references? Is that
the norm in IETF documents? It seems to me it makes things less clear.
I took a look and it looks to me like all the section references are
there. Which ones are missing?
Regards,
John Levine, jo...@taugh.com,
Scott's changes about when and how to apply policy
Neil's typos
cleaned up references to the other I-D's
Please review the changes before accepting it.
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this
If you're feeling really enterprising you can do a github pull request,
but sending the suggested changes to this list is fine.
On Sat, 27 Aug 2022, Neil Anuskiewicz wrote:
Cool! I'll proofread the whole document within two weeks unless there's a
tighter timeline. I've heard talk on the list
I made a git pull request which is intended to include the changes that
Barry
and Scott recently proposed. I also did a little editorial cleanup on the
way clearing up some grammar and tagging the **MUST** and **SHOULD**
R's,
John
PS: if you see some odd looking git commits, I accidentally
On Mon, 22 Aug 2022, Wei Chuang wrote:
I agree with the OP's premise that there needs to be a better
authentication method that works with mailing lists. ...
Google seems pretty enthusiastic about ARC.
Since large mail systems already know where the mailing lists are, I asked
why not just
On Fri, 19 Aug 2022, Alessandro Vesely wrote:
Todd and I have found it much easier to edit the markdown version of
dmarcbis than hand twiddle the XML codes, and I have twiddled more than my
share of XML.
I made a pull request with the -04 version converted to markdown and a
makefile to
Done on Github copy.
I was surprised to see that the markdown version of the draft has
disappeared from the github repo.
Todd and I have found it much easier to edit the markdown version of
dmarcbis than hand twiddle the XML codes, and I have twiddled more than my
share of XML.
Regards,
This proposal is completely out of scope for this WG.
On Thu, 18 Aug 2022, Alessandro Vesely wrote:
Hi all,
I rewrote this I-D to add the simple method to de-munge From: header fields
upon reception, which was briefly discussed on list last week (Girl Scout
troops):
On Wed, 17 Aug 2022, Murray S. Kucherawy wrote:
I can't remember if this was discussed previously. I was just responding
to the proposed change.
Understood, but I am concerned that we are spinning our wheels on changes
proposed by individuals that have no support from anyone else. It would
Most receivers don’t provide failure reports but sometimes failure reports
(when available) can be useful. I realize there are privacy and regulatory
concerns. Would it be possible to reduce the scope of the failure report in
general to address the privacy concerns so that they’re more widely
I re-read the I-D and applied some more substantive changes.
I don't find the changes improve clarity, but whatever.
How about if you fix the markdown so it has the current contents of the
draft, and you add a Makefile that can turn the markdown into XML and the
XML into text and HTML one
It does, it looks like someone did a quick cut and paste to make the
markdown. But it's not that long, you're the editor, how about fixing the
md so it's useful for editing?
It must have been me. I recalled; I searched again for something to generate
the md and again found only
I'd rather it be more general, to show where all of the plausible parts go.
Message/rfc822 is not more general, is just different. If I implemented
failure reporting, I'd choose text/rfc822-headers (and heavy redaction) to
reduce PII leakage as much as possible.
The point of the example is
On Fri, 12 Aug 2022, Alessandro Vesely wrote:
When Dave proposed the Author header, part of the idea was that DMARC could
use it rather than From.
IIRC that was the Sender: field.
No, DMARC decided not to use Sender back when DMARC was new. Dave
suggested using Author to work around the
The Source-Port field is non-standard so I'd take it out.
Defined by RFC 6692.
So it is. ARF is such a mess.
I'd change text/rfc822-headers to message/rfc822 and add ther a message
body or something like [ Message body was here ]
Why? I chose a body-less example as it looks more
On Thu, 11 Aug 2022, Alessandro Vesely wrote:
I added an example, see
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/blob/main/draft-ietf-dmarc-failure-reporting-04.txt#L528
I omit diffs, as the only difference is Appendix A.3 (and I removed an
antique Acknowledgments
On Thu, 11 Aug 2022, Murray S. Kucherawy wrote:
It only works if all or most lists add Author (none do today, and it would
take a long time to get this rolled out if they started), and no other
software co-opts and mutates it for whatever reason. Those are big enough
conditions that I'm a bit
On Tue, 9 Aug 2022, Murray S. Kucherawy wrote:
I agree with John, I think, that the amount of time we should spend
improving failure reporting should be proportional to how much it's used,
or how much the community is asking us to do so. ...
My small mail system gets failure reports every day,
On Wed, 10 Aug 2022, Barry Leiba wrote:
Yeh, I have to take serious issue with this:
It's not a "tantrum" to say that it's not reasonable to require all
mailing list software and every mailing list in the world to change
what's worked for decades in order to work around a problem caused by
use
Keeping it as-is for backwards compatibility is probably the best option.
I'm not sure that it's necessary to keep it as is for backward
compatibility. Both RFC 7489 and DMARCbis contain the phrase "unknown tags
MUST be ignored" in the General Record Format text, so even if DMARCbis
were to
Not quite. Lists are already screwed up, AFAICS.
Right. Lists were fine until DMARC screwed them up.
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
Actually, small receivers can simply trust selected, DMARC-aligned mailing
lists and restore the original From: in the cases where MLM saved it (w/o
ARC). This kind of hack could be set up really quick. >
Please please can we stop doing this. Trying to unmunge rewritten From:
headers is
On Mon, 8 Aug 2022, Alessandro Vesely wrote:
It also misses the fact that "already reported characteristics" is
undefined.
Right, that's to be defined. Clearly, the criteria differ between SPF and
DKIM. We could also define fuzzy criteria.
Mike and I just provided separate reasons why
Moving this back to the main list:
I said:
Even if I agreed that it would be a good idea for every mailing list in the
world to rewrite From lines so it's harder to tell who the messages are from and
you can't reply reliably, there's no way that would survive last call.
Remember that a few large
By remembering failure reports issued in the past, new failures having
already reported characteristics (e.g. same forwarder) can be silently
ignored. That would greatly reduce noise.
This is a horrible idea. It presupposes that failures from the same origin
(e.g. same forwarder) at different
I don't understand what you mean by "no data collection." It is true that
you can send a failure report immediately without saving anything for
later.
“Those who cannot remember the past are condemned to repeat it.” – George
Santayana, The Life of Reason, 1905.
Perhaps I'm unusually dense
On Fri, 5 Aug 2022, Alessandro Vesely wrote:
On Fri 05/Aug/2022 04:44:21 +0200 John Levine wrote:
DMARC uses available information to produce a result of "Authenticated" or
"Not Authenticated". Sometimes, the message can be reliably categorized
as "Authenticated" or "Not Authenticated"
I think that Ale's expression that he had difficulty understanding the
description of the tree walk as written is a strong sign we still need
to improve the language. Of the people involved in this specific
discussion, as far as I know, he's the only one who's first language
isn't English.
That's the reason people set p=quarantine; pct=0; t=y. Indeed, if there is a
failure, one would want to fix something.
I suggested that, we'll see.
This morning on Twitter @mnot noted with alarm that failure reports
about list messages give you a pretty good idea about who some of the
list
I still don't see any value in adding text like this. The description of
the tree walk is clear enough.
On Wed, 3 Aug 2022, Alessandro Vesely wrote:
On Tue 02/Aug/2022 14:33:21 +0200 Barry Leiba wrote:
I think it is useful to include a brief explanation of why we moved away
from the PSL,
How about this:
In general, it is not possible to determine the cut points
in DNS where a change of management occurs. However, DMARC
users define DMARC records at their Organizational Domain,
so it is possible to discover them based on that.
I'm with Barry. I see no reason to
I didn't use zone cut /instead of/ organizational domain. The paragraph I
wrote was meant to introduce readers to the network topology onto which
organizational domains are defined, so as to justify the algorithm.
But zone cuts are irrelevant to the tree walk and have nothing to do with
the
On Sun, 31 Jul 2022, Murray S. Kucherawy wrote:
You could make the argument that you "usually" find DMARC records at zone
cuts, but that's relying on convention or happenstance rather than a
standards-quality framework.
Right, we went through all of this in the failed DBOUND discussion.
If it
Sorry, but this is just wrong. DMARC and the tree walk have nothing, and I
emphasize nothing, to do with zone cuts.
I thought a zone cut marked the boundary where an organization delegates
control to another one.
No, it's the place where one set of name servers delegates part of their
DNS
I made a pull request that changes the PSD example to show how names under
a PSD are and aren't aligned, It uses giant.bank.example and
mega.bank.example, with bank.example having psd=y.
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/95
Regards,
John Levine, jo...@taugh.com,
Is there an agenda for our session? I don't see one its slot on the 114
website.
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
I hope you agree that .com is a domain. The spec says that in order to
discover the Organizational Domain for a domain, I can perform the DNS Tree
Walk as needed for any of the domains in question. That way, the domain in
question, .com, is the Organizational Domain of itself. That is wrong
I made another pass over the draft to clean up some of the descriptions.
The discussion of PSDs is shorter and clearer, and I made a few small
changes in the tree walk to make it clearer.
I think we need to make clear that the RFC5322.From domain, the
RFC5321.MailFrom domain, and the DKIM d=
I made a pull request from Scott's examples, lightly edited.
Also added a few lines to the makefile to make a diff between the current
and previous versions.
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before
On Fri, 15 Jul 2022, Alessandro Vesely wrote:
+1 from me too. Note, though, that the (current) DNS is accidentally correct
most of the time, as far as our Tree Walk is concerned.
No, it's not an accident. We designed the tree walk based on our
knowledge of the way people publish DMARC
On Fri, 15 Jul 2022, Alessandro Vesely wrote:
Organizational Domains are defined as PSD+1, and can have DMARC records
I think this would be a good time to review the way relaxed alignment
works in sections 4.5 through 4.8 of the draft.
Perhaps 0.01% of the time, a tree walk will find a
On Thu, 14 Jul 2022, Scott Kitterman wrote:
In my view, standardizing two ways to do policy discovery and alignment would
be a substantial danger to interoperability and we'd be stuck with it
approximately forever.
I agree, it's a self-evidently terrible idea. "Temporary" transition
periods
On Wed, 13 Jul 2022, John Levine wrote:
It appears that Murray S. Kucherawy said:
Speaking as an AD now, you should expect me to complain about the "SHOULD"
in Section 4.7.
I went through and looked at all of the "must" and "should", in both upper
and lower case.
A lot of the lower case
A.6 seems to be dealing with a different subject. I can still sketch some
text to be added there, though. I attach the diff.
I realize this is getting repetitive but:
-- PSDs are very, very rare, and users will generally never see them
-- long discussions of PSDs will just confuse people
--
On Mon, 11 Jul 2022, Alessandro Vesely wrote:
We are proposing an alternative to the PSL without having any experience of
it. I think a Proposed Standard should give full explanations of design
choices, so that possible, future amendments can be thoughtful and
considered.
Could you explain,
I changed it in a pull request a few weeks ago.
If you don't stop on the first psd=y that is not the original domain,
you get the wrong result if there are DMARC records above the psd=y.
I sent this example on June 21, link is
The description of the tree walk should be clear enough.
Yeah, /should/! The very fact that you yourself changed your mind about how
it works, without going into the hassle of explaining your reasoning, ...
Um, what? Scott and I went through some rounds of debugging to be sure
the tree
On Wed, 29 Jun 2022, Alessandro Vesely wrote:
Would you please show an example, realistic or not, where not stopping for
psd=y in step 2 leads to a useful result?
Keeping in mind that this is an arcane corner case that affects perhaps a
few hundred of the 100,000 domains that are likely to
What can one find continuing the walk after psd=y?
I have looked at every domain in the PSL that publishes a DMARC record and
other than the three that are in Scott's PSD list, what I found was
totally random. Some looked reasonable, some looked broken. In practice
I think the details are
Please recall what you said in April:
How about if we say that if the initial domain has psd=y, that's the org
domain and you don't look anywhere else. That is easy to explain and I
don't think we are likely to find anything that better matches the
expectations of people who send
I made a pull requests with a few tweaks to the tree walk so it will
get the right answer even with psd tags at multiple levels.
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/47
One question is what do you do if the DMARC record for your original From:
domain has psd=y. My
1 - 100 of 412 matches
Mail list logo
