mirror of
https://github.com/langgenius/dify-official-plugins.git
synced 2026-07-21 17:45:23 -04:00
Langgenius-email in Dify returns success upon sending email but no email received using maildev #635
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nemofira09 on GitHub (Sep 9, 2025).
Self Checks
Dify version
1.7.2
Plugin version
0.0.7
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
What we've tried:
✔️ Error log
No error logs generated.
Checked:
No error logs found.
@dosubot[bot] commented on GitHub (Sep 9, 2025):
The Langgenius-email plugin gets its SMTP server address directly from your configuration—whatever you enter for
smtp_serveris used as-is. If your Maildev instance is running outside the plugin's Docker container, using127.0.0.1orlocalhostwill not work, since that refers to the plugin container itself, not the host or another container. Instead, use the Docker network hostname for Maildev (for example,maildevif both are on the same Docker network) as the SMTP server address. This is a common source of "success" responses with no email actually delivered when using Dockerized services. The plugin supports Docker DNS hostnames, so as long as the network is set up correctly, it should work as expected1 2 .Also, the plugin logs errors internally, but by default only at the INFO level. If you need more details, you may need to temporarily increase the log level to DEBUG in the plugin container or source code for troubleshooting1 .
Double-check that your SMTP settings (host, port, username, password, encryption method) match your Maildev setup, and confirm that the plugin container can reach Maildev's SMTP port (1025) using the configured hostname. If you still see "success" but no email, try running a connectivity test (like
telnet maildev 1025) from inside the plugin container.To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
Langgenius-email plugin source: SMTP config and error handling ↩︎
Plugin uses user-supplied SMTP host, supports Docker DNS ↩︎
@nemofira09 commented on GitHub (Sep 9, 2025):
@dosu
I am using the VM's IP Address since that is where the maildev server is hosted and they are not within the same docker network since maildev is installed directly on the VM not via docker. Within the VM I am able to access via telnet.
@dosubot[bot] commented on GitHub (Sep 9, 2025):
Since MailDev is running directly on the VM and not in Docker, using the VM's IP as the SMTP server is correct in principle—but Docker containers sometimes can't reach the host network as expected. Even if telnet works from the VM, it doesn't guarantee connectivity from inside the plugin container.
To confirm network access, try running telnet or nc from inside the plugin container to the VM's IP on port 1025. If that fails, the issue is likely Docker network isolation. If it works, double-check that your SMTP config in the plugin matches MailDev's setup (no auth, no TLS, etc.), and that MailDev is listening on 0.0.0.0, not just localhost.
If you still see "success" but no email, try using host.docker.internal as the SMTP host (if your Docker version supports it), or add an extra_hosts entry in your docker-compose to map a hostname to the VM's IP. The plugin will only report success if the SMTP transaction completes without errors—if MailDev accepts the message but doesn't show it, the issue is likely on the MailDev side or with how it's listening for connections, not with the plugin's error handling logic (source).
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@nemofira09 commented on GitHub (Sep 9, 2025):
I am able to curl ip_address:1025 of maildev inside docker-plugin_daemon-1.
setting maildev to 0.0.0.0 makes it inaccessible even inside the VM.
The configuration is accurate to the maildev config.
@dosu
@dosubot[bot] commented on GitHub (Sep 9, 2025):
Given your setup, the most likely cause is that the SSRF proxy in Dify's Docker deployment is blocking SMTP traffic to MailDev, even though curl works. Recent changes to Dify's SSRF proxy enforce a deny-all-by-default policy, allowing only HTTP/HTTPS ports unless you explicitly whitelist your VM's IP and port 1025 for SMTP in the proxy config. This means SMTP connections can silently fail after the TCP handshake, causing the plugin to report "success" even though MailDev never receives the email (details).
To fix this, update your SSRF proxy config (usually
squid.conf.templateor/etc/squid/conf.d/) to allow your VM's IP and port 1025, then restart thessrf_proxycontainer. You can also try usinghost.docker.internalas the SMTP server address if your Docker setup supports it, but this hostname must also be whitelisted in the SSRF proxy config (reference).If you want to confirm the issue, try sending a test email using Python's
smtplibfrom inside the plugin container with the same SMTP settings. If MailDev still doesn't receive it, it's almost certainly a proxy/network restriction.To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@nemofira09 commented on GitHub (Sep 9, 2025):
How do I edit the ssrf_proxy config to allow the VM IP as well as the 1025 port. What to input in squid.conf.template.
@dosu
@dosubot[bot] commented on GitHub (Sep 9, 2025):
To allow SMTP traffic to your VM's IP on port 1025 in Dify's SSRF proxy, edit your
docker/ssrf_proxy/squid.conf.templateand add or update the following line (usually near otheracl SSL_portsentries):This expands the allowed ports for CONNECT requests, which is needed for SMTP and other non-standard ports reference.
After editing, restart the
ssrf_proxycontainer (or runsquid -k reconfigureinside it) for changes to take effect reference.If you want to restrict access to only your VM's IP, you can also add an ACL for your VM IP, like:
Make sure these lines appear before any
http_access deny allrule. If you have custom rules or want to allow only port 1025, adjust accordingly.Let me know if you need a full example or run into any issues!
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@nemofira09 commented on GitHub (Sep 9, 2025):
The ports are all enabled by default upon checking, and adding:
acl allowed_vm dst <YOUR_VM_IP>
http_access allow allowed_vm
Did not work. Still can't send.
@dosu
@dosubot[bot] commented on GitHub (Sep 9, 2025):
The key step is to explicitly uncomment or add the line:
in your
squid.conf.template(it’s commented out by default), and make sure it appears before anyhttp_access deny CONNECT !SSL_portsrule. Just adding an IP ACL or allow rule is not enough—if port 1025 isn’t inSSL_ports, Squid will always block CONNECT requests to it, regardless of other rules reference.After editing, restart the
ssrf_proxycontainer so the changes take effect. You can verify the running config inside the container (/etc/squid/squid.conf) to confirm the line is active.If you still can’t send, check the Squid logs (
docker logs <ssrf_proxy_container>) for denied CONNECT requests to port 1025. If you see denies, the port isn’t enabled inSSL_ports. If not, confirm the plugin is routing SMTP traffic through the proxy and not bypassing it.Let me know if you want a full example or if you’re still stuck after these steps.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@nemofira09 commented on GitHub (Sep 9, 2025):
@dosu
I've uncommented acl SSL_ports port 1025-65535 and checked the ssrf_proxy-1 container and there are no denied logs, or any errors. How do I confirm if plugin is routing SMTP traffic through the proxy and not bypassing it.
@dosubot[bot] commented on GitHub (Sep 9, 2025):
The Langgenius-email plugin sends SMTP traffic directly to the configured SMTP server and does not route it through the SSRF proxy by default—there’s no proxy logic or environment variable support for SMTP in the plugin code or container config (source).
To confirm the actual network path, you can:
tcpdumportsharkinside the plugin_daemon container while sending a test email to see if traffic goes straight to your VM’s IP/port 1025.If you want to force SMTP through a proxy, you’d need to set up a SOCKS or HTTP CONNECT proxy and explicitly configure smtplib for it, which isn’t supported out of the box. By default, SMTP traffic from the plugin is direct (source).
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@nemofira09 commented on GitHub (Sep 10, 2025):
@dosu
I tried tcdump via:
sudo tcpdump -i any port 1025 -nn
and got the logs:
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
05:14:50.065766 veth1fdcd87 P IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [S], seq 2190638644, win 64240, options [mss 1460,sackOK,TS val 1650518111 ecr 0,nop,wscale 7], length 0
05:14:50.065777 br-51d34c30828f In IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [S], seq 2190638644, win 64240, options [mss 1460,sackOK,TS val 1650518111 ecr 0,nop,wscale 7], length 0
05:14:50.065910 br-51d34c30828f Out IP 192.168.200.240.1025 > 172.18.0.9.44192: Flags [S.], seq 639284647, ack 2190638645, win 65160, options [mss 1460,sackOK,TS val 2075721432 ecr 1650518111,nop,wscale 7], length 0
05:14:50.065921 veth1fdcd87 Out IP 192.168.200.240.1025 > 172.18.0.9.44192: Flags [S.], seq 639284647, ack 2190638645, win 65160, options [mss 1460,sackOK,TS val 2075721432 ecr 1650518111,nop,wscale 7], length 0
05:14:50.065994 veth1fdcd87 P IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [.], ack 1, win 502, options [nop,nop,TS val 1650518111 ecr 2075721432], length 0
05:14:50.065999 br-51d34c30828f In IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [.], ack 1, win 502, options [nop,nop,TS val 1650518111 ecr 2075721432], length 0
05:14:50.177747 br-51d34c30828f Out IP 192.168.200.240.1025 > 172.18.0.9.44192: Flags [P.], seq 1:23, ack 1, win 510, options [nop,nop,TS val 2075721544 ecr 1650518111], length 22
05:14:50.177764 veth1fdcd87 Out IP 192.168.200.240.1025 > 172.18.0.9.44192: Flags [P.], seq 1:23, ack 1, win 510, options [nop,nop,TS val 2075721544 ecr 1650518111], length 22
05:14:50.177853 veth1fdcd87 P IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [.], ack 23, win 502, options [nop,nop,TS val 1650518223 ecr 2075721544], length 0
05:14:50.177860 br-51d34c30828f In IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [.], ack 23, win 502, options [nop,nop,TS val 1650518223 ecr 2075721544], length 0
05:14:50.179689 veth1fdcd87 P IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [P.], seq 1:20, ack 23, win 502, options [nop,nop,TS val 1650518225 ecr 2075721544], length 19
05:14:50.179695 br-51d34c30828f In IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [P.], seq 1:20, ack 23, win 502, options [nop,nop,TS val 1650518225 ecr 2075721544], length 19
05:14:50.179756 br-51d34c30828f Out IP 192.168.200.240.1025 > 172.18.0.9.44192: Flags [.], ack 20, win 510, options [nop,nop,TS val 2075721546 ecr 1650518225], length 0
05:14:50.179763 veth1fdcd87 Out IP 192.168.200.240.1025 > 172.18.0.9.44192: Flags [.], ack 20, win 510, options [nop,nop,TS val 2075721546 ecr 1650518225], length 0
05:14:50.180552 br-51d34c30828f Out IP 192.168.200.240.1025 > 172.18.0.9.44192: Flags [P.], seq 23:114, ack 20, win 510, options [nop,nop,TS val 2075721547 ecr 1650518225], length 91
05:14:50.180564 veth1fdcd87 Out IP 192.168.200.240.1025 > 172.18.0.9.44192: Flags [P.], seq 23:114, ack 20, win 510, options [nop,nop,TS val 2075721547 ecr 1650518225], length 91
05:14:50.180913 veth1fdcd87 P IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [P.], seq 20:26, ack 114, win 502, options [nop,nop,TS val 1650518226 ecr 2075721547], length 6
05:14:50.180919 br-51d34c30828f In IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [P.], seq 20:26, ack 114, win 502, options [nop,nop,TS val 1650518226 ecr 2075721547], length 6
05:14:50.181414 br-51d34c30828f Out IP 192.168.200.240.1025 > 172.18.0.9.44192: Flags [P.], seq 114:123, ack 26, win 510, options [nop,nop,TS val 2075721548 ecr 1650518226], length 9
05:14:50.181425 veth1fdcd87 Out IP 192.168.200.240.1025 > 172.18.0.9.44192: Flags [P.], seq 114:123, ack 26, win 510, options [nop,nop,TS val 2075721548 ecr 1650518226], length 9
05:14:50.181697 veth1fdcd87 P IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [F.], seq 26, ack 123, win 502, options [nop,nop,TS val 1650518227 ecr 2075721548], length 0
05:14:50.181702 br-51d34c30828f In IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [F.], seq 26, ack 123, win 502, options [nop,nop,TS val 1650518227 ecr 2075721548], length 0
05:14:50.181841 br-51d34c30828f Out IP 192.168.200.240.1025 > 172.18.0.9.44192: Flags [F.], seq 123, ack 27, win 510, options [nop,nop,TS val 2075721548 ecr 1650518227], length 0
05:14:50.181850 veth1fdcd87 Out IP 192.168.200.240.1025 > 172.18.0.9.44192: Flags [F.], seq 123, ack 27, win 510, options [nop,nop,TS val 2075721548 ecr 1650518227], length 0
05:14:50.181909 veth1fdcd87 P IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [.], ack 124, win 502, options [nop,nop,TS val 1650518227 ecr 2075721548], length 0
05:14:50.181913 br-51d34c30828f In IP 172.18.0.9.44192 > 192.168.200.240.1025: Flags [.], ack 124, win 502, options [nop,nop,TS val 1650518227 ecr 2075721548], length 0
@dosubot[bot] commented on GitHub (Sep 10, 2025):
Your tcpdump logs show a successful TCP connection and data exchange between the plugin_daemon container and MailDev on port 1025, so network connectivity is not the issue.
The Langgenius-email plugin sends SMTP traffic directly to MailDev, bypassing the SSRF proxy, and supports flexible SMTP config—including host, port, username, password, and encryption method (SSL, TLS, NONE). By default, it tries to use TLS and login if credentials are provided, which can cause problems with MailDev if it’s set up for plain SMTP with no auth or TLS (plugin code reference).
Next steps:
If MailDev still doesn’t receive emails, it’s likely an application-level mismatch (TLS/auth enabled in plugin, but not supported by MailDev). Let me know what you find in the MailDev logs or if you need a sample Python script for testing.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@nemofira09 commented on GitHub (Sep 10, 2025):
SMTP config is set to none, but I cannot set the username and password because it is a required field in the langgenius-email field. The port is set to 1025. I am unable to test within the container because the necessary tools aren't installed, and it is not connected to the internet.
@dosu
@dosubot[bot] commented on GitHub (Sep 10, 2025):
The langgenius-email plugin always requires username and password fields and tries to authenticate with the SMTP server—even if you set encryption to NONE and your server (MailDev) does not require authentication. This is a limitation in the plugin's design: there is no built-in way to skip authentication, and the UI forces you to enter something for those fields see code.
The only current workaround is to use dummy credentials (like username:
test, password:test). This will only work if MailDev ignores the AUTH command; otherwise, the email won't be delivered see implementation.If you want a real fix, you’d need to patch the plugin so it only calls
server.login()if both username and password are non-empty, similar to how the attachments logic works insend_mail.pysee logic:This change would allow you to leave the fields blank and send mail without authentication, making it compatible with MailDev.
Since you can't install tools or test inside the container, you could test from the host or another container with Python's smtplib, or temporarily modify the Dockerfile to install testing tools if needed.
Let me know if you want a more detailed patch or have questions about modifying the plugin!
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@nemofira09 commented on GitHub (Sep 10, 2025):
Finally solved it.
Turns out that you just need to use the --incoming-user and --incoming-pass flags when running maildev, and the values should match the email username and email password you typed in the langgenius-email form.