Suitecrm: SMTP Spamming

[mbates14]

I am noticing a problem with SuiteCRM, There apparently is an undiscovered vulnerability that is causing us extreme issues.

If I add an SMTP system account in SuiteCRM, our server gets used as a Spam Relay rather quickly, and I start getting 20 to 30 catch-all bouncebacks daily. I cannot find anything in the apache logs so its driving me nuts!!!

So I have to change the mail account password and disconnect the SMTP account from SuiteCRM. Then everything is fine.

But the 3 sales people on our current system cannot send emails through the CRM anymore if I disable SMTP.

With the spamming, I figured it was a fluke from my windows WAMP Server, so I moved over to DigitalOcean on a CentOS 7 server in the cloud.

I enabled DKIM on our domain to try and eliminate problems, and I turned on SMTP again in the SuiteCRM system.

Not even 15 minutes of adding a new SMTP system account, Boom I started getting a ton of bounce-back catch-alls. I assume spam relay??

Here is an example of the "Catch-All" bounce-back we get:

`Begin forwarded message:

From: "Content-filter at hiero.abul.org" [e-mail]
Subject: Considered UNSOLICITED BULK EMAIL, apparently from you
Date: March 23, 2017 at 7:19:20 AM EDT
To: [e-mail]

A message from < [email protected]>
to: [email protected]
to: christophe.[email protected]
to: jean.[email protected]
to: [email protected]
to: h.[email protected]

was considered unsolicited bulk e-mail (UBE).

Our internal reference code for your message is 27562-07/iHkLGB8iRfng

The message carried your return address, so it was either a genuine mail
from you, or a sender address was faked and your e-mail address abused
by third party, in which case we apologize for undesired notification.

We do try to minimize backscatter for more prominent cases of UBE and
for infected mail, but for less obvious cases some balance between
losing genuine mail and sending undesired backscatter is sought,
and there can be some collateral damage on either side.

First upstream SMTP client IP address: [147.210.68.129] osiris.abul.org
According to a 'Received:' trace, the message apparently originated at:
[160.120.51.136], osiris.abul.org osiris.abul.org [147.210.68.129] using
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Client CN
" osiris.abul.org", Issuer " osiris.abul.org" (not verified)

Return-Path: < [email protected]>
From: "Heather Koch" < [email protected]>
Message-ID: < [email protected]>
Subject: I've got strong reasons to believe that this stock is about to soar.

Delivery of the email was stopped!
Reporting-MTA: dns; hiero.abul.org
Received-From-MTA: dns; hiero.abul.org ([127.0.0.1])
Arrival-Date: Thu, 23 Mar 2017 12:19:20 +0100 (CET)

Original-Recipient: rfc822; [email protected]
Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.7.0
Diagnostic-Code: smtp; 554 5.7.0 Bounce, id=27562-07 - spam
Last-Attempt-Date: Thu, 23 Mar 2017 12:19:20 +0100 (CET)
Final-Log-ID: 27562-07/iHkLGB8iRfng

Original-Recipient: rfc822; [email protected]
Final-Recipient: rfc822; christophe.[email protected]
Action: failed
Status: 5.7.0
Diagnostic-Code: smtp; 554 5.7.0 Bounce, id=27562-07 - spam
Last-Attempt-Date: Thu, 23 Mar 2017 12:19:20 +0100 (CET)
Final-Log-ID: 27562-07/iHkLGB8iRfng

Original-Recipient: rfc822; [email protected]
Final-Recipient: rfc822; jean.[email protected]
Action: failed
Status: 5.7.0
Diagnostic-Code: smtp; 554 5.7.0 Bounce, id=27562-07 - spam
Last-Attempt-Date: Thu, 23 Mar 2017 12:19:20 +0100 (CET)
Final-Log-ID: 27562-07/iHkLGB8iRfng

Original-Recipient: rfc822; [email protected]
Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.7.0
Diagnostic-Code: smtp; 554 5.7.0 Bounce, id=27562-07 - spam
Last-Attempt-Date: Thu, 23 Mar 2017 12:19:20 +0100 (CET)
Final-Log-ID: 27562-07/iHkLGB8iRfng

Original-Recipient: rfc822; [email protected]
Final-Recipient: rfc822; h.[email protected]
Action: failed
Status: 5.7.0
Diagnostic-Code: smtp; 554 5.7.0 Bounce, id=27562-07 - spam
Last-Attempt-Date: Thu, 23 Mar 2017 12:19:20 +0100 (CET)
Final-Log-ID: 27562-07/iHkLGB8iRfng
Return-Path: < [email protected]>
Received: from osiris.abul.org ( osiris.abul.org [147.210.68.129])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN " osiris.abul.org", Issuer " osiris.abul.org" (not verified))
by hiero.abul.org (Postfix) with ESMTPS id 6B3D3158D7B2
for < [email protected]>; Thu, 23 Mar 2017 12:19:20 +0100 (CET)
Received: from [160.120.51.136] (unknown [160.120.51.136])
by osiris.abul.org (Postfix) with ESMTP id 6A24223FA7
for < [email protected]>; Thu, 23 Mar 2017 11:58:14 +0100 (CET)
Received: (from apache@localhost)
by majordisplay.com (8.14.7/8.14.7/Submit) id B5CB77C665E80A;
Thu, 23 Mar 2017 11:19:11 -0000
Message-Id: < [email protected]>
To: [email protected]
Subject: I've got strong reasons to believe that this stock is about to soar.
X-PHP-Originating-Script: 1007:Sendmail.php
From: "Heather Koch" < [email protected]>
Date: Thu, 23 Mar 2017 11:19:11 -0000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0 `

