Re: [dmarc-ietf] Codifying "Apex Domain"?

[John Levine]

It appears that Todd Herr   said:
>-=-=-=-=-=-
>
>Colleagues,
>
>I note that lately in various email fora that the term "apex domain" has
>found some favor, said term being used interchangeably with "organizational
>domain", and having the same contextual meaning as "organizational domain".

They don't mean the same thing, so please don't change anything.

"Apex" is related to what part of the DNS tree is on what name server,
the topmost name in a zone. A lot of the time the org domain is at the
apex of a zone, but sometimes it's not, and the zone structure is
irrelevant to the way DMARC works.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Codifying "Apex Domain"?

[Neil Anuskiewicz]

On Nov 9, 2023, at 6:40 AM, Todd Herr  wrote:Colleagues,I note that lately in various email fora that the term "apex domain" has found some favor, said term being used interchangeably with "organizational domain", and having the same contextual meaning as "organizational domain".DMARCbis does not contain the word "apex", nor did RFC 7489 before it.My question here is, should DMARCbis at least mention the term "apex domain", perhaps in section 3.2.9, Organizational Domain. The entirety of that section currently reads:The Organizational Domain for any domain is determined by applying the algorithm found in Section 4.8.Does it make sense to change that toThe Organizational Domain for any domain is determined by applying the algorithm found in Section 4.8. The Organizational Domain is also sometimes referred to as the Apex Domain.When I first started looking at email, I found it less than useful to have multiple names for the envelope from. I saw we call it the org domain and let the chips fall where they may. If you don’t know what an org domain is I’d say it’s time to do some reading or ask a colleague. For example, I’d love it if the envelope from was just that. Define it briefly in the document itsperhaps in the footnotes. Then you can mention it’s call reefer, pot, dope, ganja and chronic but recommend envelope from as the common name. ___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Codifying "Apex Domain"?

[Tim Wicinski]

Todd

I hate to get all DNS-y on you but the DNS terminology draft discusses Apex
and Origin in regards to Zones/Domains:

https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8499bis-10.html#name-zones

(DNSOP spent 6 months trying to clean up the definition of "Glue Records"
to some success)

tim


On Thu, Nov 9, 2023 at 9:40 AM Todd Herr  wrote:

> Colleagues,
>
> I note that lately in various email fora that the term "apex domain" has
> found some favor, said term being used interchangeably with "organizational
> domain", and having the same contextual meaning as "organizational domain".
>
> DMARCbis does not contain the word "apex", nor did RFC 7489 before it.
>
> My question here is, should DMARCbis at least mention the term "apex
> domain", perhaps in section 3.2.9, Organizational Domain. The entirety of
> that section currently reads:
>
> The Organizational Domain for any domain is determined by applying the
> algorithm found in Section 4.8
> 
> .
>
>
> Does it make sense to change that to
>
> The Organizational Domain for any domain is determined by applying the
> algorithm found in Section 4.8
> .
> 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:* 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 receive it. If you are not an intended and authorized
> recipient you are hereby notified 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.
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Neil Anuskiewicz]

> On Oct 28, 2023, at 5:01 AM, 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:
 If there isn't a consensus to do a DKIM-only feature, which seems to be 
 the case, I agree, wrap up the few minor editorial issues and we're done.
>>> 
>>> If we add the feature, we should in any case exemplify how to fix SPF, 
>>> saying that doing so is safer, at least until all DMARC software has 
>>> acquired the new feature.  As the addition would be understood as a 
>>> response to the known vulnerability, it will likely be spread.
>>> 
>>> As many of us consider it cleaner to have DMARC based on DKIM only, having 
>>> that possibility as an option is a first step in that direction anyway.  
>>> The thesis that DKIM is enough has been opposed but the only cases where 
>>> SPF saves the day seem to be software bugs.  The DKIM-only feature would 
>>> allow to probe that thesis, which fixing SPF records would not.
>> 
>> What do we know now that we didn't know the last time we decided not to go 
>> DKIM only?  I'd argue there's nothing and endless relitigation of issues 
>> like this is making it impossible to actually accomplish what we're 
>> chartered to accomplish.
> 
> 
> You're the only one strongly opposing the idea, AFAICS, and I still don't 
> know why.
> 
> 
>> Let's either focus and finish or give up and close the group.
> 
> 
> 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.MailFrom header if there is an SPF
>  pass result for the message being evaluated.
> 
> We need to add a subsection in Security Consideration, discussing an example 
> of an include mechanism with a neutral qualifier and its effect on DMARC 
> outcome; that is, how that avoids spurious authentications.
> 
> The other snippet where SPF qualifiers are discussed is Section 8.1, Issues 
> Specific to SPF.  We could add a reference to the added subsection there.
> 
If explicit language gets us a good portion of the way there. That is forward 
progress for those who support this. Alexandra there must be others not willing 
to go that direction and digging in wil just mean this same conversation 6 
months ago. To keep it neutral the hums should prevail now and those who lost 
this one, remember the battle may be winding down but you have time to provide 
tangible evidence this was a brain dead decision. I’m guess WG members are 
smart and experience quite a bit of neurogenesis (I.e., don’t hold to an idea 
for ego certitude). Even if those who don’t hum hate it, take solace that time 
will show you right if you are right and I doubt anyone humming will hum that 
dissonant song of wrong again. 

