The domain s****g.nl has the following DMARC record:
"v=DMARC1; p=reject; rua=mailto:postmaster#s****g.nl,
mailto:dmarc#s****g.nl"
A valid SPF record for the sending mail server and none DKIM record.
The domain fo***de.com has a valid SPF and DKIM record.
Example 1
From: from#s****g.nl
To: thetoadres#mail.com
Result:
SPF: PASS
DKIM: FAIL
DMARC: PASS
Example 2
From: from#s****g.nl
Sender: response#fo***de.com
To: thetoadres#mail.com
Result:
SPF: PASS
DKIM: PASS
DMARC: FAIL
So when I send the email using a sender (on behalf of) the DMARC fails and the mail is not delivered.
Is there a explanation for this and maybe a solution to send emails on behalf of a domain which contains a DMARC reject policy and have a valid SPF for the sending mailserver?
Edit:
[Screenshot results...][1]
I have a feeling, it's failing on your ADKIM and ASPF Tests of DMARC. If SPF and DKIM passes, then it must be failing on both alignment tests.
Read this to understand more about Identifier Alignments
I seen several cases where there DKIM Validator is coded wrong and it will fail DMARC when it fails 1 alignment test, but both must fail according to the RFC Standards.
The only alignment tester I know about is this email tester, if you post the full headers of the sent emails. It'll be much easier to understand what might be wrong. You're only sharing part of the information and it's impossible to make a 100% accurate assessment. But I'm 80% confident the issue is with the alignment.
Based on the image you linked of your headers, I added an "a" to the beginning and "1" to the end so bots don't spam you.
Return-Path = response#afo***de1.com
DKIM Signature = d=afo***de1.com
From = info#as**g1.nl
So for ADKIM alignment to Pass the "from" domain must match the "d=" domain of the dkim signature
info#as**g1.nl <> afo***de1.com
For the ASPF Alignment to pass the "return-path" domain must match the "from" domain
afo***de1.com <> as**g1.nl
One of those need to match in order for DMARC to pass.
Related
I'm trying to filter messages with header Return-Path contains string '#example.eu'.
I added to /etc/mail/spamassasin/local.cf this lines:
My first attempt:
header LOCAL_DEMONSTRATION_ALL Return-Path =~ /example\.eu/i
score LOCAL_DEMONSTRATION_ALL 10.0
My second attempt:
header LOCAL_DEMONSTRATION_ALL ALL =~ /Return-Path.*example.eu>/i
score LOCAL_DEMONSTRATION_ALL 10.0
Another filters work, but this above doesn't. I checked my regex is Ok.
What's wrong? Thanks.
The Return-Path header contains the Envelope Sender and is typically added to the email when it is delivered to the recipient's mailbox, i.e. it is not present as a visible header while the email is in transit.
The Envelope Sender is passed in the SMTP dialog using the MAIL FROM command and can most often be used in SpamAssassin rules, but depending on exactly how your SpamAssassin is being called the actual details may vary.
SpamAssassin has a pseudo-header EnvelopeFrom that it tries to populate with the envelope sender using some heuristics (or you can tell SpamAssassin how it should be populated using the envelope_sender_header configuration option). For most setups a rule like this should work:
header LOCAL_DEMONSTRATION_ALL EnvelopeFrom =~ /example\.eu/i
score LOCAL_DEMONSTRATION_ALL 10.0
CentOS 6, Postfix, OpenDKIM
Have correct DNS records
Sending email using PHP mail() to appmaildev.com - returns auth-report:
SPF result: Pass
DKIM result: fail (wrong body hash: MpaYoPlKy8H4qX8syH3dOM1gPr6spBK5/INxl2X2uNs=)
Tried different solutions - no result
Any ideas?
There are several causes for these two errors: the message may have been modified (perhaps by a mailing list or forwarder) in transit; the signature or hash values may have been calculated or applied incorrectly by the signer; the wrong public key value may have been published in DNS; or the message may have been spoofed by an entity not in possession of the private key needed to calculate a correct signature.
Any way you can check your DKIM entry for your MAIL-FROM domain here
I know this is an older post but, I ran into this issue yesterday. If you are using MailScanner for anti-spam efforts, try disabling the watermarking feature. I found the added watermark headers were invalidating DKIM hashes. Disabling the watermarks allowed the DKIM hashes to be valid. Yahoo was bouncing mail due to this.
As the above poster mentioned, I also had this problem. We use a windows server as our mailserver and we have antivirus installed on it.
It was setup to scan each outgoing message, but this changed the hash / body of each mail, thus failing the DKIM check.
So if you have this wrong body hash error, make sure you don't scan outgoing mails :)
I host a spread of different domains that all use my (one) mail-server to send and receive mail. When sending mails, sometimes, my mail gets rejected by the receiving end, marked to the recipient as "suspicious" or simply heads straight for the spam folder.
Also, on the inbound, I get a load of "return receipts" from random victims of spam, where one of my domain names has been used even though the mail never touched my mail server.
I have been told, that both issues stems from the fact, that my SPF record is not set properly which i have been attempting to fix for quite a while now. Unfortunately my basic knowledge of the mechanisms behind the record and the syntax itself escapes me somewhat, which is why I'm looking here for help.
For the purpose of the following example, assume the following setup:
I have two domains: mydomain.com and myotherdomain.com.
Both domains have active subdomains that send and receive mail through my mailserver.
My mail server is named mail.mydomain.com
All running on the same physical server with the IP address: 85.81.xxx.xxx.
I have a semi-static IP-address with my ISP, e.g. it never changes but is per say not mine to call my own. A whois on 85.81.xxx.xxx produces 0x39Axxxx.dslpool.isp.com
Using the tool found at http://tools.bevhost.com/spf/ i end up with the following conclusion:
Email Origin : Pass - 85.81.xx.xx
resolves to
0x39Axxxx.dslpool.isp.com which then
again resolves to 85.81.xx.xx.
Sender Details : Pass -
myname#myotherdomain.net points to a
MX-record that points to my mail sever
at mail.mydomain.net.
Host Name HELO / EHLO : Fail -
mail.mydomian.not resolves to
85.81.xxx.xxx which resolves to
0x39Axxxx.dslpool.isp.com
So, the question is: If at all possible, how would I compose the SPF entries for mydomain.com and myotherdomain.com to disregard this conflict and allow my sent mails to appear valid when spf validated by the receiver?
Hoping for a response ...
Here you should have this SPF entry in your DNS v=spf1 +ip4:85.81.xxx.xxx -all for all your domains, and nothing more in your SPF string.
Make sure that you have such a DNS entry for mail.maydomain.com as well as mydomain.com,
because the SPF entry for mydomain.com is not valid for subdomain.mydomain.com.
If you have many subdomains,you may consider to have an SPF entry for *.maydomain.com. That will take care of all the domain tree that are sub or sub.sub or sub.sub.sub etc. domains of the domain mydomain.com.
I am currently extending an e-mail system with an autoresponse feature. In a dark past, I've seen some awesome mail loops, and I'm now trying to avoid such a thing from happening to me.
I've looked at how other tools ('mailbot', 'vacation') are doing this, grepped my own mail archive for suspicious mail headers, but I wonder if there is something else I can add.
My process at this point:
Refuse if sender address is invalid (this should get rid of messages with <> sender)
Refuse if sender address matches one of the following:
'^root#',
'^hostmaster#',
'^postmaster#',
'^nobody#',
'^www#',
'-request#'
Refuse if one of these headers (after whitespace normalization and lowercasing) is present:
'^precedence: junk$',
'^precedence: bulk$',
'^precedence: list$',
'^list-id:',
'^content-type: multipart/report$',
'^x-autogenerated: reply$',
'^auto-submit: yes$',
'^subject: auto-response$'
Refuse if sender address was already seen by the autoresponder in the recent past.
Refuse if the sender address is my own address :)
Accept and send autoresponse, prepending Auto-response: to the subject, setting headers Precedence: bulk and Auto-Submit: yes to hopefully prevent some remote mailer from propagating the autoresponse any further.
Is there anything I'm missing?
In my research so far I've come up with these rules.
Treat inbound message as autogenerated, ignore it and blacklist the sender if...
Return-Path header is <> or missing/invalid
Auto-Submitted header is present with any value other than "no"
X-Auto-Response-Suppress header is present
In-Reply-To header is missing
Note: If I'm reading RFC3834 correctly, your own programs SHOULD set this, but so far it seems some autoresponders omit this (freshdesk.com)
When sending outbound messages, be sure to...
Set the Auto-Submitted: auto-generated header (or auto-replied as appropriate)
Set your SMTP MAIL FROM: command with the null address <>
Note some delivery services including Amazon SES will set their own value here, so this may not be feasible
Check the recipient against the blacklist built up by the inbound side and abort sending to known autoresponders
Consider sending not more than 1 message per unit time (long like 24 hours) to a given recipient
Notes on other answers and points
I think ignoring Precedence: list messages will cause false positives, at least for my app's configuration
I believe the OP's "auto-submit" rule is a typo and the official header is Auto-Submitted
References
RFC3834
This SO question about Precedence header has several good answers
Wikipedia Email Loop Article
desk.com article
Comments welcome and I'll update this answer as this is a good question and I'd like to see an authoritative answer created.
Update 2014-05-22
To find if an inbound message is an "out-of-office" or other automatic reply, we use that procedure:
First, Find if header "In-Reply-To" is present. If not, that is an auto-reply.
Else, check if 1 of these header is present:
X-Auto-Response-Suppress (any value)
Precedence (value contains bulk, or junk or list)
X-Webmin-Autoreply (value 1)
X-Autogenerated (value Reply)
X-AutoReply (value YES)
Include a phrase like "This is an automatically-generated response" in the body somewhere. If your message body is HTML (not plain text) you can use a style to make it not visible.
Check for this phrase before responding. If it exists, odds are good it's an automated response.
My application uses sendmail to send outbound email. I set the 'From:' address using the following format:
Fred Dibnah <fred#dibnah.com>
I'm also setting the Reply-To and Return-Path headers using the exact same format.
This seems to work in the vast majority of cases but I have seen at least one instance in which this fails, namely when the name part of the above string contains a period (full stop):
Fred Dibnah, Inc. <fred#dibnah.com>
This fails deep inside the TMail code (I'm using Ruby) but it seems like a perfectly valid thing to do.
My question is, should I actually be setting the Return-Path and Reply-To headers using only the email address as opposed to the above Name + Email format? E.g.
fred#dibnah.com
Thanks.
In a situation like this, it is best to turn to the RFCs.
Upon reading up on your question, it appears as if You shouldn't be setting the Return-Path value ever. The final destination SMTP server is supposed to be setting this value as it transitions the message to your mailbox (http://www.faqs.org/rfcs/rfc2821.html starting at 4.4).
According to http://www.faqs.org/rfcs/rfc2822.html the Reply-To field can have the following formats
local-part "#" domain (fred#dibnah.com for example)
display-name (Fred Dibna for example)
I would recommend using option 1 as it seems to be the most basic, and you will likely have less issues with that format. In choosing option 1, your Reply-To field should look like the following:
Reply-To: fred#dibna.com