Deferred: 403 4.7.0 encryption too weak 0 less than 128
Problem reported by terry fairbrother - 3/5/2026 at 2:55 AM
Resolved
I have a bank that is trying to email a user but the bank is getting a bounced email...

    **********************************************
    **      THIS IS A WARNING MESSAGE ONLY      **
    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
    **********************************************
 
The original message was received at Mon, 2 Mar 2026 09:13:30 GMT
from m0357617.ppops.net [127.0.0.1]
 
   ----- Transcript of session follows -----
403 4.7.0 encryption too weak 0 less than 128
<some.user@ourdomain.com>... Deferred: 403 4.7.0 encryption too weak 0 less than 128
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old


Having googled it, it comes back as weak TLS, however I don't believe a bank would still be running TLS 1.0. I can see in the SMTP logs that they are being accepted, but I can't figure out what the issue is. Cert is up to date. I have enabled 465 & 587 too as I only wanted 25 / 443 enabled

Any ideas? I have suggested the sender sends the bounce to the banks support team. I suspect it's their end rather than SM

Thanks
Terry
J. LaDow Replied
Is the message outbound or inbound to your server?

Inbound all connection data will be in the SMTP log - outbound data will be in Delivery log -- if there's TLS issues, the delivery log should describe them -- that's how we're dealing with the 602's (which still need a better description, ST) -- 

SMTP log should show communication issues if they're trying to send to you.

Have you run a basic SSL test against the domain they are trying to send into: https://ssl-tools.net/mailservers


MailEnable survivor / convert --
terry fairbrother Replied
It was a bank trying to email in. the SMTP logs said it acknowledged the incoming email, but I suspect when it got to the spool it was then bounced


[2026.03.05] 17:32:39.294 [143.55.149.227][65153117] Connection initiated
[2026.03.05] 17:32:39.294 [143.55.149.227][65153117] rsp: 220 mail.ourdomain.com
[2026.03.05] 17:32:39.294 [143.55.149.227][65153117] connected at 05/03/2026 17:32:39
[2026.03.05] 17:32:39.294 [143.55.149.227][65153117] Country code: US
[2026.03.05] 17:32:39.307 [143.55.149.227][65153117] cmd: EHLO mx08-00146204.pphosted.com
[2026.03.05] 17:32:39.307 [143.55.149.227][65153117] rsp: 250-mail.ourdomain Hello [123.123.1.2]250-SIZE 139810133250-AUTH PLAIN LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK
[2026.03.05] 17:32:39.321 [143.55.149.227][65153117] cmd: MAIL From:<sender email> SIZE=89410
[2026.03.05] 17:32:39.321 [143.55.149.227][65153117] senderEmail(1): sender email
[2026.03.05] 17:32:39.321 [143.55.149.227][65153117] rsp: 250 OK <sender email> Sender ok
[2026.03.05] 17:32:39.321 [143.55.149.227][65153117] Sender accepted. Weight: 0. 
[2026.03.05] 17:32:39.336 [143.55.149.227][65153117] cmd: RSET
[2026.03.05] 17:32:39.336 [143.55.149.227][65153117] rsp: 250 OK
[2026.03.05] 17:33:40.110 [143.55.149.227][65153117] cmd: QUIT
[2026.03.05] 17:33:40.110 [143.55.149.227][65153117] rsp: 221 OK
[2026.03.05] 17:33:40.110 [143.55.149.227][65153117] disconnected at 05/03/2026 17:33:40
J. LaDow Replied
Nope - there's no DATA command in there - so they never tried to send the email once they connected.

It also doesn't show them attempting to escalate the connection via STARTTLS command either -

According to your log entry, your server doesn't support STARTTLS --

Our "capability" response:

rsp: 250-[REDACTED] Hello [146.143.72.26]250-SIZE 69905066250-AUTH PLAIN LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250-SMTPUTF8250-DSN250 OK
Yours:

rsp: 250-mail.ourdomain Hello [123.123.1.2]250-SIZE 139810133250-AUTH PLAIN LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK

They don't like what your server offered. I would try to test your server using the incoming domain or IP and see what ciphers that site shows you have enabled.


As an update - here is a log entry from a JPM-Chase email to our server earlier today. You'll note early on they try to escalate via STARTTLS, then after "sender ok" and "recipient ok" there is a DATA command.  According to your log, they never even tried to sent a "RCPT" command either. Instead, in your log, it shows they tried to RSET (reset) then and then disconnected cleanly.

