6.3.1 > Severe Problems regarding attachments with certain Emailproviders

[MikeMcNuke]

Hi,

we found a big problem for many customers in the current 6.3.1. Problem not checked with older iterations.

With several emailserviceprovider, namely in this case GMX.net, attachments won't get recognized! We tested it on an empty clean 6.3.1 install. We sent a testemail with attachment of any type to a Sugar User and he won't be able to download anything - he is even not able to see that this Email has an attachment!

This is the raw code from such an Email from GMX:

Content-Type: multipart/mixed; boundary="========GMX78491328554414180479"
Date: Mon, 06 Feb 2012 19:53:34 +0100
From: XXXXXXXXXXXXXXXXXXXXX>
Message-ID: XXXXXXXXXXXXXXXXXXXXXXX
MIME-Version: 1.0
Subject: TEST
To: XXXXXXXXXXXXXXXXXXXXXXXXX
X-Authenticated: XXXXXXXXXXXXXXXXX
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX1+94ltF5b+9bjDUIfD4aAT9fQiQQePTYNMPOK2 JgZ
02yoHw9lIUyY6ZEULALjwCzQOOURwjSFRanQ==
X-GMX-UID: +URCb81/eSEqU3fIrnQhMWl+IGRvb0Cr
X-Virus-Status: No
X-Virus-Checker-Version: clamassassin 1.2.4 with clamdscan / ClamAV 0.97.3/14406/Mon Feb 6 16:31:37 2012

--========GMX78491328554414180479
Content-Type: multipart/alternative;
boundary="========GMXBoundary78491328554414180771"

--========GMXBoundary78491328554414180771
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

LBAblabalbal
--


--========GMXBoundary78491328554414180771
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

BLBABLABALBAL

--========GMXBoundary78491328554414180771--

--========GMX78491328554414180479
Content-Type: application/pdf; name="Baustellenschild 1500 x 2000.pdf"
Content-Transfer-Encoding: base64

Data cut off due to size for post.

Except for the GMXBoundary nothing special in the mail, other emailclients don't have a problem with it. It is a really big problem, because in B2C installations the usage of such an emailprovider is significantly higher - and so the recipient won't be able to see if anyone did send him an attachment.

Should I file a bug report? Is this behavior known? Nothing found in the bug tracker which seems odd.

If we send from Outlook or Roundcube an Email no problem with the attachment...Emailserver on Sugarside is Dovecot with Postfix.



And now for a strange behavior regarding the image, marking an email as attachment in the list view. If we let Sugar autoimport Emails, the attachment icon is set correctly, if the email contains attachments.

If we don't use autoimport and use only IMAP for reading, NO attachment icon is displayed, even if the email has an attachment. Seems more like a bug but found some references to it in the bug tracker as a feature. But what kind of feature is this??

Would be great to solve this mailproblems....

[MikeMcNuke]

Hi,

made several tests, problem is reproduceable on fresh installs. On the serverside dovecot und postfix are running, but except for the headers emails raw code won't get altered. So the attachment recognition of Sugar seems to fail.

Any ideas how to solve this? Should we file a bug??

Greetings

[morrighu]

This has the appearance of a non-standard email header.

What I don't see:

Content-Type: application/octet-stream; name=mytestfile.pdf
Content-ID: <5.31.32252.1057009685@server01.example.net>
Content-Disposition: attachment

[MikeMcNuke]

This has the appearance of a non-standard email header.

What I don't see:

Content-Type: application/octet-stream; name=mytestfile.pdf
Content-ID: <5.31.32252.1057009685@server01.example.net>
Content-Disposition: attachment

Seems I cut off something before the base64 data:

--========GMXBoundary29101328550786568057--

--========GMX29101328550786567819
Content-Type: application/pdf; name="Baustellenschild 1500 x 2000.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*=us-ascii''Baustellenschild%201500%20x%202000.pdf

DATA***************************

So, how can we solve this problem?

[MikeMcNuke]

We now issued an bug report, it seems to be a reproducable error.

SugarCRM Bug Tracker | Open Source Business & Social CRM - SugarCRM

[MikeMcNuke]

Further investigation revealed following statement to be the problem:

 filename*=us-ascii''Baustellenschild%201500%20x%202000.pdf

replace this with

 filename="Baustellenschild 1500 x 2000.pdf"

and the attachment gets recognized! Now we verify if this behaviour comes from GMX.

According to RFC the used code from GMX is in line with standards. http://tools.ietf.org/html/rfc2231

Character set and language information may be combined with the
parameter continuation mechanism. For example:

Content-Type: application/x-stuff
title*0*=us-ascii'en'This%20is%20even%20more%20
title*1*=%2A%2A%2Afun%2A%2A%2A%20
title*2="isn't it!"

So the implementation of filenamehandling in attachments is incomplete/bugged in the Sugar Emailclient.

[MikeMcNuke]

Dirty fix found. The attribute from GMX Email for filenames gets recognized as filename* and not only filename. Will look for the origin, why the system doesn't recognize the RFC encoding for filenames with language options and will implement a fix for the problem.

This is really a dirty workaround. But our customers can now get email from GMX ( and probably other services, too) with attachments, too.

In modules/InboundEmail/InboundEmail.php

         function retrieveAttachmentNameFromStructure($dparamaters)
        {
           $result = "";

           foreach ($dparamaters as $k => $v)
           {
               if( strtolower($v->attribute) == 'filename' ||  strtolower($v->attribute) == 'filename*')
               {
                   $result = $v->value;
                   break;
               }
           }

           return $result;

    } 
  

The real problem is the function imap_fetchstructure in PHP. Don't know if it should handle the filename of attachments with full language options or just pass the core values in the structure.

If the core values are correct Sugar has to handle the language options in the filename according to RFC specification. Else it's imap_fetchstructure problem. Who is to blame?