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.
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....
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
<cffmail subject="Foobar" to="email@example.com" from="Fred Bloggs">...</cfmail>
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!
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.
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.
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:
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.
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....
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
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...