cfmail undeliverable hell

Report · Apr 16, 2012

Running CF 9.0. Every now and then a mail file will end up in the undelivr folder. For example our external SMTP server is twitchy, and sometimes there is no connection (briefly). Other times it's impossible to tell why the mail fails to be sent. The mail log says "The ColdFusion mail spool encountered an invalid spool file..." and of course the file is moved to the undelivr directory.

Well... once there I cannot get the mail to send by moving it back to the spool directory. Once the file ends up as undeliverable it will not go. It just gets re-sent to the undelivr folder.

These emails are not malformed. They are automated messages to me and other ediotors that something has occurred on the server. Email addresses are good, etc. These scripts are many years old and they have always works flawlessly until CF9. Trust me, the files should go out just like all the other ones that do.

OK, I've searched this forum and the Internet for like problems and fixes. I've tried restarting CF and then moving the files back to the spool, deleting the first file that didn't go out (if more than one file is in the undelivr folder), and saving as ASCII, UTF-8 no BOM, and even copying & pasteing the mail into notepad and saving back to the spool. I've tried turning off TLS. (The SMTP server is SSL) I've tried turning off the spooler. Nothing works. No matter what I have tried, if it ends up in the undelivr directory it will not go out from the spooler.

Has anyone any ideas? I've been programming CF since version 4 and I can usually figure these types of things out, but this one is a tough one. Any help would be appreciated.

Report · Apr 16, 2012

Robbien,

I wonder if it's actually embedding something in the file that marks it as "bad". You might try an experiment. Send yourself a test email and watch the spool so you can copy out your test email while it's there awaiting processing, and then send an idential message but break something first (close a port or something) so that the second email fails, and copy it out as well. Then run a diff on the two files and see what's different (besides the timestamps, etc.). Might not net anything, but who knows? If you figure this one out, I'm definitely going to want to know the answer. Best of luck.

~Day

Report · Apr 18, 2012

azimuthinternet,

Good idea. I tried what you suggested (I have an application that sends out notices, and I punched it twice). I looked at the two emails--undeliverable and the one sent out (before it was sent), and they are exactly the same. I used "Ultracompare" which allows a binary comparison. The only difference was the file name itself. I'm wondering whether CF "remembers" undeliverable file names. The next time an undeliverable mail shows up I'll see if changing the name has any effect. You never know....

Report · Apr 25, 2012

We had a problem when we migrated to CF9 from 8- the cfmail structure worked a little different and it took us ages to work out what was going on...

On CF8 this worked

However, failed on CF9 - it turns out that on 9 it doesn't like the "from" being an undefined email with a space in the name -although if it said just "Fred", then it would work, which was why it took us so long to work out and may explain your apparently random issue. So, to get round it we had to restructure all our code like so:

No idea if this is related to your problem, but it may be!

Good luck!

Report · May 14, 2012

Phil,

Thanks for your input. I had your issue back in my CF 5 days, and ever since I have used your approach--using chr(60) and chr(62) for the greater than and less than symbols--to get around names with spaces..

This problem I am dealing with here appears to be related to the cfmail files themselves. Since I posted this, I tried a little experiment: One day when there were lots of undeliverables, I downloaded the undeliverable mail (our server is a virtual cloud server hosted by kickass.com) and uploaded them to a replicate virtual instance of the server on my desktop at home (I use VMWare to replicate the virtrual server as a development tool). Anyway, my VMWare server has the ability to mail out files through CF 9, so I uploaded the undeliverable mail to that spooler, and again, they would not go out, and were sent to the undelivr folder instead. This happened after rebooting my VMWare server as well, so I think the inability to send undeliverable mail has something to do with the mail file itself *after* it is sent to the undelivr directory, not with any state that CF is in (locks, etc.).

As I said above I have been comparing the spool files with the undeliverable files and I cannot see any differences in the files, but it appears that once these files are sent on to the undelivr folder thay are somehow marked as undeliverable and cannot be sent out even from another CF server.

Now it is possible that somewhow my SMTP server on the other end is refusing to accept these files after one refusal--sort of recognizing them as not acceptable or spam or something, and I am going to try some tests to see if I can determine if this is the case. Again there is nothing special about these emails. I have created a small program to resend the mail by copying and pasting the to, from, subject,. message, etc. information into a form to resend the mail, and they go out without any issues. The underliverable emails occur only sporatically and are usually related to my SMTP server going offline every now and then.

BTW I still can't believe I am the only person who has come up against these "permanently undeliverable" mail files.

Report · Sep 01, 2012

You are not the only one having this issue. We have the same issue on CF 10 and Solaris 11. I have be troubleshooting this now for two days. I am trying to track down the change made to the file. However, we have a script written in the dos batch environment that has worked for 7+ years and now we cannot use it any more. I will post the finding if I find a cure. BTW Adobe does not support Solaris 11 yet.

Report · Nov 21, 2012

We have been having the same problem through all versions of Coldfusion, and I think I finally found the answer.

Although the files look the same, I suspect CF does something in the background when looking at the charset of the mail. All of our undeliverable mail had no charset definition. The first line of the CFMAIL file looked like this:

type: text/plain

If the mail went thru when it was originally sent, everything was fine. But if the mail was determined undeliverable (for whatever reason) and wound up in the undelivr folder, no matter how many times we tried to respool it (even after the brute force effort of stopping and starting CF Server) it would not go. I found another thread that had a similar problem and solved it by adding the default charset definition of the server to the "type" definition line. So I edited the mail file and changed this line to look like this:

type: text/plain; charset=UTF-8

And magically, all the mail I added the charset definition to went thru. Maybe it's a bug that the CF people can fix and patch for us.

