This issue has been previously reported and acknowledged by Filemaker: Email header malformed when using SendMail
It can also be found in the Known Bug List
This list can be downloaded as a filemaker database: http://www.4shared.com/file/8orL8apk/FMP_Bugs.html
Sorry for duplicate report. Strange - I was checking the Known Bugs database - tried to search for SMTP and did not find any record.
Good observation. I've updated the title to include the SMTP keyword as this is specific to the SMTP option as I read the original thread. Had you searched under the more general keyword "Email", you would have found it.
This is a big deal and nothing has happened for almost a year. I have found other threads that deal with the same problem since March 2010. I know of several people at our facility that need SMTP support and use kluges like "clickyespro" to get email messages to work. Honestly, what good is an application that manages databases well but cannot get information out to users affected by the data?
is NOT useful.
Please place high priority on this Filemaker bug.
Hi. I am also having a similar problem and its quite annoying as mails are getting bounced back to us. Its especially bad on hotmail servers. Any new ideas?
I have posted here:
Thank you for your post. I have attached your post to the original reported issue that has been confirmed by our Testing department and sent to Development.
Thank you for your post and comments. They have also been attached to the original issue.
Thank you for your post. I have already replied to your message via your post at:
Was this fixed in FM Pro11?
I just purchased FMS 11 and am getting teh same problem.
Is there a way to change the encoding from UTF-8?
I think neither 11v3 nor 11v4 addressed this issue.
"HOnza Koudelka" is correct. Neither FileMaker Pro 11.0v3 nor FileMaker Pro 11.0v4 addressed this issue. There is still no information available regarding its status.
It appears that only half of this issue has been acknowledged and addressed in Email header malformed when using SendMail
The encoded subject was not addressed. Currently with emails sent from FMP 12.0v3, spam assassin still reports the following:
* 2.1 FROM_EXCESS_BASE64 From: base64 encoded unnecessarily
Header encoding still appears to be a problem in FileMaker 14. Is there any way to get this back on the radar?
I'm looking at a message just sent via PSoS on server v14. Even though I'm only using simple ascii content, text is encoded for From: and Subject:
The problem is pretty simple. RFC 2047 says,
"Use of 'encoded-word's to represent strings of purely ASCII characters is allowed, but discouraged."
FileMaker should examine data being set in these headers and encoded them only when necessary.
The first big problem here is that older legacy services garble encoded headers. For example, AT&T cellular, with over 120k subscribers, garbles messages through their official gateway: email@example.com
The second big problem, spam scanners penalize FileMaker's emails, sensibly, because they do not follow the recommendation of RFC 2047. For example, Rules/FROM_EXCESS_BASE64 - Spamassassin Wiki
Is this still an issue??? If so... we need to get someone to look at this. This is a problem... and we need to made periodic investments to make sure the tech in FileMaker isn't so old that its not usable.
The format for the Message-ID was fixed in FileMaker Pro 12.
Using FileMaker Pro 14.0.5 and accessing a hosted file, I am able to use Perform Script on Server that sends a message via SMTP. My From email address and Subject line ("Test") is not encoded. Can you provide more information on the Subject you are using?
This certainly is still a problem in FMPA 14.0.5. No server or PSOS is required to reproduce the problem. Please make sure that you are looking at the raw message source and not "decoded" headers.
Reproduce with this single step:
Send Mail [ Send via SMTP Server ; No dialog ; To: "firstname.lastname@example.org" ; Subject: "Test" ; Message "Blah" ]
Notice the headers in my attached screen shot. The plain ascii From: "John Doe" and Subject: "Test" are unnecessarily encoded. The RFC discourages unnecessary encoding of header values. When done this way, it "looks fishy" to spam filtering software.