Obviously this Koch or whatever (I assume generated from a skiddy) doesnt exist with us. And there are bunch of other random "users" on our domain.

Enabling DKIM and setting to reject does nothing to prevent these! Changing the password on the account used for the SuiteCRM System SMTP account DOES FIX IT....

This is becoming a huge problem... Fix?

[Mausino]

@mbates14 i totally agree with you. We have same problem. When is our SuiteCMR connected to SMTP many of our emails are bounced.... I don't know why :( but if we dissable connection.. the deliverity is much better. To analyse the problems we're using mxtoolbox and our score is max

Original Header of email which was sent from SuiteCRM

Return-Path: [e-mail]
Delivered-To: [email protected]
Received: from c7320.sgvps.net
by c7320.sgvps.net (Dovecot) with LMTP id 3sOHKgOVvVgsDAAAM+6LUg
for [e-mail]; Mon, 06 Mar 2017 10:57:39 -0600
Return-path: [e-mail]
Envelope-to: [email protected]
Delivery-date: Mon, 06 Mar 2017 10:57:39 -0600
Received: from [194.1.226.241] (port=52985 helo=[10.0.0.104])
by c7320.sgvps.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)
(Exim 4.87)
(envelope-from [e-mail])
id 1ckvx5-0000o6-B9; Mon, 06 Mar 2017 10:57:39 -0600
Subject: =?UTF-8?Q?[OPRAVA]_Fwd:_FW:_AW:_[RE1228]=2c_[ID1308]_Buchung_von_Un?=
=?UTF-8?Q?terkunftSuche_f=c3=bcr_die_Partnerfirma:_Marian_Dufala?=
References: [e-mail]
To: [email protected]
From: Adam Mikolaj [e-mail]
X-Forwarded-Message-Id: [e-mail]
Message-ID: [e-mail]
Date: Mon, 6 Mar 2017 17:57:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: [e-mail]
Content-Type: multipart/mixed;
boundary="------------30DCE305AAB7B0484DEC8606"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------30DCE305AAB7B0484DEC8606
Content-Type: multipart/alternative;
boundary="------------5E93334F4927F39CE1DBA9BA"

--------------5E93334F4927F39CE1DBA9BA
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

and analyse from mxtoolbox.com

we're getting those issues:

Reporting-MTA: dns; c7320.sgvps.net
Action: failed
Final-Recipient: rfc822;scensna.[email protected]
Status: 5.0.0
Remote-MTA: dns; outbound.mailspamprotection.com
Diagnostic-Code: smtp; 550 A URL in this email (dnsserver . eu) is listed on https://spamrl.com/. Please resolve and retry

