(forw) [skeptic] ISP co.site is so far too clueless to understand the trouble report

----- Forwarded message from "A mailing list devoted to critical discussion of extraordinary claims." <[email protected]> -----

Date: Thu, 7 Mar 2024 13:07:38 -0800
From: "A mailing list devoted to critical discussion of extraordinary claims."
	<[email protected]>
To: [email protected]
Subject: [skeptic] ISP co.site is so far too clueless to understand the
	trouble report
Organization: If you lived here, you'd be $HOME already.
Reply-To: [email protected]

Paul W. Harrsion wrote:

> [Note to Rick: hope you got the forwarded message from my email
> client.]

Quoting PHarrison ([email protected]):

> Hi Rick,
>
> Not sending this to the list. I just got a reply from my email
> client as follows:

I'll quote it, because I'm a bit miffed.

> Hey,
> Hope you're doing well.
>
> We have an update from the backend team.
>
> Please note that we added dmarc record for co.site and those record
> will be applicable for all the subdomains under co.site.
>
> As co.site owner by us we have enabled all the necessary settings
> in the record.
>
> Please note we wont allow users to configured dmarc record for the
> subdomain under the domain co.site. this is to prevent users from
> sending unauthenticated emails through external vendors( other than
> Neo), hence this record cannot be modified or not allow to add
> custom dmarc record for the subdomain at our end.
>
> I hope this helps
>
> Please feel free to get back to us in case of any other issues or
> queries in this regard.
>
> Regards,
> Mayank


Mayank's e-mail completely ignores what I suggested you bring to the
attention of co.site management.

To recap, I suggested you bring this to their attention:

---<begin>---

Paul, _please_ tell the technical people at co.site that the TXT record
for "_dmarc.interenglish.co.site" is absolutely _not_ a valid DMARC
record -- and that they can use any online DMARC record checker such
as https://mxtoolbox.com/dmarc.aspx , inputting "interenglish.co.site"
into the tool as the thing to check.

If nothing else, they really need to fix that.  It's broken.

---<end>---

Mayank ignored that, and talked about the DMARC record for the co.site
top-level domain.

Mayank's statement that "those record [sic] will be applicable for all
the subdomains under co.site" is incorrect.  Citing from
https://dmarcly.com/blog/how-dmarc-works-with-subdomains-dmarc-sp-tag :

"Scenario: subdomain overrides organizational domain's policy

If the organizational domain has a DMARC record with a policy (p tag)
and a subdomain policy (sp tag), while the subdomain has its own policy
(p tag), the subdomain overrides the organizational domain's subdomain
policy with its own policy."

The DMARC record for co.site is exactly such a record:

$ dig -t txt _dmarc.co.site +short
"v=DMARC1;p=reject;rua=mailto:[email protected],mailto:[email protected];ruf=mailto:[email protected],mailto:[email protected];ri=43200;aspf=s;adkim=s;sp=reject;fo=1;"
$

The point is that, as in that scenario, organizational domain co.site
has a DMARC policy with a "policy" (p tag) and a subdomain policy (sp
tag).  Therefore, if a subdomain such as interenglish.co.site also
declares a DMARC policy, then it overrides the co.site organizational
domain policy with its own policy.

interenglish.co.site _does_ publish such a policy, and it is a severly
broken policy, because it is not in valid DMARC record format, but
rather in SPF format.

$ dig -t txt _dmarc.interenglish.co.site +short
"v=spf1 include:spf.titan.email -all"
$

Mayank's statement that co.site "doesn't allow users to configured dmarc
record for the subdomain under the domain co.site" may be true, but is
irrelevant to the fact that such a record objectively exists and is dead
wrong.

Jesus fscking Christ.

Please provide this redundant, second explanation to the co.site people,
in hopes of them realizing that they are shooting their customers in the
foot and putting DNS incompetence on public display.

If they are truly this oblivious to verifiably correct technical
information, then I strongly suggest you change providers again to
someone who is competent at system administration.  In the meantime,
perhaps they need to escalate the trouble ticket to someone on the
back-end team who is more senior than Mayank.

-- 
Cheers,                              "I would unite with anybody to do right,
Rick Moen                            and with nobody to do wrong."
[email protected]                             -- Frederick Douglass
McQ! (4x80)   

_______________________________________________
skeptic mailing list
[email protected]
http://linuxmafia.com/mailman/listinfo/skeptic
To reach the listadmin, mail [email protected] 

----- End forwarded message -----