On March 29, 2023 4:49:16 AM UTC, John Levine wrote:
>It appears that Dotzero said:
>>I agree with Scott on this. I don't believe that "open signup" domains
>>deserve this special call out in this manner. ...
>
>The only way to get an account on my system is to know me personally,
>but my
It appears that Dotzero said:
>I agree with Scott on this. I don't believe that "open signup" domains
>deserve this special call out in this manner. ...
The only way to get an account on my system is to know me personally,
but my human users have the same issues as Gmail's or Yahoo's. They're
Are we trying to define a protocol that evaluators can follow automatically
without ever making any mistakes? I am not.
It is simply wrong to assume that changes-in-transit are the only cause of
DMARC Fail on acceptable messages.If you work with a mailstream, you
should be aware of these
On March 29, 2023 1:00:29 AM UTC, "Murray S. Kucherawy"
wrote:
>On Wed, Mar 29, 2023 at 5:30 AM Trent Adams 40proofpoint@dmarc.ietf.org> wrote:
>
>> Regardless of the outcome of that analysis, though, it does seem
>> reasonable to ask the reporter to include a tag indicating the method
On 29 Mar 2023, at 5:20, Todd Herr wrote:
In my estimation, the language you propose here establishes the
primacy of interoperability over the needs/wishes of the domain
owner.
As is appropriate for such normative language. From RFC 2119:
6. Guidance in the use of these Imperatives
On Wed, Mar 29, 2023 at 5:30 AM Trent Adams wrote:
> Regardless of the outcome of that analysis, though, it does seem
> reasonable to ask the reporter to include a tag indicating the method they
> employed to discover the policy. They will know which method they use,
> it's reasonable to
A cursory glance at the policies for domains under our purview indicates that
there are more than a negligible number that'll return different results
whether the evaluator performs the RFC7489 "hop" or proposed "tree walk" to
determine the policy. To gauge true impact, we're spinning up a
I think it's much closer to acceptable in theoretical cases which are unlikely
to exist now, but may be okay in the future, but it will be difficult to know.
It's perfectly fine for a domain owner to accept this and take the risk, but we
shouldn't even try to pretend there aren't issues.
Scott
On March 28, 2023 8:20:54 PM UTC, Todd Herr
wrote:
>On Tue, Mar 28, 2023 at 4:01 PM Scott Kitterman
>wrote:
>
>>
>> "...MUST NOT deploy a DMARC policy other than p=none because use of
>> p=reject
>> or (to a slightly lesser extent) p=quarantine for such domains is
>> extremely
>> harmful to
There may need to be a bit more clarification around the use of sp= in these
cases. "We are telling you that p=reject is harmful, but sp=q/r is acceptable
in many cases, where these conditions are satisfied".
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
>
On Tue, Mar 28, 2023 at 4:01 PM Scott Kitterman
wrote:
>
> "...MUST NOT deploy a DMARC policy other than p=none because use of
> p=reject
> or (to a slightly lesser extent) p=quarantine for such domains is
> extremely
> harmful to email interoperability. Mitigation strategies are discussed in
>
On Tuesday, March 28, 2023 3:14:38 PM EDT Todd Herr wrote:
> On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman
>
> wrote:
> > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote:
> > > NEW
> > >
> > >5.5.6. Decide If and When to Update DMARC Policy
> > >
> > >Once the Domain
On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman
wrote:
> On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote:
>
> > NEW
> >
> >5.5.6. Decide If and When to Update DMARC Policy
> >
> >Once the Domain Owner is satisfied that it is properly authenticating
> >all of its mail,
On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote:
> I raised this issue in the DMARC session in Vienna, and have let it
> sit for a while so as not to derail other discussion. As we're pretty
> close to finished with the DMARCbis document, I'd like to raise it
> again, this time with
On Tue 28/Mar/2023 17:11:46 +0200 Brotman, Alex wrote:
I only made one minor modification there based on a ticket JohnL had submitted.
Now I read it:
ridtxt = ("<" *(ALPHA / DIGIT / "." / "-") ["@" (ALPHA / DIGIT / "." / "-")]
">") / ((ALPHA / DIGIT / "." / "-") ["@" *(ALPHA / DIGIT /
On Tuesday, March 28, 2023 1:09:34 PM EDT Alessandro Vesely wrote:
> On Tue 28/Mar/2023 17:49:57 +0200 Scott Kitterman wrote:
> > I can live with it [the ] since it's optional (I
> > don't think it'll get a lot of traction), but I do think it's misplaced.
> > I
> > think it's metadata, not
Negative on software specifics.
A general security principle is to not release configuration specifics
that could be used against you to exploit a product-specific vulnerability.
Doug
On Tue, Mar 28, 2023, 1:09 PM Alessandro Vesely wrote:
> On Tue 28/Mar/2023 17:49:57 +0200 Scott Kitterman
On Tue 28/Mar/2023 17:49:57 +0200 Scott Kitterman wrote:
I can live with it [the ] since it's optional (I
don't think it'll get a lot of traction), but I do think it's misplaced. I
think it's metadata, not message data as it's about how the receiver processed
the message, not about anything
Technically I think it's domains that send mail which is received via indirect
mail flows and want such mail delivered.
I think that's approximately all domains with human users. The only exception
I can think of is if a corporate domain prohibits employees from using their
company email
On Tue, Mar 28, 2023 at 12:18 PM Scott Kitterman
wrote:
>
>
> I don't understand the connection between DMARC policies and open signup
> domains? What makes them in any way special relative to DMARC?
>
> Scott K
>
I agree with Scott on this. I don't believe that "open signup" domains
deserve
Should it reference consumer-oriented domains instead?
Users of comcast.net can't get an email account with out first being an ISP
customer. I don't believe the intent was to exclude them from the proposed
language. Similarly for a few other providers, and then there are explicit
pay-for
On Tuesday, March 28, 2023 11:58:40 AM EDT Todd Herr wrote:
> 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
> >> >
>
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. Decide If and When to Update DMARC Policy
>> >
>> >
Since the version number (as far as I found) is optional, it's not useful as
receivers have to be able to parse reports without the hint about the version.
Given the extensibility of XML and the hooks in the document for extensions, I
do see either a current or likely future need.
I think the
Ale,
Thanks for the notes, I'll try to get those sorted out. I'll check RE the
7405/5234 to see what I can find. I only made one minor modification there
based on a ticket JohnL had submitted.
Scott,
There were two version fields in this document at one point. The second
originally came
On Tue, Mar 28, 2023 at 9:51 AM Mark Alley wrote:
> I know that M3 is totally separate from this group, but this is more-so a
> question for Todd H- does this mean that the M3AAWG authentication best
> practices recommendation will also change based on this if this is the
> intended usage going
I know that M3 is totally separate from this group, but this is more-so
a question for Todd H- does this mean that the M3AAWG authentication
best practices recommendation will also change based on this if this is
the intended usage going forwards with DMARCbis?
Quote from the existing
On Tue, Mar 28, 2023 at 8:36 AM Jim Fenton wrote:
> On 28 Mar 2023, at 17:15, Barry Leiba wrote:
>
> > NEW
> >
> >5.5.6. Decide If and When to Update DMARC Policy
> >
> >Once the Domain Owner is satisfied that it is properly authenticating
> >all of its mail, then it is time to
On 28 Mar 2023, at 17:15, Barry Leiba wrote:
> NEW
>
>5.5.6. Decide If and When to Update DMARC Policy
>
>Once the Domain Owner is satisfied that it is properly authenticating
>all of its mail, then it is time to decide if it is appropriate to
>change the p= value in its DMARC
I raised this issue in the DMARC session in Vienna, and have let it
sit for a while so as not to derail other discussion. As we're pretty
close to finished with the DMARCbis document, I'd like to raise it
again, this time with specific proposed text for us to discuss.
And so:
OLD
5.5.6.
30 matches
Mail list logo