Action: failed
Final-Recipient: rfc822;Angelina.[email protected]
Status: 5.0.0
Remote-MTA: dns; mail.iso-perfekt.com
Diagnostic-Code: smtp; 550 5.7.1 [e-mail]: Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; please relay via your ISP (unterkunft-suche.eu)

Reporting-MTA: dns; se9.mailspamprotection.com
Action: failed
Final-Recipient: rfc822;[email protected]
Status: 5.0.0
Remote-MTA: dns; mta-in.telekom.sk
Diagnostic-Code: smtp; 550 5.1.1 unknown or illegal alias: [email protected]

[samus-aran]

Hi @mbates14 and @Mausino

Sounds like a genuine issue and we would like to encourage Security issues to be raised by sending us an email at security[at]salesagility.com.

We do know the current PHPMailer 5.2.21 was introduced for 7.7.9 SuiteCRM which included the Security Fixes listed on PHPMailers Github page

The latest upgrade doesn't appear to contain a solution to what it sounds like your issue is.

What versions are you both on?

[gunnicom]

@Mausino But you should check your dns settings. Wrong reverse DNS-Lookup often leads to bounced mails:

SMTP Reverse DNS Mismatch Reverse DNS does not contain the hostname More Info
SMTP Banner Check Reverse DNS does not match SMTP Banner More Info
SMTP TLS Warning - Does not support TLS. More Info

[Mausino]

sorry, that i didn't write those info @samus-aran we have SuiteCRM 7.8.3, Chrome 55.x, Win 10 home..

@gunnicom i did the test of smtp i got also those results https://mxtoolbox.com/SuperTool.aspx?action=mx%3aunterkunft-suche.eu&run=toolpage# currently i'm working on it with hosting

what i want only tell you that i have same (similary) issue as @mbates14 that if my smtp is disconnected away from SuiteCRM that it's working much better ( success in % deliverity of mails)

[mbates14]

I used gitclone and grabbed the build directly from here in late February, so whatever it was at that point?

We are getting 20 to 30 bounce-backs to script-kiddy generated fake emails in our catch-all account daily so this issue really needs fixed something fierce.

Soon as I changed the password to the account I had associated for SuiteCRM's notification/system SMTP mailer, the spamming goes away.

I fix it, and it comes right back! The one thing that I am noticing is the password HAS to be changed on the SMTP side to fix it, its almost as if they are getting the password somehow.

Also in case it matters, the Mail server/SMTP server IS NOT the same box as the CRM server! Our mail server is register.com and is hosted for/by our domain, and I use their DKIM services.

[mbates14]

Also I want to state, it seems my issue is different than his.

When sending out email from our standard webmail accounts, and through the CRM (when its working), I have 0 issues.

Like [email protected] doesnt exist, but email "From" is from that.... As noted above, aka Spamming Scripts...

But our catch-all account is attached to the same exact account as we are using for SMTP Authentication for SuiteCRM's System email.

So, if I change that SMTP server to my personal one, my personal email gets flooded with bounce-backs. Reason being, since my personal account is the one being used for SMTP-Authentication, thats how the bounce-backs route them back to me. It's not instant. it can take anywhere from 15 minutes to a day after I change the SMTP system account to mine for spam returns to start showing up in my Inbox. the "From" being users that dont exist, but somehow the mail routs back to me. Probably because again, my SMTP credentials are pillaged.

So that proves to me the info the skiddys need to turn on the spamming wagon is being siphoned from, or relayed through SuiteCRMs SMTP/PHPMailer system. Somehow...

whatever it is, it doesnt show up in the Apache log, or I am missing it...

[chris001]

Your problem: https://en.wikipedia.org/wiki/Backscatter_(email)
The solution:
Enable all of these email security features on your SMTP mail server:

1. DMARC
2. DNSSEC
3. SPF
4. DKIM
5. Sender-ID
6. Greylisting

If you don't know what these are or how to enable them, you should ask your hosting tech support.
Then report back here about if this solved your spam problem.

[gunnicom]

And if it is a security problem we need to collect informations.
Can you see the sent emails in your mail server log?
If yes, from which IP are they sent (SuiteCRM IP?)?
If it is an other IP, can you try to block this ip, and check if problem persist?

[mbates14]

Thats just it. I cant find anything in the logs, at least nothing that I know how to see?