08:36:17.198 [146.143.72.26][66455712] Connection initiated
08:36:17.198 [146.143.72.26][66455712] rsp: 220 [REDACTED] SMTP SVC [UCE SENDERS AND ABUSIVE PROVIDERS ARE BLOCKED] - ready
08:36:17.199 [146.143.72.26][66455712] connected at 3/5/2026 8:36:17 AM
08:36:17.199 [146.143.72.26][66455712] Country code: US
08:36:17.226 [146.143.72.26][66455712] cmd: EHLO vsin80p3237.jpmchase.com
08:36:17.226 [146.143.72.26][66455712] rsp: 250-[REDACTED] Hello [146.143.72.26]250-SIZE 69905066250-AUTH PLAIN LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250-SMTPUTF8250-DSN250 OK
08:36:17.264 [146.143.72.26][66455712] cmd: STARTTLS
08:36:17.264 [146.143.72.26][66455712] rsp: 220 Start TLS negotiation
08:36:17.354 [146.143.72.26][66455712] cmd: EHLO vsin80p3237.jpmchase.com
08:36:17.354 [146.143.72.26][66455712] rsp: 250-[REDACTED] Hello [146.143.72.26]250-SIZE 69905066250-AUTH PLAIN LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK
08:36:17.381 [146.143.72.26][66455712] cmd: MAIL From:<no.reply.alerts.01@chase.com> SIZE=34054
08:36:17.381 [146.143.72.26][66455712] senderEmail(1): no.reply.alerts.01@chase.com
08:36:17.730 [146.143.72.26][66455712] rsp: 250 OK <no.reply.alerts.01@chase.com> Sender ok
08:36:17.730 [146.143.72.26][66455712] Sender accepted. Weight: 0. Block threshold: 50. 
08:36:17.758 [146.143.72.26][66455712] cmd: RCPT To:<REDACTED>
08:36:17.758 [146.143.72.26][66455712] rsp: 250 OK <REDACTED> Recipient ok
08:36:17.785 [146.143.72.26][66455712] cmd: DATA
08:36:17.785 [146.143.72.26][66455712] Performing PTR host name lookup for 146.143.72.26
08:36:17.785 [146.143.72.26][66455712] PTR host name for 146.143.72.26 resolved as vsin80p3237.jpmchase.com
08:36:17.786 [146.143.72.26][66455712] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
08:36:17.813 [146.143.72.26][66455712] senderEmail(2): no.reply.alerts@chase.com parsed using FROM: Chase <no.reply.alerts@chase.com>
08:36:17.813 [146.143.72.26][66455712] Sender accepted. Weight: 0. Block threshold: 50. 
08:36:17.842 [146.143.72.26][66455712] DMARC Results: Passed (Domain: chase.com, Reason: SPF: True, DKIM: True, Alignments: 2, Domain: chase.com), Reason: SPF: True, DKIM: True, Alignments: 2, Domain: chase.com, Reject? False
08:36:17.842 [146.143.72.26][66455712] rsp: 250 OK
08:36:17.844 [146.143.72.26][66455712] Received message size: 34780 bytes
08:36:17.844 [146.143.72.26][66455712] Successfully wrote to the HDR file. (d:/pub/mail/Spool/SubSpool18/39461317.hdr)
08:36:17.844 [146.143.72.26][66455712] Data transfer succeeded, writing mail to 39461317.eml (MessageID: <113653965.18221620.1772717776000.JavaMail.webuser@iaasn00692073>)
08:36:17.870 [146.143.72.26][66455712] cmd: QUIT
08:36:17.870 [146.143.72.26][66455712] rsp: 221 OK
08:36:17.870 [146.143.72.26][66455712] disconnected at 3/5/2026 8:36:17 AM

MailEnable survivor / convert --
terry fairbrother Replied
Ahh, that's probably the cause (STARTTLS). I only had 25 and 443 open as I have it in my mind that 465 and 587 are for users sending and receiving emails from their own mailbox via a client rather than some external person sending a secured email (i'm not really a mail admin, prefer dead servers!!). However I did open those ports but the email was sent to an alternative email account so I don't know if it was fixed.

But I think you are correct and I appreciate your input. Thank you
Douglas Foster Replied
Not fixed.   Starttls runs on port 25, so no need to change ports.   You need a mentor to get you started and help you develop spam defenses.  If you are willing to pay for advice, Mailsbestfriend.com is one place to start.   If you want to do it on the cheap,  a junior college class might help.
J. LaDow Replied
Marked As Resolution
@terry:

STARTTLS will have to be enabled on port 25.  587 and 465 are for clients - 25 is for inbound/outbound traffic to other servers (basically).


Enabling STARTTLS on port 25, (with a valid certificate for the domain receiving mail that matches the DNS pointing to the server) should solve your problems.  Clients and servers that don't want TLS won't ask for it on STARTTLS ports. Only "SSL/TLS" ports will REQUIRE it from the connecting server or client.

(and as Doug Foster noted) - if you're not well-versed in email hosting, you will want to free up some time for log-watching - and be ready to dedicate some hours to monitoring what's actually going in and out of the server. Fighting the spam war (and malware-laden email war) is not as simple as "turning on virus protection" and calling it a good job.  Just a heads-up --
MailEnable survivor / convert --

Reply to Thread

Enter the verification text