On Mon 18/Jul/2022 12:18:00 +0200 Scott Kitterman wrote:
On July 18, 2022 9:37:25 AM UTC, Alessandro Vesely wrote:
The reason I want to change it is that a mail From: brings the tree
walk process to conclude that .com is an organizational domain, which is wrong.
Since com. doesn't h
On Sun 17/Jul/2022 17:09:06 +0200 Scott Kitterman wrote:
Without John's change in the other step 2, that of Section 4.6, this step 2
should have been worded differently, but the concept is that a PSD which sends
mail or signs messages should be treated as a regular (sub)domain,/within/ the
On Sun 17/Jul/2022 19:05:58 +0200 John R. Levine wrote:
I made a pull request from Scott's examples, lightly edited.
Could we please add a convoluted PSD example?
5322..From domain
: psd.example.com
5321.MailFrom domain
: mail.psd.example.com
DKIM-Signature d=
: signing.psd.example.com
Th
On Sat 16/Jul/2022 16:20:09 +0200 Douglas Foster wrote:
My proposal:
Sibling authentication should be disabled by default, even for
policies that specify relaxed authentication. Those organizations
that want sibling authentication should explicitly request it using a
tag (to be defined) on
On Sat 16/Jul/2022 18:15:56 +0200 Scott Kitterman wrote:
However, if you're coding the tree walk, d=; forces you to consider the
assumptions you need to put on the input domain. Namely, it must neither
be the root nor a PSD. Right?
No. It doesn't come up. In 4.8, the input to the tree walk i
On Sat 16/Jul/2022 18:12:14 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
No, it's not an accident. We designed the tree walk based on our knowledge of
the way people publish DMARC records.
I don't understand this unwearying opposition irrespective of the
arg
On Sat 16/Jul/2022 18:00:25 +0200 Scott Kitterman wrote:
On Saturday, July 16, 2022 11:56:04 AM EDT Alessandro Vesely wrote:
On Sat 16/Jul/2022 17:34:24 +0200 John Levine wrote:
It appears that Scott Kitterman said:
I think the proposed change is incorrect. To pick a real example, gov.uk
On Sat 16/Jul/2022 17:34:24 +0200 John Levine wrote:
It appears that Scott Kitterman said:
I think the proposed change is incorrect. To pick a real example, gov.uk is a
PSD with a DMARC record. It's one that I expect will add psd=y once the tag
is assigned.
There is no benefit from preventi
On Sat 16/Jul/2022 16:43:02 +0200 Scott Kitterman wrote:
On Saturday, July 16, 2022 7:50:04 AM EDT Alessandro Vesely wrote>>
[...]
A mail receiver receives an email with 5322.From domain = example.com,
5322.MailFrom domain = example.com, and a DKIM signature with d =
signing.examp
Alleluia!
Couple of notes below:
On Sat 16/Jul/2022 09:17:54 +0200 Scott Kitterman wrote:
When I have implemented RFCs in the past, I have found the examples to be
critical to making sure I understand the RFC correctly. Generally, among my
first goals is to ensure I can replicate the example
On Fri 15/Jul/2022 18:03:36 +0200 John Levine wrote:
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
On Fri 15/Jul/2022 13:23:20 +0200 Laura Atkins wrote:
On 15 Jul 2022, at 12:02, Alessandro Vesely wrote:
On Wed 13/Jul/2022 23:51:31 +0200 John Levine wrote:
I went through and looked at all of the "must" and "should", in both upper and
lower case.
A lot of the lower ca
On Fri 15/Jul/2022 21:28:09 +0200 Scott Kitterman wrote:
On July 15, 2022 6:26:39 PM UTC, "John R. Levine" wrote:
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
On Wed 13/Jul/2022 23:51:31 +0200 John Levine wrote:
I went through and looked at all of the "must" and "should", in both
upper and lower case.
A lot of the lower case "must" was saying that one thing is the same
as another using tortured syntax so I rewrote most of them to be
shorter an
On Thu 14/Jul/2022 17:12:19 +0200 Murray S. Kucherawy wrote:
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
On Wed 13/Jul/2022 17:56:08 +0200 Scott Kitterman wrote:
On July 13, 2022 3:10:38 PM UTC, "Murray S. Kucherawy"
wrote:
Once again, participating only:
On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster wrote:
[...]
3) The critical question is whether we can treat the PSL as replaced
without ob
On Tue 12/Jul/2022 17:12:40 +0200 John Levine wrote:
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
On Wed 13/Jul/2022 07:12:25 +0200 Murray S. Kucherawy wrote:
If we want a migration period, some kind of hybrid model might work:
Do the DNS tree walk, but at each step, if you find you've hit a name
that's present in the PSL, you can stop and pretend you found a marker
you're looking for. Whe
On Wed 13/Jul/2022 07:32:37 +0200 Murray S. Kucherawy wrote:
Speaking as an AD now, you should expect me to complain about the
"SHOULD" in Section 4.7. Specifically, since "SHOULD" ultimately
permits a choice, we ought to [1] give implementers some guidance
about when one might opt not to do
On Mon 11/Jul/2022 21:54:25 +0200 John Levine wrote:
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
On Sun 10/Jul/2022 19:04:08 +0200 Scott Kitterman wrote:
On July 10, 2022 11:17:13 AM UTC, Alessandro Vesely wrote:
On Sun 10/Jul/2022 03:05:47 +0200 John Levine wrote:
It appears that Scott Kitterman said:
On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely wrote:
Yeah, /should/! The
On Sun 10/Jul/2022 03:05:47 +0200 John Levine wrote:
It appears that Scott Kitterman said:
On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely wrote:
Yeah, /should/! The very fact that you yourself changed
your mind about how it works, without going into the hassle
of explaining your
On Fri 08/Jul/2022 22:07:09 +0200 John Levine wrote:
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 th
On Thu 07/Jul/2022 22:32:56 +0200 John Levine wrote:
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, proves that a more extensive walk
tle
sympathy for this suggestion or some derivative of it. Using "psd" as
the tag name is rooted in history that will be lost as we move away
>from using a public suffix list.
Barry
On Mon, Jun 27, 2022 at 6:20 AM Alessandro Vesely
wrote:
On Sun 26/Jun/2022 18:05:44 +0200 Barry Le
On Wed 29/Jun/2022 19:17:05 +0200 Scott Kitterman wrote:
Yes, the example is contrived, but since there are no rules limiting delegation
to third parties, we cannot be sure how subdomains are going to evolve.
My view is that we are in a case that is sufficiently obscure that the answer to
c
On Wed 29/Jun/2022 12:40:36 +0200 Scott Kitterman wrote:
On June 29, 2022 10:16:00 AM UTC, Alessandro Vesely wrote:
On Tue 28/Jun/2022 18:46:18 +0200 Scott Kitterman wrote:
On June 28, 2022 4:33:15 PM UTC, Alessandro Vesely wrote:
What can one find continuing the walk after psd=y?
For
On Tue 28/Jun/2022 18:46:18 +0200 Scott Kitterman wrote:
On June 28, 2022 4:33:15 PM UTC, Alessandro Vesely wrote:
What can one find continuing the walk after psd=y?
For example, let's consider an imaginary bank, com.bank, say. They use that
domain as corporate domain, and have a
On Wed 29/Jun/2022 00:23:08 +0200 John R Levine wrote:
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, som
On Mon 27/Jun/2022 15:54:51 +0200 John R Levine wrote:
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 b
On Sun 26/Jun/2022 18:05:44 +0200 Barry Leiba wrote:
Please comment in this thread about whether you agree with making the
registration now, or whether you do not agree and why.
I'd like to make a last appeal to use more intuitive symbols to be used instead
of the current ones:
instead of
On Sun 26/Jun/2022 17:42:10 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
One question is what do you do if the DMARC record for your original From:
domain has psd=y. My text says you ignore it since if you're sending mail,
you're not really a PSD.
I disagree.
for the Author Domain -
dmarcbis-06
Date: Tue, 5 Apr 2022 10:43:49 +0200
From: Alessandro Vesely
To: dmarc@ietf.org
On Mon 04/Apr/2022 15:29:40 +0200 Scott Kitterman wrote:
>
> The diff is relative the last text I posted.
Section 5 has to stay before Section 4. It makes no sense to exemplif
On Thu 23/Jun/2022 03:50:29 +0200 Ángel wrote:
On 2022-06-22 at 08:39 -0400, Scott Kitterman wrote:
I agree. How about changing "Instead, some domains will inherit their DMARC
policy records from parent domains one level or more above them in the DNS
hierarchy" to "Instead, domains which have
These were already there in older versions, I only saw them no.
Section 4.6, DNS Tree Walk
The relevant DMARC record for these purposes is not necessarily the
DMARC policy record found in DNS at the same level as the name label
for the domain in question. Instead, some domains will inh
On Sun 19/Jun/2022 18:08:57 +0200 John R Levine wrote:
That seems like a pessimal way to make things interoperate: use one of
an unknown set of algorithms ...
Given that we're already working in an environment where it's unlikely that
everyone's working from a common version of the PSL, I don't
On Sat 18/Jun/2022 15:47:47 +0200 Scott Kitterman wrote:
The code to switch from PSL based organizational domain to tree walk based is
trivial. I think any marginal cost associated with implementing it or not
will be in the noise compared to the overall cost of designing, coding,
testing, and de
On Sat 18/Jun/2022 02:40:49 +0200 Scott Kitterman wrote:
On Thursday, June 16, 2022 11:57:08 AM EDT Alessandro Vesely wrote:
On Wed 15/Jun/2022 19:47:42 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
I think we found the few critical domains which need a flag.
We may have
On Wed 15/Jun/2022 19:47:42 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
I think we found the few critical domains which need a flag.
We may have found some domains that need a psd flag, but it's silly to
assert we have found all or even most of them.
The PSL has
On Wed 15/Jun/2022 04:40:31 +0200 Douglas Foster wrote:
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 information about
organizational
On Tue 07/Jun/2022 04:03:35 +0200 John Levine wrote:
Here's my alternate take: make the ABNF a lot simpler to
reflect the actual loose syntax.
dmarc-record= dmarc-version *(*WSP ";" *WSP dmarc-tag) *WSP *%x3b
dmarc-tag = 1*ALPHA %WSP '=' *WSP 1*dmarc-value
dmarc-value
On Mon 06/Jun/2022 22:05:08 +0200 Les Barstow wrote:
On a technical note, “0” and “1” generate DMARC failure reports, while “d”
produces a DKIM failure report and “s” produces an SPF failure report.
No, they are the same format specified in RFC 6591.
DKIM Failure Reporting (RFC 6651) and SPF
On Mon 06/Jun/2022 17:06:05 +0200 Todd Herr wrote:
Here's what's currently written in rev -07 for the subject at hand:
A DMARC policy record MUST comply with the formal specification found
in Section 5.4 in that the "v" tag MUST be present and MUST appear
first. Unknown tags MUST b
On Wed 01/Jun/2022 20:01:58 +0200 John Levine wrote:
It appears that Barry Leiba said:
(Not about Phill's message in particular: his is just the most recent
one to reply to.)
This was a fine topic to ask about, and the early discussion answered
the initial questions -- and pointed out, correc
On Wed 01/Jun/2022 12:42:03 +0200 Douglas Foster wrote:
Yes. But David said that Verisign forwards to your designated server,
rather than operating a mail store.
So j...@smith.name may forward to Hotmail while j...@smith.name may forward
to gmail., and j...@smith.name may forward somewhere else.
On Wed 01/Jun/2022 16:19:10 +0200 Todd Herr wrote:
On Wed, Jun 1, 2022 at 6:27 AM Alessandro Vesely wrote:
The point of domain level authentication, stressed by DMARC by requiring
alignment, is that hosting domains provide mail servers for both incoming
and outgoing messages. The old habit
On Wed 01/Jun/2022 05:14:22 +0200 Douglas Foster wrote:
As John observed, there is no way to provide outbound authentication for
these addresses, because authentication is based on domain name (and
changing that would take 100 years to deploy.) m...@smith.name and
jos...@smail.name are likely t
On Tue 26/Apr/2022 19:23:06 +0200 Scott Kitterman wrote:
On April 26, 2022 4:50:08 PM UTC, Alessandro Vesely wrote:
On Tue 26/Apr/2022 14:53:27 +0200 Scott Kitterman wrote:
On April 26, 2022 8:06:50 AM UTC, Alessandro Vesely wrote:
On Mon 25/Apr/2022 05:56:46 +0200 Scott Kitterman wrote
On Tue 26/Apr/2022 14:53:27 +0200 Scott Kitterman wrote:
On April 26, 2022 8:06:50 AM UTC, Alessandro Vesely wrote:
On Mon 25/Apr/2022 05:56:46 +0200 Scott Kitterman wrote:
How about something like this:
9.7 Determination of the Organizational Domain For Relaxed Alignment
DMARC evaluation
On Mon 25/Apr/2022 05:56:46 +0200 Scott Kitterman wrote:
How about something like this:
9.7 Determination of the Organizational Domain For Relaxed Alignment
DMARC evaluation for relaxed alignment is highly sensitive to errors in the
determination of the organizational domain if the RFC5322.Fro
On Fri 22/Apr/2022 08:40:34 +0200 Damian Lukowski wrote:
The record
v=DMARC1; rua=mailto:rep...@example.com; garbage=101; more-garbage
should not yield DMARC reports at all, as there is no DMARC record.
Some later document may specify additional tags, like garbage=1*DIGIT.
Tags with
On Wed 20/Apr/2022 15:46:19 +0200 Brotman, Alex wrote:
The main gist of the change was resolving a few inconsistencies that were
reported, as well as a few typos. Thanks folks.
I hope it will be possible to add some of the suggestions that emerged
about a year ago, mainly by Matt. Having r
On Thu 14/Apr/2022 05:54:32 +0200 Seth Blank wrote:
On Wed, Apr 13, 2022 at 2:25 PM Jim Fenton wrote:
On 12 Apr 2022, at 20:39, Seth Blank wrote:
Policies: https://dmarc.org/2022/03/dmarc-policies-up-84-for-2021/
Those are domains which publish a policy. An alternative graph here:
https:/
On Wed 06/Apr/2022 07:07:32 +0200 Scott Kitterman wrote:
On April 6, 2022 2:21:52 AM UTC, John R Levine wrote:
On Tue, 5 Apr 2022, Scott Kitterman wrote:
_dmarc.ac.me TXT "v=DMARC1; p=quarantine; adkim=r; aspf=r; fo=0; pct=100;
rua=mailto:dm...@ac.me";
ac.me mail is handled by 10 mail.ac.me.
On Wed 06/Apr/2022 01:01:46 +0200 Scott Kitterman wrote:
On Tuesday, April 5, 2022 12:22:57 PM EDT John R Levine wrote:
Scott took the time to define PSDs and PSOs in RFC 9091, restated in
Sections 3.2.8 and 3.2.9 of the current draft. Since the definitions of
Organizational Domain (both the cu
On Wed 06/Apr/2022 00:44:50 +0200 Scott Kitterman wrote:
On Monday, April 4, 2022 1:39:35 PM EDT Alessandro Vesely wrote:
On Mon 04/Apr/2022 15:14:07 +0200 Scott Kitterman wrote:
On Sunday, April 3, 2022 12:15:23 PM EDT Alessandro Vesely wrote:
On Mon 21/Mar/2022 23:02:03 +0100 Scott
On Mon 04/Apr/2022 15:29:40 +0200 Scott Kitterman wrote:
The diff is relative the last text I posted.
Section 5 has to stay before Section 4. It makes no sense to exemplify
_dmarc.example.com if we haven't yet said that:
Domain Owner and PSO DMARC preferences are stored as DNS TXT reco
On Mon 04/Apr/2022 19:31:36 +0200 John R Levine wrote:
If it's the original domain, yes.
We know that co.uk is not an Organizational Domain. Asking what is the
Organizational Domain of co.uk is an ill-posed question.
These are all in the PSL. What are their organizational domains?
Scott
On Mon 04/Apr/2022 15:14:07 +0200 Scott Kitterman wrote:
On Sunday, April 3, 2022 12:15:23 PM EDT Alessandro Vesely wrote:
On Mon 21/Mar/2022 23:02:03 +0100 Scott Kitterman wrote:
On March 21, 2022 5:42:42 PM UTC, Alessandro Vesely wrote:
According to the definition, two identical domains
On Mon 04/Apr/2022 17:24:34 +0200 John R Levine wrote:
On Mon, 4 Apr 2022, Alessandro Vesely wrote:
The last sentence is particular in that Section 4.8 aims at determining the
Organizational Domain for /any/ identifier, not just the From: domain. We
are assuming that an org domain can be
On Sun 03/Apr/2022 18:07:29 +0200 John R Levine wrote:
On Sun, 3 Apr 2022, Alessandro Vesely wrote:
(If the one beneath it has no DMARC record, is it still the org domain? I
think it is.)
This seems to be inconsistent with the sentence that follows. Would the
landscape change if .com
On Mon 21/Mar/2022 23:02:03 +0100 Scott Kitterman wrote:
On March 21, 2022 5:42:42 PM UTC, Alessandro Vesely wrote:
According to the definition, two identical domains having psd=y
are in strict alignment but not in relaxed alignment, which is
somewhat counterintuitive. >
Actually, no:
On Sun 03/Apr/2022 01:35:16 +0200 Scott Kitterman wrote:
On Wednesday, March 23, 2022 6:59:08 AM EDT Alessandro Vesely wrote:
Hm...
On Wed 23/Mar/2022 03:08:35 +0100 Douglas Foster wrote:
During my ruminations last night, I gained some clarity around that
question and wanted to highlight
On Sun 03/Apr/2022 04:49:03 +0200 John Levine wrote:
It appears that Scott Kitterman said:
2. In the policy discovery section I added a few sentences on which policy to
use once the policy record is identified. This doesn't change anything
relative to what's currently defined, but it seems
On Wed 23/Mar/2022 12:08:16 +0100 Douglas Foster wrote:
But we do have a difference between PSOs, which never send mail, and private
registrars, which may or may not send mail from the domain or subdomain used as
a private registration point. It seems desirable to resolve this ambiguity so
tha
Hm...
On Wed 23/Mar/2022 03:08:35 +0100 Douglas Foster wrote:
During my ruminations last night, I gained some clarity around that
question and wanted to highlight those conclusions. They simplify the
alignment search significantly:
- If the common substring is shorter than the Organizational
On Tue 22/Mar/2022 18:35:03 +0100 Ken O'Driscoll wrote:
I don't think there is any other place where the default is not one of
the explicit options. The benefit of psd=u, such as it might be, is to
make it more consistent, and to be clear that we really mean it when we
say that psd=y, psd=n. an
I think we need something like the following.
On Mon 21/Mar/2022 21:50:42 +0100 internet-drafts wrote:
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
OLD
5.5.4. Publish a DMARC Policy for the Author Domain
Once SPF, DKIM,
On Mon 21/Mar/2022 17:46:43 +0100 John R Levine wrote:
After thinking once more, it should be:
_dmarc.a.users.scale.virtualcloud.com.br v=DMARC1 (possibly)
_dmarc.users.scale.virtualcloud.com.br v=DMARC1; psd=y
_dmarc.scale.virtualcloud.com.br NO DATA
_dmarc.virtualcloud.com.br
Ouch, forget my previous message(s).
On Sun 20/Mar/2022 20:21:32 +0100 Alessandro Vesely wrote:
Then, suppose we have the following:
_dmarc.a.users.scale.virtualcloud.com.br NO DATA
_dmarc.users.scale.virtualcloud.com.br v=DMARC1
_dmarc.scale.virtualcloud.com.br NO DATA
On Mon 21/Mar/2022 01:23:58 +0100 Scott Kitterman wrote:
2. Due to the differing purpose of the PSL, there are cases where the correct
data for the PSL is not the correct data for DMARC (see the recent message
from John Levine with examples).
No, the PSL results are correct for those examples
On Sun 20/Mar/2022 20:47:57 +0100 John R Levine wrote:
On Sun, 20 Mar 2022, Alessandro Vesely wrote:
Maybe performance doesn't matter. However, what do we expect to find out by
a tree walk? We'd come to the same conclusion as using the ICANN only list
unless their record cont
On Fri 18/Mar/2022 20:30:09 +0100 John R Levine wrote:
You're right, those weren't a good example.
Try these from the PSL:
com.br
users.scale.virtualcloud.com.br
virtualcloud.com.br is not algned with a.users.scale.virtualcloud.com.br
(For the latter name it would start at users.scale.virtual
On Fri 18/Mar/2022 17:11:56 +0100 John R Levine wrote:
Repeating the tree walk, we'd get a different result if we find psd=y at
_dmarc.f.c.d. Is that realistic?
Yes, of course it is. Look at some of the PSL entries.
I may be dumb, but I stared at the PSL for a few minutes and couldn't thi
On Thu 17/Mar/2022 23:40:37 +0100 Douglas Foster wrote:
In the general case, we allow for this possible configuration:
public suffix domain segments
organization domain for public registration organization
subdomains of the organization
registration point for private registration clients
On Thu 17/Mar/2022 20:50:39 +0100 John Levine wrote:
It appears that Alessandro Vesely said:
To find the org domain for a domain:
chop the domain to the last five labels and walk up the tree.
stop when you find a DMARC record with psd or you hit the root.
if a record has psd=n
On Wed 16/Mar/2022 03:10:03 +0100 Douglas Foster wrote:
I started from the assumption that we would want to generalize NP into
organizations. But after spending a lot of time on the subject for the last
15 months, I am convinced that it is not needed.
Assume that a university or other organi
On Thu 17/Mar/2022 04:02:00 +0100 John Levine wrote:
It appears that Scott Kitterman said:
It took a fair amount of editing and I expect you all will have further
suggestions, so instead of getting up to my elbows in XML, I took the
published DMARCbis-05 text and updated it directly. The mod
On Tue 15/Mar/2022 02:54:21 +0100 Douglas Foster wrote:
For subdomains of registered organizations, SP=reject protects both existent
and non-existent domains. This means that a NP policy would only be relevant
when sp=none and np=reject.
While that's true, someone may want to set, for exam
On Sun 27/Feb/2022 18:43:10 +0100 John Levine wrote:
It appears that Alessandro Vesely said:
Setting a role=org flag would be akin to updating the PSL. Not something that
every domain does every day. Perhaps nobody will ever do it. ...
Assuming you expect role=org to mean the same as what
On Sat 26/Feb/2022 18:14:30 +0100 John R Levine wrote:
No. This just adds more useless complexity that is unlikely to get
implemented.
While composing a DMARC record, setting role=org seems more likely than psd=n.
For the umpteenth time, the goal here is to be as compatible as possible with
On Fri 25/Feb/2022 21:51:21 +0100 John Levine wrote:
It appears that Alessandro Vesely said:
I would prefer role=X, with enumerated values for X. It is more explicit. I
don't think we'd make grand savings by scrimping on symbols.
No. This just adds more useless complexi
On Thu 24/Feb/2022 18:15:57 +0100 Scott Kitterman wrote:
I don't know why you dismiss possible enhancements as if psd=y were already
standard. Of course, users of legacy software won't deploy new
enhancements. That is, org=y would initially not be honored by the majority
of receiving servers. T
On Wed 23/Feb/2022 19:55:35 +0100 Scott Kitterman wrote:
On Wednesday, February 23, 2022 1:25:50 PM EST John Levine wrote:
It appears that Scott Kitterman said:
Leaving that aside, then I think it's:
1. Lookup DMARC record for the 5322.From domain. If found, that's the policy.
2. Walk up
On Wed 23/Feb/2022 05:09:19 +0100 Scott Kitterman wrote:
On Monday, February 21, 2022 6:45:09 PM EST John Levine wrote:
It appears that Scott Kitterman said:
Today, if I send mail from 5322.From example.kitterman.com that is signed
by dkim.kitterman.com, if example.kitterman.com has a DMARC r
On Tue 22/Feb/2022 13:09:12 +0100 Douglas Foster wrote:
On Tue, Feb 22, 2022 at 3:57 AM Alessandro Vesely wrote:
On Mon 21/Feb/2022 23:55:56 +0100 Douglas Foster wrote:
To accurately identify PSD policies, we have two choices:
- assume that PSDs will add the "psd=y" flag to thei
On Mon 21/Feb/2022 23:55:56 +0100 Douglas Foster wrote:
To accurately identify PSD policies, we have two choices:
- assume that PSDs will add the "psd=y" flag to their policies prior to
publication, or
- declare that the "NP" clause is the PSD indicator, meaning
(a) it indicates that the first c
On Fri 18/Feb/2022 23:47:18 +0100 John Levine wrote:
It appears that Alessandro Vesely said:
If they have MX and non-trivial SPF records, they probably are using the domain
to send and receive mail. Yet, they also host independent subdomains. IMHO,
we should trait u...@us.com as a regular
On Thu 17/Feb/2022 20:17:30 +0100 John R Levine wrote:
I took another look at Scott's original message, and now I'm trying to figure
out if there are situations where an upward vs downward tree walk will make a
significant difference and the downward walk is a surpsise.
Consider the domain us.
On Fri 11/Feb/2022 19:25:15 +0100 John Levine wrote:
It appears that Alessandro Vesely said:
I think it is already clear to the WG that the tree walk is screwed up.
Yes, we know we have to rewrite sections 4.5 and 4.6.
I think there are 2 1/2 situations we need to look at.
The first is
On Fri 11/Feb/2022 09:29:07 +0100 Douglas Foster wrote:
Using the reverse tree walk for alignment can become disastrous if a PSD
publishes a policy record without the PSD=Y flag. Worse yet, organizations
would be powerless to defend against its harm. To prent this harm, the
alignment tree wa
On Fri 11/Feb/2022 08:57:17 +0100 Douglas Foster wrote:
This section implies that publishing SPF -ALL is a risky move, which is made
worse by DMARC.SPF -ALL is a only risk when (a) the message is forwarded
without MAILFROM rewrite and (b) the evaluator does not implement DMARC.
My reading of
On Tue 01/Feb/2022 00:01:33 +0100 Dotzero wrote:
On Mon, Jan 31, 2022 at 3:51 PM Alessandro Vesely wrote:
(This message is not going to be accepted by the IETF today, so I CC John too)
Why wouldn't your email be accepted?
I messed around with the DNS and reverse IP wasn't
(This message is not going to be accepted by the IETF today, so I CC John too)
On Sun 30/Jan/2022 05:25:30 +0100 Dave Crocker wrote:
3. The role of the function that uses the PSD and the role of the
function that does a tree walk are identical. Since you apparently feel
otherwise, please explai
On Wed 26/Jan/2022 20:01:24 +0100 Dave Crocker wrote:
On 1/26/2022 10:54 AM, John R Levine wrote:
Ahh, You are claiming I said something about a 'general method'.
I didn't.
Since you think otherwise, could you explain in simple language
that even I could understand how you reached that inte
Alex,
isn't it time we try and release a version which allows XSD automated
validation?
Recall, for example, Matt's suggestions in
https://mailarchive.ietf.org/arch/msg/dmarc/JdRxmT9Aw3HkWM7rr3Av9B3EwRc/
Thank you
Ale
Forwarded Message
Subject: Re: [dmarc-ietf] draft-ietf-dm
On Tue 25/Jan/2022 20:39:11 +0100 Murray S. Kucherawy wrote:
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
On Tue 25/Jan/2022 12:47:21 +0100 Scott Kitterman wrote:
On January 25, 2022 11:30:51 AM UTC, Alessandro Vesely wrote:
On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote:
On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote:
On January 25, 2022 12:46:48 AM UTC, John Levine
On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote:
On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote:
On January 25, 2022 12:46:48 AM UTC, John Levine wrote:
It appears that Scott Kitterman said:
What I implemented is roughly:
For policy determination, first check the
On Mon 24/Jan/2022 15:40:01 +0100 John Levine wrote:
On Mon, 24 Jan 2022, Alessandro Vesely wrote:
This misses the point. It would be a good idea for a multi-tenant
domain to publish a PSD record to keep the tenants apart, just as
it would be a good idea to send a PSL pull request to keep
401 - 500 of 1114 matches
Mail list logo