Also everything above, Only thing I have access to is DKIM. I dont have access to anything else as its Register.com webmail.

At this point I am unsure how to proceed, as I explained above, I know what works, and what doesnt. Disabling mail in the SuiteCRM system and changing SMTP passwords fixes the problem, it takes a bit to stop but it will.

Re-adding the system account SMTP-Auth, it starts up again. I read your "Backscatter" link, but from what I could tell backscatter happens on "BOUNCE" requests from the SMTP server.

I am getting BOTH BOUNCE AND REJECTs....

[mbates14]

I checked, SPF was already done when I setup DKIM.

[chris001]

@mbates14 In fact, Backscatter happens when any random spammer, from any random IP address on the internet, is able to get away with sending a spam email with a forged "From:" email address, consisting of a fake (or real) user@your email domain, and their spam email message is NOT instantly rejected by the global internet mail server infrastructure due to bad sending IP address, why was it not rejected instantly, because your domain doesn't have strong anti-forgery email security protections enabled.
Ask register.com tech support to enable ALL of the email protections on the list above ,especially DMARC and DNSSEC.
Also, post the full headers of the backscatter spam, it should contain the originating IP and/or hostname of the spammer.

[mbates14]

I did all that and now my LEGIT emails are bouncing back... GRRR....

The original message was received at Mon, 24 Apr 2017 12:45:48 -0400
from [10.30.77.134]

* ATTENTION *

This email is being returned to you because the remote server would not
or could not accept the message. The registeredsite servers are just
reporting to you what happened and are not the source of the problem.

The address which was undeliverable is in the section labeled:
"----- The following addresses had permanent fatal errors -----".

The reason your mail is being returned to you is in the section labeled:
"----- Transcript of Session Follows -----".

This section describes the specific reason your e-mail could not be
delivered.

Please direct further questions regarding this message to your e-mail
administrator.

--Registeredsite Postmaster

----- The following addresses had permanent fatal errors -----

[e-mail]
(reason: 550-5.7.1 Unauthenticated email from majordisplay.com is not accepted due to)

----- Transcript of session follows -----

... while talking to gmail-smtp-in.l.google.com.:

DATA
<<< 550-5.7.1 Unauthenticated email from majordisplay.com is not accepted due to
<<< 550-5.7.1 domain's DMARC policy. Please contact the administrator of
<<< 550-5.7.1 majordisplay.com domain if this was a legitimate mail. Please visit
<<< 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about the
<<< 550 5.7.1 DMARC initiative. o1si18620515qtb.231 - gsmtp
554 5.0.0 Service unavailable

[chris001]

That error means, your DMARC settings are set to make it so that you're not allowed (nobody is allowed) to send email without SMTP AUTH (logging in with your email password). You were trying to send it thru gmail server without SMTP AUTH. So read the link they provide to learn how to send it with SMTP AUTH.
Is your majordisplay.com using gmail mail servers to host its email? No, it's using register.com mail servers. So, you need to send out thru the designated SMTP servers for majordisplay.com which are listed in its DNS, as mx07.register.com.

Just remember: DMARC tells the SMTP servers what to do with the message when your email message fails SPF or DKIM.

More info:
https://dmarc.org/wiki/FAQ

[mbates14]

which doesnt make sense because I am logged into my webmail page to send the email??? So I am authenticated.

[chris001]

Which one are you, the gmail.com email address, or the majordisplay.com email address

[mbates14]

Majordisplay I own that domain, and I use register's services. DNS for A records, MX, and their webmail services.

Trying to combat this spam problem, Apparently something got broken somewhere. This happens when I log into my domain webmail, and send an email to a gmail address.

[chris001]