Happy Thanksgiving!

Report · Nov 28, 2012

cvcocuzza,

Last night CF hiccuuped and I had four undeliverable messages in my undelivr folder this morning. Unfortunately, when I examined them, they all started with: type: text/plain; charset=UTF-8, so there was nothing to edit. Nevertheless I tried changing to ISO-8859-1 and removing the character set declaration altogether. No luck. I removed the archive attribute and tried respooling, but no luck. I even tried changing permissions on the files and spool directory as well, but still no luck. (I vaguely remember trying this before)

I am glad that the missing character set declaration worked for you, but for me I still haven't found the key to solving the problem.

One last thing: This morning I sent a test email and intercepted it in my ascii editor before it went out successfully. I compared it to my undeliverables, and I can discern no differences in the header information. I even tried saving the intercepted email to the undelivr directory and then moving it back to the spool. Guess what? It would not go the 2nd time! It is as if the fact of being in the undelivr folder caused the file not to be "sendable" by the spooler. If the origination is from CF it goes. If the origination is my ascii text editor, it does not go. I can't image why that would be, unless CF adds some hidden information to .cmail files that is lost when the file is moved to the undelivr folder.

Whatever, I still have to deal with the occasional undeliverable mail and manually resend it. I even created a form to "re-mail" the undeliverable ones, and so far the "re-mailed" emails--although exactly the same as the originals--have gone out successfully the 2nd time. Go figure....

Report · Jan 24, 2013

We have this same issue whenever our mail server goes offline except we have CF10.

Here's a quick sequence of events of error and resolution I performed this morning:

Mail server goes offline for a brief period of time.

Messages in Spool folder gets stuck and are sent to undeliverable folder

Mail server goes back online

We manually move the emails from undeliverable to spool

Depending on the volume of emails, some email which have always worked for years, ends right back to the undeliverable folder

In the case I ran into today, out of 3 undeliverables, 1 did not want to go through for some reason, I suspected it maybe because of the attachment, but this was not it.

I checked the CF mail error log and found this:

""Error","scheduler-0","01/24/13","09:26:20",,"javax.mail.MessagingException: missing body for message"

javax.mail.MessagingException: missing body for message

at coldfusion.mail.MailImpl.createMessage(MailImpl.java:696)

at coldfusion.mail.MailSpooler.deliver(MailSpooler.java:1295)

at coldfusion.mail.MailSpooler.sendMail(MailSpooler.java:1197)

at coldfusion.mail.MailSpooler.deliverFast(MailSpooler.java:1657)

at coldfusion.mail.MailSpooler.run(MailSpooler.java:1567)

at coldfusion.scheduling.ThreadPool.run(ThreadPool.java:211)

at coldfusion.scheduling.WorkerThread.run(WorkerThread.java:71)"

It made no sense why CF was requiring the body of the email as it normally goes through without issue any other time.

So, I manually edited the mail in the undelieverable folder and basically copied the subject into the body as well by typing it in the following on a new line at the very end "body: Random Blabber," then moved it back to the mail folder and it went through...

Report · Apr 03, 2015

we are having problems connecting to our hosting provider's mail relay.

emails will never go first time and we have it setup that every 5 mins undelivered emails are moved back into the spool folder. eventually the emails will successfully go after several attempts.

however in the .cfmail file if i manually remove the port no. which is 25 and save the file and manually move it to the spool folder, the email will leave our system immediately.

unfortunately in the coldfusion administrator a port no. must be specified, but is there any way to get around this?

Report · Nov 04, 2015

This may or may not be related, but I work with a client that sends out 2500 emails at a time, often a couple of times an hour. The majority of them immediately end up in the Undelivr folder and it's taken me days to figure out why. After lots of experimenting, I've discovered that CF (or at least this particular configuration) will only send out 600 emails per hour. Obviously... hopefully... this is a setting that can be changed? Does anyone know how to tweak this? I can't imagine CF having a 600/per hour limit. This is a private server running CF11 Standard, Windows 2012 server, and Smartermail 14.

In the meantime, I've tweaked and implemented this script to automatically move undelivered mail back into the spool every 30 minutes: https://www.hass.de/content/coldfusion-10-move-coldfusion-undelivery-mail-back-spool Works great, but it sure would be nice to get around the 600 per hour limit. Anyone have any ideas?

I should clarify that CF only sends 300 emails at a time, but will do it twice in a 60 minute period...

Report · Nov 05, 2015

This wont be CF with the restriction. We have sent our 10s of 1000s of emails a time with no issues at all, been doing this since CF 9. It will most likely be an issue with the mail server configuration you are sending them too. We find turning off spooling speeds up processes like this but makes it harder to track undeliverables. CF will only move it to the undeliverable folder if it gets a negative response from the mail server. You will be able to see additional information in the mail.log for coldfusion and the smtp servers logs.

Report · Aug 11, 2020

I know this is like 8 years after the original post but I'm currently working for a client who is still running CF 9 and I've run into the same issue you're describing LOL They have recently upgraded the mail server and I had a little over 1000 e-mails stuck in the undelivr folder ... after reading ALL of the guys' suggestions and recommendations first I took a look at the rejected e-mails and noticed that it embedded the old mail server name which was only slightly different from the new mail server name (by few letters)

I've opened all 1000+ rejected CF9 emails using EditPlus and edited the server: line to match the name of the new mail server as specified in the CF Admin ... yes, you do have to include the port number on that line as well 🙂

After doing that and moving the files back to the SPOOL folder they all went without a hitch ... Thank you to all who contributed to this post over the last 8 years LOL