Issue Outgoing mail queue, how to find the source of the spam?

[D4NY]

Server operating system version

CentOS Linux 7.9.2009 (Core)

Plesk version and microupdate number

Plesk Obsidian 18.0.49

Hello everyone,
in my mail queue i've found in the last days some outgoing mails (see screenshot). It's not a massive queue with tons of spam (like when a bugged script is running or mail account password hacked).


Only a couple of them every 30/40 minutes are added to this list.
I would like to find the source of the problem and fix it.

Opening the message header i read this:

Received: by flamboyant-goldwasser.54-36-113-226.plesk.page (Postfix)
id 47DAC30972C53; Fri, 24 Feb 2023 23:01:06 +0100 (CET)
Date: Fri, 24 Feb 2023 23:01:06 +0100 (CET)
From: [email protected] (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: kohls_poll_reward-marco.giorio=[email protected]
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="892BC30972C55.1677276066/flamboyant-goldwasser.54-36-113-226.plesk.page"
Message-Id: <20230224220106.47DAC30972C53@flamboyant-goldwasser.54-36-113-226.plesk.page>

the only detail in common for all is

flamboyant-goldwasser.54-36-113-226.plesk.page

Running
tail -f /var/log/maillog
tail -f /var/log/maillog | grep sasl_username
I couldn't find nothing relevant to my eyes.

Any idea?

 

[D4NY]

This is what i've found on the maillog for the last of those mail in the queue

Feb 24 23:01:00 [MYSERVERNAME] postfix/smtpd[18384]: 5A88C3092FD82: client=unknown[193.24.210.61]
Feb 24 23:01:00 [MYSERVERNAME] psa-pc-remote[24313]: 5A88C3092FD82: from=<kohls_poll_reward-[NAME-CHANGED].[SURNAME-CHANGED]=[DOMAIN-CHANGED]@ldgqobsidianglow.autos> to=<[NAME-CHANGED].[SURNAME-CHANGED]@[DOMAIN-CHANGED]>
Feb 24 23:01:01 [MYSERVERNAME] dovecot: pop3-login: Disconnected: Disconnected: Too many bad commands (no auth attempts in 0 secs): user=<>, rip=185.58.117.243, lip=[MYSERVERIP], session=<Sw/PQ3n1cNu5OnXz>
Feb 24 23:01:01 [MYSERVERNAME] dovecot: pop3-login: Disconnected: Disconnected: Too many bad commands (no auth attempts in 0 secs): user=<>, rip=185.58.117.243, lip=[MYSERVERIP], session=<M5/WQ3n1dtu5OnXz>
Feb 24 23:01:03 [MYSERVERNAME] dovecot: pop3-login: Disconnected: Connection closed: SSL_accept() failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown: SSL alert number 46 (no auth attempts in 0 secs): user=<>, rip=5.91.97.79, lip=[MYSERVERIP], TLS handshaking: SSL_accept() failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown: SSL alert number 46, session=<SFjyQ3n1DOcFW2FP>
Feb 24 23:01:03 [MYSERVERNAME] dovecot: pop3-login: Disconnected: Connection closed: SSL_accept() failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown: SSL alert number 46 (no auth attempts in 0 secs): user=<>, rip=77.32.17.220, lip=[MYSERVERIP], TLS handshaking: SSL_accept() failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown: SSL alert number 46, session=<RcfyQ3n11sNNIBHc>
Feb 24 23:01:03 [MYSERVERNAME] postfix/cleanup[18279]: 5A88C3092FD82: message-id=<[email protected]>
Feb 24 23:01:03 [MYSERVERNAME] psa-pc-remote[24313]: 5A88C3092FD82: py-limit-out: stderr: INFO:__main__:No SMTP AUTH and not running in sendmail context (incoming or unrestricted outgoing mail). SKIP message.
Feb 24 23:01:03 [MYSERVERNAME] psa-pc-remote[24313]: 5A88C3092FD82: py-limit-out: stderr: SKIP
Feb 24 23:01:03 [MYSERVERNAME] psa-pc-remote[24313]: 5A88C3092FD82: spf: stderr: PASS
Feb 24 23:01:03 [MYSERVERNAME] psa-pc-remote[24313]: 5A88C3092FD82: check-quota: stderr: SKIP
Feb 24 23:01:03 [MYSERVERNAME] postfix/qmgr[30184]: 5A88C3092FD82: from=<kohls_poll_reward-[NAME-CHANGED].[SURNAME-CHANGED]=[DOMAIN-CHANGED]@ldgqobsidianglow.autos>, size=5883, nrcpt=1 (queue active)
Feb 24 23:01:03 [MYSERVERNAME] postfix-local[18455]: 5A88C3092FD82: from=<kohls_poll_reward-[NAME-CHANGED].[SURNAME-CHANGED]=[DOMAIN-CHANGED]@ldgqobsidianglow.autos>, to=<[NAME-CHANGED].[SURNAME-CHANGED]@[DOMAIN-CHANGED]>, dirname=/var/qmail/mailnames
Feb 24 23:01:03 [MYSERVERNAME] dovecot: service=lda, user=[NAME-CHANGED].[SURNAME-CHANGED]@[DOMAIN-CHANGED], ip=[]. sieve: msgid=<[email protected]>: discard action: Marked message to be discarded if not explicitly delivered (discard action)
Feb 24 23:01:03 [MYSERVERNAME] plesk-sendmail[18458]: S18458: from=<kohls_poll_reward-[NAME-CHANGED].[SURNAME-CHANGED]=[DOMAIN-CHANGED]@ldgqobsidianglow.autos> to=<[email protected]>
Feb 24 23:01:03 [MYSERVERNAME] plesk-sendmail[18459]: S18458: add-from: stderr: SKIP
Feb 24 23:01:04 [MYSERVERNAME] postfix/smtpd[18384]: disconnect from unknown[193.24.210.61] ehlo=1 mail=1 rcpt=1 bdat=1 quit=1 commands=5
Feb 24 23:01:04 [MYSERVERNAME] plesk-sendmail[18459]: S18458: py-limit-out: stderr: INFO:__main__:Setting 'X-PPP-Vhost' header to 'localhost.localdomain'
Feb 24 23:01:04 [MYSERVERNAME] plesk-sendmail[18459]: S18458: py-limit-out: stderr: PASS
Feb 24 23:01:04 [MYSERVERNAME] plesk-sendmail[18459]: S18458: check-quota: stderr: SKIP
Feb 24 23:01:04 [MYSERVERNAME] postfix/pickup[3247]: 34FEC30972C57: uid=30 from=<kohls_poll_reward-[NAME-CHANGED].[SURNAME-CHANGED]=[DOMAIN-CHANGED]@ldgqobsidianglow.autos>
Feb 24 23:01:04 [MYSERVERNAME] postfix/cleanup[18279]: 34FEC30972C57: message-id=<[email protected]>
Feb 24 23:01:04 [MYSERVERNAME] postfix/qmgr[30184]: 34FEC30972C57: from=<kohls_poll_reward-[NAME-CHANGED].[SURNAME-CHANGED]=[DOMAIN-CHANGED]@ldgqobsidianglow.autos>, size=6814, nrcpt=1 (queue active)
Feb 24 23:01:04 [MYSERVERNAME] dovecot: service=lda, user=[NAME-CHANGED].[SURNAME-CHANGED]@[DOMAIN-CHANGED], ip=[]. sieve: msgid=<[email protected]>: redirect action: forwarded to <[email protected]>
Feb 24 23:01:04 [MYSERVERNAME] postfix-local[18455]: 5A88C3092FD82: send message: id=S18455 from=<SRS0=YRSt=6U=ldgqobsidianglow.autos=kohls_poll_reward-[NAME-CHANGED].[SURNAME-CHANGED]=[DOMAIN-CHANGED]@[DOMAIN-CHANGED]> to=<[email protected]>
Feb 24 23:01:04 [MYSERVERNAME] plesk-sendmail[18469]: S18455: from=<SRS0=YRSt=6U=ldgqobsidianglow.autos=kohls_poll_reward-[NAME-CHANGED].[SURNAME-CHANGED]=[DOMAIN-CHANGED]@[DOMAIN-CHANGED]> to=<[email protected]>
Feb 24 23:01:04 [MYSERVERNAME] plesk-sendmail[18470]: S18455: add-from: stderr: SKIP
Feb 24 23:01:04 [MYSERVERNAME] postfix/smtpd[18374]: lost connection after AUTH from unknown[115.239.177.131]
Feb 24 23:01:04 [MYSERVERNAME] postfix/smtpd[18374]: disconnect from unknown[115.239.177.131] ehlo=1 auth=0/1 commands=1/2
Feb 24 23:01:04 [MYSERVERNAME] plesk-sendmail[18470]: S18455: py-limit-out: stderr: INFO:__main__:Setting 'X-PPP-Vhost' header to '[DOMAIN-CHANGED]'
Feb 24 23:01:04 [MYSERVERNAME] plesk-sendmail[18470]: S18455: py-limit-out: stderr: PASS
Feb 24 23:01:04 [MYSERVERNAME] plesk-sendmail[18470]: S18455: check-quota: stderr: SKIP
Feb 24 23:01:04 [MYSERVERNAME] postfix/pickup[3247]: 892BC30972C55: uid=30 from=<SRS0=YRSt=6U=ldgqobsidianglow.autos=kohls_poll_reward-[NAME-CHANGED].[SURNAME-CHANGED]=[DOMAIN-CHANGED]@[DOMAIN-CHANGED]>
Feb 24 23:01:04 [MYSERVERNAME] postfix/cleanup[18279]: 892BC30972C55: message-id=<[email protected]>
Feb 24 23:01:04 [MYSERVERNAME] postfix/qmgr[30184]: 892BC30972C55: from=<SRS0=YRSt=6U=ldgqobsidianglow.autos=kohls_poll_reward-[NAME-CHANGED].[SURNAME-CHANGED]=[DOMAIN-CHANGED]@[DOMAIN-CHANGED]>, size=6709, nrcpt=1 (queue active)
Feb 24 23:01:04 [MYSERVERNAME] postfix/pipe[18291]: 5A88C3092FD82: to=<[NAME-CHANGED].[SURNAME-CHANGED]@[DOMAIN-CHANGED]>, relay=plesk_virtual, delay=4.2, delays=3.5/0/0/0.71, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
Feb 24 23:01:04 [MYSERVERNAME] postfix/qmgr[30184]: 5A88C3092FD82: removed

[NAME-CHANGED], [SURNAME-CHANGED] and [DOMAIN-CHANGED] are the hidden data of an existing mailbox on my server.
[MYSERVERNAME] and [MYSERVERIP] are the hidden data of my Plesk server.

Can it be related to an auto-forward to a Gmail external address?

 

[Peter Debik]

Feb 24 23:01:00 [MYSERVERNAME] postfix/smtpd[18384]: 5A88C3092FD82: client=unknown[193.24.210.61]
--> Source IP is 193.24.210.61

 

[trialotto]

This is what i've found on the maillog for the last of those mail in the queue



[NAME-CHANGED], [SURNAME-CHANGED] and [DOMAIN-CHANGED] are the hidden data of an existing mailbox on my server.
[MYSERVERNAME] and [MYSERVERIP] are the hidden data of my Plesk server.

Can it be related to an auto-forward to a Gmail external address?

@D4NY

It is always a good idea to setup a Fail2Ban jail for these types of "unknown[IP address]" connections - prevent them from occurring anyway.

However, that will not solve your issue completely, it will only reduce (not completely remove) a specific (sub-)set of malicious attempts.

It will help you to make a very useful distinction between "rubbish" in the maillogs and the relevant entries that can give you a clue about the origin of spam.

Please note that any mail server can misused for spamming, since the nature of the design of mail servers is "open" : each mail server sends and listens.

In order to combat spam, one has to take action

1 - on the mail server level : setup specific configuration, (and)

2 - before the mail server level : setup spam filters, use an external spam filter, use DNSBL or even setup a spam cluster (rspamd cluster, for instance) etc.

Nevertheless, one can never combat spam completely and one has to prioritize before configuring a heavy mail server setup.

In short, first try to setup a Fail2Ban jail.

It is not that difficult to create your own jail and apply a custom filter.

In order to make life more easy, a very simply (but sufficient) filter will be given here :

[Definition]
_daemon = postfix\/smtpd
failregex = ^%(__prefix_line)s.*unknown\[<HOST>\].*$
ignoreregex =

[INCLUDES]
before = common.conf

You can add that filter to a file called postfix-[random].local (with emphasis on the .local extension!) in /etc/fail2ban/filter.d directory.

After having created the filter and defined the jail, reload fail2ban with the command : service fail2ban reload

After reloading Fail2Ban, just wait 24 hours and have a look at the banned IPs - please note that "good" IPs can also be banned, if the mail server with that good IP is not properly configured (and that should not really bother you, since a badly configured mail server often is or will become the origin of spam).

I hope the above helps a bit!

Kind regards...

 

[trialotto]

This is what i've found on the maillog for the last of those mail in the queue



[NAME-CHANGED], [SURNAME-CHANGED] and [DOMAIN-CHANGED] are the hidden data of an existing mailbox on my server.
[MYSERVERNAME] and [MYSERVERIP] are the hidden data of my Plesk server.

Can it be related to an auto-forward to a Gmail external address?

@D4NY

With respect to your question

Can it be related to an auto-forward to a Gmail external address?

the answer is : no, not at all.

You simply have a party sending or attempting to send spam or attempting hack into your mail system.

Just ban a set of IP addresses and also add the string *@*.autos to your mail server black list ..........

Kind regards....

 

[D4NY]

Feb 24 23:01:00 [MYSERVERNAME] postfix/smtpd[18384]: 5A88C3092FD82: client=unknown[193.24.210.61]
--> Source IP is 193.24.210.61

Yes, almost all of the mail in the queue are from 193.24.210.*
Should i ban that class from the server?

 

[D4NY]

@D4NY

It is always a good idea to setup a Fail2Ban jail for these types of "unknown[IP address]" connections - prevent them from occurring anyway.

However, that will not solve your issue completely, it will only reduce (not completely remove) a specific (sub-)set of malicious attempts.

It will help you to make a very useful distinction between "rubbish" in the maillogs and the relevant entries that can give you a clue about the origin of spam.

Please note that any mail server can misused for spamming, since the nature of the design of mail servers is "open" : each mail server sends and listens.

In order to combat spam, one has to take action

1 - on the mail server level : setup specific configuration, (and)

2 - before the mail server level : setup spam filters, use an external spam filter, use DNSBL or even setup a spam cluster (rspamd cluster, for instance) etc.

Nevertheless, one can never combat spam completely and one has to prioritize before configuring a heavy mail server setup.

In short, first try to setup a Fail2Ban jail.

It is not that difficult to create your own jail and apply a custom filter.

In order to make life more easy, a very simply (but sufficient) filter will be given here :

[Definition]
_daemon = postfix\/smtpd
failregex = ^%(__prefix_line)s.*unknown\[<HOST>\].*$
ignoreregex =

[INCLUDES]
before = common.conf

You can add that filter to a file called postfix-[random].local (with emphasis on the .local extension!) in /etc/fail2ban/filter.d directory.

After having created the filter and defined the jail, reload fail2ban with the command : service fail2ban reload

After reloading Fail2Ban, just wait 24 hours and have a look at the banned IPs - please note that "good" IPs can also be banned, if the mail server with that good IP is not properly configured (and that should not really bother you, since a badly configured mail server often is or will become the origin of spam).

I hope the above helps a bit!

Kind regards...

Thank you very much for your detailed answer.
I'm not a Fail2ban expert at all to be honest, it will be not easy to setup it following your instructions.
In the ban list i've found (recidive) a list in which some of them were good ip and it's worrying from my point of view.

 

[D4NY]

@D4NY

With respect to your question



the answer is : no, not at all.

You simply have a party sending or attempting to send spam or attempting hack into your mail system.

Just ban a set of IP addresses and also add the string *@*.autos to your mail server black list ..........

Kind regards....

Maybe i'm tired and a little bit confused but... in the queue i've a lot of Undelivered Mail Returned to Sender that means that someone is authenticating in some way for sending, right? But in the logs i've no evidence of hacked mailbox sending spam. So maybe it's a script/plugin but how to find it?

Moreover the [NAME-CHANGED], [SURNAME-CHANGED] and [DOMAIN-CHANGED] is a real mailbox (password changed ovbiously) with an auto forward to an external Gmail mailbox. Disabled the autoforward but nothing changed.

Than what is [email protected]? The 54.36.113.226 is an Ovh ip, and my server is located on Ovh datacenter.

Feel confused to be honest.

 

[trialotto]

@D4NY,

Are you familiar with the Plesk firewall extension?

If so, then it would be recommended to start first by adding

54.36.113.226
193.24.210.61

to a firewall rule that blocks all traffic from these IPs to all ports.

Fail2Ban is a good method to detect offending IPs and block them during a specific period of time - a permanent ban with Fail2Ban is not a good idea.

A permanent ban of bad IPs can be best achieved by blocking the offending IPs by means of a firewall.

As a final remark, it should be noted that OVH is not the best choice to host any server - there are considerable issues with security and reliability.

Kind regards....

 

[D4NY]

Thank again for replying also on Sunday.
Yes, i'm more familiar with Plesk Firewall. I use it for banning some bad ips (all traffic all port) so i prefer use this solution.

Just one final question.... Should i disable ip exclusione (recidive ban) from here?



IP 54.36.113.226 is here (should be the whitelist... and i've not put it there). Why? Maybe it's not spammer?


I'll ban 193.24.210.0/8 using Plesk Firewall and we'll see if it works. Thanks again

 

[trialotto]

@D4NY

You should NOT disable "recidive ban" (I think that you mean to say "recidive jail").

What is not clear to me : what is the IP of your own server? Could that be - coincidentally - 54.36.113.226????

If yes, then do NOT block your own IP address, not on via the Plesk firewall and not via Fail2Ban!!!!

Kind regards.....

 

[D4NY]

@D4NY

You should NOT disable "recidive ban" (I think that you mean to say "recidive jail").

What is not clear to me : what is the IP of your own server? Could that be - coincidentally - 54.36.113.226????

If yes, then do NOT block your own IP address, not on via the Plesk firewall and not via Fail2Ban!!!!

Kind regards.....

No, obviously is not the IP of my server. But it's geo located at OVH and i found it in the IP list (whitelist?) in Fail2ban.

Anyway i'm banning 193.24.210.0/24 via Plesk Firewall right now (incoming / all TCP and UDP / all ports)

 

[D4NY]

Damn!

Feb 26 15:16:34 myserver postfix/cleanup[29693]: 9163F30121494: message-id=<20230226141634.9163F30121494@flamboyant-goldwasser.54-36-113-226.plesk.page>
Feb 26 15:16:34 myserver postfix/bounce[29719]: 3C1BB30121366: sender non-delivery notification: 9163F30121494
Feb 26 15:16:34 myserver postfix/qmgr[30184]: 9163F30121494: from=<>, size=32895, nrcpt=1 (queue active)
Feb 26 15:18:34 myserver postfix/smtp[29717]: 9163F30121494: to=<msprvs1=19421pSlMoBeu=[email protected]>, relay=none, delay=120, delays=0/0/120/0, dsn=4.4.1, status=deferred (connect to eu.tryquote.net[2a06:98c1:3121::d]:25: Connection timed out)

 

[trialotto]

No, obviously is not the IP of my server. But it's geo located at OVH and i found it in the IP list (whitelist?) in Fail2ban.

Anyway i'm banning 193.24.210.0/24 via Plesk Firewall right now (incoming / all TCP and UDP / all ports)

@D4NY

Just block 54.36.113.226 with the firewall on all ports.

Kind regards......

 

[D4NY]

[UPDATE]

193.24.210.0/24 banned on plesk firewall
54.36.113.226 banned on plesk firewall (confirmed from OVH that one of their ip and listed on https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a54.36.113.226&run=toolpage)

Today when i checked the queue i've found other few mails there, disappointed.

I know, it's strange but i'm considering the possibility again that it's a problem related to the auto-forward or sending to Gmail.com. Some mailbox of different domains on our server received a mail delivery error like this trying to send to some @gmail.com addresses:

Received: by flamboyant-goldwasser.54-36-113-226.plesk.page (Postfix)
id 974CE3016E6DB; Mon, 27 Feb 2023 13:30:44 +0100 (CET)
Date: Mon, 27 Feb 2023 13:30:44 +0100 (CET)
From: [email protected] (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender

How is it possible that is not MYSERVERNAME.MYDOMAIN to answer with that delivery error?

 

[D4NY]

This is what is read in the queue:

Received: by flamboyant-goldwasser.54-36-113-226.plesk.page (Postfix)
id A3728301210C5; Mon, 27 Feb 2023 19:01:26 +0100 (CET)
Date: Mon, 27 Feb 2023 19:01:26 +0100 (CET)
From: [email protected] (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: msprvs1=19422U5TC8FL4=[email protected]
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="1FEE630106A47.1677520886/flamboyant-goldwasser.54-36-113-226.plesk.page"
Message-Id: <20230227180126.A3728301210C5@flamboyant-goldwasser.54-36-113-226.plesk.page>

And this is what really happens in the maillog:

Feb 27 19:01:23 MYSERVERNAME postfix/smtpd[27232]: connect from mta-70-17-6.sparkpostmail.com[156.70.17.6]
Feb 27 19:01:24 MYSERVERNAME postfix/smtpd[27232]: 1F879301210C5: client=mta-70-17-6.sparkpostmail.com[156.70.17.6]
Feb 27 19:01:24 MYSERVERNAME psa-pc-remote[24313]: 1F879301210C5: from=<msprvs1=19422u5tc8fl4=[email protected]> to=<[email protected]>
Feb 27 19:01:24 MYSERVERNAME postfix/cleanup[11407]: 1F879301210C5: message-id=<[email protected]>
Feb 27 19:01:24 MYSERVERNAME psa-pc-remote[24313]: 1F879301210C5: py-limit-out: stderr: INFO:__main__:No SMTP AUTH and not running in sendmail context (incoming or unrestricted outgoing mail). SKIP message.
Feb 27 19:01:24 MYSERVERNAME psa-pc-remote[24313]: 1F879301210C5: py-limit-out: stderr: SKIP
Feb 27 19:01:24 MYSERVERNAME psa-pc-remote[24313]: 1F879301210C5: spf: stderr: PASS
Feb 27 19:01:24 MYSERVERNAME psa-pc-remote[24313]: 1F879301210C5: check-quota: stderr: SKIP
Feb 27 19:01:24 MYSERVERNAME postfix/qmgr[30184]: 1F879301210C5: from=<msprvs1=19422U5TC8FL4=[email protected]>, size=48541, nrcpt=1 (queue active)
Feb 27 19:01:24 MYSERVERNAME postfix-local[11417]: 1F879301210C5: from=<msprvs1=19422U5TC8FL4=[email protected]>, to=<[email protected]>, dirname=/var/qmail/mailnames
Feb 27 19:01:24 MYSERVERNAME plesk-sendmail[11420]: S11420: from=<msprvs1=19422U5TC8FL4=[email protected]> to=<[email protected]>
Feb 27 19:01:24 MYSERVERNAME plesk-sendmail[11421]: S11420: add-from: stderr: SKIP
Feb 27 19:01:25 MYSERVERNAME plesk-sendmail[11421]: S11420: py-limit-out: stderr: INFO:__main__:Setting 'X-PPP-Vhost' header to 'localhost.localdomain'
Feb 27 19:01:25 MYSERVERNAME plesk-sendmail[11421]: S11420: py-limit-out: stderr: PASS
Feb 27 19:01:25 MYSERVERNAME plesk-sendmail[11421]: S11420: check-quota: stderr: SKIP
Feb 27 19:01:25 MYSERVERNAME postfix/pickup[2845]: 1FEE630106A47: uid=30 from=<msprvs1=19422U5TC8FL4=[email protected]>
Feb 27 19:01:25 MYSERVERNAME postfix/cleanup[11407]: 1FEE630106A47: message-id=<[email protected]>
Feb 27 19:01:25 MYSERVERNAME dovecot: service=lda, user=[email protected], ip=[]. sieve: msgid=<[email protected]>: redirect action: forwarded to <[email protected]>
Feb 27 19:01:25 MYSERVERNAME postfix/qmgr[30184]: 1FEE630106A47: from=<msprvs1=19422U5TC8FL4=[email protected]>, size=49431, nrcpt=1 (queue active)
Feb 27 19:01:25 MYSERVERNAME dovecot: service=lda, user=[email protected], ip=[]. sieve: msgid=<[email protected]>: stored mail into mailbox 'INBOX'
Feb 27 19:01:25 MYSERVERNAME postfix/pipe[11416]: 1F879301210C5: to=<[email protected]>, orig_to=<[email protected]>, relay=plesk_virtual, delay=1.1, delays=0.75/0.01/0/0.37, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
Feb 27 19:01:25 MYSERVERNAME postfix/qmgr[30184]: 1F879301210C5: removed
Feb 27 19:01:26 MYSERVERNAME postfix/smtp[11431]: 1FEE630106A47: to=<[email protected]>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1b]:25, delay=1.5, delays=0/0.01/1.1/0.38, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[2a00:1450:400c:c06::1b] said: 550-5.7.1 [2001:41d0:602:2cac:: 19] Our system has detected that this 550-5.7.1 message is likely suspicious due to the very low reputation of the 550-5.7.1 sending domain. To best protect our users from spam, the message has 550-5.7.1 been blocked. Please visit 550 5.7.1 Why has Gmail blocked my messages? - Gmail Help for more information. i10-20020a05600c354a00b003e21ddf7222si8820487wmq.77 - gsmtp (in reply to end of DATA command))
Feb 27 19:01:26 MYSERVERNAME postfix/cleanup[11407]: A3728301210C5: message-id=<20230227180126.A3728301210C5@flamboyant-goldwasser.54-36-113-226.plesk.page>
Feb 27 19:01:26 MYSERVERNAME postfix/bounce[11433]: 1FEE630106A47: sender non-delivery notification: A3728301210C5
Feb 27 19:01:26 MYSERVERNAME postfix/qmgr[30184]: A3728301210C5: from=<>, size=52623, nrcpt=1 (queue active)
Feb 27 19:01:26 MYSERVERNAME postfix/qmgr[30184]: 1FEE630106A47: removed
Feb 27 19:01:29 MYSERVERNAME postfix/smtpd[27232]: disconnect from mta-70-17-6.sparkpostmail.com[156.70.17.6] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7

 

[trialotto]

@D4NY

Apparently, the following applies (in chronological order) :

1 - you have a (second) "bad" domain, using SparkPost (a mail service) to send multiple mails to one or more mail addresses on your server,

2 - each and every mail is forwarded to a backup mail address on Gmail, with the X-PPP-Vhost header being changed to the local domain on the server,

3 - the mails are ending up in your inbox,

4 - the forwarded mails (read: the backup emails sent to Gmail) are ending up in the mail queue,

5 - Gmail blocks the mails, because it is considered to be spam originating from your server,

and hence the challenge here is that

6 - you have a spammer, using

6.1 - a domain with the name plesk.page, not having DNS associated with any IP,
6.2 - a subdomain with the name 54-36-113-226.plesk.page, having DNS associated with the IP 54-36-113-226,
6.3 - a sub-subdomain with the name flamboyant-goldwasser.54-36-113-226.plesk.page, having DNS associated with the IP 54-36-113-226,
6.4 - another domain with the name tryoffer.net, hidden behind SparkPost and Cloudflare,

all in order to send spam messages via your and many other servers - what a waste of time and life to be so elaborate about facilitating spam!

7 - you cannot really do anything about it terms of spam combatting solutions like SPF or DMARC,

8 - you cannot really block SparkPost or Cloudflare, since that would also imply blocking genuine mail traffic (read: mails that are not spam),

9 - you will have to make sure that your mail server does NOT ACCEPT spam mails or connections associated with spam!


Simply stated, your mail server is used as some kind of relay.

In essence, you should be "ahead of the trouble", as opposed to combatting outgoing spam.


There are three simple solutions that are considered to be "good practice" (read: always configure/implement them) :

A - just add the string *@*.tryoffer,net to the spam filter blacklist - repeat this for any offending domain,

B - go to Tools & Settings > Mail Server Settings > Add "sbl.spamhaus.org" to the field DNS Zones for DNSBL Service and activate DNSBL protection,

C - go to Tolls & Settings > Mail Server Settings and configure (read: limit) outgoing mail


As a final remark, it is highly recommended to use a (small) dedicated server (as opposed to a VPS) and - more important - not host at OVH at all.

The latter recommendation seems to be strange, but OVH is notorious when it comes to security ...... and many spammers make use of the loopholes.

This simply means that - when hosting at OVH - the IP of your server (probably or factually) is part of an IP range or even an entire CIDR net block that has been banned in the past or still is banned on many DNSBL lists - this is not desirable, since you will have a bad reputation even if you own the server (and IP) for 1 minute and never have sent any spam at all .......


I hope the above helps a bit!

Kind regards....

 

[D4NY]

Well, first of all many thanks for your detailed answer. It's always a pleasure to find kind and competent people trying to help other users.

All point from 1 to 9 are extremely well detailed and now it's all more clear to me. But having never faced an issue like this it's a bit difficult to understand HOW all this is possibile. Especially point 1. i have a "bad" domain you mean that one of the hosted domains could be hacked and used for that? 6. Still unclear to me to how it works, but i know it's my knowhow limit. Anyway the IP 54-36-113-226 has been banned via Plesk Firewall.

I'm trying to find (and to deactivate) the auto forwarder to a Gmail account that are having problems. After this almos all bad traffic has been eliminated. From time to time a mail in the queue but it's normal like in the past months.

Regarding A, B, C solutions.... A) ok, done... let's see B) was already set up like this: "cbl.abuseat.org;sbl.spamhaus.org;xbl.spamhaus.org" C) limits were already set up, but never reached....has told there is not a so long queue (i mean not thousands) but it was from 10 to 100 mails stuck there (limit was higher).

Regarding OVH.... i know maybe is not the best choice overall but it's not possible at the moment to change everything in a short time. Anyway my server is a phisical dedicated server and not a vps.

 

[trialotto]

@D4NY

I will try to respond to your statements one by one.

In response to

it's a bit difficult to understand HOW all this is possibile. Especially point 1. i have a "bad" domain you mean that one of the hosted domains could be hacked and used for that?

it has to be admitted that it IS difficult to understand.

When taking a "pure" approach, one could safely conclude that issue with mail are often related to the way mail servers are set up to communicate .... and there is no reasonable of even feasible way to change that : the system works as intended, but that has drawbacks that we should accept.

I can give you proof for the "we should accept" part by stating that the mail server as a communication concept did not really change over time - it is robust !

Whe taking a different approach, one can safely conclude that most of the issues with mail and mail servers are related to configuration issues.

For instance, your mail accounts or mail server does not have to be hacked ...... it is always possible to send mails, as if they (seem to) come from your server.

That and other tricks can be combatted with proper configuration and things like SPF or DMARC.

So, with any mail server, we suddenly have another level of configuration to do, the level of SPF and DMARC ......


In response to

I'm trying to find (and to deactivate) the auto forwarder to a Gmail account that are having problems. After this almos all bad traffic has been eliminated. From time to time a mail in the queue but it's normal like in the past months.

can could argue that the traffic is eliminated.

In essence, your queue is not filling up as a result of mails that cannot be delivered to Gmail (recall: Gmail blocked them).

So, you could also have cleaned the queue and get the same result.

In essence, your gmail forward is from your server to gmail's servers (and that has been cleaned up by now).

However, the mail from the spammer is from another server to your server ...... and that should be absent too, by taking appropriate action (read: banning IPs temporarily via Fail2Ban, using DNSBL lists, blocking specific IPs via the firewall etc.)

You could try to reinstate your backup gmail address ...... it is often quite handy, if you have a lot of mail accounts to deal with and you still want one centralized mail account that makes your life easy and functions as a backup mailbox at the same time.

And if you are still blocked by Gmail, then just try to get your IP removed from the lists - this is another tutorial


In response to

B) was already set up like this: "cbl.abuseat.org;sbl.spamhaus.org;xbl.spamhaus.org"

