This thread's discussion is locked. If it doesn't give you the information you need, head to its forum board for active discussions or to start a new discussion.
I'm... not quite sure. It's a message formatted by Outlook using Word as the editor, that went through an Exchange server, and it did contain an image, but when I look at the raw message as I received it on my private (non-Telus) mail, it looks like the image was inline, neither an attachment or an external link.
Try sending something that you didn't have Word or Outlook create as a test. The error mentioned an issue with the Body syntax. Wonder if something corrupted when you sent it? The error could still mean that the spam filters blocked it but it's more often displaying a different error message.
So much I had surmised, and in fact a plain text message sent via approximately the same route (using SquirrelMail to create a message forwarded to the Exchange server via IMAP/SMTP for transmission to a Telus account) was received without difficulty. Does the actual message body, then, count as a "parameter" to the BODY command? I kind of have to discount the filters; the two times (in ten years) that spam filters have popped, there has been an RBL notice and a link to clear up the problem...
If it's got HTML in it, which if it's showing formatting, picture, links, etc, then yes, it has a Body tag in it. Microsoft Word is not known for remotely being able to create the cleanest code. Outlook won't improve it. You may want to try another HTML editor to format the email you send out to see if that solves it.
Umm... I don't want to be contrarian here, but this is a response from the mail server, which should not be trying to interpret the incoming stream as HTML. I'm reading this as being an error return from the SMTP BODY command. IIRC, an SMTP message exchange consists of a certain amount of header information, notably recipients; followed by a BODY command, followed by a nominally opaque block of data which is the message body. The mail server should not be looking for content in that stream; it should only be looking for the blank line delimiter that says the body has ended.
It is possible that the Telus mail server is choking on the embedded image... but why only the Telus server? The same message went to about 100 parents of students at the school and only the eight Telus addresses bounced...
I'm working on it but it's tricky -- so far I have only received this email via my Outlook client, and Outlook won't allow me to see the raw email. I've asked that it be resent to an account that I can reach with a different client, but it hasn't happened yet.
Update: Sending a simple text-only message from the Exchange server to Telus worked. Sending the possibly broken message from the Exchange server to a Linux sendmail server also worked, and sending that same message on from the sendmail server to Telus also worked. It looks like it's just something odd about this message being sent from Exchange to Telus... but I still don't know quite what.
I suspect that the HTML editor is creating one or more lines with more than 1000 characters. The limit is described in RFC 5322 Internet Message Format section 2.1.1.
Not all mail server implementations have this limit but the RFC specifies the lowest common denominator.
This may explain why plan text works as the line length corresponds to the actual message lines whereas in HTML message will contain HTML tags that do not require LF's between them. A multi line text message could be sent as a single line of HTML.
Not sure about your test from Linux but it may be that that sendmail automatically re-formats HTML lines by adding LF's where necessary when sending. Note that the limit includes the CR/LF so it may also be a case of the Microsoft using the extra CR and making a line 1001.
A good point. I suspect that the issue is not with the HTML, but with the embedded MIME stream that makes up the image. We'll leave it at that for the moment, I guess: for whatever reason, Telus' servers are hewing a little more closely to the spec than most.