[GH-ISSUE #130] More debug info for relay errors

kerem commented

2026-03-15 12:29:10 +03:00

Owner

Originally created by @luomoxu on GitHub (Jun 25, 2023).
Original GitHub issue: https://github.com/axllent/mailpit/issues/130

when I try to debug why smtp reply not work , only get the message like this

DEBU[2023/06/25 05:39:46] [release] removing Message-ID: <1388026813.36.1687671563531@jira-6c88ff495b-sg5tt>
 header
ERRO[2023/06/25 05:40:03] [smtp] error sending message: EOF            
WARN[2023/06/25 05:40:04] [smtp] error relaying message: EOF

Originally created by @luomoxu on GitHub (Jun 25, 2023). Original GitHub issue: https://github.com/axllent/mailpit/issues/130 when I try to debug why smtp reply not work , only get the message like this ``` DEBU[2023/06/25 05:39:46] [release] removing Message-ID: <1388026813.36.1687671563531@jira-6c88ff495b-sg5tt> header ERRO[2023/06/25 05:40:03] [smtp] error sending message: EOF WARN[2023/06/25 05:40:04] [smtp] error relaying message: EOF ```

kerem closed this issue

2026-03-15 12:29:15 +03:00

kerem commented

2026-03-15 12:29:21 +03:00

Author

Owner

@axllent commented on GitHub (Jun 25, 2023):

@luomoxu Can you please tell me a bit more about your setup? Is this via a manual message release via the web UI or are you using the API or auto-forwarding? What configuration are you using for your SMTP server (TLS, authentication etc)?

I do get your point about the debug information not being very descriptive (which is probably something I can help with), however I'm also trying to work out where in the process you're getting the error, and ultimately why.

@axllent commented on GitHub (Jun 25, 2023): @luomoxu Can you please tell me a bit more about your setup? Is this via a manual message release via the web UI or are you using the API or auto-forwarding? What configuration are you using for your SMTP server (TLS, authentication etc)? I do get your point about the debug information not being very descriptive (which is probably something I can help with), however I'm also trying to work out where in the process you're getting the error, and ultimately why.

kerem commented

2026-03-15 12:29:26 +03:00

Author

Owner

@luomoxu commented on GitHub (Jun 25, 2023):

I had try with
starttls: true/fasle
auth: plain/login
with webUI and auto-forwarding
all not work for me
this is the config of smtp replay

host: smtp.qiye.aliyun.com
port: 465
starttls: false
allow-insecure: true
auth: plain
username: username@example.com
password: password
return-path: username@example.com
recipient-allowlist: '@example\.com$'

@luomoxu commented on GitHub (Jun 25, 2023): I had try with starttls: true/fasle auth: plain/login with webUI and auto-forwarding all not work for me this is the config of smtp replay ``` host: smtp.qiye.aliyun.com port: 465 starttls: false allow-insecure: true auth: plain username: username@example.com password: password return-path: username@example.com recipient-allowlist: '@example\.com$' ```

kerem commented

2026-03-15 12:29:31 +03:00

Author

Owner

@axllent commented on GitHub (Jun 25, 2023):

The fact that you're using port 465 implies it needs starttls: true. Are you sure your SMTP details are correct (have you tried them elsewhere)? I'm not yet sure why this is happening, nor am I able to look into extending the debugging right now (next few days), but I will be looking into this in the next few days.

In the meantime, are you able to share any details about the SMTP server itself? Is this one you administer, and if so, any idea what software it is using? It doesn't identify itself when I connect via telnet, and it appears (based on your error log) to be just killing the connection.

@axllent commented on GitHub (Jun 25, 2023): The fact that you're using port 465 implies it needs `starttls: true`. Are you sure your SMTP details are correct (have you tried them elsewhere)? I'm not yet sure why this is happening, nor am I able to look into extending the debugging right now (next few days), but I will be looking into this in the next few days. In the meantime, are you able to share any details about the SMTP server itself? Is this one you administer, and if so, any idea what software it is using? It doesn't identify itself when I connect via telnet, and it _appears_ (based on your error log) to be just killing the connection.

kerem commented

2026-03-15 12:29:36 +03:00

Author

Owner

@luomoxu commented on GitHub (Jun 25, 2023):

I had try use starttls:true, not work
I use this config with https://hub.docker.com/r/juanluisbaptiste/postfix ,it work fine for me
This smtp server is a business mailbox,I don't know the specific info about it
some info about smtp config info https://help.aliyun.com/document_detail/36576.html
I config OVERWRITE_FROM to a default address with juanluisbaptiste/postfix, I don't know if this makes a difference

@luomoxu commented on GitHub (Jun 25, 2023): I had try use starttls:true, not work I use this config with https://hub.docker.com/r/juanluisbaptiste/postfix ,it work fine for me This smtp server is a business mailbox,I don't know the specific info about it some info about smtp config info https://help.aliyun.com/document_detail/36576.html I config `OVERWRITE_FROM` to a default address with juanluisbaptiste/postfix, I don't know if this makes a difference

kerem commented

2026-03-15 12:29:42 +03:00

Author

Owner

@axllent commented on GitHub (Jun 25, 2023):

Hmmm, I'm not sure I will be able to answer this. Sending should work with any SMTP server, but clearly not the Alibaba one. The error you got [smtp] error sending message: EOF appears like the SMTP server simply cuts the connection (doesn't answer / respond with the expected response). I am suspecting it may be a security-related policy on their end to block suspicious connections, or block emails being relayed via their server. Some SMTP servers do not allow you to send from anyone other than the account holder account.

