Solved Exim and DKIM fail (on forwards?) since exim.conf update.

@mxroute i am sure Richard is not ( meaning) insulting you. ;) ( IN Dutch we say very often please read what i am trying to explain, so maybe Language..)

(The problem is only with forwarded mails.) They are using hostname , that was not before.
After this update please see and read the diff:

--- 4.5.33/exim.conf-SpamBlockerTechnology-v4.5.33.txt 2020-10-27 05:05:12.928999379 -0600
+++ 4.5.34/exim.conf-SpamBlockerTechnology-v4.5.34.txt 2020-12-10 16:53:15.318037047 -0700
@@ -1,5 +1,5 @@
-# SpamBlockerTechnology* powered exim.conf, Version 4.5.33
-# September 9, 2020
+# SpamBlockerTechnology* powered exim.conf, Version 4.5.34
+# December 10, 2020
# Exim configuration file for DirectAdmin
# Requires exim.pl as distributed by DirectAdmin here:
# http://files.directadmin.com/services/exim.pl version 21 or higher
@@ -639,6 +639,16 @@

.include_if_exists /etc/exim.routers.pre.conf

+lookuphost_forward_router:
+ driver = dnslookup
+ domains = ! +local_domains
+ ignore_target_hosts = 127.0.0.0/8
+ condition = ${if !eq{$original_domain}{$domain}}
+ condition = ${if !eq{$original_domain}{}}
+ condition = "${perl{check_limits}}"
+ transport = remote_smtp_forward_transport
+ no_more
+
lookuphost:
driver = dnslookup
domains = ! +local_domains
@@ -1007,6 +1017,15 @@
helo_data = ${if exists{/etc/virtual/helo_data}{${lookup{$sending_ip_address}iplsearch{/etc/virtual/helo_data}{$value}{$primary_hostname}}}{$primary_hostname}}
hosts_try_chunking =
hosts_try_fastopen =
+.include_if_exists /etc/exim.dkim.conf
+
+remote_smtp_forward_transport:
+ driver = smtp
+ headers_add = "${if def:authenticated_id{X-Authenticated-Id: ${authenticated_id}}}"
+ interface = <; ${if exists{/etc/virtual/domainips}{${lookup{$original_domain}lsearch*{/etc/virtual/domainips}}}}
+ helo_data = ${if exists{/etc/virtual/helo_data}{${lookup{$sending_ip_address}iplsearch{/etc/virtual/helo_data}{$value}{$primary_hostname}}}{$primary_hostname}}
+ hosts_try_chunking =
+ hosts_try_fastopen =
.include_if_exists /etc/exim.dkim.conf

#EDIT#62

He sofar i know thought had look to the important things already, not seen that tree between the rest in the forest.

I am interested to while before that exim.conf update this was no problem.
In between he has set a dkim for the host/servername now.

So i guess he will folow up here. ;)

Thanks MXroute
Is this ok @Richard G ?

Maybe you have to made some changes ("custom") there now because of that update?

If doing a email test ( not forwarding) it fails only FQDN name, in a test, where the MX record is pointing to mail.hisdomain.nl and not to hostname/mailserver. That is normal for having mailsni and so on on domainnames itself? i don't know ??
Tested with this https://mecsa.jrc.ec.europa.eu/en/

Also strange his banners has a b' before in that test, i am not knowing what this is ?
"
Banner

220 b'server23.serverhostserssss.nl ESMTP Exim 4.94 Fri, 12 Feb 2021 21:31:25 +0100'"