OK so clearly the problem is, you've configured Suitecrm to transmit emails directly out thru the gmail smtp server. Gmail smtp is very open, it accepts email from anyone on earth, it loves spying on the text and uses machine learning to read people's correspondence, and tries to use basic filtering to remove obvious spam, Gmail servers also use the full set of standard email security technologies, which when configured on your domain, such as SPK, DKIM, DMARC etc., allow gmail to, after it saves a copy of your private mail for future analysis, to correctly reject mail from any random spammer attempting to impersonate you to send email pretending to come from your domain. Rejecting spam this way is good for the internet. Yet how do you have SuiteCRM send out your email notifications then?
* The solution is, the Gmail smtp servers are not appropriate for you to be using for sending email. You must change the SuiteCRM Outgoing Email Configuration settings.
1. Login as an admin user, click your user icon, Admin, Email, Email Settings, Outgoing Mail Configuration.
2. Supply the From name and valid From address. Such as, [email protected], this is a good one to create and use for the SuiteCRM system notification emails.
3. You must have it transmit email out thru your designated mail server on your domain, so set Set SMTP Mail Server to mx07.register.com.
4. Check on the box for "Use SMTP Authentication", supply a username and password to your [email protected] email account on the mx07.register.com mail server,
5. Set Enable SMTP over SSL or TLS? Yes, TLS. Set SMTP port to 587.
6. There are several other email account settings, under your user icon, Admin, Email. Review those and set them to use your designated mail server, mx07.register.com, and not using the gmail mail server.

[mbates14]

Again, I don't use gmail. EVER.... Never have I, and Never will I for sending mail.

Just so happens some of the people I send email TO are on GMAIL. I fixed the GMAIL problem by removing my SPF entry on my domain.

And Yes, my SuiteCRM is configured correctly to send email. I would like to get back to my original topic of when I add my SMTP credentials no matter WHO THE SMTP PROVIDER IS, whether it is my Domain, or my ISP, or anything, the second I add that and get the mail system working, I immediately start getting bounces. or this "backscatter" as someone has coined.

[chris001]

It's likely that your SPF entry has a mistake in it. SPF, when configured correctly, works just fine and prevents spammers from impersonating you for the purposes of sending email. If you've configured it incorrectly, then even you, who should be set as a legit mail sender, could be classified as an unauthorized sender of mail. The same goes for your DMARC entry, it might have a mistake in it. You should have someone look over them, or post them here.

[lispeedyg]

Hi All, I've been saddled with this same issue for almost a year now. I've posted on a number of site without resolution. We've gone through all the DMARC configurations and still continue to be the spam center for this bug. I've also sent an email to security>salesagility recently, based on this thread.

Anyway, i think I may have another clue to the problem. As mentioned above, there seemed to be no end to the spamming. The implementation was originally hosted within a static domain with all normal ports open for such a domain. I then moved the VM to another installation (Consumer) where the IP was dynamic and the ports were much more restrictive. And, with all other configurations left unchanged there was NO spam. So, it appears that the bug may only work if port 25 is available on the domain. I'm going to do a bit more research to see if I can further identify the issue(s), and report back.

[mbates14]

I am glad I am not the only one. See, I am not insane! Cant blame the "customer" again here. Dont get me wrong, setting up SPF, DKIM, and DMARC has helped tremendously but its still not perfect. But the FACT of the matter is, I didn't have to worry about ANY of it until adding mail support in the CRM. Soon as I did that, BAM the Spoofers and Spammers have started.

[chris001]

@Mausino

Action: failed
Final-Recipient: rfc822;[email protected]
Status: 5.0.0
Remote-MTA: dns; mail.iso-perfekt.com
Diagnostic-Code: smtp; 550 5.7.1 [email protected]: Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; please relay via your ISP (unterkunft-suche.eu)

    SMTP Reverse DNS Mismatch Reverse DNS does not contain the hostname More Info
    SMTP Banner Check Reverse DNS does not match SMTP Banner More Info
    SMTP TLS Warning - Does not support TLS. More Info

@Mausino @mbates14 and @lispeedyg :
You need to provide the following information so that the cause of your backscatter spam problems can be determined.

1. SuiteCRM server and mail server - running on same server, or separate machines?
2. Operating system and version your SuiteCRM app is running on? Who's the system administrator that set it up and maintains it?
3. What operating system and version is your SMTP mail server running on? Who's the system admin?
4. Servers running on same or separate subnets ?
5. What mail scanning + system security software are you running on both servers?
6. What firewall are you running on both servers?
7. What server admin panel software are you running on both?
8. What other public server software are you running on both - web sites? ftp? documents? ssh? other?
9. Who configured the security settings on the outgoing mail submission connection between crm server and smtp server?
10. Which ports are exposed to the internet on both servers?
11. Which ports are accepting outgoing mail submissions on both?
12. Are either or both configured to require SMTP AUTH prior to accepting an outgoing mail?
13. Which protocols and ciphers are configured for accepting outgoing mail submissions?
14. Which of the following are configured on your smtp mail server, who configured them.
    a. SPF, b. DMARC, c. DNSSEC, d. DKIM, e. Sender-ID, f. Greylisting.
