Section 4.6 to 4.8 is the most important part of our document. After an
abundance of preliminaries, this material defines the actual evaluation
procedure. More than any other area, it needs to be clear and complete
and procedural. If developers finds our text to be vague, implementations
will
complexity of parsing A-R records can be neglected.
>
>
> Best
> Ale
>
>
> On Tue 20/Sep/2022 03:18:15 +0200 Douglas Foster wrote:
> > The whole point of RFC 7960 is that a DMARC FAIL is an ambiguous result.
> > I suggest that either our document or its successor n
rtion as to the
> authentication status of the message at the point they signed it.
>
> Ken.
>
> On Mon 19 Sep 2022, 18:31 Douglas Foster, <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> I am trying to specify the generic form of a local policy rule to
I am trying to specify the generic form of a local policy rule to trust ARC
to override DMARC FAIL.
This is my current draft:
- The message's RFC532.From address indicates a wanted and valued sender.
- The message produces DMARC FAIL.
- The ARC chain is intact
- An ARC-A/R entry exists and indi
Covering all scenarios is what ensures consistent implementations and
protects against crafted malicious data.
Corner cases matter.
On Fri, Sep 2, 2022, 1:59 PM John R. Levine wrote:
> >> I will agree with Ale somewhat. While we should say that PSDs MUST NOT
> >> publish a ruf= tag, it would
Todd, your confusion makes me think we do need a four-valued identifier.
Any domain might be used to send mail, legitimately or fraudulently, and
may have a DMARC record. Therefore, an initial PSD=Y is always a
possibility.
Initial PSD=Y means that an organizational boundary exists below the
cur
As currently defined, psd=u seems to contain no information and be
identical to no token. I see no value in defining a tag that has no
meaning.
It could optionally be defined to mean "this is an organizational subdomain
which will lead to a psd=n tag". Then if the Tree Walk ends on anything
oth
rote:
> Where in the document are you proposing this text be added?
>
> Scott K
>
> On August 28, 2022 9:04:18 PM UTC, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> >I have stewed on the issues more while mowing the lawn. The language
> >b
> Scott, John, and Mike in that I don’t see a real-world benefit either.
>
> Barry
>
> On Sun, Aug 28, 2022 at 3:03 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> The PSL has two problems:
>> - It removes control of relaxed authenticatio
ed by text suggestions,
> preferably in an OLD/NEW format.
> >
> > Doug, if you believe there is an issue here within scope of the text I
> quoted from Barry, please cite the section and text in the document and
> propose updated language.
> >
> > Otherwise, the t
Alternative token design.
Boundary=A (Above only)
Literal: The domain owner asserts that an organizational/administrative
boundary exists between the current domain and its parent, meaning the
domain and its parents are not aligned for relaxed authentication. No
boundary exists immediately below
pe definition so severely that
we cannot find a couple of sentences to include these exceptions in the
document. But as long as the reader understands that these cases are not
relevant because they do not fit the strict scope definition, then so be it.
Doug
On Wed, Aug 24, 2022 at 2:38
I understand the need to limit scope, if DMARC limits its claims to what it
covers. This complaint was triggered largely with the "MUST NOT" claim in
the draft, which implied that DMARC is the all-inclusive tool for
validating the RFC5322.From address using SPF and DKIM. If it is all
inclusive, i
ting evaluators to ignore this information is
unreasonable. Using this document in an effort to prevent them from
knowing that they should do so is unacceptable.
Doug
On Tue, Aug 23, 2022 at 7:24 AM Todd Herr wrote:
> On Mon, Aug 22, 2022 at 9:14 PM Douglas Foster <
> dougfoster.emai
If an ARC chain with SPF PASS demonstrates that a list post is legitimate,
it only does so because the evaluator is testing alignment (exact match)
between the domain reported in the ARC results and the domain of the FROM
address on the message. This is the DMARC verification algorithm, without
t
Mailing lists are supposed to be a closed group. This means that posts
should only be accepted if they are verifiably from the subscriber
indicated in the RFC5322.From address. This requirement means that a list
needs a mechanism for verifying the RFC5322.From address, and the mechanism
needs t
The errata should be against that final paragraph of section 3.6 in RFC
5321, as the MUST NOT prohibition is simply wrong in theory and is ignored
in practice. RFC 7489 is fine as written.
Many MTAs have the dual role of deciding whether a message should be
relayed, as well as deciding where it s
This is just a test, please discard.
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
We will not be
> revisiting our charter while dmarc-bis is in progress.
>
> Seth, as Chair
>
> On Thu, Aug 18, 2022 at 2:07 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Out of scope? Scope is a choice, and is negotiable with those who
>&g
Out of scope? Scope is a choice, and is negotiable with those who approve
charters.
We could define scope to be "technologies which help evaluators correctly
identify messages from wanted senders, while hindering malicious
impersonators".
If we define our desired end result, we are more likely
If RFC7591bis is attempted, I suggest that we need result types for
authenticated reception, such as
- SMTP Auth of Mailfrom address
- SMTP Auth of server using an address other than MailFrom
- SMTP whitelist of server IP
- Trusted server via VPN Tunnel
The particular concern relates to outbound f
We have three possible protocol modes:
1) Evaluator using RFC 7489 with any domain owner policy
2) Evaluator using DMARCbis with domain owner publishing policies based on
RFC 7489 only
3) Evaluator using DMARCbis with domain owner publishing policies based on
DMARCbis
We know that the first mode
The problems with the document have not been corrected.
1) Wrong goal: the design equates the transition state with the final
state, preventing us from addressing the whole problem.
2) Wrong tag design: 3 tags are used to describe 5 states, because
omitted tags are a goal to be achieved rath
guide me.
Doug
On Thu, Aug 11, 2022 at 12:26 PM Murray S. Kucherawy
wrote:
> 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 mai
Ale's approach has the best fit with our current reality. Lists continue
to mung everything, because they cannot or will not mung conditionally, and
this ensures that nothing is blocked by P=reject.
Participating lists also supply an author field to simplify un-munging, and
probably a DKIM signa
ulnerability for all of their recipients.
Doug
On Thu, Aug 11, 2022 at 12:29 AM Murray S. Kucherawy
wrote:
> 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
and which have not. Making ARC work involves
> having it implemented widely enough that the other workarounds are
> needed seldom enough that we don't have to do them any more.
>
> Barry
>
> On Wed, Aug 10, 2022 at 9:16 AM Douglas Foster
> wrote:
> >
> > To avoid
"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 the interest of his own
recipients.
Consider the possible causes of DMARC FAIL:
Failures that can be
To avoid munging, MLMs have a double problem: (1) the evaluator must find
an alternative to DMARC for concluding that the message is "not untrusted",
and (2) the MLM must know that this trust has been granted.
If (2) is known for some recipients but not others, the MLM must be able to
make mungi
You misconstrue. This is not about guesswork.
SPF PASS and DKIM VERIFIED provide proxy verification of the From address,
comparable to a badge reader authenticating an employee, or perhaps more
closely, a notary seal with attestation validating a document signature.
DMARC policy primarily provi
at is necessary for trusting a list message when
trust is granted.
Doug
On Mon, Aug 8, 2022, 3:10 AM Laura Atkins wrote:
>
>
> On 8 Aug 2022, at 05:10, Murray S. Kucherawy wrote:
>
> On Sun, Aug 7, 2022 at 4:07 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote
Yes.
Evaluators need to use much more sophistication, when applying DMARC, than
simply applying the formula and doing whatever the policy suggests.
Developers need to provide exception mechanisms which permit that
complexity to be implemented as local policy. This means we need language
to depre
The most obvious shortcuts are that names must match on the right-most two
labels before the org domain is found, and must match on the entire org
domain once it is known.
A high percentage of tree walks can be eliminated with these two tests.
On Sun, Aug 7, 2022, 2:56 PM John Levine wrote:
> I
Ale is correct, the current outline is flawed.
Organizational domain determination and default policy determination are
one process, not two, and should be described together.
Relaxed alignment checking cannot begin until the organizational domain has
been determined, and should be a separate top
What is the applicable section and wording? I could not find it. Sorry
to be obtuse on this point.
Doug
On Sat, Aug 6, 2022, 5:05 PM John Levine wrote:
> It appears that Murray S. Kucherawy said:
> >-=-=-=-=-=-
> >
> >On Tue, Aug 2, 2022 at 4
n.com", because com does not have a DMARC
policy. I cannot understand the usefulness of that distinction.
Doug
On Sat, Aug 6, 2022, 1:30 AM Murray S. Kucherawy
wrote:
> On Fri, Aug 5, 2022 at 5:02 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>&
Yes.
When the same-domain policy exists and contains the "psd=y" token, then
alignment is forced to "strict" for both SPF and DKIM.
On Sat, Aug 6, 2022, 1:20 AM Murray S. Kucherawy
wrote:
> On Tue, Aug 2, 2022 at 4:34 AM Douglas Foster <
> dougfoster.em
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 discovery of a DMARC
policy (or SPF policy or DKIM key), then it should be explicitly tested for
existence a
First of all, this is not Best-Guess SPF, because it is not a guess.
DMARC is all about authentication - it says that a message has, or has not,
been judged to be free of impersonation risk. What it does not say is
whether a message is wanted, because "wanted" involves much more than
authenticat
Consider two names:
u...@promotions.fake.bank, where "fake.bank" is non-existent.
"promotions.fake.bank" is therefore also non-existent.
and
u...@promotion.real.bank, where "real.bank" exists, but
"promotions.real.bank" does not exist.
We can assume that the marketing department made up the
"prom
where in the document the text you're
> commenting about is, but you haven't said and it's not clear to me.
> Can you cite the specific text and say in what section it is?
>
> Barry
>
> On Wed, Aug 3, 2022 at 11:41 PM Douglas Foster
> wrote:
> >
> >
RFC 9091 provides a way to detect misuse of unregistered organizations, one
level below the PSD/Registrar level. Use of an unregistered name is
inherently a form of unauthorized impersonation. Consequently, the test
may be used whether the PSD has published a policy or not, and the default
can
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 address(es). But the specification does not require evaluators
to send reports and does not require domain owner
Despite the discussion, the text still seems to say nothing about the case
of a PSD=Y policy on the same-domain policy.
A guiding principle of the move to tree walk is to get accurate boundary
data by giving domain owners the ability and responsibility to publish
those boundaries. That means th
Correction: GOV.UK is not part of the UK organization, therefore relaxed
alignment does not apply
On Tue, Jul 26, 2022 at 7:11 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I don't see that the text reflects Ale's understanding either, and I think
> he
dro Vesely wrote:
> On Mon 25/Jul/2022 12:56:02 +0200 Douglas Foster wrote:
> > We had a discussion about domains that need to set both PSD=Y and
> > PSD=N. It highlighted one of the problems with using a tag which
> > implies mutual exclusivity when exclusivity does not app
Yes I should have said psd=y or psd=7, to match the later material in item
7.
On Mon, Jul 25, 2022, 9:27 AM Alessandro Vesely wrote:
> On Mon 25/Jul/2022 12:45:30 +0200 Douglas Foster wrote:
> > 4.6 DNS Tree Walk
> >
> > 2. Records that do not start with a "v
I was asking a question: where does the text say that PSD=y forces strict
alignment?
On Mon, Jul 25, 2022, 10:24 AM Scott Kitterman wrote:
>
>
> On July 25, 2022 1:27:07 PM UTC, Alessandro Vesely wrote:
> >On Mon 25/Jul/2022 12:56:02 +0200 Douglas Foster wrote:
> >> W
When the organizational domain name search walks up to a PSD=Y policy, what
alignment should be used?
The primary purpose of the PSD policy was to hinder usage of non-existent
names, and to provide a reporting destination.But since a PSD=Y policy
can be used for authenticating messages from it
We had a discussion about domains that need to set both PSD=Y and PSD=N.
It highlighted one of the problems with using a tag which implies mutual
exclusivity when exclusivity does not apply.
The stated solution was that when PSD=Y is found on the same-domain policy,
then PSD=N is also assumed, wh
4.6 DNS Tree Walk
2. Records that do not start with a "v=" tag that identifies the
current version of DMARC are discarded. If multiple DMARC
records are returned, they are all discarded. If a single record
remains and it contains a "psd=n" tag, stop.
7. Records that do no
When a topic is decided with consensus, it does not get reopened.What
happened here?
On Sun, Jul 24, 2022, 9:35 PM John R Levine wrote:
> >> 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
> T
Ale's point is part of a larger inefficiency. As information is gathered,
the candidate names can be reviewed for a match. If a match is obtained,
the result is PASS and the algorithm exits. If not, then candidate names
which can be ruled out are discarded. If this makes the candidate list
em
Barry is technically correct: Any coding system can be technically
sufficient if it is explained.We could, for example, choose
qzx=(#|&|~) instead of psd=(y|n|u)
Of the infinite set of choices, how do we choose one, or does it even
matter? The answer should be driven by the needs of the re
This optimization is only relevant when a very inefficient algorithm is
being used. There is no reason to ever compute all of the organizational
domains for all of the candidates for relaxed authentication.
A highly simplified summary of the new DMARC process looks like this:
1) Check for and u
n imperfect PSL. Are we obligated
to perpetuate vulnerabilities for the sake of upward compatibility?
Doug
On Mon, Jul 18, 2022 at 5:57 AM Scott Kitterman
wrote:
>
>
> On July 18, 2022 9:21:33 AM UTC, Alessandro Vesely wrote:
> >On Sat 16/Jul/2022 16:20:09 +0200 Douglas Foste
Any single message has three verification states and five policy states.
Verification states:
MATCH - The message has at least one identifier that is verified and
exactly matches the FROM domain.
INEXACT - The message has at least one verified identifier that may pass
relaxed alignment because it
I remain concerned about the often-stated position that the DMARC
specification is OK if it only produces false PASS in rare cases. False
PASS is never OK, and our goal should be to prevent the problem rather than
ignore it.
In RFC 7489, PASS is a consolidation of 8 different trust indicators, bu
This is about Ale's question about handling the situation where the tree
walk starts on a PSD=y entry:
When the tree walk starts at a PSD=Y record, the appropriate response is to
treat it as a self-contained organization (PSD=N) and force alignment to
STRICT for both SPF and DKIM.
This rule appli
We can limit the transition period by specifying a date, after which any
untagged record is interpreted with strict alignment.
On Wed, Jul 13, 2022, 11:10 AM Murray S. Kucherawy
wrote:
> Once again, participating only:
>
> On Wed, Jul 13, 2022 at 3:43 AM Dougl
t
the assumptions and risks to the evaluator, and lets them decide what to
do. This is what sections 4.7. and 4.8 in my text from Sunday night
attempted to do.
Doug
On Wed, Jul 13, 2022 at 1:12 AM Murray S. Kucherawy
wrote:
> Hatless once again.
>
> On Tue, Jul 12, 2022 at 3:08 PM
nting and therefore inconvenient, while the tree walk errors are
likely to be org-consolidating and therefore grievous.
I do not see that we have changed the risk profile favorably. Please help.
DF
On Tue, Jul 12, 2022, 2:41 PM Todd Herr wrote:
> On Tue, Jul 12, 2022 at 1:30 PM Dougla
What problem does this tree walk solve? Can anyone explain how this tree
walk improves on RFC7489 evaluation results?
On Tue, Jul 12, 2022, 11:13 AM John R Levine wrote:
> > A.6 seems to be dealing with a different subject. I can still sketch
> some
> > text to be added there, though. I att
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 percent. The size of the fraction is not a reason to ignore a
problem. I support a change. But is th
Barry challenged me to provide specific text needed to address my concerns
with the current draft.. The changes are significant. My first pass
appears below/ I have not yet tried to create a full XML draft yet, but
wanted to get the changes introduced.
Key changes
1) Added definitions.
2) Add
I see no personal attack. John was clear, and has been clear, that he has
no intention of documenting any limitations or risks associated with the
tree walk, because in his judgement, they are not important. My concern
is about a document that creates a new vulnerability, then fails to
document
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 he does not wish exposed.
Chairs, does IETF support this approach to design?
DF
On Thu, Jul 7, 2022 at 4:33 PM John Levine wrot
Yes, PSD is still the appropriate term for a PSO-controlled domain. We
need an additional definition for a "Private Registry Domain" (optionally
"PRD" if we want to create another acronym.) Collectively, PSDs and PRDs
are "registry domains". We intend to use a single DNS token for both PSD
an
The latest draft continues to blur the rather substantive differences
between the two tree walks. Important details get lost with no clear
place to add the text needed to fix omissions. For example, the first
tree walk terminates in four different ways, and each termination method
has different
icitly tagged. As long as that assumption holds, I
think the design works properly, even with additional private registry
layers.
DF
On Thu, Jun 30, 2022 at 2:30 AM Murray S. Kucherawy
wrote:
> On Wed, Jun 29, 2022 at 7:18 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com>
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.
So the question is "How do I know which one applies?" The best solution
is for the domain owner registrar
reason to contain any other resource record
either. However, in this week's testing, every TLD or PSD tested is
returning NODATA. So I don't understand my results.
Doug
On Tue, Jun 28, 2022 at 2:03 PM Todd Herr wrote:
> On Mon, Jun 27, 2022 at 8:36 PM Douglas Foster <
> dou
.br
71.28.plusnetprovedor.net.br: Non-existent domain
> 28.plusnetprovedor.net.br
Non-existent domain
> plusnetprovedor.net.br
Name:plusnetprovedor.net.br
On Mon, Jun 27, 2022 at 9:52 AM Todd Herr wrote:
> On Sun, Jun 26, 2022 at 1:27 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.co
forum:
mail.foodnetwork.com
returns NXDOMAIN
but
_dmarc.mail.foodnetwork.com
returns DATA for type=TXT
On Mon, Jun 27, 2022 at 9:52 AM Todd Herr wrote:
> On Sun, Jun 26, 2022 at 1:27 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Our draft references
I could accommodate myself to PSD=Y, if we wer to document that "PSD" in
this context means either "Public Suffix Domain" or "Private Suffix Domain"
I oppose use of the PSD=N tag to indicate an organizational domain. The
use of PSD=N originated because some participants believed that explicit
ta
Our draft references and repeats RFC 8020, which asserts that
"when a DNS resolver receives a response with a response code of NXDOMAIN,
it means that the domain name which is thus denied AND ALL THE NAMES UNDER
IT do not exist."
My testing indicates that this is not correct. NXDOMAIN means tha
Clarity:
The two types of tree walks have different starting conditions, different
ending conditions, and different processing tasks at each iteration. So I
think clarity will be improved by describing them separately.
Efficiency:
The purpose of the secondary tree walk is to confirm alignment, b
Before we move to coding the similarities, differences, and risks into the
document, it would be useful just to generate a complete list within this
WG.
It would certainly be a breach of trust to omit information from the
document, if done for the purpose of hiding tree walk limitations.
Doug
On
I fully support replacing the PSL with organization boundary information
provided by domain owners and registrars, as that data becomes available.
We have good theoretical reason to conclude that domain owners and
registrars have the best knowledge about boundaries, and appropriate
incentives to re
Let's talk through the selling process for the Tree Walk algorithm.
Who are our Stakeholders?
There are three main stakeholder groups for DMARC: Senders,
Intermediaries, and Evaluators.Senders and Intermediaries just want to
ensure their messages get delivered. Evaluators have the m
To avoid more argument, it is time to do a consensus check.
A) To allow the Tree Walk to proceed without dependence on new policy
flags, it is necessary to ignore the risks created by private registries.
This will allow malicious impersonation within some private registries to
be undetected and p
I have done a lot of thinking about the current confrontation and how to
bridge it.
The problem seems rooted in our different attitudes toward the PSL. If
one assumes that the Tree Walk must displace the PSL completely and
quickly, then it becomes necessary to “make do” with incomplete informati
ad.
>
> Let's have an example of a real domain, with a real DMARC record, that
> would be negatively impacted by being assessed using the DMARCbis design. I
> haven't found any I think are problematic, but if you have, I'm all ears?
>
> Scott K
>
> On June 12
Les' question has returned us to the problem of justifying the tree walk.
We need to document the problems with PSL, but we also need to demonstrate
that the tree walk solves those problems without creating others.
In most cases, the tree walk and PSL will produce the same results, because
they w
Todd, as you prepare for the next draft, I want to restate my significant
concerns with the previous draft and subsequent discussions:
1) Private Registres
Private registries are a significant design consideration because they
cause a single DNS path to have two organizational boundaries instead o
Do you manage a message stream that uses DMARC results in the message
disposition decision?
If so,
- How often is a DMARC result determinative to your disposition?
- What other factors whether the DMARC result is significant?
- What best practices do you recommend for using DMARC data?
All of the spf issues spply to dmarc as well.
.
But I still assert that the answer is that these addresses are intended for
inbound only and that the problem is unsolvable if they are used for
outbound.
Verisign could certainly do something different, but it is not in their
interest to do so.
Thi
.
Verisign wants to be the S/MiME solution for any mailbox provider account,
not rhe competition for them.
Doug
On Wed, Jun 1, 2022, 6:27 AM Alessandro Vesely wrote:
> On Wed 01/Jun/2022 05:14:22 +0200 Douglas Foster wrote:
> > As John observed, there is no way to provide outbound authentic
David's goal for the name registration is different from what Verisign
intended. Here is what I have inferred:
Verisign wants to sell personal identity PKI certificates to the masses,
for use with S/MIMIE. A personal PKI certificate requires a subject name
and an owner email address. "first.l
Private registries create a problem for the PSD for DMARC specification.
The subtree underneath the PSD policy may include the PSD-registered
organization and potentially the client of that organization, if the
organization operates a private registry.
Presumably, in some cases such as .Bank, the
That part of the design is unchanged. We check for an exact-match policy
first, and it is used if it exists. The tree walk is used to find an org
domain when the exact-match policy is not present, and to find the subtree
scope for relaxed alignment when relaxed alignment is specified.
On Tue,
Unfortunately, the PSL is not an adequate tool for validating the Tree Walk
algorithm. You disparaged that idea when I proposed it earlier, and you
were right.
The expected PSL error is domain fragmentation, because
Cross-Site-Scripting scope boundaries are likely to be narrower than email
domai
Alessandro has figured me out. I am trying to be very clear about the
advantages of strict alignment and same-domain policies.I would stop
short of calling it a campaign, because I have no intent of trying to
deprecate the other options.
Security considerations are about ensuring that the ev
stand why you think it is
already handled by the existing text.
On Sun, Apr 24, 2022 at 11:57 PM Scott Kitterman
wrote:
> On Sunday, April 24, 2022 9:16:04 PM EDT Douglas Foster wrote:
> > I have attempted to capture the security-related content of recent
> > discussio
I have attempted to capture the security-related content of recent
discussions:
Security Considerations
Determination of the Organizational Domain
DMARC evaluation is highly sensitive to errors in the determination of the
organizational domain, as the organizational domain is used for the defaul
RFC 7489 says that the p=(none|quarantine|reject) term is required (Section
6.3, page 17).
We could preserve that requirement or state that p=none can also be taken
as a default.
On Sat, Apr 23, 2022 at 1:50 PM John Levine wrote:
> It appears that Damian Lukowski said:
> > From the perspective
d, is there any issue you see with
> the tree walk that isn't equally a problem if the putative hostile
> registrar asks for a change in the PSL?
>
> Scott K
>
> On April 20, 2022 10:56:01 AM UTC, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> >This i
y lower level entity for these
> PSDs
> that has a problem would be able to publish psd=n and stop it.
>
> Scott K
>
> On Tuesday, April 19, 2022 8:18:53 PM EDT Douglas Foster wrote:
> > Scott asked for my list, so it is attached. I walked up the tree from
> the
> &
Scott Kitterman
wrote:
> On Monday, April 18, 2022 10:14:37 PM EDT Douglas Foster wrote:
> > Concern 1
> > Of the several thousand private registry domains listed in the PSL, 45
> have
> > DMARC policies at or above the registry point. 40 of these 45 specify
> > relax
Glad to have your opinion on this. What is your process for determining
whether a private registrar's clients use their subtree for mail? I am
aware of several technical obstacles to making that sort of determination,
so I wonder how you both resoled those obstacles.
The jump-to-5 rule was chos
301 - 400 of 693 matches
Mail list logo