(while i am only using hostname in mx records with also then the dkim from hostname in DNS for those domains, so we couldn't find out because of different settings our servers.)
 
Last edited:
Hello Mxroute.

I'm very wondered about the fact that you accuse me of insulting you, which is certainly not the case and if yes, please state where I did this.
I only asked to read the thread before answering, because the log only shows direct mail, which already knowingly not having an issue.

It's happening quite often on forums that users read the last reply and not the rest and then start asking questions which are already answered, which is rather unpleasent for the one having the issue.
That might indeed not have been the case for you, but especially after your first reply which only stated to look in the logs and headers, which is the normal thing to do first, gave that impression. So was my reply about the logs a bit irritated? Yes that it was, but certainly not insulting.
But it did not contain any questions on your behalve either, it was just a tip you gave, no questions at all.

About the ticket... I didn't up this ticket every time just to up it, I added additional information to maybe help others help me to find something weird I might be overlooking.
Since all direct mail is all working fine, I don't want to fuzz DA with tickets about something which might be something on my side. So I would likek to investigate thorougly myself, before taking up their precious time.
However, in the meantime before you replied, there is a ticket send in to DA, and I put it at low priority.

You didn't provide the data I asked for before in the thread, and I don't think you've provided it now, so I'd ask you to spare me the insulting accusations that I can't read.
Logically, since you didn't ask me any data in the thread. The only comment you gave was that I had to look into the logs and that I wouldn't get any further until I (not you) would have access to the mails and the headers.
Looking in the logs is the first thing I always do, but there is nothing to see there. I don't want to be insulting, but since direct mail is no issue, one can expect to not find anything in the logs.
So seen from my side please spare me of accusations that I was insulting (which I didn't) and don't accuse me of not providing things you didn't ask for.

If you still want to help me, which yes I do appreciate, I hope we can now leave this behind us and I will answer the rest below.

1.) I would love to get my hands on a failing email. If that would have been the case I would certainly have investigated that and put the information here. But unfortunately that is not the case.
This part of the search for info, is exactly the reason why I created a forward myself, as would my customers to. But unfortunately, those forward tests did not give any issue either.

2.) Backtracking is logically thing to do. Trying that was the cause that gave me the impression that the issue would be forwarded mail. All direct mail does not give an issue and I did n't change anything except for those updates.
Can the issue still be caused from something else? Sure, but then I wouldn't now where.

No doubt that there are mails going out from [email protected] or from [email protected] but I have nothing to do with that, since the hostname domain is different from my company's domain, hence the difference I made between hostname.nl and mycompany.nl in the examples.

But from mycompany.nl domain I'm 100% certain that only smtp-authenticated mail is leaving. Added to that, I can stated that I do have 1 script present. This is a contact form. But this contact form only sends mail to my address so is send and received locally. Nothing is outgoing from that form and that is tested regularly.

And I'm telling you that I think you should be looking for these:
If the hostname domain and the company domain would be the same, then yes you certainly would have a point here. But this is not the case, they are different domains and they are seperate accounst. The mycompany.nl domain is a reseller account.

Still... I don't mind checking to be sure.
Output of the first command is only a mail send -to- me, coming from csf/lfd which sends the mail as root.
Output of the second command gives the same result.
But that makes perfect sense to me since we're talking about separate domains here.

If you would like to have all domain names and full dmarc reports, I can give you those per pm. The latest report I got from dmarcapp was that -all- messages would have been originated from my company's domain name with a fail of 87%. Which just can't be the case. And that was february 8. I expect that report tomorrow to have a 100% fail issue.

@ikkeben More is changed. On advies of DA support I triend using the old exim.dkim.conf which generated errors in the log and mails were nog signed with DKIM anymore, which they were before. Version 1.6 is exactly the same as version 1.4 which also has always been working fine for me. So imho the issue isn't caused by exim.dkim.conf either.

All:
Tomorrow I will get new dmarc weekly reports. I'm very curious as what they will state, maybe it's best to wait and see what they say? I don't know.
 
Output of the first command is only a mail send -to- me, coming from csf/lfd which sends the mail as root.
Output of the second command gives the same result.

Since the emails are claiming your reseller domain as the Envelope From, that's what should be logged in your exim logs. Because that doesn't just log what's in the From header. So if there's nothing in the logs that refers to that hostname in such a way that's going out to Gmail, then you solved the problem. Google is making up details that don't exist and that's why it's failing DKIM/SPF. It's nothing on your server.
 
Since the emails are claiming your reseller domain as the Envelope From, that's what should be logged in your exim logs. Because that doesn't just log what's in the From header. So if there's nothing in the logs that refers to that hostname in such a way that's going out to Gmail, then you solved the problem. Google is making up details that don't exist and that's why it's failing DKIM/SPF. It's nothing on your server.
hmm something like this?
 
Well @mxroute I wish that would be the case, but it's not only Google (and even then I wouldn't really believe they messed up) but also xs4all. A big provider in the Netherlands.
So @ikkeben if it would have to do with that, then xs4all/kpn must have done that too and it's very curious that these things just happen at the same time when DA updates exim and other exim files.

By the way, I'm not frustrated because I cornered myself, but because DA cornered me.
I look at it this way.

All was running fine until the updates.

After the exim (and other eixm files) update, things started to go wrong.
1.) Some customers could not send mail anymore.
2.) I started getting bad dmarc reports.

As for 1.) this was due to a change in exim.variables.conf were a dh_perm was added and excluded several ciphers this way.
I also got a topic about that but there is also one here (click) and this got fixed.