Have you tried via the unencrypted port (110) with starttls: false?

@axllent commented on GitHub (Jun 25, 2023): Hmmm, I'm not sure I will be able to answer this. Sending should work with any SMTP server, but clearly not the Alibaba one. The error you got `[smtp] error sending message: EOF` appears like the SMTP server simply cuts the connection (doesn't answer / respond with the expected response). I am suspecting it may be a security-related policy on their end to block suspicious connections, or block emails being relayed via their server. Some SMTP servers do not allow you to send from anyone other than the account holder account. Have you tried via the unencrypted port (110) with `starttls: false`?

kerem commented

2026-03-15 12:29:47 +03:00

Author

Owner

@luomoxu commented on GitHub (Jun 25, 2023):

I had try use unencrypted port,not work

@luomoxu commented on GitHub (Jun 25, 2023): I had try use unencrypted port,not work

kerem commented

2026-03-15 12:29:52 +03:00

Author

Owner

@axllent commented on GitHub (Jun 25, 2023):

I think the SMTP server is blocking you from sending based on the email's "From" address. If, for instance, the From address host (eg: @example.com in your example) is either:

invalid, or
is valid, but is not authorised to send via Alibaba (eg: uses DMARC), or
Alibaba only allows you to send "From" your registered email address with aliyun.com

then the SMTP server probably blocks you. Their SMTP server does not identify itself, so I'm guessing it is likely that they have their own implementation, and it probably just closes the connection to your client (Mailpit). Mailservers like this get a lot of attempted spam connections, and hackers trying to guess passwords, so it would not surprise me if this is the case.

You would need to confirm that you can send that exact same email (that you are trying to relay via Mailpit) using another method (not via Mailpit). I suspect you can't. Sorry, I don't know how to help you if Alibaba won't allow the message through.

@axllent commented on GitHub (Jun 25, 2023): I _think_ the SMTP server is blocking you from sending based on the email's "From" address. If, for instance, the From address host (eg: `@example.com` in your example) is either: 1. invalid, or 2. is valid, but is not authorised to send via Alibaba (eg: uses DMARC), or 3. Alibaba only allows you to send "From" your registered email address with `aliyun.com` then the SMTP server probably blocks you. Their SMTP server does not identify itself, so I'm guessing it is likely that they have their own implementation, and it probably just closes the connection to your client (Mailpit). Mailservers like this get a lot of attempted spam connections, and hackers trying to guess passwords, so it would not surprise me if this is the case. You would need to confirm that you can send that exact same email (that you are trying to relay via Mailpit) using another method (not via Mailpit). I suspect you can't. Sorry, I don't know how to help you if Alibaba won't allow the message through.

