So, it seems to have been a hardware issue and/or a config issue with the Arm instance
I spun up another Arm instance and the test java app ran successfully.
Now I get to spend tomorrow getting everything configured again…
2 Likes
Well…I am back to square 1.
Lucee is set up on new instance, the java app works connecting to the SMTP server, but, I am getting the 530 error…
Current working theory is that the version of javax-mail included with Lucee is not the most recent (or at least not the same version included in the java test app). At this point, that seems to be the only difference between the test java app and Lucee.
Does anyone know the best way to try and replace the javax-mail jar?
The latest javax.mail package is 1.6.2 from August 2018.
5.3.8 uses 1.6.2 as of here https://lucee.daemonite.io/t/5-3-8-84-snapshot-5-3-7-45-rc-java-mail-upgraded-to-1-6-2/7528
It’d be easier to ensure your test app is using the version Lucee is using, if that’s your concern.
The only way to get to the bottom of javax.mail behavior is to turn on logging, analyze the results and determine which part has gone awry. Then you can trace it back and figure out why.
Your test app was probably a couple class files linked to javax.mail, using a standard jvm running a single clasloader.
Lucee is an ecosystem of java modules running on OSGi with its own well-established configuration parameters, properties files and hundreds of jars.
All your test app has proven is there’s something different in its environment when compared to Lucee.
You have to test+reproduce+fix in the environment where it’s not working. That’s why we’ve been trying to help you get logs and post them. Obviously, if I could reproduce it on my mac, using the exact same SMTP server you’re using, I would have pointed out the problem already.
I have tried your suggestions for getting logging information, but I was never able to see any information regarding the emails being sent. More than likely this is a knowledge gap on my part.
Based on this, is it safe to assume that Lucee 5.3.8.206 is using 1.6.2?
OK, I was able to pull up some log info.
[ERROR] Jan 06, 2022 9:49:14 AM javax.mail.Session <init>
CONFIG: JavaMail version 1.6.2
[ERROR] Jan 06, 2022 9:49:14 AM javax.mail.Session loadResource
WARNING: expected resource not found: /META-INF/javamail.default.address.map
[ERROR] Jan 06, 2022 9:49:14 AM javax.mail.Session loadResource
WARNING: expected resource not found: /META-INF/javamail.default.address.map
[ERROR] Jan 06, 2022 9:49:14 AM javax.mail.Session loadAddressMap
CONFIG: failed to load address map, using defaults
[ERROR] Jan 06, 2022 9:49:14 AM javax.mail.Session getProvider
FINE: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Oracle]
[ERROR] Jan 06, 2022 9:49:14 AM com.sun.mail.smtp.SMTPTransport protocolConnect
FINE: useEhlo true, useAuth true
[ERROR] Jan 06, 2022 9:49:14 AM com.sun.mail.smtp.SMTPTransport openServer
FINE: trying to connect to host "smtp.email.us-ashburn-1.oci.oraclecloud.com", port 587, isSSL false
[ERROR] Jan 06, 2022 9:49:14 AM com.sun.mail.smtp.SMTPTransport openServer
FINE: connected to host "smtp.email.us-ashburn-1.oci.oraclecloud.com", port: 587
Hopefully this will help…
One question answered. 
It’s set to use EHLO, so that’s good.
Do you have more? We didn’t get to the failure or exception yet.
That is all that showed up when I tried to send an email.
sudo vi+wq javamail.default.address.map
mv wq javamail.default.address.map /META-INF/
restart Lucee/tomcat
No offense, but exactly what steps did you take to get that error as its a configuration issue on your end.
Step 1, what did you do
Step 2, what else did you do
step 3, next
step 4, next…
Step 1: Spun up VM instance.
Step 2 : Installed CommandBox
Step 3: Deployed code to server (using a gradle script I have locally)
Step 4: Started Lucee using CommandBox
Step 5: Tried sending email
Step 6: Started pulling out hair because of the 530 error.
I do not configure mail servers in the admin. I pass all the info I need when sending the messages.
Once again, the code and configuration are EXACTLY the same between dev and production. No values are different.
- what kind of virtual machine, what size, where, whats the hypervisor? are any hypervisor tools installed?
- Whats the OS, and patch level
- When was the last time it was updated?
- When was the lase time it was rebooted
- Whats the current java environment and environmental paths
Did you check permissions on all files, users, ectra
Does your script install the users, groups, paths, so on and so forth?
what do the OS logs tell you
What happens when you manually use ssh or telnet to step through sending an email via command line from the non working box
I do not configure mail servers in the admin. I pass all the info I need when sending the messages.
Once again, the code and configuration are EXACTLY the same between dev and production. No values are different.
So you CLONED The Virtual machine and just changed instance ip?
what the NIC card on the devices?
Did you check your hosts file?
Did you check your firewall settings?
Go down the complete list and see the differences as something is different.
if you have the resources spin up a lucee instance and run the same code. Does it work?
Take a step back and then go down the list.
I did not clone the virtual machine and change the IP.
It is a brand new instance with nothing from the old instance.
Why would the HOSTS file matter? I have a java based app to test and it works as expected.
Firewall: same as above. If it was a firewall issue, the test app would also fail.
File permissions have no bearing on sending mail using cfmail (or the script equivalent)
If you are referring to my deployment script, all it does is put code on the server. It does not ‘install’ users, groups, paths, etc.
The OS was updated/rebooted as recently as this morning.
There are a lot of differences between dev and prod. The main one being dev is running on Windows and prod is on Linux.
Add mail.debug=true.
This will cause Javamail to output debug info.
Why would the HOSTS file matter? I have a java based app to test and it works as expected.
Some instances of virtual machines set the hostname via DHCP. You can accidentally have 2 instances of the same machine name on the same network which can cause networking issues, plus *NIX boxes far more rely upon actual RFC compliance than Windows, so properly setting up the OS is in order.
File permissions have no bearing on sending mail using
cfmail(or the script equivalent)
Actually, they do. Though if you insist they dont then I will just disengage.
There are a lot of differences between dev and prod. The main one being dev is running on Windows and prod is on Linux.
Yes, *NIX vs Windows is literally day versus night.
For the hell of it, I spun up a oracle box, followed the instructions in the documentation and i am able to send email via lucee without fail.
Day vs Night.
Windows 2012r2 patched and onwards has TLS 1.2 enabled by default.
You really need to read this, maybe reach out to Oracle support to have them guide you command by command in setting up your NIX box.
2 Likes
Did you spin up an Arm instance using Oracle Linux? What version of Lucee? What version of Java?
I have followed all the steps in that guide (except the analytics, because I am not using that) in the past. It is how I got the Oracle email account working on my older (pre-Arm) instance. There is nothing else on that page I need to do.
I actually had one of Cloud Evangelists for Oracle helping me on this and they are stumped as well.