2.) Since 1 also occurred, and I did nothing else except just updating with custombuild as should be done, it seems to me that the most logical reason of the issue lies with those updates.
 
hmm something like this?

No, that has no relation to the situation described in this thread.

Well @mxroute I wish that would be the case, but it's not only Google (and even then I wouldn't really believe they messed up) but also xs4all. A big provider in the Netherlands.

Suppose you could extend further than just mainlog. Since the last report you know you had was an email from Feb 5 (using the epoch time from the DMARC reports you posted here) , logs may have rotated. So you could expand to like:

grep "server23.hosting010.nl" /var/log/exim/mainlog*

If it's truly not logged in that way then I'd start to consider that it's not using exim on your server at all, and perhaps it is directly opening a connection with the external services via SMTP port. If that is the case, you could set SMTP_BLOCK to "1" in /etc/csf/csf.conf and run "csf -r" to reload it. If this stops it from occurring moving forward, you can more than rule out any DA updates as having any relation to this as that's going to be a script under a user account that isn't running in such a way that utilizes the exim conf.
 
The last report posted is from Feb 5. But the last report I received is from february 14th. I tried a quarantine policy with that.
This is that last report.
Code:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <version>1.0</version>
  <report_metadata>
    <org_name>xs4all.nl</org_name>
    <email>[email protected]</email>
    <extra_contact_info>mailto:[email protected]</extra_contact_info>
    <report_id>[email protected]</report_id>
    <date_range>
      <begin>1613088000</begin>
      <end>1613174399</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>mycompany.nl</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>none</sp>
    <pct>70</pct>
    <fo>1</fo>
  </policy_published>
  <record>
    <row>
      <source_ip>95.xx.xx.xx</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>quarantine</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>server.serverdomain.nl</envelope_from>
      <header_from>mycompany.nl</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>server.serverdomain.nl</domain>
        <scope>mfrom</scope>
        <result>none</result>
      </spf>
    </auth_results>
  </record>
</feedback>

As for the grep command, I have to look at this because that gives me loads of output.

I already have SMTP_BLOCK=1 in csf/lfd for a long time, and have SMTP_ALLOWLOCAL=1 to allow scripts to send out mail.

I have to go now, but I will put some of the log of the grep command when I'm back within an hour.
 
The last report posted is from Feb 5. But the last report I received is from february 14th. I tried a quarantine policy with that.
This is that last report.
Code:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <version>1.0</version>
  <report_metadata>
    <org_name>xs4all.nl</org_name>
    <email>[email protected]</email>
    <extra_contact_info>mailto:[email protected]</extra_contact_info>
    <report_id>[email protected]</report_id>
    <date_range>
      <begin>1613088000</begin>
      <end>1613174399</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>mycompany.nl</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>none</sp>
    <pct>70</pct>
    <fo>1</fo>
  </policy_published>
  <record>
    <row>
      <source_ip>95.xx.xx.xx</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>quarantine</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>server.serverdomain.nl</envelope_from>
      <header_from>mycompany.nl</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>server.serverdomain.nl</domain>
        <scope>mfrom</scope>
        <result>none</result>
      </spf>
    </auth_results>
  </record>
</feedback>

As for the grep command, I have to look at this because that gives me loads of output.

I already have SMTP_BLOCK=1 in csf/lfd for a long time, and have SMTP_ALLOWLOCAL=1 to allow scripts to send out mail.

I have to go now, but I will put some of the log of the grep command when I'm back within an hour.

Ok so that narrows a lot at least. It should be hitting exim and we should have a sample between these times GMT:

Friday, February 12, 2021 12:00:00 AM
Friday, February 12, 2021 11:59:59 PM

So converting that time to server time and running through all exim logs (mainlog and the others), filtering for server.serverdomain.nl, anything that should be finding its way to xs4all. I don't know if xs4all provides hosting for custom domains or just like a free @xs4all.nl address, you'd know more on that. If the latter, easier to filter for. If they allow custom domains, you'd have to check MX for everything going out to be sure.

So let's just say for the sake of an example that your server time is set to GMT, and that @xs4all.nl is the only recipient domain that xs4all will be receiving mail to, I'm thinking something like:

for i in $(grep "2021-02-12" /var/log/exim/* | grep "<=" | grep "server.serverdomain.nl" | awk '{print $3}' | sort | uniq); do grep $i /var/log/exim/* | grep "xs4all"; done

We're going to get more than the right answer, I'm just thinking the right answer will be packed in there too. If we come up dry with that theory, I'm stumped, and either my logic is flawed or not being applied in the way I'm expecting it to in my head.
 
Yep that was a good idea. I tried that before too looking at times but couldn't find anything as far as xs4all goes.
I do know that I have at least one customer with an xs4all forward, but I didn't send him any mails in that time as far as I know. The system did though.
This is the output:
Code:
/var/log/exim/mainlog-20210214:2021-02-12 08:24:33 1lASoa-0001kP-Vz <= [email protected] U=root P=local S=989 T="Script Updates Available" from <[email protected]> for [email protected]
/var/log/exim/mainlog-20210214:2021-02-12 08:24:36 1lASoa-0001kP-Vz => [email protected] F=<[email protected]> R=lookuphost T=remote_smtp S=1049 H=mx4.xs4all.nl [194.109.24.139] X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C="250 2.0.0 mxdrop305.xs4all.net accepted message 11C7OXIY005046"

Just to be sure I adjusted your command and changed xs4all to mycompany and I got this:
Code:
/var/log/exim/mainlog-20210214:2021-02-12 02:00:08 1lAMoa-0001dV-BN => mymail <[email protected]> F=<[email protected]> R=virtual_user T=dovecot_lmtp_udp S=1157 C="250 2.0.0 <[email protected]> IFrNHBjTJWBQcwAAursqdw Saved"
/var/log/exim/mainlog-20210214:2021-02-12 03:10:44 1lANuu-0004aS-D7 <= [email protected] U=diradmin P=local S=932 T="New Message: Your backups are now ready (id=1)" from <[email protected]> for [email protected]
/var/log/exim/mainlog-20210214:2021-02-12 03:10:44 1lANuu-0004aS-D7 => mymail <[email protected]> F=<[email protected]> R=virtual_user T=dovecot_lmtp_udp S=1099 C="250 2.0.0 <[email protected]> tVPmHqTjJWDiAQAAursqdw Saved"
/var/log/exim/mainlog-20210214:2021-02-12 08:24:32 1lASoa-0001k2-EN <= [email protected] U=root P=local S=21720 T="Software Updates (server.serverdomain.nl)" from <[email protected]> for [email protected]
/var/log/exim/mainlog-20210214:2021-02-12 08:24:32 1lASoa-0001k2-EN => mymail <[email protected]> F=<[email protected]> R=virtual_user T=dovecot_lmtp_udp S=22830 C="250 2.0.0 <[email protected]> T80nJDAtJmB8EwAAursqdw Saved"

Both of these are the only entrances which appear when running the command. No other entries found.

XS4all was previously a small provider until years ago been takenover by KPN which was the biggest ISP in the Netherlands at that time. Now the biggest is Ziggo, which is a cable company.
No free @xs4all or @kpn domains available, all are customers of these company's. Most dmarc reports I get from Google though, but they look the same as this.

My server time is set to Europe/Amsterdam which is GMT+1 if I'm correct.

I'm stumped, and either my logic is flawed or not being applied in the way I'm expecting it to in my head.
Yeah exactly that! That's what I was thinking about my logic or application of it when I ran into this issue. So you're not alone. ;)
 
I think you're on to something. Doing a little digging led me down an interesting path that started here: https://www.softaculous.com/news/tag/directadmin

And then led me here: https://forum.directadmin.com/threads/getting-odd-gmail-dkim-reports.61517/

Seems like you've been down this path before and it led you to where I'm already going with it. On March 24, 2014 there's a post on Softaculous blog that suggests the "Script Updates Available" emails are sent using the DA reseller's email as the From address. So that'd be the "email=" in /usr/local/directadmin/data/users/yourresellerusername/user.conf. If that has your company domain, the one you're receiving these DMARC reports for, any chance you can get your hands on one of these softaculous emails to check the headers and see if we might have a match? If I'm right then it would have "Envelope From" as root@hostname, "From" as the value in "email=" from user.conf, and would fail SPF/DKIM.

Now as to why this just now becomes relevant after a DA update I can't say, but if we've found the culprit then that's probably the single greatest thing.
 
Pfoe that is long time years ago something then with alias or so whatever i can't find my notes,.
For the software updates.

This is here the header for your information hostname replaced and owndomain on same server also. ( so you can look if yes or no same)
Return-Path: <root@hostname>
Delivered-To: info@owndomain
Received: from hostname
by hostname with LMTP
id 0XCHA6E9KGDsbZAAALUHJOA
(envelope-from <root@hostname>)
for <info@owndomain>; Sat, 13 Feb 2021 21:59:13 +0100
Return-path: <root@hostname>
Envelope-to: info@owndomain
Delivery-date: Sat, 13 Feb 2021 21:59:13 +0100
Received: from root by hostname with local (Exim 4.94)
(envelope-from <root@hostname>)
id 1lB20sW-00s06kF-V3
for info@owndomain; Sat, 13 Feb 2021 21:59:13 +0100
To: info@owndomain
Subject: =?UTF-8?B?U29mdHdhcmUgVXBkYXRlcyAodnBzNjQsweNjIuYy15ZXMuY29tKQ==?=
X-PHP-Originating-Script: 0:mail_functions.php
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
From: Softaculous <info@owndomain>
Reply-To: info@owndomain
X-Mailer: P
Message-Id: <E1lB20W-0006ekF-V3@hostname>
If so then this in combi with exim.dkim.conf ? Wen forwarding.


If so i think it is not good for reputation for mailserver, while the ip mailserver/host is same as the domains normally are sending mails or?

And if yes the softacolous has then the emailscript where looking for long time now. https://forum.directadmin.com/threads/getting-odd-gmail-dkim-reports.61517/#post-315920

Richard for the 23 server where you have now dkim on hostname, that dkim in dmarc reports should be ok now or?
If in those dns you has set to:

So indeed either make sure it sends from a different address, or you need to add a TXT/SPF record for server.serverdomain.nl.
oals je kunt zien uit het dmarcian rapport mag serverdomein.nl dus ook sturen vanuit mijn naam. Echter zal dan wat ArieH zegt nodig zijn omdat het niet via SMTP gaat maar via php mail dat die hostnaam ook opgenomen dient te worden.
Het enige wat mij verbaast is dat de SPF check het (sub)domein c.q. hostnaam niet resolved want dan zou het geauthoriseerde ip tevoorschijn komen.
Maar schijnbaar is dat hoe die combinatie werkt. https://forum.directadmin.com/threads/getting-odd-gmail-dkim-reports.61517/page-2#post-316023
 
Last edited:
Now as to why this just now becomes relevant after a DA update I can't say,
Good find! (y)
In that post we're talking june last year. At that time exim.dkim.conf version 1.4 was present. I didn't have those issues anymore later in exim.dkim.conf 1.5.
Now since the update we're at exim.dkim.conf 1.6 which is exactly the same as 1.4. Which could again cause the same issues I was having at that time. So that could explain why it happened after the update.

Due to this fact I now remember I put in an email address of mycompany.nl indeed in the "from" setting in Softaculous.

I'm going to try to have Softaculous send an email and get the headers.
OMG if that is indeed the culprit, it should be an easy fix I think.
 
We're getting somewhere indeed.
I created several tries now. when looking in the headers in softaculous mail, I indeed see my company name.

SPF is pass, but DMARC is fail and DKIM record is not even present. In spite of the fact that this is set for the hostname @ikkeben, in this case no DKIM record is created. I don't know why, maybe because Softaculous is using php mail?
This is when I used the current setting with my company's email address:

Code:
Received-SPF: pass (google.com: domain of [email protected] designates 95.xx.xx.xx as permitted sender) client-ip=95.xx.xx.xx;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] designates 95.xx.xx.xx as permitted sender) [email protected];
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mycompany.nl
Received: from root by server.serverdomain.nl with local (Exim 4.94) (envelope-from <[email protected]>) id 1lBLd5-00056D-M4

When I add my server's hostname in SPF as suggested in the other thread I get the same. SPF pass, but DMARC still fail.
The message is titled:
[email protected] via server.serverdomain.nl

If I use [email protected] as from address in Softaculous, then I only get an SPF pass since the hostname has an SPF record and no fails.

On every test I did, the envelope-from is indeed [email protected].

So if I'm correct, the only solution would be to not use mydomain.nl in any way as sending from address in Softaculous, correct?
That is a pity.

Customers don't expect "root@hostname" messages, which was the reason I used this in the past.
Otherwise I will keep getting DMARC fails and ofcourse also DKIM fails because no DKIM record is created in any way.

Odd that softaculous/exim is creating spf records, but no dkim records.
Seens that can only be setup in the admin section of Softaculous if I've read that correctly on Softaculous just now.
 
We're getting somewhere indeed.
I created several tries now. when looking in the headers in softaculous mail, I indeed see my company name.

SPF is pass, but DMARC is fail and DKIM record is not even present. In spite of the fact that this is set for the hostname @ikkeben, in this case no DKIM record is created. I don't know why, maybe because Softaculous is using php mail?
This is when I used the current setting with my company's email address:

Code:
Received-SPF: pass (google.com: domain of [email protected] designates 95.xx.xx.xx as permitted sender) client-ip=95.xx.xx.xx;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] designates 95.xx.xx.xx as permitted sender) [email protected];
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mycompany.nl
Received: from root by server.serverdomain.nl with local (Exim 4.94) (envelope-from <[email protected]>) id 1lBLd5-00056D-M4

When I add my server's hostname in SPF as suggested in the other thread I get the same. SPF pass, but DMARC still fail.
The message is titled:


If I use [email protected] as from address in Softaculous, then I only get an SPF pass since the hostname has an SPF record and no fails.

On every test I did, the envelope-from is indeed [email protected].

So if I'm correct, the only solution would be to not use mydomain.nl in any way as sending from address in Softaculous, correct?
That is a pity.

Customers don't expect "root@hostname" messages, which was the reason I used this in the past.
Otherwise I will keep getting DMARC fails and ofcourse also DKIM fails because no DKIM record is created in any way.

Odd that softaculous/exim is creating spf records, but no dkim records.
Seens that can only be setup in the admin section of Softaculous if I've read that correctly on Softaculous just now.

I think what we've identified here is a lazy solution by Softaculous that isn't up to expectations with current email trends. The way that they send these emails needs to be revisited, in my opinion.

Best way would clearly be to let you define SMTP settings for their app and send through your actual intentional methods. That's not a large ask.
 
You're quite correct.
At least they should add the smtp-auth option for resellers too.

I totally forgot about Softaculous since I never use it myself.

Anyway, many thanks for thinking with me and finding the culprit. At least I have a workaround now which I can use the fix the bad reports.
Thank you! (y) (y)
 
You're quite correct.
At least they should add the smtp-auth option for resellers too.

I totally forgot about Softaculous since I never use it myself.

Anyway, many thanks for thinking with me and finding the culprit. At least I have a workaround now which I can use the fix the bad reports.
Thank you! (y) (y)
I think what we've identified here is a lazy solution by Softaculous that isn't up to expectations with current email trends. The way that they send these emails needs to be revisited, in my opinion.

Best way would clearly be to let you define SMTP settings for their app and send through your actual intentional methods. That's not a large ask.
Thanks

But then after the DA update, more APPS / plugins using such scripts in that older lazy way could have problems i guess.
If i am correct , for email reputation to take care of such or?
 
more APPS / plugins using such scripts in that older lazy way could have problems i guess.
Yes but only if DKIM and DMARC is used. Unfortunately lots of admins and resellers only use SPF records (or worse, nothing at all) and so they probably don't run into this problem.

The only odd thing is that in the headers of the mais I've tested now, in every case SPF was passed while in the Dmarc reports both spf and dkim say fail.
 
But then after the DA update, more APPS / plugins using such scripts in that older lazy way could have problems i guess.
If i am correct , for email reputation to take care of such or?

It's unclear. While we're talking about the correlation of a DA update, we still haven't arrived at any conclusive evidence that it's related. It could be timing.

For example, Softaculous may go months without having to send out these emails because there were no script updates or they were run before notification was needed.

Before or after an update, DKIM wouldn't be signing for the server hostname by default. DKIM signing should be based on what ends up being read as "envelope from" and that "shouldn't" have changed with any update of anything but Softaculous. I don't see the logic of the DKIM signing string changes making an impact on that. Maybe @smtalk wants to fact check me on that just for a second opinion.

I remain open to a different conclusion on that, but that's my interpretation of the data at this point in time.

The only odd thing is that in the headers of the mais I've tested now, in every case SPF was passed while in the Dmarc reports both spf and dkim say fail.

This is indeed the remaining puzzle piece. I suppose we probably have to shrug it off as the base function is imperfect to a more relevant degree, but it still bothers me because I like to have problems wrapped up with a nice bow on top.
 
Last edited:
but it still bothers me because I like to have problems wrapped up with a nice bow on top.
Well... we can shake hands on that. Got the same thoughts here, also with pc problems or anything. I like it when it's solved, but still keep get a bit bothered when I can't find the real bottom of the issue. Wrapped up like you say. However, sometimes we just don't get that far.

By changing the from name in softaculous at least the bad reports should stop now, except for those generated by spoofing systems.

In any case I put in a suggestion at Softaculous to put in SMTP-auth options for resellers too.
 
Back
Top