New Install- Can't Send Mail

dev support
1

Hi All-
New Lucee user here. Inherited a few sites that someone else created, and trying to help out with moving them from an old server to a new VPS.

Everything seems to be working fine except for email. When I try to send mail from Lucee admin or via a simple test page, I don’t get any errors in the UI, but the mail never hits my smtp server. I see this in catalina.[date].log under c:\lucee\tomcat\logs:
WARNING [Thread-12] javax.mail.Session.loadResource expected resource not found: /META-INF/javamail.default.address.map

I followed the steps here to no avail, but it also seems to be for an older Lucee release.
https://lucee.daemonite.io/t/email-not-sending-lucee-5-3-5-92/6864

OS: Windows Server 2019
Java Version: OpenJDK 11.0.10
Tomcat Version: 9.0.35
Lucee Version: 5.3.7.48, but I’ve also tried both of the currently available RCs

Thank you for any tips/assistance!

2

You need to properly setup email sending from the host or use a third party server or service.At the bare minimum for windows 2019 you would need to install the simple SMTP server

from powershell as administrator

Install-WindowsFeature smtp-server

The tag is used like this:

<cfmail 
	to="emailto@domain.com" 
	replyto="replyto@domain.com" 
	from="no-reply@domain.com" 
	subject="My Subject" 
	server="localhost" 
	username="no-reply@domain.com" 
	password="no-reply-email-password"
>

Email body 

</cfmail>
3

Thanks for the suggestion, Terry. I had Lucee configured with Mailgun from the admin interface, which is what we use for a variety of other applications. However, your post gave me the idea that maybe Lucee wasn’t cooperating with Mailgun’s SSL. I disabled SSL, and now mails are sent.

Although we prefer to have SSL enabled, this resolution is acceptable as the application doesn’t send confidential mailings.

4

Well SSL isnt secure either, its just a feel good security proposal.

Why?

SSL certificates require a verified SSL Certificate Authority to issue your certificate.

This is the same as requiring you to go give the city and the locksmith a set of keys to your house after you pay a lock smith for the privilege of installing a lock on the door.

5

:slight_smile: Love the analogy! Very true.

6

That’s not how it works.

You don’t give the certificate authority the private key, only the public key.

7

Lucee 5.3.7.45 had the big SMTP upgrade for javaxmail. It fixed SSL/TLS access to most SMTP servers. A good site to check SMTP SSL is checktls.com. Maybe the certificate was wrong or not setup correctly?

8

Just a little, but important off-topic note about that: As soon as:

  • personal data is affected and
  • your machine is on EU soil
  • or the personal data of an EU citizen is affected (no matter where your servers are located),.

Then he European General Data Protectiom Regulation (GDPR) dictates encryption.

Here in Germany that was already happening before GDPR: In 2013 we’ve been warned by the regional data protection authority to adapt our MTAs to always do encryption (that by the way needes also forward secrecy) as default, and only allow none encryption as a last fallback. The cause was one end user that issued a complaint back at that time.

For whom is.interessted to read about the GDPR, here is the link to the regulation:

https://eur-lex.europa.eu/eli/reg/2016/679/oj

We always thought: “No way we are affected, because we don’t send personal data and no confidential data is envolved in our simple web application”, but we have been told better: the simple email address of a user during a SMTP connection may potentially be such data. They’ve dictated to implement the encryption.

9

Bit way off topic but I am an American

Long before 9-1-2001, the NSA was installing communication interception centers in all major carriers in the US, after 9-1-11 the US Patriot Act just made what they had been doing legal.

Comcast, ATT and other carriers use deep packet inspection (SSL DECRYPTION) real-time.

Fast forward 15 years and now you have intel management engine which cant be turned off, leaks data and can be used to completely decrypt, unlock and bypass any os level related locks on your intel computer.

So lets go back to What Peter said, and try to take it at absolute fact that nobody ever will get your private key.

Was your private key generated on an intel or AMD processor? Maybe a cloud server? did you shell out thousands of dollars for one of the few remaining RISC chips that have sub par performance? What OS did you use to create the certificate request, Maybe Novel Netware 3.X or IBM OS/2 Warp or BEoS?

You certainly wouldn’t want anything public domain that the NSA has diligently contributed to, at least you might not want to considering how many projects they have contributed to publicly, let alone in secret.

Now how did you generated certificate request to the CA? did you throw it on a thumb drive and mail it? maybe put it on a “cd rom”

So your certificate, no matter how it arrived at the Certificate Authority (CA) reads the CSR and generates the certificate, which in theory has NO IDEA what your private key is, it just knows that you requested some random string for some other random string and it looks correct so here is your packaged random math string based upon a number you provided.

now your CA sends you the certificate, did they send it armed carrier? what was it created upon? Can you at anytime download that certificate again? Why is it being stored by them again? No matter how it arrives you have a mathematical text string based upon an encryption math problem developed by??? that you are hoping that nobody will ever figure out how to reverse engineer that math string.

Sure, you use your new math string and its “magic” the browser just knows as your “CA” gave it to you, and anything is 100x better than the certicaite you created by yourself that never left your computer / server, could possibly even of used your own chip to create.

Yes, that is tongue in cheek sarcasm, as you can go google it for yourself, your “encryption” all encryption, in its current state is very deeply flawed and it is the basis of why BITCOIN and other user generated encryption has actual value.

I

1 Like
10

Good news everyone- SSL and TLS are both working now. :smile:

It ended up being as simple as connecting to port 465 instead of the RFC complaint 587.

Not sure why something is mad at port 587, but I don’t think I’m going to worry about solving that. I’m also quite confident that this is not Lucee’s fault, either.

2 Likes