SmarterMail Enterprise Builds 9168 - 9245 have been confirmed to continue having the same issue with incorrectly caching a a Permanent Negative Completion Reply of "550 No such user here" in the \SmarterMail\Service\Settings\SmartHostCaches when a SMTP Block occurs, resulting in all inbound email to the recipient being rejected for delivery for several minutes.
An example: a Spam Server that is blocked by IP Address or HELO/EHLO in SECURITY > BLACKLIST attempts a connection. As they are listed in the Blacklist they are given the catchall Permanent Negative Completion Reply of "550 No such user here". Then, a few seconds later a legitimate Mail Server that is not listed in the Blacklist attempts delivery to the same recipient and it is incorrectly rejected with the Permanent Negative Completion Reply of "550 No such user here".
Clearly, the blocked connection due to Blacklisting is resulting in the recipient being added erroneously to the \SmarterMail\Service\Settings\SmartHostCaches ultimately resulting in the bouncing of any and all attempted deliveries to that address for a period of time.
If that is too abstract to understand, here are the detailed SMTP Logs of an example:
[2025.05.06] 07:54:12.204 [62.60.208.107][52961553] rsp: 220 mta01.scarabmedia.com Tue, 06 May 2025 14:54:12 +0000 UTC
[2025.05.06] 07:54:12.204 [62.60.208.107][52961553] connected at 5/6/2025 7:54:12 AM
[2025.05.06] 07:54:12.204 [62.60.208.107][52961553] Country code: IR
[2025.05.06] 07:54:12.415 [62.60.208.107][52961553] cmd: EHLO [62.60.208.107]
[2025.05.06] 07:54:12.418 [62.60.208.107][52961553] rsp: 250-mta01.scarabmedia.com Hello [62.60.208.107]250-SIZE 69905066250-AUTH250-STARTTLS250-8BITMIME250-SMTPUTF8250-DSN250 OK
[2025.05.06] 07:54:12.624 [62.60.208.107][52961553] cmd: MAIL FROM:<no-reply@bestpromos.click>
[2025.05.06] 07:54:12.627 [62.60.208.107][52961553] senderEmail(1): no-reply@bestpromos.click
[2025.05.06] 07:54:12.629 [62.60.208.107][52961553] rsp: 250 OK <no-reply@bestpromos.click> Sender ok
[2025.05.06] 07:54:12.629 [62.60.208.107][52961553] Sender accepted. Weight: 0. Block threshold: 30.
[2025.05.06] 07:54:12.826 [62.60.208.107][52961553] cmd: RCPT TO:<csd@marinwood.org>
[2025.05.06] 07:54:12.950 [62.60.208.107][52961553] rsp: 550 <csd@marinwood.org> No such user here
[2025.05.06] 07:54:13.126 [62.60.208.107][52961553] cmd: QUIT
[2025.05.06] 07:54:13.126 [62.60.208.107][52961553] rsp: 221 Service closing transmission channel
[2025.05.06] 07:54:13.127 [62.60.208.107][52961553] disconnected at 5/6/2025 7:54:13 AM
This is working as intended as the IP Address 62.60.208.107 is listed on our Blacklist.
But then, 90 seconds later Sparkpostmail, which is not listed on our Blacklist (they are Whitelisted) gets the same response because the previous Permanent Negative Completion Reply of "550 No such user here" resulted in an erroneous SMTP User Verification entry for the RCPT TO in the \SmarterMail\Service\Settings\SmartHostCaches\
[2025.05.06] 07:56:26.836 [168.203.36.157][29712642] rsp: 220 mta01.scarabmedia.com Tue, 06 May 2025 14:56:26 +0000 UTC
[2025.05.06] 07:56:26.836 [168.203.36.157][29712642] connected at 5/6/2025 7:56:26 AM
[2025.05.06] 07:56:26.836 [168.203.36.157][29712642] Country code: US
[2025.05.06] 07:56:26.858 [168.203.36.157][29712642] cmd: EHLO mta-203-36-157.sparkpostmail.com
[2025.05.06] 07:56:26.861 [168.203.36.157][29712642] rsp: 250-mta01.scarabmedia.com Hello [168.203.36.157]250-SIZE 69905066250-AUTH250-STARTTLS250-8BITMIME250-SMTPUTF8250-DSN250 OK
[2025.05.06] 07:56:26.881 [168.203.36.157][29712642] cmd: STARTTLS
[2025.05.06] 07:56:26.881 [168.203.36.157][29712642] rsp: 220 Start TLS negotiation
[2025.05.06] 07:56:26.960 [168.203.36.157][29712642] cmd: EHLO mta-203-36-157.sparkpostmail.com
[2025.05.06] 07:56:26.963 [168.203.36.157][29712642] rsp: 250-mta01.scarabmedia.com Hello [168.203.36.157]250-SIZE 69905066250-AUTH LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK
[2025.05.06] 07:56:26.992 [168.203.36.157][29712642] cmd: MAIL FROM:<msprvs1=202210c7ngBZN=bounces-240922-50@bounces.email.active.com>
[2025.05.06] 07:56:26.995 [168.203.36.157][29712642] senderEmail(1): msprvs1=202210c7ngBZN=bounces-240922-50@bounces.email.active.com
[2025.05.06] 07:56:26.996 [168.203.36.157][29712642] rsp: 250 OK <msprvs1=202210c7ngBZN=bounces-240922-50@bounces.email.active.com> Sender ok
[2025.05.06] 07:56:26.996 [168.203.36.157][29712642] Sender accepted. Weight: 0. Block threshold: 30.
[2025.05.06] 07:56:27.016 [168.203.36.157][29712642] cmd: RCPT TO:<csd@marinwood.org>
[2025.05.06] 07:56:27.016 [168.203.36.157][29712642] rsp: 550 <csd@marinwood.org> No such user here
[2025.05.06] 07:56:32.035 [168.203.36.157][29712642] cmd: QUIT
[2025.05.06] 07:56:32.035 [168.203.36.157][29712642] rsp: 221 Service closing transmission channel
[2025.05.06] 07:56:32.036 [168.203.36.157][29712642] disconnected at 5/6/2025 7:56:32 AM
The smartHostCache*.xml has the following entry created by the first transaction:
<CachedSMTPUser>
<User>-1459548764</User>
<UserExists>False</UserExists>
</CachedSMTPUser>
Since Sparkpostmail has a One Bounce rule they stop delivering to that email address and the entire domain is entered on their Suppression List to prevent further potential abuse, resulting in hundreds of transactional emails to be never be attempted for delivery.
I assume that the only way to prevent this until it is fixed by SmarterTools Dev is to disable GATEWAYS/FAILOVER > OPTIONS > SMTP USER VERIFICATION and just deal with the tens of thousands of bounces daily?
Wouldn't it be nice if connections that are blocked due to Blacklists didn't result in the RCPT TO: being cached erroneously in the SMTP User Verification in \SmarterMail\Service\Settings\SmartHostCaches? It is absolutely broken and this issue has been reported at least twice here and a Ticket opened and closed over this issue (with the excuse of "we have no real way to test this").
Can this bug please be resolved before I lose any more customers due to unreliable rejection of their email for weeks and months at a time and having to daily contact their senders to request their email address or domain removed from the sender's Suppression Lists?