|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
Tim Holloway wrote:Tomcat doesn't have even the remotest idea of what JavaMail is - just one of the things that shows it's not a full-stack JEE implementation.
If you're getting a timeout, it's almost certainly either because you have a firewall issue or because you're talking to the wrong port or wrong server. These days mail isn't always handled on port 25.
One of the best ways to test that is to use telnet to try and connect to the upstream mailserver. For example:
telnet mail.mousetech.com 25
Basic SMTP is a text-based protocol and it's actually possible to send mail directly via telnet, but the important thing is whether it connects and responds. If it doesn't then definitely the problem is not in Tomcat.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
Tim Holloway wrote:Well, again, Tomcat knows nothing. Tomcat does not interject itself into network traffic. It either owns ports outright (8080, 8443, etc.) or the application does. No sharing, packet conditioning, traffic routing/shaping. Nothing.
So, taking you at your word (though I do recommend a telnet test on port 465), I would look at the larger environment. Is there a virtual storage issue? Has the Tomcat JVM been allocated enough object memory? Is the machine it's running in being starved?
And last, but definitely not least, have you attempted to run the system using a different JVM?
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
Tim Holloway wrote:Actually, that message reads to me like a problem with the mailserver. It's also mostly reported from other systems than tomcat. For example:
https://lists.exim.org/lurker/message/20090831.204705.8e09002e.en.html
In this particular case, it looked like the mailserver was doing a blacklist check against a third-party server and didn't get an answer back fast enough to complete the transmission.
So one possibility would be to make sure that the destination mailserver locally whitelists the machine that Tomcat lives on.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
Tim Holloway wrote:Lacking direct access, I cannot offer any better suggestions at the moment. Except to note that if your machine has both internal and external IP addresses, the mailserver probably should whitelist them all.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
Tim Holloway wrote:My condolences. Have you a friendly network expert who can do packet tracing for you? Also, look at mailserver logs (preferably at debug level). You can also set debug-level logging in the webapp, although that probably won't tell you anything.
1
Tim Moores wrote:For JavaMail problems I find that turning on debug mode quite often provides sufficient information to pinpoint the problem. See https://javaee.github.io/javamail/FAQ#debug for which flag to set (and the following few questions for additional things to test).
1
Tim Moores wrote:That looks pretty normal - the client seems to connect successfully to the server, and transmit the message. Only when it tries to close the connection does the exception occur. Odd.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
Tim Holloway wrote:Well, again, it does sound like you might need the services of a network expert. About the only other theory I i can propose would be if the reply port was blocked.
Every tcp connection requires 2 network ports. One is the server port on the destination server. The other is the reply port on the source client. The reply port is typically a high-numbered port number assigned at random where responses from the server are returned. It is not a fixed port since a single client might have multiple server connections concurrently active. In fact, web browsers might be running 10 different requests in parallel for a single web page.
So the reply port needs to be visible through the local firewalls. In Linux using iptables, this is covered as part of a pair of stock rules for state=ESTABLISHED and state=RELATED. I don't know what the MacOS equivalents are, but it's possible that these rules aren't set up quite right on the offending machine. It doesn't make sense in that supposedly without that sort of access all connections on the client machine would potentially fail, but it's about my best guess.
Other than that, I suppose that somehow the mail client in the Spring Boot app is subtly different from the stand-alone and it's invoking something that makes the mailserver pause. I am, incidentally, assuming that your problems come when running the offending application directly on the client OS and not in a container, where networking gets an extra layer of complexity.
Also see if you can get the maillog from the mailserver for your connections. It may shed some light.
1
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
Tim Holloway wrote:Congratulations!
Was the working stand-alone app using the 1.6.2 version also?
I don't know if this means that the newer version was trying some sort of fancy tricks that annoyed the server or if there's an actual bug there - and since it's OS-specific, possibly even involving something within the network stack. Would be interesting to investigate if I wasn't busy on other stuff - and, of course, had a Big Sur system. But we'll take a win however we can get it.
Don't forget to put a comment about this in your POM against the day when things get upgraded!
Tim Moores wrote:That's quite odd. In my experience, upgrading JavaMail from version to version has been seemless for a looong time, certainly since the 1.4 days.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
Tim Holloway wrote:
Tim Moores wrote:That's quite odd. In my experience, upgrading JavaMail from version to version has been seemless for a looong time, certainly since the 1.4 days.
Unfortunately, I know of no product and no vendor that has been completely immune to an occasional "dud" release. It's possible that none of the testers had a Big Sur machine to run under.
|
There's a city wid manhunt for this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
|