kerem commented

2026-03-15 12:29:57 +03:00

Author

Owner

@luomoxu commented on GitHub (Jun 26, 2023):

I made a flowchart show I had try
I guess that some informationmay be missing during smtp verification or Alibaba had smtp client whitelist , But it's stupid,I am more prone to missing information

@luomoxu commented on GitHub (Jun 26, 2023): I made a flowchart show I had try I guess that some informationmay be missing during smtp verification or Alibaba had smtp client whitelist , But it's stupid,I am more prone to missing information ![绘图1](https://github.com/axllent/mailpit/assets/1317574/8035bd51-7d7a-40fe-bdb5-048627ce4a15)

kerem commented

2026-03-15 12:30:02 +03:00

Author

Owner

@axllent commented on GitHub (Jun 26, 2023):

That is helpful - clearly postfix is either modifying the email somewhat, there is something missing in Mailpit's SMTP authentication, or potentially postfix is "whitelisted" in Alibaba. I just do not know how to test this yet. Ideally what I was looking for is: Same mail -> something else (not Mailpit or Postfix) -> Alibaba SMTP

But I think I may know why this is happening. For Authentication, a mailserver is supposed to return its capabilities via a EHLO <host> command - but ALibab's just closes the connection instead.

For example, if I try on postfix:

EHLO my-mail-server
250-PIPELINING
250-SIZE 20240000
250-ETRN
250-STARTTLS
250-AUTH PLAIN
250-AUTH=PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING

But with Alibaba I get:

telnet smtp.qiye.aliyun.com 465
Trying 47.246.165.89...
Connected to smtp.qiye.aliyun.com.
Escape character is '^]'.
EHLO smtp.qiye.aliyun.com 
Connection closed by foreign host.

I believe this is where the issue lies - the SMTP client asks Alibaba what it supports, and Alibaba just closes the connection. I have just released v1.6.22 which includes better error messages, and I suspect yours will return the error authenticating. Can you please try the latest release and confirm that is where the error is coming from?

@axllent commented on GitHub (Jun 26, 2023): That is helpful - clearly postfix is either modifying the email somewhat, there is something missing in Mailpit's SMTP authentication, or potentially postfix is "whitelisted" in Alibaba. I just do not know how to test this yet. Ideally what I was looking for is: Same mail -> something else (not Mailpit or Postfix) -> Alibaba SMTP But I think I may know why this is happening. For Authentication, a mailserver is supposed to return its capabilities via a `EHLO <host>` command - but ALibab's just closes the connection instead. For example, if I try on postfix: ``` EHLO my-mail-server 250-PIPELINING 250-SIZE 20240000 250-ETRN 250-STARTTLS 250-AUTH PLAIN 250-AUTH=PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING ``` But with Alibaba I get: ``` telnet smtp.qiye.aliyun.com 465 Trying 47.246.165.89... Connected to smtp.qiye.aliyun.com. Escape character is '^]'. EHLO smtp.qiye.aliyun.com Connection closed by foreign host. ``` I believe this is where the issue lies - the SMTP client asks Alibaba what it supports, and Alibaba just closes the connection. I have just released v1.6.22 which includes better error messages, and I suspect yours will return the `error authenticating`. Can you please try the latest release and confirm that is where the error is coming from?

kerem commented

2026-03-15 12:30:07 +03:00

Author

Owner

@luomoxu commented on GitHub (Jun 26, 2023):

axllent/mailpit:v1.6.22

DEBU[2023/06/26 05:46:56] [release] removing Message-ID: <1653293015.1.1687758329959@jira-6c88ff495b-gvqgw>
 header 
ERRO[2023/06/26 05:47:15] [smtp] error sending message: error connecting to smtp.qiye.aliyun.com:465: EOF