15. Does your CRM server and SMTP mail server have certified system admin hosting tech support personnel available to test/validate any/all of your security settings.

[Mausino]

@chris001 i will provide you all info 👍 but i will need some time (week) because yesterday i got with my wife baby and other things are priority... when i will have more time i will collect all points to help community grow up :) one question.. is possible in github write a privat messages ?

[chris001]

Congratulations! 🚬 There isn't a private message system in github. I sent you an email.

[chris001]

@Mausino @lispeedyg @mbates14
Which web server you using, Apache?

[ghost]

@chris001 I'm new to this whole spam-prevention stuff. just came across ARC. Sounds new. important?

http://arc-spec.org/

[chris001]

The OpenARC milter should be soon available as an add-on package for Postfix Sendmail and all other SMTP MTA mailers supporting the Sendmail milter interface standard.
https://github.com/mskucherawy/OpenARC
ARC will reduce or eliminate false positives, where certain legitimate email - mailing lists, etc. - previously registered as spam and filed to the spam folder or dropped.

[sergio91pt]

Suggestion

SuiteCRM should add headers to every sent email.
Something like X-SuiteCRM-User-Id and X-SuiteCRM-Mail-Id (when applicable).

This would help triage weather or not it is SuiteCRM code sending the emails and weather or not it may be sending through a compromised user account.

[chris001]

@sergio91pt
The SMTP server is supposed to add a unique Message-ID header already.
https://tools.ietf.org/html/rfc5322
http://www.postfix.org/postconf.5.html

[sergio91pt]

@chris001 Message-ID §3.6.4 is normally set by the client and not modified by the server, as it would probably break email threading.

If set by the SMTP server, it won't be of use to identify weather or not SuiteCRM code is sending those emails. Trace headers added by SMTP servers should be enough to know which machine is sending the emails.

SugarPHPMailer's Message-ID is generated, if unset, in preSend()
and is equivalent to md5(uniqid(time())) . '@' . $sugar_config['host_name'].

Message-ID would work for module=Emails&action=send, in fact there already is a message_id field in the Email bean (indexed in the database), but seems to be only used for imported emails and not type = out.
If we go through this route, we should prefix the Message-Id, so we can easily identify ones that should have a corresponding entry in the emails table.

[Mausino]

Small update from our side :)

@Dillon-Brown i think that upgrade to PHPMailer 6.x + #6024 (this is not merge yet, but in our instance yes, + we did some correction in this pull request by our developer) helps us in spam score. Now we have any problem with spam score in our new client. Can't tell you that only this did but in 7.11 our score is for us sure better because we have less complains about undelivery of emails or spam assign by our clients.

[pgorod]

@Mausino nice to hear that.

About this issue here, I am not sure I understand what needs to be done. It is marked as a high-priority "bug" but I don't know what the bug is, if there is one. Can you help clarify?

[Mausino]

@pgorod also i am not sure... But my main problem was if i sent from other software like roundcube or thunderbird, my spam score was much better as from SuiteCRM rewamped email module. The server settings like dkim, etc were same for all...

I think that if apache spam assassin cant identify email by uniqe id you start get banned. Your score is better if your email is open a best if other site reply on it.

But from discussions many of users can confirm that isnt possible on replied email identify and missing also function about if was email recieived or red.

I am not email expert.. You cant agree and maybe i am wrong. I only see that after upgade and add ids we have better deliverity to clients.

[pgorod]

@samus-aran @Dillon-Brown with the changes made to SuiteCRM lately, involving the new PHPMailer and possibly some other changes, I suggest closing this issue. Most of it is the troubleshooting of a particular case of email reputation.

If there is something to change in SuiteCRM in this regard, then it needs to be clearly defined, and it needs to apply to the current version, so it's better if someone starts a new issue then.