On Wednesday, June 19, 2024 10:53:59 AM EDT John R Levine wrote:
> On Wed, 19 Jun 2024, Alessandro Vesely wrote:
>
> > There are two considerations which I think are worth being considered.
> > One
is that it may sound unnatural to apply the PSD policy when a
> > domain within the organization
On June 3, 2024 12:24:10 PM UTC, Richard Clayton wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>In message <20240603104545.8DB7A8C84B2F@ary.local>, John Levine
> writes
>
>>It appears that Richard Clayton said:
>>>You will need to say EHLO with a domain name that aligns with the
On May 13, 2024 2:37:01 PM UTC, Alessandro Vesely wrote:
>On Mon 13/May/2024 12:53:14 +0200 Scott Kitterman wrote:
>>
>>
>> On May 13, 2024 7:59:20 AM UTC, Alessandro Vesely wrote:
>>> Hi,
>>>
>>> someone objected to PSDs being unable
On May 13, 2024 7:59:20 AM UTC, Alessandro Vesely wrote:
>Hi,
>
>someone objected to PSDs being unable to receive failure reports even if the
>PSD is the From: domain. For example:
>
>_dmarc.psd.example IN TXT "p=none psd=y ruf=reports@psd.example
>
>In case a mail having "From:
On Tuesday, May 7, 2024 9:09:02 PM EDT Mark Alley wrote:
> On 5/7/2024 7:00 PM, Dotzero wrote:
> > https://www.ic3.gov/Media/News/2024/240502.pdf
> >
> > This was released this past week by the FBI. Although we are in last
> > call, I have to wonder if a) the attack itself, and/or b) the
> >
On Tuesday, April 16, 2024 5:17:44 PM EDT Todd Herr wrote:
> Colleagues,
>
> DMARCbis currently describes the value of 'n' for the 'psd' tag in a policy
> record as follows:
>
> The DMARC policy record is published for a PSD, but it is not the
> Organizational Domain for itself and its
On Wednesday, April 17, 2024 11:41:34 AM EDT Alessandro Vesely wrote:
> On Tue 16/Apr/2024 23:17:44 +0200 Todd Herr wrote:
> > Colleagues,
> >
> > DMARCbis currently describes the value of 'n' for the 'psd' tag in a
> > policy
> >
> > record as follows:
> > The DMARC policy record is
On Wednesday, April 17, 2024 9:20:10 PM EDT John Levine wrote:
> It appears that Todd Herr said:
> >When DMARC was first developed, there was concern about DNS load and
> >needing to minimize DNS lookups. Operational expertise now shows that this
> >is no longer cause for concern.
> >
> >Short
On Wednesday, April 17, 2024 9:42:23 AM EDT Todd Herr wrote:
> On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman
>
> wrote:
> > I am confused.
> >
> > Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be
> > found
> > either in this cas
On Tuesday, April 16, 2024 4:55:49 PM EDT Todd Herr wrote:
> On Mon, Apr 15, 2024 at 8:08 PM Douglas Foster <
>
> dougfoster.emailstanda...@gmail.com> wrote:
> > Todd, can you clarify this?
> >
> > N is not concerned with maximum labels on a subdomain. We are interested
> > in the maximum
On Tuesday, April 16, 2024 2:24:07 PM EDT John Levine wrote:
> It appears that Scott Kitterman said:
> >In the case of a.b.c.example.com and example.com is in the PSL, the DMARC
> >records in a.b.c.example.com (if present) and example.com (otherwise) are
> >consulted.
On April 16, 2024 2:36:53 AM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>>I'm with Scott, pick a number, 5, 8, whatever, and be done with it.
>>>
>>Modulo we do need to explain why 8. Related, I think we also need to explain
>&g
On April 15, 2024 4:34:40 PM UTC, John Levine wrote:
>It appears that Alessandro Vesely said:
>>8 is not needed and not justified. A mail site using 8 labels would have
>>troubles with the RFC 7489 version, which uses the PSL. They'd have to ask
>>for
>>PSL upgrades, right?
>
>No, they
On April 15, 2024 11:43:08 AM UTC, Alessandro Vesely wrote:
>On Mon 15/Apr/2024 13:16:50 +0200 Douglas Foster wrote:
>> Our original choice of N was based on the PSL. The PSL could not detect
>> organizational boundaries could not boundaries below level 5, because it had
>> no entries
On April 8, 2024 1:02:53 AM UTC, Neil Anuskiewicz
wrote:
>
>
>> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz wrote:
>>
>>
>>
>>> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote:
>>>
>>> Scott Kitterman writes:
>>>>
On April 7, 2024 4:32:06 PM UTC, "John R. Levine" wrote:
>On Sat, 6 Apr 2024, Scott Kitterman wrote:
>> As a side effect of the switch to the tree walk approach in DMARCbis, this is
>> no longer true. For any subdomain without a DMARC record, the domains above
&
osure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
>
> On Sat, Apr 6, 2024 at 13:44 Scott Kitterman wrote:
> > Th
d of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
>
> On Sat, Apr 6, 2024 at 13:01 Scott Kitte
On Saturday, March 30, 2024 4:05:17 PM EDT Seth Blank wrote:
> Section 4.6: DNS Tree Walk:
>
> The text is correct, but N is wrong. I've shared my notes with this list
> but we never reached consensus:
> https://mailarchive.ietf.org/arch/msg/dmarc/GoExCeJYWhxnvH8lwjbr7nAcFh4/
>
> tl;dr: N of 5
On Monday, April 1, 2024 4:45:20 PM EDT Todd Herr wrote:
> 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.
>
>
On Sunday, March 31, 2024 3:45:31 PM EDT Seth Blank wrote:
> On Sun, Mar 31, 2024 at 2:00 PM John Levine wrote:
> > It appears that Mark Alley said:
> > >> People who publish -all know what they do.
> > >
> > >I posit that there is a non-insignificant amount of domain owners that
> > >don't
On April 1, 2024 11:05:02 PM UTC, John Levine wrote:
>It appears that Todd Herr said:
>>Issue 144 has been opened for the question of what to say about ARC (RFC
>>8617) in the context of indirect mail flows, a la Murray's example text
>>from this post
On March 31, 2024 7:49:08 PM UTC, Seth Blank
wrote:
>On Sun, Mar 31, 2024 at 1:40 PM Scott Kitterman
>wrote:
>
>>
>>
>> On March 31, 2024 5:32:13 PM UTC, "John R. Levine" wrote:
>> >>>> I’m probably being pedantic here: is “gov” a dom
On March 31, 2024 5:32:13 PM UTC, "John R. Levine" wrote:
I’m probably being pedantic here: is “gov” a domain?
>>> Yup, it's a domain.
>> I stand corrected on that.
>
>Anything that meets the DNS spec is a domain namen, e.g., argle.bargle.parp is
>a domain name. If and how particular
On March 30, 2024 11:27:42 PM UTC, "Murray S. Kucherawy"
wrote:
>On only the charter point:
>
>On Sat, Mar 30, 2024 at 2:27 PM Jim Fenton wrote:
>
>>
>> >> ??? Not Found
>> >> -
>> >>
>> >> I expected to find some text at least recommending a rewriting strategy
>> for From
On March 31, 2024 3:20:41 PM UTC, Jim Fenton wrote:
>
>
>On 30 Mar 2024, at 17:22, John R. Levine wrote:
>
> Entities other than domains: Public suffixes aren’t (necessarily) domains,
Of course they're domains. What else could they be? The things that are
out of scope are
On March 22, 2024 2:52:28 AM UTC, John Levine wrote:
>According to Mark Alley :
>>> I don't feel particularly strongly about this, but I can see people
>>> thinking there's some correlation between DKIM testing and DMARC
>>testing. It's not completely illogical, so it might be better to be
On March 21, 2024 11:39:35 PM UTC, "Murray S. Kucherawy"
wrote:
>On Fri, Mar 22, 2024 at 12:59 AM Scott Kitterman
>wrote:
>
>> >> For t=y, DKIM says:
>> >>
>> >>y This domain is testing DKIM. Verifiers MUST NOT treat
&
On March 21, 2024 2:15:00 PM UTC, 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 having, say
>> >>
>> >>
On Tuesday, March 19, 2024 5:23:52 AM EDT Alessandro Vesely wrote:
> On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote:
> > On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely
wrote:
> >>On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote:
> >>> On Mon, Mar 18,
On March 18, 2024 6:53:29 PM UTC, John R Levine wrote:
>On Mon, 18 Mar 2024, Alessandro Vesely wrote:
>> The text should be terser and clearer, possibly with an example.
>
>I would be happy to remove the whole thing, since it's only distantly related
>to defining or implementing DMARC.
I
On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote:
>On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote:
>> On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote:
>>> On Sun, 17 Mar 2024, Dotzero wrote:
> Whenever mail is sent, there is a risk that an overly permissive source
> may
On March 18, 2024 3:15:42 AM UTC, "Murray S. Kucherawy"
wrote:
>On Mon, Mar 18, 2024 at 1:08 PM Dotzero wrote:
>
>>
>> Add this to 11.1 Authentication Methods
>>>
>>>
>>> Both of the email authentication methods that underlie DMARC provide
>>> some assurance that an email was transmitted by
On March 18, 2024 1:36:29 AM UTC, John Levine wrote:
>Tightened up a little, reworded in view of the fact that your own
>mail provider (M*r*s*ft) may let people spoof you through shared IP ranges.
>
>
>>11.X External Mail Sender Cross-Domain Forgery
>
>Add this to 11.1 Authentication Methods
On March 17, 2024 11:11:04 AM UTC, Alessandro Vesely wrote:
>On Sat 16/Mar/2024 20:01:22 +0100 Scott Kitterman wrote:
>> On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote:
>>> On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
>>&g
On Wednesday, February 28, 2024 7:37:30 PM EDT Barry Leiba wrote:
> The editors and chairs think version -30 resolves the open issues and is
> ready for a final look, so this message starts a working group last call
> for the DMARCbis spec. Because of the upcoming IETF 119 meeting, we’ll let
>
Not sure if this is "significant" or not.
I don't particularly like the title, but that's been that way for quite some
time, so for WGLC, meh.
The particular concern I have is with the text that was added right before
WGLC about multi-valued RFC5322.From fields. It includes the statement:
>
On Thursday, March 7, 2024 8:55:55 AM EDT Todd Herr wrote:
> 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
On Wednesday, March 6, 2024 6:04:01 AM EDT Alessandro Vesely wrote:
> On 05/03/2024 21:47, Scott Kitterman wrote:
> > On March 5, 2024 8:10:46 PM UTC, Todd Herr
wrote:
> >> On Tue, Mar 5, 2024 at 1:30 PM Scott Kitterman
wrote:
> >>> On March 5, 2024 2:4
On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote:
> On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
> > Colleagues,
> >
> > Issue 135 is open for the subject topic. Please add your thoughts to this
> > thread and/or to the issue in
On Saturday, March 16, 2024 4:52:54 AM EDT Tero Kivinen wrote:
> John Levine writes:
> > It appears that Todd Herr said:
> > >I agree that clarifying it can't hurt, obviously, ...
> >
> > I disagree, it does hurt.
> >
> > If we say you're allowed to use CNAMEs to point to DMARC records,
> >
On Friday, March 15, 2024 10:15:55 AM EDT Todd Herr wrote:
> On Fri, Mar 15, 2024 at 1:47 AM Douglas Foster <
>
> dougfoster.emailstanda...@gmail.com> wrote:
> > DMARC is an imperfect tool, as evidenced by the mailing list problem,
> > among others. DMARCbis has failed to integrate RFC7489 with
On March 14, 2024 8:38:17 PM UTC, 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 was confused.
>>
>> Do we know what
On March 14, 2024 8:18:31 PM UTC, Todd Herr
wrote:
>Colleagues,
>
>There was a discussion among M3AAWG members on March 13 that centered on
>the question of whether DMARC records can be published in DNS as CNAMEs,
>e.g.,
>
>_dmarc.example.com IN CNAME _dmarc.example.org
>
>_dmarc.example.org
On Thursday, March 14, 2024 1:59:58 PM EDT Alessandro Vesely wrote:
> On Thu 14/Mar/2024 18:35:05 +0100 Scott Kitterman wrote:
> > On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote:
> >> On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote:
> >>> [...]
On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote:
> On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote:
> > [...]
> >
> > In the ticket, I propose the following replacement text:
> >
> > ==
> > Because DMARC relies on SPF
On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
> 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.
I'd suggest we discuss where to say it first. I think the right place is
security
On Thursday, March 14, 2024 10:09:37 AM EDT Todd Herr wrote:
> Colleagues,
>
> After reviewing the "Another point SPF advice" thread and Murray's separate
> post re: SHOULD vs. MUST, I have opened issue 132 on the topic:
>
> The current text of section 5.5.1, Publish and SPF Policy for an
On March 12, 2024 11:42:11 PM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send
>>mail for anything other than their own domains. ESP customers, don't use
>>ESPs that do t
On March 12, 2024 5:37:47 PM UTC, Richard Clayton
wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>In message , Scott
>Kitterman writes
>
>>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send
>>mail for anything other than the
Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send
mail for anything other than their own domains. ESP customers, don't use ESPs
that do this.
Scott K
On March 12, 2024 4:05:15 PM UTC, Dotzero wrote:
>Neil, SPF essentially deals with hosts and IP address ranges.
On March 5, 2024 8:10:46 PM UTC, Todd Herr
wrote:
>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
On March 5, 2024 2:47:47 PM UTC, Todd Herr
wrote:
>On Tue, Mar 5, 2024 at 6:12 AM Alessandro Vesely wrote:
>
>> Hi,
>>
>> Section 5.3, in the format description of psd:
>>
>>n: The DMARC policy record is published for a PSD, but it is the
>> Organizational Domain for itself
On March 5, 2024 3:46:39 PM UTC, Alessandro Vesely wrote:
>Todd Herr writes:
>> On Tue, Mar 5, 2024 at 9:30 AM Alessandro Vesely wrote:
>>
>>> in section 5.5.1, Publish an SPF Policy for an Aligned Domain, the last
>>> sentence says:
>>>
>>> The SPF record
On March 5, 2024 2:54:10 PM UTC, Todd Herr
wrote:
>On Mon, Mar 4, 2024 at 6:30 AM Alessandro Vesely wrote:
>
>> Hi,
>>
>> Section 5 has a paragraph that can fit Scott's solution to SPF spoofing.
>> Here's a possible change:
>>
>> OLD
>> A Domain Owner or PSO may choose not to participate
which was a mistake he wants to fix transparently.
>
>On Thu, Feb 29, 2024 at 4:04 PM Scott Kitterman
>wrote:
>
>> I think it ought to be resolved by the same AD that made the consensus
>> call.
>>
>> Scott K
>>
>> On February 29, 2024 8:58:21 PM UTC, Dotze
pefully the chairs will rule on this so we don't have a previous issue
>reopened during last call.
>
>Michael Hammer
>
>On Thu, Feb 29, 2024 at 2:53 PM Seth Blank 40valimail@dmarc.ietf.org> wrote:
>
>> I thought we landed on SHOULD NOT, there was strong resistance to MUST
:10 PM UTC, Seth Blank
wrote:
>I thought we landed on SHOULD 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?
>>
>&g
my part when the new text in 8.6 was published, and I just want to
>confirm that 7.6 is indeed wrong.
>
>On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman
>wrote:
>
>> In what way is this a new issue that has not already been argued to death
>> in the WG? I think for WGLC, we'
In what way is this a new issue that has not already been argued to death in
the WG? I think for WGLC, we've already done this. We will, no doubt get to
have this conversation during the IETF last call, but for the working group,
this strikes me as exactly the type of relitigation of issues
On February 29, 2024 6:15:37 PM UTC, Benny Pedersen wrote:
>Douglas Foster skrev den 2024-02-29 18:48:
>> I am surprised at the lack of feedback about Barry's research link.
>> It is a devastating attack on our ability to trust SPF when shared
>> infrastructure is involved. As a result of
On Thursday, February 29, 2024 9:04:03 AM EST Todd Herr wrote:
> On Wed, Feb 28, 2024 at 6:27 PM Douglas Foster <
>
> dougfoster.emailstanda...@gmail.com> wrote:
> > I interpret your data differently. These domains collected data until it
> > was clear that they could safely move to
Looks good to me. Are we there yet?
Scott K
On February 28, 2024 11:09:24 PM UTC, Todd Herr
wrote:
>Summary of changes from rev -29...
>
> 1. Removed mention of "XML" from Section 5.5.3, Setup a Mailbox to
> Receive Aggregate Reports. This is future-proofing against any format
> changes
On Saturday, February 10, 2024 7:39:37 PM EST Murray S. Kucherawy wrote:
> On Sat, Feb 10, 2024 at 12:34 PM Jim Fenton wrote:
> > > No, it's perfectly fine to declare that DMARC only applies to certain
> > > classes of messages.
> >
> > This actually concerns me a bit. If having multiple From:
On Saturday, January 27, 2024 8:00:24 AM EST Alessandro Vesely wrote:
> On Fri 19/Jan/2024 18:00:35 +0100 Hector Santos wrote:
> >> On Jan 19, 2024, at 10:19 AM, Todd Herr
> >> wrote:
> >>
> >> Perhaps the way forward for DMARC is to look for a Sender header when
> >> there is more than one
On January 15, 2024 4:49:10 PM UTC, Alessandro Vesely wrote:
>On 11/01/2024 18:15, Todd Herr wrote:
>> On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre wrote:
>>
>>> https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1
>>>
>>> "The case of a syntactically valid multi-valued
Thanks. I think we will come to regret the decision to privilege DKIM over
SPF in this section. For the moment, it's not wrong, but I think the moment
will be fairly transitory.
Scott K
On Tuesday, January 2, 2024 3:12:09 PM EST Todd Herr wrote:
> Revision 28 was due to expire this weekend,
;say?
>
>> On Oct 23, 2023, at 9:07 PM, Scott Kitterman wrote:
>>
>> On Monday, October 23, 2023 4:03:36 AM EDT Francesca Palombini wrote:
>>> I have been asked by Murray to assist with a consensus evaluation on the
>>> discussion that has been going on fo
On Saturday, October 28, 2023 4:03:30 PM EDT Emanuel Schorsch wrote:
> > As to why, I don't think there's a valid use case and the proponents for
> > this haven't really thought it through. As an example, someone (I don't
> > recall who) cited the issue of domain owners that publish SPF, but
On October 28, 2023 5:38:00 PM UTC, Barry Leiba wrote:
>I'm starting this in a separate thread that I want to keep for ONLY
>the following question:
>
>Do we want to use the session we have scheduled at IETF 118 to talk
>about the issue that clearly is still in discussion about adding a tag
On Saturday, October 28, 2023 11:26:40 AM EDT Richard Clayton wrote:
> In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman
> writes
>
> >What's your plan for when easily getting a DMARC pass due to bad SPF
> >records doesn't work anymore, so the bad guy
On Saturday, October 28, 2023 10:51:27 AM EDT Scott Kitterman wrote:
> >Even if we don't add the feature, we should address the vulnerability.
Currently there is only a bullet in Section 4.8, Organizational Domain
Discovery, saying:
> > * The domain found in the RFC5321.Mai
On Saturday, October 28, 2023 10:49:46 AM EDT Richard Clayton wrote:
> In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro
> Vesely writes
>
> >On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
> >> On October 27, 2023 5:54:03 PM
On October 28, 2023 12:01:05 PM UTC, Alessandro Vesely wrote:
>On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote:
>>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
>>>>
>>>&g
On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote:
>On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
>> It appears that Scott Kitterman said:
>>>> That is unfortunately true, but if we could decouple the DMARC from SPF,
>>>> then at least w
On October 26, 2023 9:46:04 PM UTC, Tero Kivinen wrote:
>John Levine writes:
>> It appears that Scott Kitterman said:
>> >>* Is there consensus on moving ahead with the idea of a way to indicate
>> >>which authentication method(s) the Domain Owner wa
On Wednesday, October 25, 2023 11:01:27 AM EDT Richard Clayton wrote:
> In message , Scott
> Kitterman writes
>
> >>> My reading of the discussion is:
> >>>
> >>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
>
>
On Wednesday, October 25, 2023 10:46:09 AM EDT Emanuel Schorsch wrote:
> > >There's the counterargument "so don't publish SPF" but it's on so many
> >
> > checklists
> >
> > >that even though that would be a fine idea, it's not practical.
> >
> > Diving into the SPF angle, if someone has a
On October 25, 2023 1:37:55 PM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>>* Is there consensus on moving ahead with the idea of a way to indicate
>>>which authentication method(s) the Domain Owner wants Receivers to use? If
>>>so, it does
On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely wrote:
>On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
* Is there consensus on moving ahead with the idea of a way to indicate
which authentication method(s) the Domain Owner wants Receivers to use?
If so, it doesn't
On October 25, 2023 3:38:01 AM UTC, "Murray S. Kucherawy"
wrote:
>On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba
>wrote:
>
>> Now that we have a consensus call on the main issue that has remained open:
>>
>> 1. Do we need to retain our session at IETF 118 and discuss this (or
>> something else)
On October 24, 2023 3:38:54 PM UTC, "Murray S. Kucherawy"
wrote:
>On Mon, Oct 23, 2023 at 9:07 PM Scott Kitterman
>wrote:
>
>> I don't think this is consistent with the IETF's mandate to provide
>> documents
>> which promote interoperability. I do
On Monday, October 23, 2023 4:03:36 AM EDT Francesca Palombini wrote:
> I have been asked by Murray to assist with a consensus evaluation on the
> discussion that has been going on for a while about the dmarcbis document
> and how to move forward.
>
> I have made an attempt to evaluate consensus
On October 17, 2023 5:56:47 PM UTC, Alessandro Vesely wrote:
>On Tue 17/Oct/2023 14:03:40 +0200 Scott Kitterman wrote:
>> On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely wrote:
>>> On Mon 16/Oct/2023 20:00:00 +0200 Scott Kitterman wrote:
>>>> On O
On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely wrote:
>On Mon 16/Oct/2023 20:00:00 +0200 Scott Kitterman wrote:
>>
>>
>> On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely wrote:
>>> On Fri 13/Oct/2023 16:35:43 +0200 Neil Anuskiewicz wrote:
&g
On October 16, 2023 9:20:26 PM UTC, Neil Anuskiewicz
wrote:
>
>
>> On Oct 16, 2023, at 11:00 AM, Scott Kitterman wrote:
>>
>>
>>
>>> On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely
>>> wrote:
>>>> On Fri 13/Oct/202
On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely wrote:
>On Fri 13/Oct/2023 16:35:43 +0200 Neil Anuskiewicz wrote:
>> Thank you, sir. That’s part of the reason to cautiously transition away from
>> the PSL. It has the feel of a throwback to a time when people thought the
>> number of
ic, and consequently we can be
>certain of heuristic-induced harm. We should give domain owners full
>control over their organizational boundary, and stop guessing.
>
>Doug Foster
>
>
>
>
>
>On Mon, Oct 9, 2023 at 9:00 AM Scott Kitterman wrote:
>
>> Where does it sa
Where does it say to stop at the first policy found?
Scott K
On October 9, 2023 12:51:33 PM UTC, Douglas Foster
wrote:
>Right, but we walk up from both domains separately, and each walk stops at
>the first policy found. Since the two walks stop at different policies,
>they are presuned to be
On September 19, 2023 8:50:02 AM UTC, Alessandro Vesely wrote:
>Hi all,
>
>the second sentence of the second paragraph of Section 5.8:
>
>OLD
> In particular, because of the considerations discussed
> in [RFC7960] and in Section 8.6 of this document, it is important
> that
On Thursday, September 14, 2023 5:27:08 PM EDT Wei Chuang wrote:
> On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman
>
> wrote:
> > On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote:
> > > We had an opportunity to further review the DMARCbis changes more
&g
On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote:
> We had an opportunity to further review the DMARCbis changes more broadly
> within Gmail. While we don't see any blockers in the language in DMARCbis
> version 28
>
On August 7, 2023 7:47:03 PM UTC, "Murray S. Kucherawy"
wrote:
>On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski wrote:
>
>> Based on the ABNF in -28, how about something like this:
>>
>>
>> dmarc-method = "dkim" / "spf"
>>
>> dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method)
it's feasible with DKIM too. The RFC should ask forwarders to
>do this review when they p=reject downgrade otherwise it does add systemic
>risk to the DMARC protected From identity.
>
>-Wei
>
>On Sun, Aug 6, 2023 at 11:38 AM Scott Kitterman
>wrote:
>
>> On
On Sunday, August 6, 2023 2:10:35 PM EDT Hector Santos wrote:
> > On Aug 5, 2023, at 5:37 PM, Scott Kitterman wrote:
> >
> > On Saturday, August 5, 2023 3:59:02 PM EDT John Levine wrote:
> >> It appears that Scott Kitterman said:
> >>>> When receivers
On August 6, 2023 11:02:04 AM UTC, Alessandro Vesely wrote:
>On Sat 05/Aug/2023 21:37:31 +0000 Scott Kitterman wrote:
>> On Saturday, August 5, 2023 3:59:02 PM EDT John Levine wrote:
>>> It appears that Scott Kitterman said:
>>>>> When receivers apply the
On Saturday, August 5, 2023 7:38:21 PM EDT Dave Crocker wrote:
> On 8/5/2023 4:23 PM, Neil wrote:
> > > The language used for DMARC has always been problematic. "Policy"
> > >
> > > implies control, but the domain owner has no control over the receiving
> > > platform. Quarantine and Reject
On Saturday, August 5, 2023 6:11:03 PM EDT Tim Wicinski wrote:
> On Sat, Aug 5, 2023 at 6:00 PM Scott Kitterman wrote:
> > On August 5, 2023 9:51:54 PM UTC, Tim Wicinski wrote:
> > >On Sat, Aug 5, 2023 at 5:35 PM John Levine wrote:
> > >
On August 5, 2023 9:51:54 PM UTC, Tim Wicinski wrote:
>On Sat, Aug 5, 2023 at 5:35 PM John Levine wrote:
>
>> According to Tim Wicinski :
>> >-=-=-=-=-=-
>> >
>> >Based on the ABNF in -28, how about something like this:
>> >
>> >
>> >dmarc-method = "dkim" / "spf"
>> >
>> >dmarc-auth = "auth"
On Saturday, August 5, 2023 3:59:02 PM EDT John Levine wrote:
> It appears that Scott Kitterman said:
> >>When receivers apply the "MUST NOT reject" in Section 8.6 to accept
> >>unauthenticated messages as quarantined messages, receivers SHOULD
> >>carefu
1 - 100 of 884 matches
Mail list logo