maybe I can use a capture tool to find the difference between postfix and mailpit

@luomoxu commented on GitHub (Jun 26, 2023): axllent/mailpit:v1.6.22 ``` DEBU[2023/06/26 05:46:56] [release] removing Message-ID: <1653293015.1.1687758329959@jira-6c88ff495b-gvqgw> header ERRO[2023/06/26 05:47:15] [smtp] error sending message: error connecting to smtp.qiye.aliyun.com:465: EOF ``` maybe I can use a capture tool to find the difference between postfix and mailpit

kerem commented

2026-03-15 12:30:12 +03:00

Author

Owner

@axllent commented on GitHub (Jun 26, 2023):

Oh I see - Alibaba doesn't even respond properly when you connect to it. I just looked into the SMTP code and found this: https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/net/smtp/smtp.go;l=64-74 - it's specifically the text.ReadResponse(220) part which expects a 220 response which Alibaba's SMTP server does not give (it gives nothing).

The expected response is something like:

220 example.com ESMTP Postfix

So the short answer is: sorry, their custom implementation of SMTP won't work with Mailpit, or more specifically with the SMTP protocol that is standard within Go. There may be custom implementations of SMTP libraries out there that handle this, however the issue here isn't Mailpit, it's Alibaba's SMTP.

@axllent commented on GitHub (Jun 26, 2023): Oh I see - Alibaba doesn't even respond properly when you connect to it. I just looked into the SMTP code and found this: https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/net/smtp/smtp.go;l=64-74 - it's specifically the `text.ReadResponse(220)` part which [expects a 220 response](https://pkg.go.dev/net/textproto#Reader.ReadResponse) which Alibaba's SMTP server does not give (it gives nothing). The expected response is something like: ``` 220 example.com ESMTP Postfix ``` So the short answer is: sorry, their custom implementation of SMTP won't work with Mailpit, or more specifically with the SMTP protocol that is standard within Go. There may be custom implementations of SMTP libraries out there that handle this, however the issue here isn't Mailpit, it's Alibaba's SMTP.

kerem commented

2026-03-15 12:30:17 +03:00

Author

Owner

@luomoxu commented on GitHub (Jun 26, 2023):

thanks for your tip,I try to change smtp port to 587,it works fine now,Amazing
I think the 465 port has some weird configuration on Alibaba's SMTP
the work fine config for me

host: smtp.qiye.aliyun.com
port: 587
starttls: true
auth: plain

possibly useful reference
https://github.com/prometheus/alertmanager/issues/980

@luomoxu commented on GitHub (Jun 26, 2023): thanks for your tip,I try to change smtp port to 587,it works fine now,Amazing I think the 465 port has some weird configuration on Alibaba's SMTP the work fine config for me ``` host: smtp.qiye.aliyun.com port: 587 starttls: true auth: plain ``` possibly useful reference https://github.com/prometheus/alertmanager/issues/980

kerem commented

2026-03-15 12:30:22 +03:00

Author

Owner

@axllent commented on GitHub (Jun 26, 2023):

Thanks for the testing and feedback, and the confirmation. I'm glad you finally got it working on a different port!

@axllent commented on GitHub (Jun 26, 2023): Thanks for the testing and feedback, and the confirmation. I'm glad you finally got it working on a different port!

kerem commented

2026-03-15 12:30:27 +03:00

Author

Owner

@arnt commented on GitHub (Aug 14, 2025):

JFYI, port 465 is a Microsoft extension. I've never seen proper documentation for it. The server expects a TLS hello packet from the client, and will send an SMTP banner only after negotiating TLS. It's basically Microsoft's alternative to the STARTTLS command.

@arnt commented on GitHub (Aug 14, 2025): JFYI, port 465 is a Microsoft extension. I've never seen proper documentation for it. The server expects a TLS hello packet from the client, and will send an SMTP banner only after negotiating TLS. It's basically Microsoft's alternative to the STARTTLS command.

Rows
Columns

[GH-ISSUE #130] More debug info for relay errors #90