I cannot get the mailx -r option to set the sender "From" field correctly.
echo "email text" | mail -s "test 123" -r donotreply#domain.com user#domain.com
The email gets sent if the "-r" field is a fake domain. If it is a real domain, the email does not get sent. The username does not matter, only the domain name.
Where should I check to fix this?
RHEL6.4
The final result... I should have checked my spam folder. All the test emails using the real domain were in there.
Details:
Fake return domain – went through
Received-SPF: none (google.com: do-not-reply#blahblahfake.com does not designate permitted sender hosts) client-ip=54.201.xx.xx;
Real domain – caught in spam trap
Received-SPF: fail (google.com: domain of do-not-reply#real.com does not designate 54.201.90.208 as permitted sender) client-ip=54.201.xx.xx;
The reason is that the "real.com" domain uses a white list and this specific NAT IP was not added to that list. The fake domain was let through, probably because the mail policy is to let through too much instead of too little.
Related
I'm getting hundreds/thousands of emails on my catch all address for my domain, with the subject "Returned mail: see transcript for details".
I am trying to catch these emails with spam assassin (SA) to mark them as spam, but the SA rule only works if I email a test email to my domain with that text in the subject. The actual spam mails are not marked... only the once I send myself as a test.
I have tried (in local.cf):
header LOCAL_SUBJECT_RETURNED_MAIL Subject =~ m/Returned mail/i
score LOCAL_SUBJECT_RETURNED_MAIL 10.0
header LOCAL_SUBJECT_RETURNED Subject =~ /\bReturned\b/i
score LOCAL_SUBJECT_RETURNED 10.0
Again... the rules are working, yet it looks like the spam emails come in without being scanned by spam assassin.
Does anyone have any idea on what I could try?
Things I've tried/done
I enabled php mail logging on my system, to ensure it's not being send through a script on my domain. Log is empty, so that's good.
The reason why spamassassin is not catching these emails (backscatter), is because they don't come through spamassasin, because they come from the mailer deamon inside my domain/webserver.
Test mail I send myself:
Received: from localhost by server.myprovider.net
with SpamAssassin (version 3.2.4);
Backscatter spam:
Return-Path:
Received: from localhost (localhost)
As you can see, it doesn't come through spamassassin, hence, no rules are triggered...
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.
Here is an example of how I have configured sieve to forward any mail sent to [nameA|nameB|nameC]#example.org to my private email address.
if address :localpart :is ["To","Cc","Bcc"]
["nameA", "nameB", "nameC"] {
redirect "<my private email address>";
stop;
}
Sometimes though, email is not forwarded because the address that it was sent to is tucked away somewhere in a "Received" header.
Received: from ###server### ([###ip_address###])
by ###server### with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
(Exim 4.84)
(envelope-from <###email_address###>)
id 1alDM0-0000yT-60
for nameA#example.org; Wed, 30 Mar 2016 12:28:00 +0200
Is there an effective way to catch these emails in the sieve rule, too?
You have an XY Problem here. What you actually want to do here is filter based on the address being delivered to, not the address in the headers. (As unintuitive as it may be, the address in the headers may have nothing to do with the address it's being delivered to, which is how Bcc can work at all.)
The command to test against the actual SMTP envelope is envelope.
require "envelope";
if envelope :localpart :is "to" ["nameA", "nameB", "nameC"] {
redirect "<my private email address>";
stop;
}
This will handle all mail being delivered to those names, regardless of whether they show up in the mail headers or not.
With the help of the sieves' index feature you can parse the recipient address out of the Received headers.
For BCC sorting I typically do something like this:
require ["fileinto", "envelope", "variables", "mailbox", "index", "subaddress"];
...
if header :index 3 :matches "Received" "*<*#example.com>*" {
set :lower "foldername" "${2}";
fileinto :create "inbox.${foldername}";
} elsif header :index 2 :matches "Received" "*<*#example.com>*" {
set :lower "foldername" "${2}";
fileinto :create "inbox.${foldername}";
}
...
In the Received headers of the mails I receive the adress is set in angle brackets and that's why I've chosen the pattern in the example above.
Additionally, sometimes the number of Received headers varies thus I test at least for two different ones.
So would username#gtld be a valid email? As a practical example google is purchasing the gTLD "gmail". Obviously they can associate A records with that permitting you to just type http://gmail/ to access the site. But, are there any specs that prohibit them from associating MX records with that as well, allowing folks to give out an alternative address username#gmail?
I ask because I want to make sure our email validator is future proof and technically correct.
I think I answered my own question. Section 3.4.1 of rfc5322 which defines a valid email address states:
addr-spec = local-part "#" domain
[...]
domain = dot-atom / domain-literal / obs-domain
[...]
The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [RFC1034], [RFC1035], and [RFC1123]. In the domain-literal form, the domain is interpreted as the literal Internet address of the particular host.
"gmail" would be a valid domain and host name and thus someone#gtld is a valid email address.
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.