to their mail that
might be considered somewhat higher than "low" in the eyes of some
beholders.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprie
From field
puts
at risk the trust it has built with its recipients, then it is
**RECOMMENDED** that
the Domain Owner make use of the p and/or sp tags to set policy to
'quarantine' or
'reject' for those streams most at risk of loss of trust.
If going that route, probably wan
nteroperability over the needs/wishes of the domain owner.
My preference is for language that acknowledges the primacy of the domain
owner over interoperability.
I don't have time tonight to propose alternative text, but I wanted to
acknowledge that I've read your message and make
e well understood and fully documented (to include
references to mitigation strategies) then a domain owner will have all the
information they need to make their choice as to what policy to deploy. To
mandate that certain classes of domains not do something (and just how do
we define "general-purpo
Upon further reflection, I find myself liking Barry's proposed text less,
and instead propose the following:
On Tue, Mar 28, 2023 at 9:42 AM Todd Herr wrote:
> On 28 Mar 2023, at 17:15, Barry Leiba wrote:
>>
>> > NEW
>> >
>> >5.5.6.
.. where possible",
but you're right that this question is probably off-topic for this working
group.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprieta
step and the repercussions of each decision.
In particular, this document makes explicit that domains for general-purpose
email **MUST NOT** deploy a DMARC policy of p=reject.
END
Obviously, the last paragraph of section 7.6 will reflect the consensus of
whatever 5.5.6 ends up being.
--
of any issues with dmarcbis that would be worth a
> meeting. I think it's ready for last call and we certainly don't need
> a meeting for that.
>
>
As much as I relish the idea of a call at 2:30AM EDT, I must concur here.
--
*Todd Herr * | Technical Director, Standards and E
e previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-27
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> dmarc mailing
ation checks where a prevailing DMARC policy exists seems
to me to be the epitome of unauthorized mail, so I don't see how rejecting
it would be a false positive. Can you help me understand why rejecting such
a message would be the wrong thing to do?
--
*Todd Herr * | Technical Direct
//author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-26
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmar
understand that that decision can still be
'deliver to spam', 'reject', or anything you deem appropriate, based on
those many other factors."
>
> - To protect all subdomains: use sp=reject on the organization domain.
>
This is the only option that will apply to non
main being non-existent
means that the message cannot be replied to, and is therefore not worthy of
acceptance.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
propr
legitimate mail streams that are sending on behalf of the domain owner but
that do not yet have proper authentication in place, but that's all they're
good for.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and a
org/iddiff?url2=draft-ietf-dmarc-dmarcbis-25
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dm
e.
I don't recall consensus, rough or otherwise, from the group suggesting
that this passage should be changed, nor to what it should be changed. Can
you please assist me in my search for said consensus and point to the
thread where that was achieved?
--
*Todd Herr * | Technical Director,
mailstanda...@gmail.com> wrote:
> >
> > A policy search is used to determine the applicable DMARC policy, and
> where applicble, the organizational domain to be used for relaxed alignment.
>
> ___
> dmarc mailing list
> dmarc@ietf.org
by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@va
lable by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> o
s://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-21.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-21
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
>
only that a GSuite server made the
> disposition decision.
>
I do not recall making such an argument, but I allow that my memory is not
what it used to be. I'll visit the archives to refresh my memory.
It is also possible that I misunderstood the terminology you used in your
previous post
g/archive/id/draft-ietf-dmarc-dmarcbis-20.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-20
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
>
/Report_DMARC_and_GDPR.pdf
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to rec
nting to promote more widespread adoption
of authentication far outnumber those who don't.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprietary informati
etf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-19
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
--
*Todd Herr * | Techn
s. I hope these small changes are
> helpful.
>
>
Neil,
Forgive me, but I'm not seeing evidence of your changes in the github
repository - https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis
Can you please help me understand what I'm missing?
Thanks.
--
*Todd He
On Tue, Aug 30, 2022 at 12:20 PM Scott Kitterman
wrote:
>
> While we're fixing typos, the last sentence in the rua definition in
> Section 5.3
> needs a period at the end.
>
Fixed in git.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.
On Tue, Aug 30, 2022 at 11:05 AM Scott Kitterman
wrote:
> On Tuesday, August 30, 2022 10:58:10 AM EDT Todd Herr wrote:
> > No substantive differences between this version and version 17.
> >
> > Version 18 was created with the latest revs of the tools for converting
>
___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
--
*Todd Herr * | Tech
0
I'm submitting just the XML that the Makefile produces from the .md file.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprietary information intended s
steps 6 and 7
until the process stops or there are no more labels remaining.
Step 2 seems to contain an implicit assumption that the first record
queried for will never contain "psd=y", but perhaps it should have as its
final sentence the same wording as step 7, i.e., "If a single r
On Mon, Aug 29, 2022 at 11:10 AM Scott Kitterman
wrote:
> On Monday, August 29, 2022 10:59:55 AM EDT Todd Herr wrote:
> > Version created from the pull request John mentioned on-list on August
> 28.
>
> Thanks.
>
> Why did you remove the specific paragraph pointers for th
s://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-17.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-17
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
internet-drafts
>
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-
is achieved
through applying the DMARC mechanism to a message, which is evaluating the
message for impersonation, is it not?
>
> In sum, PASS is more useful than FAIL because the result is more certain.
> Tthe value of DMARC PASS seems poorly understood by the vendor community.
>
DMARC P
; without a policy. Other messages can be verified as FAIL, without a
> policy, because they don't align at all. ("Sendgrid.net" does not align
> with "Example.com".) The policy adds value when it is present, but it is
> not required.Expecting evaluators t
idation when there is no DMARC policy record published.
If one chooses to do validation in such circumstances, what p= value would
be applied? "none" seems to be the only one that makes sense, but there's
no DMARC policy record and so no corresponding rua tag to use for r
On Thu, Aug 18, 2022 at 11:23 AM Scott Kitterman
wrote:
> On Thursday, August 18, 2022 10:57:16 AM EDT Todd Herr wrote:
> > On Thu, Aug 18, 2022 at 9:57 AM Scott Kitterman
> >
> > wrote:
> > > I agree. The one thing I think would be useful would be to move
cussion of
both aggregate and failure reporting have been moved to separate documents
dedicated to the topics."
I'm curious to see the specifics you propose -
https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h.
ful at identifying the culprit if there is a one-to-one relationship
between source IP and host generating mail messages.
For the cases of a farm of two or more machines sending from behind a
single IP address, the usefulness of the aggregate report in identifying
the troublesome host(s) diminishes in
o even if DMARCbis
were to strike the 'ruf' tag and the concept of failure reporting entirely,
it shouldn't break anything for compliant legacy or updated implementations.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This
uch conditions, that text must be corrected.
It is possible, perhaps even likely, that receiving domains will refuse
mail when the RFC5322.From domain does not exist, on the theory that such
mail cannot be replied to and therefore should not be accepted, at which
point the DMARC mechanism is not app
licy is not used for Organizational Domains that have
published a DMARC policy. Specifically, this is not a mechanism to
provide feedback addresses (rua/ruf) when an Organizational Domain
has declined to do so.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@vali
y imposition of "must" on an evaluator. His
> only "must" is to act in his own best interest to protect himself from
> harm. Ignoring obviously favorable data is not in his interest.
>
There is currently no "MUST" with regard to sending reports. Section 5.
drafts
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all d
applicable DMARC policy is discovered for the RFC5322.From domain
during the tree walk for that domain. In this case, the DMARC mechanism
does not apply to the message in question. <#section-4.8-4.2>
- The record for the RFC5322.From domain indicates strict alignment. In
this ca
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-14.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-14
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
ailFrom's in B.4.2 and B.4.3.
>
>
>
I'll prepare a new rev to address those.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprietary
by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*
t;https://www.taugh.com/draft-ietf-dmarc-dmarcbis-13-from-2.diff.html
> >
> >There's a github pull request with the changes.
>
> These all look like reasonable changes to me.
>
>
I've merged John's pull request and created rev-13 in github, but due to
the blackout fo
addresses the denial-of-service attack
possibility by limiting the DNS queries to no more than five, regardless of
the name length.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confi
vious version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-12
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> dmarc mailing list
> dmarc@ietf.
available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.ht
= tag policy
is used for subdomains.
This would mean in this case that for those sites that adhere to the
DMARCbis specification and elect to accept mail from non-existent
domains, the policy published at "_dmarc.foodnetwork.com" would apply
to this message (p=none), rather than the polic
which subdomain node of that domain did you query and
receive resource record(s) in return?
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprietary informati
ync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 7
On Tue, Jun 21, 2022 at 1:08 PM John Levine wrote:
> It appears that Todd Herr said:
> >-=-=-=-=-=-
> >
> >The main differences between this rev and rev-07 are the ABNF updates and
> >the addition of a discussion in section 9.7 on the topic of "Determination
>
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-08.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-08
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
On Mon, Jun 6, 2022 at 10:03 PM John Levine wrote:
>
> dmarc-tag = 1*ALPHA %WSP '=' *WSP 1*dmarc-value
>
>
Is there a typo here? That is, should it be:
dmarc-tag = 1*ALPHA *WSP '=' *WSP 1*dmarc-value
(asterisk replacing the percent sign before
r if DKIM failed) or "1:d:s"
(any, dkim, spf) make no sense, because 1 implies d and s.
I'd rather see the description of the "fo" tag cleaned up to stress this.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4
t;
> ...and so on? I find that to be easier on the eyes, though others
> might see it as adding complication to the ABNF. Thoughts?
>
>
I kinda like it, and it's not that hard to change the text to use this.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:
On Mon, Jun 6, 2022 at 1:47 PM Les Barstow wrote:
>
>
> On Monday, June 6, 2022 9:06 AM Todd Herr wrote:
>
>
>
> > Back in late April, after rev -07 of DMARCbis was released, there was
> on-list discussion focused on the ABNF bits (section 5.4), and a need to
> re
;rf" *WSP "=" *WSP Keyword *(*WSP ":" Keyword)
; registered reporting formats only
"Keyword" is imported from Section 4.1.2 of [RFC5321].
I've also got the following nits teed up for rev -08:
- dmarc-test = "t" *W
bounces could be
captured and suppressed. We never accepted mail for per...@foo.com, or
roleacco...@foo.com.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprieta
ri question?
>
>
I can put out a new revision today that includes Scott's proposed text for
"Determination of the Organizational Domain for Relaxed Alignment" once we
have something new suggested for the dmarc-uri ABNF.
--
*Todd Herr * | Technical Director, Standards
ree walk is needed to find an
> SPF/
> DKIM related org domain.
>
>
Apologies for the delayed reply; I was away for a few days.
This will be updated in rev -08 when it's released.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220
C53222.From domain and either the SPF or DKIM domain (or both) don't
match the RFC5322.From domain, and we've already determined that DMARC is
in play because we found the applicable DMARC policy during the first tree
walk.
All that aside, I'll happily update the text for the
ggest to change
> the ABNF as :dmarc-record= dmarc-version dmarc-sep dmarc-request *(
> dmarc-sep dmarc-tag ) [ dmarc-sep ]
> - dmarc-fo dmarcbis-07 :
> the rule ' dmarc-fo = "fo" *WSP "=" *WSP ( "0" / "1" / ( "d" / "s"
uot; should be "system".
>
>
Thank you. It will be corrected when the next rev is released at some point
in the near future.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains c
www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-07
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
--
*Todd Herr * |
f you find psd=n or psd=y you stop, if you find psd=u keep
> > going.
>
> I think the attached addresses this. I also tried to make it clear that
> if
> there's only one domain (common 5322.From, 5321.MailFrom, and d=), then no
> tree walk is needed.
>
> The diff is
itled "DNS Tree Walk" and just prior to the section now titled
"Organizational Domain Discovery" (nee Determine The Organizational Domain)
- The sections DNS Tree Walk, DMARC Policy Discovery, and Organizational
Domain Discovery have been rewritten to incorporate current l
ce, and I think I've
got a new draft ready that incorporates the latest comments.
Happy to post that if it'll save you some work, Scott.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmit
no use for the np
tag, because a non-existent RFC5322.From domain would be reason to reject
the message, full stop, with no need to find a DMARC policy record
associated with it.
I always believed that if a message couldn't be replied to, it wasn't worth
accepting, and so non-existent
as that Mr. Kitterman had planned to propose
some text to share with the group.
Is this still where we are on things?
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confident
On Wed, Feb 16, 2022 at 6:52 PM John Levine wrote:
> It appears that Todd Herr said:
> >The process for a DNS Tree Walk will always start at the point in the DNS
> >hierarchy that matches the domain in the RFC5322.From header of the
> >message, and [will always end no
etf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.6-2>
Note: If no applicable DMARC policy is discovered for the RFC5322.From
domain during the first tree walk, then there is no need to search for an
Organizational Domain, as the DMARC mechanism does not apply to the message
in
aft-ietf-dmarc-dmarcbis-05.html#section-4.5-7.3>
- _dmarc.example.com
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-7.4>
- _dmarc.com
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-7.5>
--- cut here
--
ot;The definition of alignment needs
to change, because the current definition exposes domains to
security/abuse risks."
My personal opinion is that arguing this case on just the merits of "The
current definition of alignment exposes domains to security/abuse risks,
here are examples of how the
the topic.
- Numerous updates to use the terms "Mail Receiver" or "Report Consumer"
as appropriate.
Full diffs are here:
https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-dmarcbis-04&url2=draft-ietf-dmarc-dmarcbis-05
--
*Todd Herr * | Technical Director, S
massive "Issue X is now Y" message.
I hope the above is clear, but if not, I'll try to answer any questions you
have, or funnel them to the people who should be able to answer them.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m
where it makes sense to release a new draft.
If anyone thinks that timeline is too aggressive, please let me know.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confidential a
rries; that's what draft revisions are for...
I'll work to rewrite these sections for the next version.
Scott Kitterman, do you mind if I just incorporate your suggested text
re:PSD into that same rev, rather than your going through the machinations
of a pull request?
--
*Todd Herr
ing on DMARC, which requires that the
entire message be consumed by the receiving server so that the RFC5322.From
header can be parsed for the domain and DMARC checking can proceed.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
On Tue, Jan 18, 2022 at 4:17 PM John Levine wrote:
> It appears that Todd Herr said:
> >If the intent of the tree walk is, at least in part, to allow for
> >publishing of policy records at the PSD level and for those records to be
> >inherited by existing subdomains
ain Owner. Therefore,
reputation assessment of that stream by the mail-receiving
organization is not encumbered by accounting for unauthorized use of
that domain in the RFC5322.From field. A message that fails this
verification is not necessarily associated with the Domain Owner'
ng its handling decision.
Put more simply, no DMARC policy record does not help the domain owner at
all, but not performing the DMARC mechanism check *might* help the
receiving domain.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
T
f you have a rule that you will apply the DMARC mechanism regardless of
whether or not a DMARC policy exists for a domain, then you are seemingly
implementing a policy of "no auth, no entry" (and you are well within your
rights to do so) but you are not following the DMARC protocol w
owner has given no
indication that it's authenticating mail in a way that might generate a
pass. Perhaps an intelligent evaluator with essentially unlimited resources
would have data available to them that tracked all possible combinations of
sources, paths, and domains used for SPF, DKIM, and RFC
ain might be for good, or they might be for evil, and DMARC is
just one data point that an evaluator has to make the final
interpretation of the domain owner's intent.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email
scribes best
practices for email authentication for senders, intermediaries, and
receivers; here is a link to one such document -
https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf
--
*Todd Herr * | Technical Director, Standards and Ecosy
wish to hold our document or our breath waiting for that to happen.
> But I would like the issue documented.
>
The IETF emailcore working group is actively engaged in updates to RFCs
5321 and 5322. It would be much more appropriate for your suggestion to be
documented there, I think.
RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field
as the Author Domain and apply the most strict
policy selected among the checks that fail.
Option 1 above is proposed in DMARCbis as a way to mitigate the risk of a
DoS attack by a bad guy inserting a From: header with umpte
here were ten, twenty, or one hundred domains?
To mitigate the risk of the denial of service, the text was proposed that
the only time to support multiple From addresses is when all domains are
the same.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.2
On Tue, Dec 7, 2021 at 4:14 PM Dotzero wrote:
>
>
> On Tue, Dec 7, 2021 at 4:00 PM Todd Herr 40valimail@dmarc.ietf.org> wrote:
>
>>
>> Why do aspf=s and adkim=s not mitigate the risks you're discussing here?
>>
>> You obviously don't remembe
nd enable potential malicious behavior? We know that "bad
> guys" have been early adopters of email authentication. Anyone think there
> aren't bad guys subscribed to this list and thinking about the
> possibilities for abuse of this mechanism?
>
>
>
Why do aspf=s an
changed to explicitly state that. On the other hand, if there's no such
requirement, I believe that should be explicitly called out, too, in order
to avoid misunderstanding in the future.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.
On Mon, Dec 6, 2021 at 9:08 AM Scott Kitterman wrote:
>
>
> On December 6, 2021 1:35:10 PM UTC, Todd Herr 40valimail@dmarc.ietf.org> wrote:
> >On Mon, Dec 6, 2021 at 7:45 AM Alessandro Vesely wrote:
> ...
> >>Should any over
overlooked systems/failures/, since surprises can also arise from
> systems
> that the Domain Owner considered to have been set up well.
>
How about:
"Should any authentication failures for systems under the Domain Owner's
control be found in the reports, the Domain Owner can
ow the
extensible "tag-value" syntax for DNS-based key records defined in DKIM" as
declared in section 5.3, General Record Format.
This doesn't mean we can't break new ground here, but doing so would
require rewriting the beginning of section 5.3, as well.
--
*Todd Herr *
101 - 200 of 327 matches
Mail list logo
