SARS Mime Encoded E-mail

[ramar]

Hi, not sure if anyone can help me shed any light on this problem:

I have a client that has hosted exchange e-mail with Mweb.

When they receive MIME encoded e-mails from Sars (embedded pdf docs), the e-mail arrives in an unreadable format, just a whole bunch of characters as though it is encrypted.

We have tested by asking Sars to send the same e-mail to a yahoo address as well as the hosted exchange address. They are readable when delivered to the Yahoo address but not when delivered to the hosted exchange address (also checked in OWA to rule out an issue on the client side).

But the odd thing is that if you forward the e-mail from the yahoo address to the hosted exchange address they are then readable when received by the hosted exchange address.

They are using outlook 2007 and Acrobat 9 and say that before they moved to the hosted exchange they had no problems and it happens on all the computers.

They do not have any problems receiving any other mails, normal pdf attachments etc.
So far Mweb have been unable to shed any light on the issue.
Anyone else seen this problem before?

 

[bubbatentoe]

Had the same problem with secured PDF's some time ago from our bank (Outlook 2007 on Exchange 2010).

Rather save the PDF locally (desktop) and then open it with Acrobat 10, not 9.
Don't open the file from within Outlook.

My guess is that once you open the file from within Outlook, Acrobat 9 is trying to connect to the certificate provider (Thawt, Verisign, GoDaddy etc) in order to verify the certificate.
It bombs somehow and Outlook displays garbage.

 

[Tofu]

I've been having this problem intermittently for a year. It's inconsistent because the mail comes through the same mail server, but to different mail programs and adobe versions.
It's been suggested by SARS call centre agents that mail servers are recognising the address of origin as spam, and that those particular addresses must be set up under mail rules as non-spam in order for them to come through properly, but this doesn't make sense to me.

 

[metatron]

Regardless of what you do the mail is still unreadable, we have added the specified address to a whitelist and still no change.
Very frustrating.

 

[metatron]

So, it would appear that this depends on your hosting provider, whether or not they support the encryption needed by SARS.
Hetzner's response to this is

"Thank you for your email.

At this time, our servers do not support the encryption that SARS
sends their statements in. Until such a time if and when we do
support this, I suggest one of the following processes:

1) Download the mail to your local machine and see if your local
machine reads the email.

If the above does not work, then

2) Forward the mail on to servers that do read the encryption and
open it from there."

 

[Tinuva]

I work for an ISP that also does mail hosting. So out of interest sake after reading this thread I just looked at the headers of these mails, and noticed something out of the ordinary.

X-Amavis-Alert: BAD HEADER SECTION MIME error: error: part did not end with
	expected boundary
Content-Type: multipart/mixed; boundary=MIME_BOUNDARY
Mime-Version: 1.0

some text - why is there not a boundary start here?

--MIME_BOUNDARY

some more text - wut? I expected HTML code here...

--MIME_BOUNDARY
Content-Type: application/pdf; name="PROVSA_979040104.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="PROVSA_979040104.pdf"

base64 code for the pdf file...

-- no boundary end  line here?

I didn't read the RFC on mime mails, but usually I expect a end line after the last boundary, but this mail had none...
Could be that they are sending it wrong and not all mail servers parse it correctly.

Personal opinion: Sars are sending out the mails incorrectly, and Amavisd-new flags this problem correctly, and they need to fix it.

Last time I wrote a php script to send out mail correctly, I had to always have boundaries to show where one start and where the last one ends (its where the last one ends that this sars mail missed).

Eg.

$headers .= "Content-Type: multipart/alternative; boundary=\"PHP-alt-".$random_hash."\"\r\n"; 
$headers .= "Message-Id: <".md5(uniqid(microtime()))."@".$_SERVER["SERVER_NAME"].">\r\n";

$mailmessage = "
--PHP-alt-".$random_hash."
Content-Type: text/plain; charset=\"iso-8859-1\"
Content-Transfer-Encoding: 7bit

$message

--PHP-alt-".$random_hash."
Content-Type: text/html; charset=\"iso-8859-1\"
Content-Transfer-Encoding: 7bit

$message_html

--PHP-alt-".$random_hash."--
";

Summary, this fault lies with SARS and not the hosting companies, though I bet it will help the hosting companies to have a work-around if possible, but the onus is on SARS to fix it, since the email is originated by their services, not to say its their email servers, its their software that generates the emails and send it out. eg. A developer needs to go read the RFC and fix the code.

 

[vixen_800]

Short term solution

Hi, experienced exactly the same problem, found a solution at http://www.ehow.com/how_5024066_read-mime-format-emails.html which works for me, its a short term solution ... i'm sure there is a setting somewhere in Outlook 2007, i spoke to our hosting company and they said our email settings were fine.

Anyway back to the solution which worked for me:

1) Open the MIME format email which you wish to read. Select all of the text with your cursor.
2) Launch the Notepad (on a Windows PC) or TextEdit (on a Mac) program, included on all PCs or Macs
3) Paste the MIME formatted email (from Step 1) into the text editor
4) Highlight and delete all of the text before the standard email header (e.g., the headers in which you find the "From" and "To" fields).
5) Save the document to your computer desktop, adding the ".eml" file extension to the file name
6) Double-click the file you saved in Step 5. Your email management software (e.g., Outlook Express) will then open the file and interpret it as a standard email, thus allowing you to read MIME format emails without attempting to decipher the mismatched symbols and garbled text that is often the result of mistranslated MIME code.

Good luck
V

 

[BradDC]

I tend to agree with Tinuva - it does have boundaries missing.. does anyone have contact within SARS? Also having this problem with quiet a few clients...