If the no hummers are right I hope they humbly re litigate this and change a 
bad policy. Let’s test drive this baby and see if it breaks down out in the 
boonies.
> 
> 
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Codifying "Apex Domain"?

[Todd Herr]

Colleagues,

I note that lately in various email fora that the term "apex domain" has
found some favor, said term being used interchangeably with "organizational
domain", and having the same contextual meaning as "organizational domain".

DMARCbis does not contain the word "apex", nor did RFC 7489 before it.

My question here is, should DMARCbis at least mention the term "apex
domain", perhaps in section 3.2.9, Organizational Domain. The entirety of
that section currently reads:

The Organizational Domain for any domain is determined by applying the
algorithm found in Section 4.8

.


Does it make sense to change that to

The Organizational Domain for any domain is determined by applying the
algorithm found in Section 4.8
.
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:* 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 receive it. If you are not an intended and authorized
recipient you are hereby notified 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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC session at IETF 118

[Neil Anuskiewicz]

For routine, remote is perfect but I’d imagine hums leave no doubt in Prague and a chance for rapport to be established. As an observer this proces made me tense and annoyed at time. Myn2 cents is go to Prague. It’s a gorgeous city. This group has a gruff vibe in the tradition of Usenet but our tribe tends to forget and forgive setting the stage for you to work more smoothly together. It’s like when the godfather called in the 5 families.On Nov 1, 2023, at 3:21 PM, Barry Leiba  wrote:The sense I’m getting is to cancel the session in Prague.  I’ll do that tomorrow (Thursday) morning SFO time unless someone screams loudly with a convincing reason that we need to keep the session.BarryOn Sat, Oct 28, 2023 at 10:38 AM 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
to specify which authentication mechanism(s) to use when evaluating
DMARC?

Or shall I cancel the 118 session and just let the discussion continue
on the mailing list?

And being clear here: the "eliminate SPF entirely" suggestion is
definitely out, failing rough consensus.  We're *only* talking about
the suggestion to add a tag to specify what the sender wants.

Barry

___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC session at IETF 118

[Neil Anuskiewicz]

On Oct 29, 2023, at 7:57 AM, Dotzero  wrote:On Sat, Oct 28, 2023 at 1:38 PM 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
to specify which authentication mechanism(s) to use when evaluating
DMARC?

Or shall I cancel the 118 session and just let the discussion continue
on the mailing list?

And being clear here: the "eliminate SPF entirely" suggestion is
definitely out, failing rough consensus.  We're *only* talking about
the suggestion to add a tag to specify what the sender wants.

BarryLet the discussion continue on the list. Personally I think there has been enough discussion that there can be a call for consensus.Barry, you think there’s rough consensus now? If so then by all means count asap and get closure. Even those who disagree respect the process and will keep their party dry to fight another day. I don’t know exactly what rough consensus is no I know it when I see it, to paraphrase Brandeis. And we all know what it looks like. Accepting defeat even when we think we are fire right is part of what makes this country great. We concede. That’s honor.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] (no subject)

[Neil Anuskiewicz]

> On Nov 8, 2023, at 8:46 AM, John R. Levine  wrote:
> 
> On Mon, 6 Nov 2023, Douglas Foster wrote:
>> Since IETF cannot protect its own lists from conspicuous impersonation, it
>> seems poorly qualified to tell anyone else how to do so.
> 
> Actually, that message had nothing whatsoever to do with impersonation, and 
> everything to do with an obscure configuration error in my mail system.
> 
> Leaping to conclusions is rarely helpful.
> 
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for 
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

I’m not consistent lurking but I get the feeling there’s one more large issue 
that’s a big blocker. The only is a talk at least on zoom not email, where both 
gentlemen do the honor of earnestly steal maning the other argument then from 
there refute the best case not the straw man version that’s human nature. 
Everyone else listen with an open mind and get to rough consensus. The steal 
man method should settle this. It’s easier than dialing.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc