EmailDiscussions.com  

Go Back   EmailDiscussions.com > Discussions about Email Services > Email Help Needed!
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
Stay in touch wirelessly

Email Help Needed! Having problems with your email service, or with the email software you're using? Post your questions and answers here!

Reply
 
Thread Tools
Old 27 Mar 2023, 10:48 PM   #31
TenFour
Master of the @
 
Join Date: Feb 2017
Location: USA
Posts: 1,640
Your domain is requesting these DMARC reports and apparently your email address is listed as the one to send the reports to.

Quote:
DMARC reports are usually sent once a day by email. They're sent to the email addresses you specify when you define your DMARC record. If reports are turned on with the rua DMARC record tag in your DMARC record, every server that receives mail from your domain sends a report.
https://support.google.com/a/answer/10032472?
TenFour is offline   Reply With Quote
Old 27 Mar 2023, 11:12 PM   #32
TenFour
Master of the @
 
Join Date: Feb 2017
Location: USA
Posts: 1,640
Use the MX Toolbox and select the DMARC tool to see what email addresses are set for the account.

https://mxtoolbox.com/SuperTool.aspx
TenFour is offline   Reply With Quote
Old 27 Mar 2023, 11:17 PM   #33
DougLass
Member
 
Join Date: May 2014
Posts: 54
The issue isn't what e-mail is getting these messages. The issue is why these messages seem to be implying that my SPF is failing, when everyone else says my SPF is fine. Mxtoolbox says my DMARC Quarantine/Reject policy is not enabled, which I don't believe is a "fail" kind of fault. Everything else checks out. I should add that maybe I'm getting a report from Google because as of a week ago, my rua was set properly. It wasn't before.

Last edited by DougLass : 27 Mar 2023 at 11:45 PM.
DougLass is offline   Reply With Quote
Old 28 Mar 2023, 12:01 AM   #34
DougLass
Member
 
Join Date: May 2014
Posts: 54
So here's a sigh-ful fact. When I do a blacklist check on my domain at mxtoolbox.com, it comes out entirely clean,in some twenty-odd lists EXCEPT for a listing at UCEPROTECT. I get on the line to Hostgator support (it's their domain), and they point me to https://www.inmotionhosting.com/supp...tect-rbl-scam/. So UCEPROTECT is crapola. Sheesh!

Last edited by DougLass : 28 Mar 2023 at 01:28 AM.
DougLass is offline   Reply With Quote
Old 28 Mar 2023, 04:33 AM   #35
SideshowBob
Essential Contributor
 
Join Date: Jan 2017
Posts: 277
Quote:
Originally Posted by DougLass View Post
Um, some of my recipients have Comcast e-mails, which is why I might be getting this message from Comcast, but no, that doesn't have anything to do with an SPF failure. SPF is about authorization, and sending to Comcast doesn't invalidate anyone's authorization records.
It's not about the email you sent to Comcast, it's about the email that ended-up at Comcast after being sent elsewhere.

Have you actually established that: <source_ip>xxx.x.xxx.xxx</source_ip> in the Comcast report is in your SPF record?
SideshowBob is offline   Reply With Quote
Old 28 Mar 2023, 06:11 AM   #36
DougLass
Member
 
Join Date: May 2014
Posts: 54
Quote:
Originally Posted by SideshowBob View Post
Have you actually established that: <source_ip>xxx.x.xxx.xxx</source_ip> in the Comcast report is in your SPF record?
Good question. The xml from Comcast has my IP. Curiously, the xml from google does not. It has an IP I've never seen before, appears to be some scam IP, and might belong to Amazon.
DougLass is offline   Reply With Quote
Old 28 Mar 2023, 11:51 PM   #37
DougLass
Member
 
Join Date: May 2014
Posts: 54
OK, the plot thickens. I have now just received four new DMAC reports (all xml, all unreadable in a modern browser). They are from
google (sent my dmarcsupport@google.com
aol.com (sent by dmarc.yahoo.com)
yahoo.com (sent by dmarc.yahoo.com)
verizon.com (sent by dmarc.yahoo.com)

All of them specifically refer to my domain, as well as the sendersrv.com website which is the host of my e-mail listserve provider (Sender) and also point to "source IP's" that are ones I've never heard of. My own IP is not listed anywhere in these.

Looking at thiese xml files in a terminal window, it's hard to translate them, but <spf>fail</spf> is seen frequently, and also a few passes. Everything else is a pass (dkim, stmp, etc.)

I'm pretty sure I'm getting all these because now my DKIM has a functional rua. It didn't before.

BUT I DON'T UNDERSTAND THEM! I don't know what they're trying to tell me! Are they reporting that everything is fine or are they trying to tell me what is wrong? These are DMARC Aggregate Feedback reports, but I'm not sure exactly what information I'm being fed.
DougLass is offline   Reply With Quote
Old 29 Mar 2023, 12:04 AM   #38
TenFour
Master of the @
 
Join Date: Feb 2017
Location: USA
Posts: 1,640
DMARC Report Analyzer. You can upload the XML file there. https://mxtoolbox.com/DmarcReportAnalyzer.aspx
TenFour is offline   Reply With Quote
Old 29 Mar 2023, 12:14 AM   #39
DougLass
Member
 
Join Date: May 2014
Posts: 54
Now, this is interesting. I was told above to go to the "DMARC XML to Human Converter" which sounded intriguing. That didn't accept my original Comcast reports the other day. But it IS accepting these. I am told therin for all of these reports that my "SPF Alignment" is 0%. SPF Alignment error, they say, is where "the domain provided for SPF authentication must match the From header domain". I don't understand what that means. Up above, in post #14, I relayed my SPF. Both Hostgator and Sender say that SPF is exactly right. These reports are saying it isn't.

OK, I did the DMARC Report Analyzer, and it gives a table for each of the anonymous IPs referred to in these reports. For the Google report, my SPF and DKIM "passes" entirely for my own IP, 114 times. It fails like, once, for some of the other anonymous IPs. I get a "DMARC compliance" rating of 98.41%. But what am I supposed to do with this?

So confusing.

I am trying to understand why my Sender e-mails are getting Junked by many servers. How does this DMARC report analysis bear on that?
DougLass is offline   Reply With Quote
Old 29 Mar 2023, 12:30 AM   #40
Avion
Member
 
Join Date: Sep 2022
Posts: 52
Look at it this way:

The correct DMARC should report that e-mails that you are sending meet all the criteria.

Anything else, and it should report as a failure as part or all of the criteria.

That means your DMARC record is working as intended.
Avion is offline   Reply With Quote
Old 29 Mar 2023, 12:38 AM   #41
DougLass
Member
 
Join Date: May 2014
Posts: 54
Thank you. So that means all of these reports are unrelated to my issue of non-deliverability for many e-mail servers. My suspicion, as I said before, is that my IP, as assigned to me by Sender, was ONCE a spam IP. It isn't blacklisted anymore. But Office 365 servers just haven't realized that yet.
DougLass is offline   Reply With Quote
Old 29 Mar 2023, 01:09 AM   #42
TenFour
Master of the @
 
Join Date: Feb 2017
Location: USA
Posts: 1,640
In my experience delivery to Outlook/Microsoft 365 addresses is always problematic. There appears to be no way to guarantee delivery.
TenFour is offline   Reply With Quote
Old 29 Mar 2023, 01:12 AM   #43
DougLass
Member
 
Join Date: May 2014
Posts: 54
Yes, I think I've heard that. Unfortunately, many large companies and agencies rely on Outlook and deploy it throughout their organization, and are beholden to Office 365 spam police. The funny thing is, there appears to be NO WAY to communicate with those spam police. Escalation in the Office 365 Anti-Spam IP Delist Portal does NOTHING.
DougLass is offline   Reply With Quote
Old 29 Mar 2023, 07:47 AM   #44
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 480
Quote:
Originally Posted by DougLass View Post
... The xml report from the Comcast DMARC Report Generator uploads to Dmarcian with an "Invalid XML File" error. For what it's worth, that xml file strangely can't be opened in a modern browser, because it doesn't have any style information associated with it. Somewhat of a defective file, I guess.
I don't think so. There doesn't have to be either style data or a definition of what is legitimate syntactically in an XML file (a DTD definition) for it to be useful.

It's irrelevant to your problem, but if I c&p one of your examples, eg

Code:
<row>
<source_ip>xxx.x.xxx.xxx</source_ip>
<count>3</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
into a file then drag that into a Firefox browser tab, it displays as well as I'd expect, which is to say that it shows the nested aspect of the tags with indented lines, and uses colour to differentiate between tags like <dkim> and its ending tag </dkim>, and the value sandwiched between them.

I've done the same with some XML data files from various applications installed here and for some of them there's a little more colouring, eg when tags have named attributes like <section id="one"> then "id" is in a different colour from "section" and "one" is in a third colour,

I am curious what else you'd expect to see.

As far as I understand it, XML used like this is just a way for programmes to pass data around in a relatively-easily parsable manner; a program can ask for, for example, the contents of each "<row>" in a file, or the <dkim> element in the 17th <row> and it's up to the XML parsing code to return the right subset of the whole data.


It's different if you want to pass data that relates to some specific international programming standard around. Then there'd also be a DTD (and the XML file would - much as modern HTML pages usually do - start by saying which DTD it uses). The DTD describes to the parser which tags can appear inside which other tags; which ones are required, which optional, and what attributes they can contain. It also describes what sorts of values can be sandwiched between all these tags and what's valid for an attribute value - eg only integers, or a quoted name or eg a literal like "pass" or "fail" ... so that any parser anywhere can decide if a specific file is syntactically correct or not before allowing it to be used.

As far as I understand it, stylesheets are used to describe how data that's represented by an XML file might be manipulated (eg turning it into a more-readable PDF).

I don't think that having a browser tell you that a file contains no reference to a stylesheet means the file is invalid; I think it's just adjusting your expectations to what it is able to show you.
JeremyNicoll is offline   Reply With Quote
Old 29 Mar 2023, 08:06 AM   #45
DougLass
Member
 
Join Date: May 2014
Posts: 54
Well, xml files are *supposed* to be openable in a modern browser. When you try to do that with these, what I reported is the complaint that you get from the browser. But of course, what you would see if you DID open it in a browser would be just a prettified version of what you see with a text editor. You wouldn't have any more information about what you're seeing. That's where the DMARC XML to Human Converter and DMARC Report Analyzer come into play. Those apps add some real detail to the problem.
DougLass is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +9. The time now is 07:34 PM.

 

Copyright EmailDiscussions.com 1998-2022. All Rights Reserved. Privacy Policy