DMARc SPF autoreply vacation message Gmail fails

[ikkeben]

IF "100%"

DMARc, DKIM, SPF are used with p=reject.

Then Vacation message set in DA CP GUI replied to gmail adressed are rejected.

Unauthenticated email from thatdomain.tld is not accepted due to domain's\n550-5.7.1 DMARC policy. Please contact the administrator of domain if\n550-5.7.1 this was a legitimate mail. Please visit\n550-5.7.1 https://support.google.com/mail/answer/2451690

How to solve this while i know with forwarding it could be...
But this should not be a problem

hostname is mailhost and mailserver DKIM dns for that domain has then ofcourse DKIM from hostname.
Is in tests all 100%

So how to this?
http://arc-spec.org/

or even so https://www.spamresource.com/2015/12/mail-forwarding-in-dmarc-world.html

SRS hu???????? https://forum.directadmin.com/showthread.php?t=39066&p=195150#post195150

Some one solved this for ( domain and mail on DA box where hostname is mx mailserver for all domains) then using vacation message in Directadmin account.
Then someone sending from Gmail account, the autoreply is blocked by Gmail see above for message.

This should be working out of the BLUE in DA admin GUI with dmarc, spf, dkim set right reslust in tests ok only this...

Is long long a not solved problem?

As for issues with DKIM and SPF on servers with SRS enabled.... it was found out that DKIM might get corrupted due to SRS, and SPF might fail if you don't have SRS. So we have to options here:

Also can't find a HELP topic / docu for SRS related as /etc/exim.srs.conf and this one ? .include_if_exists /etc/exim.srs.forward.conf

 

[Richard G]

I got the same issues with forwarded mail. I get a report with a SPF fail when I send a mail to my customer and the customer has a forward to gmail. Because customers domain is not allowed to send mail in behalve of me ofcourse.

Same kind of issue.

It does not get into the spam, but there should be some solution.

 

[ikkeben]

Don't know if the new exim.conf update 4.5.17 to 4.5.18 solved this?

Changes in

#EDIT#58: uservacation:
to = "${sender_address}"
to = "${reply_address}"

and
#COMMENT#59: userautoreply
to = "${sender_address}"
to = "${reply_address}"



the same

I don't have time to test

Can somone from DA support explain this? ?

 

[IT_Architect]

I got the same issues with forwarded mail. I get a report with a SPF fail when I send a mail to my customer and the customer has a forward to gmail. Because customers domain is not allowed to send mail in behalve of me ofcourse.
Same kind of issue.
It does not get into the spam, but there should be some solution.

Forwards will always fail if it depends on the sending servers DNS being right because the E-mail came from the forwarder's server, not the original sender's server so they will never match, not SPF or DKIM. You set in DMARC what the policy is. If the policy can be nothing has to match, one has to match, all have to match, and what happens when there isn't a match. So unless you set it up to where nothing has to match, which is worthless, then there will be some impact on delivery. If you set up nothing has to match, then you still need anti-spam software after that, that quantifies what impact that will be, which would have to be analyzed by downstream software with Bayesian methods. However, spammers analyze them to get by them. Their DMARC may be if SPF or DKIM don't match, it's trash. How can they tell if you forwarded a message or if your server is spamming and saying it is who it isn't? Maybe checking if the server isn't on an RBL isn't good enough. People jump IP addresses and change their name every day.

What does GMail do? When GMail forwards a message, they change the sender's domain to theirs. Example: [email protected] sends as [email protected]. Replies will still go to you, but the address is altered to indicate that it's coming from an automatically generated message. This way, SPF and DKIM remain perfectly aligned when received by an E-mail server on the other end because it is using the SPF and DKIM of [email protected] on their server. Another thing it does is if an autoresponder is responding to an autoresponder, it's not going on with your E-mail account, and Google can easier localize it. Perhaps if the SPF or DKIM don't match, Google's and Hotmail's, etc., DMARC policy is to throw them into the bit bucket. Perhaps the only way to beat it is to play the same game they are playing by changing the E-mail address. When GMail sells businesses accounts to consolidate E-mails, they do not have your server forward to theirs. You set up your virtual user's E-mail credentials on their server so they send and receive using your server just as your E-mail client does. SPF and DKIM remain aligned. You are not going to have any better luck with Hotmail/Live Mail/Outlook Mail. I have not tested others.

 

[Richard G]

Forwards will always fail if it depends on the sending servers DNS being right because the E-mail came from the forwarder's server, not the original sender's server so they will never match, not SPF or DKIM.

Mostly, But in my case they were on the same server. Even if the original sender's server is the same as the forwarder's server it will still fail.

I found this on the wiki:

SPF breaks plain message forwarding. When a domain publishes an SPF FAIL policy, legitimate messages sent to receivers forwarding their mail to third parties may be rejected and/or bounced if all of the following occur:

1. The forwarder does not rewrite the Return-Path, unlike mailing lists.
2. The next hop does not whitelist the forwarder.
3. This hop checks SPF.

This is a necessary and obvious feature of SPF – checks behind the "border" MTA (MX) of the receiver cannot work directly.

Publishers of SPF FAIL policies must accept the risk of their legitimate emails being rejected or bounced. They should test (e.g., with a SOFTFAIL policy) until they are satisfied with the results. See below for a list of alternatives to plain message forwarding.

I have to test again, because I didn't have any issues for a long time, but I did change the -all to ~all in the SPF record but I'm not sure if that did the trick or some in between exim.conf update.

 

[IT_Architect]

Plus DKIM fails, in which case you are worse off with it than without it in a forward situation.

 

[Richard G]

Exactly. And then you think you have everyting in great order, SPF and DKIM and DMARC all setup very nice and strict, and then your customers are using auto-forward to forward their domain mails to Gmail/Hotmail and you get your invoices rejected or returned.
Hence I was already thinking of removing them again.

Still I thought I've read somewhere that on forwards, the mail would be accepted if the original sender's SPF and DKIM were aligned and passed DMARC.
Anyway, did not have issues lately, but if it happens again I will change to ~all again and might remove DKIM and DMARC from the company's domain to prevent mails not arriving with customers.

 

[IT_Architect]

The claim is that with a full DMARC setup, your E-mail messages would be rock solid. In my experience, E-mails got through fine without it, and with it, customers sometimes have issues. Some customers leave it on and some turn it off because of trouble with certain destinations. My thoughts are, the big problem is spam. A hacked server or a spammer's server can have a perfect a perfect DMARC setup, and a lot of legit ones that don't. So then, how big of a factor can they play in determining if a message is spam? What matters most is your E-mail servers are not on DNSRBLs, followed by an accurate PTR record for the mail server, followed by an accurate SPF record for the domain, followed by intelligent spam software that has Bayesian capabilities that can be user-taught. SpamAssassin operates at the user level, not the virtual user level, but there are both pros and cons to that. For business, it is usually a pro because I only set up one teacher, and one who understands the significance of his actions. After that, they totally LOVE SpamAssassin.

 

[Richard G]

he claim is that with a full DMARC setup, your E-mail messages would be rock solid.

They are, unless I sended them to a customer of mine on the same server, which auto forwarded it to gmail.
My servers have not been on DNSRBLs for several years and everyting is setup correctly including PTR etc. We've got a 10/10 score on mail-tester too.
But as said, don't know for sure if it was the ~all instead of -all which I changed before, or an Exim update, but I didn't have difficulties with forwarding for a couple of months now. I think around end of october or november.