AnsweredAssumed Answered

Email header malformed when using SendMail

Question asked by JonJ on Mar 9, 2010
Latest reply on Dec 8, 2015 by TSGal


Email header malformed when using SendMail

Description of the issue

I have posted this on a couple of forums, and I think that it represents an as-yet unreported bug.  I am trying to use the sendmail script step while specifying the SMTP server. The mails get sent OK, however the message header isn't formed correctly. The message-id is something like: Message-ID:  i.e. without a server or a domain to the right of the @. We have noticed a number of spam-traps block the mail as suspicious -- a malformed header under RFC 2822 guidelines. Here's an example from a Baracuda antispam server: //////////////////////////// X-Barracuda-Spam-Report: Code version 3.2, rules version breakdown below pts rule name description---- ---------------------- -------------------------------------------------- 2.26 INVALID_MSGID Message-Id is not valid, according to RFC 2822 //////////////////////////// ...i.e. any message needs to have a message-id formated as "message-id: " -- the lack of text after the @ symbol on mail sent by the SendMail script is a problem! I've tried running the script on FM10.3 client on a PC running Windows 7, a Mac running OSX10.5 and as a serverside script on FMSA10 on a server running Windows Server 2007, all with the same results.  I have also tried using MS Exchange 2003 as the mail server and also SmarterMail Enterprise 5.5. I have seen reports of a work-around for another SendMail script issue which involves leaving the 'name' field blank in the 'user information' section of the SMTP setup. This has no affect on the problem reported here -- in fact, it makes it more likely that the message will get trapped by a Baracuda server, as it triggers another rule:1.00 NO_REAL_NAME From: does not include a real nameExperiments with various mail recipients shows about a 50:50 ratio of mails successfully delivered to mails either explicitly trapped or not making it into the recipient's mailbox (usually a sign of an aggressive domain-level spam trap quietly stopping mails without informing users!)Any help or comments gratefully received! Jon.