One of our datacenters hosts a webapplication written in CFML / Lucee. It sends mails to customers, but the mails have a high X-Barracuda-Spam-Score. Especially on the Message-Id:
pts rule name description
2.60 INVALID_MSGID_2 Message-Id is not valid, according to RFC 2822
The message-Id looks like this:
<844275327.4929.1591341519768.JavaMail."LOCAL SERVICE"#servername>
When reading the RFC, it looks like the quotes are the problem.
The question is: is there a way to alter this "LOCAL SERVICE" part? The cfmail tag does not give any control over the Message-Id, nor do I find any setting in Lucee. Lucee uses JavaMail for sending messages.
The specs of out Lucee server are:
Lucee Versio 5.3.5.92
Tomcat 9.0.31
Java 11.0.6
Windows Server 2016 (10) 64 BIT
One of our customers uses Coldfusion 9,0,0,251028. The Message-Id of their mails looks like:
<170351411.4299.1591215728394.JavaMail.ServerName$#mailrelay.company.local>
Thanks!
The session property mail.from can be used to control the user account name that is encoded in the Message-Id.
If you can't set the from address you can set the session property for mail.user to change the messageid and use the mail.<protocol>.user to switch back to the correct userid.
The session also supports a value of user.name which can be used to change the user name.
Make sure that you are running the latest version of JavaMail as there are some fixes related to this issue. Mainly versions 1.5.3 and newer remove the user name from the message id.
Another option is to subclass MimeMessage to override the messageID computation.
Related
We are using APEX_MAIL.send procedure to send the mails. IT was working fine till now. Recently we have changed its hostaddress and after that it has stopped sending the mails.
My database version is 11.2.0.3 and APEX version is APEX 4.2.6
Can you please let me know what could be the reason and how can i resolve that.
Thanks
Oracle database has internal access control lists that limit which network resources can be accessed by PL/SQL packages like APEX_MAIL. It also relies on an initialization parameter to define the default SMTP host. If you changed your mail host, then it is very likely that one or both of these needs to be updated.
See here for details about setting up ACLs in Oracle 11g: https://oracle-base.com/articles/11g/fine-grained-access-to-network-services-11gr1
And see here for details about the SMTP_OUT_SERVER parameter: https://docs.oracle.com/cd/E18283_01/server.112/e17110/initparams239.htm
I am currently in the finishing stages of building an application and have asked the user group to perform production-level usage testing on the application. My application is a makeshift order management system that sends an email to a customer when an order is saved that includes an invoice.
I ran into a problem yesterday when I was doing some testing; this environment currently contains production-quality data, including old customer records. I processed a few orders and forgot about the functionality, and the customer who I did the orders for received emails saying the order is complete. Good that it worked, bad that it lead to this confusion.
The action I would prefer would be to set something somewhere within the application that forces all emails, regardless of the to recipient, to be sent to a specific address, though I would settle for simply being able to turn it off for this application alone. Turning it off on the server level is available not a preferred option due to the need to perform testing on other applications that process email, but are not populated with production-quality data.
Are there any specific flags or code I can use to override server settings in the application to only send email to a certain address based on how we identify our environment, or to not send email altogether?
Reference this page:
http://cookbooks.adobe.com/post_How_can_I_use_Application_level_SMTP_Server_Settin-16469.html
For testing purposes you could set the SMTP server to a non existant IP address. The cfmail routine will still work and coldfusion will move it to an undeliverable folder.
You could add <cfif> statements around it to determine if your on a production URL or dev URL so that it uses the right server while on the production server, or uses the "fake" server while on your development server. OR while on the production server, have an on/off variable that you could use to test emails through your smtp server or shut off emails and route them to the fake SMTP server.
If your on version 8.0 or older, you can setup an application level variable for your mail server and modify your cfmail tags to reference:
<cfmail server="#application.mailserver#" to="" from="" subject="">
This solution presumes you use the same mail server but just want to swap emails to a test address (perhaps yours, so you can see the result). It also presumes your live server name resolves to something that has 'www.something.somethong.' and your dev/test/qa etc servers do not.
In your Application cfc onApplicationStart() try this:
<cfscript>
if(listFirst(CGI.SERVER_NAME,'.') != 'www') {
Application.szEmailToTestEnv = 'test#somewhere.com'; // Use your test email here
}
</cfscript>
Then where you send the email have a bit of logic infront of your mail param such that:
<cfscript>
if(isDefined('Application.szEmailToTestEnv') && len(Application.szEmailToTestEnv)) {
Variables.szEmailTo = Application.szEmailToTestEnv;
} else Variables.szEmailTo = Variables.qCustomerEmail;
</cfscript>
And then in your cfmail:
<cfmail to="#Variables.szEmailTo#"....
Adjust scopes and variable names and value as necessary.
Essentially, any 'site' (say dev.yoursite.com) that is not your live site will then use the test email you set at app startup to send the email and live will continue to use the correct customer email with no code changes between your live and test code.
I'm part of a two-man business selling LED glow toys and one aspect of this is handling support requests. I have a server running exim4 and DJango and have email working so that if a user sends an email to support#myhost.com I'm able to pick up the email and respond.
I'd like to develop something a bit tidier to keep track of the email chain for a particular support request.
To do this, I was thinking of piping the output of my email using a rule in my support email's filter:
pipe /usr/bin/email_to_django_script
What I'm unsure of is how best to go about the last step to actually turning the email content into something DJango can process.
What's the best method to do this? Would a script using curl -d be a sensible option or are there better / less convoluted ways?
You can pipe the output of the email server into a management command. As an example, I have a file /inquiries/management/commands/proc_email.py. I have a single Command class, and the handle() method gets most of the email from the environment, and the body of the email from STDIN:
from_email = strip_tags(os.environ.get('SENDER', None))
to_email = strip_tags(os.environ.get('RECIPIENT', None))
emailMessage = email.message_from_string(''.join(sys.stdin.readlines()))
There is other code in there, but that is how I get the important bits out of it. You can then pipe this into your ORM objects, and access it from the website at some later time.
This is then accessed through /path/to/project/manage.py proc_email.
Depending on your email server, you can also use plus addressing to insure replies come back to the same address. For example, I have my Reply-To headers set to inquiry+12345#whatever.com. The mail server (postfix) then dumps this into the environment under EXTENSION. If no number is supplied, I simply create a new Inquiry, instead of attaching to an existing one.
Not exactly a pure Django solution but I would recommend taking a look at Lamson Project. It's an email server written in Python that you can use to build email applications like what you are describing. I can also integrate with the Django ORM. http://lamsonproject.org/docs/hooking_into_django.html
I can't believe I've never noticed this before, but it seems that CFMail won't send to an email address that isn't explicitly set up on the destination mailserver.
This means that if I'm using 'info#somedomainorother.com' and have that set up to catch all email on the domain, CFMail won't send to 'test#somedomainorother.com'.
This causes a massive amount of problems for me, as I'm using CFMail to send out order confirmations, member activations and all manner of other bits and pieces.
Whatever your views on using catchall addresses, it can't be denied that people do use them So, in any case that a user enters a made-up address into one of my sites, they won't receive their email.
There must, simply MUST be a way around this - can anyone help?
For refernece, the message that appears in the logs when sending to a catchall address is 'Invalid Addresses'.
EDIT: Here's the CFMail syntax I'm using -
<cfmail to="#Arguments.sEmailAddress#" from="#Application.sAppEmailAddress#" subject="Stock reminder confirmation: #Local.qGetProductDetails.sProductName# - #Application.sCompanyName#" type="HTML" server="#Application.sAppEmailServer#" username="#Application.sAppEmailAddress#" password="#Application.sAppEmailPassword#">
Translates into:
<cfmail to="thisisatest#somedomainorother.com" from="application#mydomainname.com" subject="Stock reminder confirmation: Some product - My Company" type="HTML" server="mail.mydomainname.com" username="application#mydomainname.com" password="XXXXXX">
All works fine for info#somedomainorother.com but not for randombunchofcharacters#somedomainorother.com.
Important to note of course, that the catch-all is working correctly in all other respects, test emails from mail clients work perfectly.
Its not ColdFusion that cares about email validity, its the SMTP server. CF only cares about well formed email addresses.
If you initiated a telnet session to your mail server and tried to use the same address, I'm sure it would have the same result.
Debugging tips for SMTP Connectivity:
http://www.talkingtree.com/blog/index.cfm/2004/11/22/debug-smtp
Can I see your CFMAIL tag setup? CFMAIL doesn't care as long as the email address is properly formatted.
Urgh!
Turns out it was an issue with the server. For some reason, catchall email accounts serverwide had stopped working properly. After an email to my hosting provider, it's all working fine with no code changes.
They're somewhat cagey as to what caused the issue, and I was still able to use an email client to send mail out to the addresses...
Thanks for the help in any case. ;)
I am getting an error when trying to connect to an Exchange server using the cfexchangeconnection tag. First some code:
<cfexchangeconnection action="open"
server="****"
username="****"
password="****"
connection="myEX"
protocol="https"
port="443">
I know its the right server because it fails when not processing via https. I have tried:
Following all the instructions here http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec14f31-7fed.html
Prefixing username with a domain name, adding #domain name, etc and no luck.
The error I get is:
**Access to the Exchange server denied.**
Ensure that the user name and password are correct.
Any ideas
Here's an idea - this is what I needed to do to make my cfexchange connection work. Not entirely sure if it's the same problem. I think I had a 440 error, rather than your 401 error.
I'm using:
https
webdav
forms based auth
Exchange 2007
Coldfusion 8
Windows 2003 servers
Here's the connection string that worked for me. What was keeping my connection from working was the need for the formBasedAuthenticationURL. This is a poorly documented attribute by both Adobe and Microsoft.
<cfexchangeconnection action="open"
username="first.last"
password="mypassword"
mailboxname="myAcctName"
server="my.mail.server"
protocol="https"
connection="sample"
formBasedAuthentication="true"
formBasedAuthenticationURL="https://my.mail.server/owa/auth/owaauth.dll">
<cfexchangecalendar action="get" name="mycal" connection="sample">
<cfexchangefilter name="startTime" from="#theDate#" to="#theEndDate#">
</cfexchangecalendar>
<cfexchangeConnection action="close" connection="sample">
Additional notes:
IIS and WebDAV are enabled on the target Exchange server.
The username and password you're using has the appropriate permissions for
a WebDAV connection. (I'm not the Exchange admin, so I'm not sure what they
are, but I think the account needs to be allowed to connect to OWA. - Please
correct me if I am wrong.)
Optional: (don't use if you don't have to)
IF HTTPS is required, use the appropriate argument.
IF Forms Based Authentication is on in Exchange 2007 (as was my case),
you'll have to work around it using the formBasedAuthenticationURL argument.
Not sure if that's it, but I hope it is!