It still begs the question why they would refuse a message with ASCII content. I would be very interested to understand why they block this. The pessimist in me suspects it is a knee-jerk reaction.
At the office we have a customer who requires invoices be sent by email as pdf files. Each time we do that we receive an "invalid format" rejection notice. It has been determined that the plain text part is what is triggering the rejection. We're sending plain text messages but they're being received with a plain text part and with the attachment.
I have tested with the "Generate multipart/alternative versions of richtext messages" option disabled and with the "Don't add "attachment information" sections to Multipart messages" enabled with no joy. Messages without attachments don't have a plain text part but messages with attachments do.
I also tried using the option of sending the attachment as a separate message. This might work for the attachment message but we'd still have to deal with the rejection of its associated message.
Anyone know of a way to send an attachment without the message containing a plain text part?
Why is the message being rejected? What is triggering the rejection on the part of the customer? Do they have some exotic system or conformity requirements in place? As Mercury conforms to SMTP, it may be that your customer needs to adjust their system, and that you do not need to adjust yours. [Edited]
The recipient is Daimler so I don't hold much hope with affecting any sort of change although we're still talking with their AP support folks.
We know that they have an automated system that rejects any message received with an attachment other than a .pdf and they claim that the plain text part is what is triggering the rejection.
That sounds like they are rejecting multipart messages, which are completely standard. The only thing I can come up with, is to send the pdf content as the body of the message, This will require a message without content-type: multipart/*, but instead content-type: application/pdf and the Pdf paste'd into the message body. Then a content-disposition: line and finally a content-encoded: line to request Base64 conversion before sending.
In other words you build an outgoing message from scratch, the save it as stationery for the next time it is needed
HTH
Martin