I cannot really argue, but I do have to warn you about abuseat.org (recommendation : do not include that) and I can state that the combination of both sbl.spamhaus.org and xbl.spamhaus.org is a bit redundant - I concluded that (only) using sbl.spamhaus.org is the most efficient (at least for me).


In response to

Regarding OVH.... i know maybe is not the best choice overall but it's not possible at the moment to change everything in a short time. Anyway my server is a phisical dedicated server and not a vps.

I can only warn you and give some recommendations.

In the past, OVH had many infrastructure related issues that were not acknowledged and not patched for years - amongst others, their internal network was wide open to anybody that was handy with a server and some simple programming ....... and it took a couple of years before some action was taken by OVH.

As a result, many OVH based servers were compromised and the majority of European based spam (and hacks) were routed through OVH.

I am not fully aware of their current situation, but you can imagine that most IPs associated with OVH are considered to be bad - in the past or even now.

I cannot share much details, but if I could, then there would be a lot of funny anecdotes

Nevertheless, as a sysadmin, it is your responsibility to do some checks before renting a server somewhere.

In essence, as a sysadmin you should avoid hosting providers that are offering machines with bad hardware (read: cheap is certainly not better) or that are associated with bad IPs or bad CIDR networks (read: ranges of IP addresses).

And never hesitate to make a switch from one to another hosting provider : it will save you time and bad reputation (and also note that bad reputation is not only confined to an IP, but also to domains ..... so if you migrate with a domain from a bad IP to a good IP, there still is the chance that the domain is blocked, as a result of that bad reputation).

Plesk makes your life quite simple, when trying to migrate ....... of all tools provided by Plesk, the migration manager is wonderful!

Oh, by the way, try to prevent any Italian hosting provider ...... but that is another story....


Kind regards.....

 

[mow]

Part of this looks like double-bounce spam:

• The spammer sends a mail to an intentionally malformed address
• The receiving server does not reject the mail outright like it should, but only figures out it is bad / should be discarded after the message was already accepted, therefore that server can only create a bounce as it is not allowed to discard it after accepting
• For the return address the bounce is sent to, the server can only use information the delivering server provided, all of which (envelope-from/return-path, from, sender) will be fake and made up such that the bounce will be sent to the spammer's intended repicient
• The server sends the bounce to that recipient.
• The server where that recipient is hosted accepts the mail because it looks like a legit bounce
• Specifically plesk allows such bounces even from servers it would not normally accept mail from

To prevent these, the mail server would need to run all spam checks before accepting a mail, and reject if it doesn't pass. Plesk currently does not do that, it only rejects for greylisting (which helps a bit, but is becoming less and less effective, and does not help in this case.)