also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> I-D-Announce mailing list -- i-d-annou...@ietf.org
> To unsubscribe send an email to i-d-announce-le...@ietf.org
>
--
Todd Herr | Technical Director, S
On Mon, Apr 22, 2024 at 10:01 AM Todd Herr wrote:
> Colleagues,
>
> I intend to produce the next draft of DMARCbis this week, incorporating as
> best as I can all the parallel threads that have spun up since WGLC was
> called.
>
> In order for me to be most effective i
is published, as the editing
process suffers when the target keeps moving.
Thank you for your consideration in this matter.
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 703-220-4153
This email and all data transmitted with it contains confiden
published for any
specific domain used as the RFC5322.From domain, so perhaps a bit of text
in the Tree Walk section describing the really deep use case and
the solution for it might be a compromise.
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.co
On Wed, Apr 17, 2024 at 1:18 AM Neil Anuskiewicz wrote:
>
>
> On Apr 16, 2024, at 2:18 PM, Todd Herr 40valimail@dmarc.ietf.org> wrote:
>
>
> Colleagues,
>
> DMARCbis currently describes the value of 'n' for the 'psd' tag in a
> policy record as follow
Walk in section 4.6 be updated, to
mention that valid DMARC records with no explicit psd tag might be found
during the walk, and these should be preserved for later comparison to
determine the organizational domain?
I look forward to the discussion.
--
Todd Herr | Technical Director, Stand
se regardless of where we land on N for the tree
walk, I think the description of the value of 'n' for the 'psd' tag is
inadequate, a conclusion I've arrived at during the writing of this reply.
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone
ot
only accommodate for current usage but also to allow for a bit of future
expansion of the depth of the name space used for RFC5322.From domains.
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 703-220-4153
This email and all data transmit
m X is [ARC], which provides for a
mechanism to demonstrate 'chain-of-custody' of a message. However, use of
ARC is nascent, as is industry experience with it in connection with DMARC."
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/144
--
Todd Herr | Technical Dir
dmarc/draft-ietf-dmarc-dmarcbis/issues/143
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 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)
a
Greetings.
Jim Fenton's message kicking off the thread
<https://mailarchive.ietf.org/arch/msg/dmarc/zwZtb3w4mD87OcFaOh_nCyREBPM/>
"WGLC review of draft-ietf-dmarc-dmarcbis-30" has been captured as Issue
142 - https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/142
Greetings.
Issue 141 has been opened to collect ideas around the discussion about what
to say in DMARCbis (if anything) about honoring SPF records that end in
-all when SPF fails.
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/141
--
Todd Herr | Technical Director
rcbis/issues/140
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 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 receive it. If you
On Mon, Apr 1, 2024 at 12:53 PM Jim Fenton wrote:
> On 1 Apr 2024, at 9:26, Todd Herr wrote:
>
> > I'm digesting the threads for the purpose of preparing tickets to track
> the
> > work, and I suspect one of the tickets will include, "Add reference to
> the
>
fault/files/m3aawg_managing-spf_records-2017-08.pdf
2.
https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 703-220-4153
This
On Thu, Mar 21, 2024 at 10:15 AM Todd Herr wrote:
> On Thu, Mar 21, 2024 at 5:55 AM Alessandro Vesely wrote:
>
>> On Wed 20/Mar/2024 23:11:20 +0100 Matthäus Wander wrote:
>> > Alessandro Vesely wrote on 2024-03-20 15:42:
>> >> what is the result of DMARC on
ot; result, and <#section-4.1-4.1.1>
2.
produces that result based on an identifier that is in alignment, as
described in Section 4.4 <#identifier-alignment-explained>.
===
If there's anything to say about reporting a
Issue 137 has been opened for this.
On Mon, Mar 18, 2024 at 9:50 AM Todd Herr wrote:
> On Sun, Mar 17, 2024 at 7:17 AM Alessandro Vesely wrote:
>
>> On Sat 16/Mar/2024 21:07:53 +0100 Neil Anuskiewicz wrote:
>> > Unless I’m misunderstanding, a General Purpose Domain is
> number of
> > Author Domains processed will avoid this risk. If not all Author Domains
> > are processed, then the DMARC evaluation is incomplete.
>
> I don't think we need to tell people what to do with such messages. I
> think
> this is enough.
>
> Scott K
>
>
ility
Considerations) for further discussion of this topic." and be done with it.
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 703-220-4153
This email and all data transmitted with it contains confidential and/or
proprietary informat
rstand how reliable the
Domain Owner believes its authentication practices to be and, along with
everything else the Mail Receiver knows about the sending domain, the
source of the mail stream, etc., etc., how much weight can be assigned to a
failed DMARC authentication result for that domain.
--
On Thu, Mar 14, 2024 at 4:52 PM Hector Santos wrote:
>
> On Mar 14, 2024, at 4:02 PM, Todd Herr 40valimail@dmarc.ietf.org> wrote:
>
> On Thu, Mar 14, 2024 at 3:25 PM Hector Santos 40isdg@dmarc.ietf.org> wrote:
>
>> On Mar 14, 2024, at 10:09 AM, Todd Herr >
On Thu, Mar 14, 2024 at 5:05 PM Mark Alley wrote:
> On 3/14/2024 3:49 PM, Todd Herr wrote:
>
> On Thu, Mar 14, 2024 at 4:43 PM Mark Alley 40tekmarc@dmarc.ietf.org> wrote:
>
>> On 3/14/2024 3:38 PM, Todd Herr wrote:
>>
>> On Thu, Mar 14, 2024 at
On Thu, Mar 14, 2024 at 4:43 PM Mark Alley wrote:
> On 3/14/2024 3:38 PM, Todd Herr wrote:
>
> On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman
> wrote:
>
>>
>> I think this is correct. I think it's obviously enough correct that I'm
>> surprised anyone wa
...
Granted, the first two citations are in regards to DKIM records, not DMARC
records, but those were the reasons given.
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 703-220-4153
This email and all data transmitted with it contains co
n a DNS RR in
the expected format.
Issue 136 has been opened for this.
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 703-220-4153
This email and all data transmitted with it contains confidential and/or
proprietary information intended sole
On Thu, Mar 14, 2024 at 3:25 PM Hector Santos wrote:
> On Mar 14, 2024, at 10:09 AM, Todd Herr 40valimail@dmarc.ietf.org> wrote:
>
> To configure SPF for DMARC, the Domain Owner MUST choose a domain to use
> as the RFC5321.MailFrom domain (i.e., the Return-Path domai
Colleagues,
Issue 135 is open for the subject topic. Please add your thoughts to this
thread and/or to the issue in Github.
Thank you.
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 703-220-4153
This email and all data transmi
On Thu, Mar 14, 2024 at 11:04 AM Alessandro Vesely wrote:
> On Thu 14/Mar/2024 15:38:23 +0100 Todd Herr wrote:
> > To summarize this thread, I see three nits, all of which have been added
> to
> > issue 133:
> >
> [snip]
> >
> > 3. Section 5.3., Genera
ject issue for this matter, and in that issue I floated
the possibility of moving A.5 to section 7, Changes from RFC 7489, with
some text along the lines of "we deleted the discussion of ADSP from this
version, but it's preserved here for historical purposes"
Discuss...
--
Todd Herr
ty to be true, Ale.
DMARCbis, like RFC 7489 before it, contains this sentence in the
description of DMARC records:
Unknown tags MUST be ignored.
Any site implementing the DMARCbis spec will see "pct" as an unknown and
ignore it.
--
Todd Herr | Technical Director, Standar
and assuming I am
> reading it correctly, I support the change.
>
That is the gist of the text I've proposed, yes.
[rest snipped for further discussion when issue is opened and reported to
list]
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@vali
ed from [RFC3986]; commas
> ; (ASCII 0x2C) and exclamation points
> ; (ASCII 0x21) MUST be encoded
>
> Could they be rewritten for readability
>
> ; "URI" is imported from [RFC3986];
> ; (ASCII 0x2C) commas and
>
tion Date : March 2015
> Author(s) : M. Kucherawy, Ed., E. Zwicky, Ed.
> Category : INFORMATIONAL
> Source : INDEPENDENT
> Area : N/A
> Stream : INDEPENDENT
> Verifying Party : ISE & Editorial Board
>
> ___
> dmarc mailin
umers
for both aggregate and failure reports, though, so I submit that it is
"real-life" to exemplify directing failure reports to third parties.
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 703-220-4153
This email and all data transmitte
llelize the roles of
> the identifiers.
>
>
> Best
> Ale
> --
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
--
Todd Herr | Technical Director, Standards &
gt;>> or (more likely) leave a tombstone page in its place. I'll ask.
>>>
>>> -MSK
>>> ___
>>> dmarc mailing list
>>> dmarc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmarc
>>>
>&g
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 703-22
rgery discussed in RFC 7208 Section 11.4, and
I will open a separate issue for that to expand on section 8.1
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 703-220-4153
This email and all data transmitted with it contains confidential an
have the same
organizational domain as the From domain; it can be the organizational
domain, as I mentioned above. Perhaps this could be written as "When a
string comparison shows that the rightmost labels of the SPF/DKIM domain
are not identical to the organizational domain, in which ca
On Fri, Mar 8, 2024 at 4:52 AM Alessandro Vesely wrote:
> On 06/03/2024 15:42, Todd Herr wrote:
> > On Tue, Mar 5, 2024 at 10:45 PM Barry Leiba
> wrote:
> >
> >> SHOULD NOT was the consensus call, and the correction Todd
> >> proposes is just making that sent
On Wed, Mar 6, 2024 at 7:02 PM Murray S. Kucherawy
wrote:
> On Wed, Mar 6, 2024 at 11:42 AM Todd Herr 40valimail@dmarc.ietf.org> wrote:
>
>> The text reported in the erratum doesn't really exist in DMARCbis; it's
>> been replaced by the DNS Tree Walk (
>> http
On Thu, Mar 7, 2024 at 5:08 AM Alessandro Vesely wrote:
> On 06/03/2024 21:00, Todd Herr wrote:
> >
> > Section 4.7, DMARC Policy Discovery, starts with the following sentence:
> >
> > For policy discovery, a DNS Tree Walk starts at the domain found in
>
scovery,
the Tree Walk is only necessary if there's no policy published specifically
for the RFC5322.From domain.
I've created Issue #128 for this.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153
This email and all
e more explicit about what's going on here.
>
The text reported in the erratum doesn't really exist in DMARCbis; it's
been replaced by the DNS Tree Walk (
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-dns-tree-walk
)
Are we to issue an actual update to RFC 7489 here as we
absence of
> DMARC and will not be able to take the senders' policies into account.
> END
>
> (Or just skip the second sentence and do it as you suggest)
>
> Barry
>
> On Thu, Feb 29, 2024 at 4:44 PM Todd Herr
> wrote:
> >
> > Colleagues,
> >
> > T
s; Todd, please just add this change to your other
> editorial changes.
>
>
Done and recorded in closed issue #122.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153
This email and all data transmitted w
On Tue, Mar 5, 2024 at 1:30 PM Scott Kitterman wrote:
>
>
> On March 5, 2024 2:47:47 PM UTC, Todd Herr 40valimail@dmarc.ietf.org> wrote:
> >On Tue, Mar 5, 2024 at 6:12 AM Alessandro Vesely wrote:
> >
> >> Hi,
> >>
> >> Section 5.3, i
Mail
Receivers who send reports.
Can you please describe the reports you'd expect Domain Owners to create?
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153
This email and all data transmitted with it contains confident
y for such services is enabled by
> DMARC but defined in other referenced material such as [RFC6591] and
> [I-D.ietf-dmarc-failure-reporting]
>
>
Issue 127 open to track this. I think there's something here to work with.
--
*Todd Herr * | Technical Director, Standards
world in which two of the largest mailbox providers (Google and Yahoo)
are requiring SPF authentication, DKIM authentication, and DMARC pass for
certain classes of mailers to get their mail accepted, I'm not sure that
offering advice that will ensure the lack of an SPF pass (and therefore a
lack of SPF
t; the
> domain is not a PSD /and/ it is the Organizational Domain for itself and
> its subdomain.
>
>
You may be correct in your assertion here; I'll wait for others to weigh in.
In the meantime, Issue 126 has been opened to track this.
--
*Todd Herr * | Technical Director, Standar
t;
To further this discussion, please define "public sources", compare and
contrast that definition to the definition of "private sources", and then
describe which sources are "trusted" and by whom.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e
domain. URIs not supported by Mail Receivers MUST be ignored. The format
for message-specific failure reporting is described in [
I-D.ietf-dmarc-failure-reporting <#I-D.ietf-dmarc-failure-reporting>].
= cut here ==
Discuss at your convenience,
On Thu, Feb 29, 2024 at 10:12 PM John Levine wrote:
> It appears that Todd Herr said:
> >p=none by default." This seems inconsistent with the text in 5.7.2
> >("Continue if one is found, or terminate DMARC evaluation otherwise") and
> >4.7 ("Handling
On Thu, Feb 29, 2024 at 10:10 AM Todd Herr wrote:
> On Thu, Feb 29, 2024 at 9:58 AM OLIVIER HUREAU <
> olivier.hur...@univ-grenoble-alpes.fr> wrote:
>
>> Would you prefer one comment/issue or in batch?
>>
>
> I would prefer that Barry's request be honored from h
d exists with a
policy of p=none" I believe the phrase "causing recipients to assume p=none
by default" should be stricken from the bullet in 11.3.
Please discuss.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
ULD NOT, there was strong resistance to MUST NOT
>
> On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman
> wrote:
>
>> Okay. I think 8.6 is the one in error. You see how this is going to go,
>> right?
>>
>> Scott K
>>
>> On February 29, 2024 7:45:15 PM UT
t; issues we've been counseled to avoid.
>
> Scott K
>
> On February 29, 2024 6:54:57 PM UTC, Todd Herr 40valimail@dmarc.ietf.org> wrote:
> >Colleagues,
> >
> >I've been reading DMARCbic rev -30 today with a plan to collect the first
> >set of minor
might post messages to
mailing lists SHOULD NOT publish p=reject")
Section 7.6 therefore should be updated to read "domains for
general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes?
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h.
121,
> which I've cleverly titled "WGLC Minor Issues and Editorial Comments".
>
so I can pull the minor issues and comments from this thread into that
Github Issue.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:*
es and editorial comments in Github Issue 121,
which I've cleverly titled "WGLC Minor Issues and Editorial Comments".
I've already found one: Kurt Andersen's last name is misspelled in
"Acknowledgements - RFC 7489".
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis
igate against risk of these sorts of attacks, and DMARC
aggregate reports are a tool that can be used to do so.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153
This email and all data transmitted with it contains confid
;
> _______
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
>
>
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:
;
> Agreed on 5.5.3.
>
I also agree on 5.5.3, and DMARCbis rev-30 will contain no occurrences of
the three letter sequence "XML".
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153
This email and
MARC does not change that, regardless of
the policy setting for the claimed sending domain or the DMARC validation
results. Sites participating in DMARC are not required to honor the policy
statement published by the domain owner.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:*
ng the
tag after all -
https://mailarchive.ietf.org/arch/msg/dmarc/lplcAiYMqCh_Grp7lwfbDqlVicA/
>
> As at the moment, as per the example I gave in the email, DKIM is futile
> to have if SPF passes.
>
Your example shows an SPF result of "softfail", which I do not understand
ect.
>
Perhaps the way forward for DMARC is to look for a Sender header when there
is more than one RFC5322.From domain and use that for DMARC processing,
with the stipulation that messages that don't contain such a Sender header
are invalid and should be rejected?
--
*Todd Herr * | Technical
iving MTA to recognize such messages
as the threats they might be and handle them appropriately.
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#section-11.5-1>
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-41
-ietf-dmarc-dmarcbis-29
>
> 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 * | Technical Director,
//www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-28.html#organizational-domain-discovery>.
The Organizational Domain is also sometimes referred to as the Apex Domain.
Discuss...
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 7
r "content".
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*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)
authoriz
text from
$MAILING_LIST_THREAD
Todd, as editor whose mail client isn't one that lends itself well to
piecing together multiple threads into a coherent list...
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153
This
to WeSendEmail.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*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
ing...
The illustrative example cited is intended to illustrate a full tree walk
that follows the steps for a full tree walk that are spelled out in the
numbered list just prior to the illustrative example.
That numbered list includes conditional stops (i.e., if one record is found
with the specified cond
stop.
Might make sense to only address the topic in one section, rather than two.
Section 6.4, Feedback Leakage. The paragraph on Multi-organizational PSDs
that require DMARC starts with the word "Reports" stretched over two lines,
but not hyphenated.
Section 10, Normative References, contain
9258-NA
Their use of 5.7.26 seems in keeping with IANA - Multiple authentication
checks failed - since in order to fail DMARC, both SPF and DKIM must fail.
https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml
--
*Todd Herr * | Technical Director, Standards
and today was as good a time for that as any.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use
t;
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153
This
of spelling out the full name of the mechanism.
I am not looking to change the name of the mechanism; I'm just genuinely
curious how the name was arrived at.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153
T
right
way to go here.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*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)
authoriz
ee a
perhaps higher than expected percentage of DMARC passes that relied on SPF
only (or at least a higher than expected rate of DKIM failures) I'd posit
that many of those DKIM failures are due to the challenges that Marty and
people like them face with getting the key published.
--
*Todd Herr *
On Wed, Jun 21, 2023 at 4:22 AM Alessandro Vesely wrote:
> On Tue 20/Jun/2023 15:40:11 +0200 Todd Herr wrote:
> >
> > I can't speak for Patrick, but I don't think he's necessarily thinking
> of
> > different encryption algorithms here.
> >
> > Not all who
evices to engage third party senders, and that should solely be the
province of the IT staff that manages DNS, but I fear that the energy
required to type and distribute such words would be wasted.
--
*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703
ith no document
> change needed.
>
Done.
--
*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 ind
r SHOULD choose a DKIM-Signing domain (i.e., the d= domain
in the DKIM-Signature header) that aligns with the Author Domain.
--
*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
On Wed, Apr 12, 2023 at 11:35 PM Murray S. Kucherawy
wrote:
> On Wed, Apr 12, 2023 at 11:41 AM Todd Herr 40valimail@dmarc.ietf.org> wrote:
>
>> On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy
>> wrote:
>>
>>> I've been thinking about the point a
hey may not want).
>
My preference here would be to add text for Domain Owners to make them
understand the ways that p=reject might cause some mail using their domain
to not make it to its destination, with "mailing lists might reject your
mail" being one such example.
--
*Todd Herr * | T
ing seems to be from the same neighborhood
as the Sender Rewriting Scheme used sometimes for 5321.From rewriting to
mitigate SPF failures - https://www.libsrs2.org/srs/srs.pdf
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data
whose aren't
Anyway, this is why I continue to support the idea of describing the
interoperability issues, but opposed to the idea of telling domain
owners not to use p=reject.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.415
previous
employer deployed p=reject) and so I want to be able to send a message that
would result in such a bounce.
Can anyone help me?
Thanks.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted
o 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
proprietary infor
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 want to consider expanding on 5.5.5, too; I
need to think about it some more.
--
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 a promise to propose
alternative text tomorrow.
--
*
d 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-purpose" ema
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. Decid
be ... 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
proprietary inf
epercussions 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.
--
*Todd Her
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 Ecosystem
*e:* t
s 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 list
> dmarc@ietf
1 - 100 of 313 matches
Mail list logo
