Bugfix: message sent as encoded garbage (Mandrill)

[shevron]

If a Zend\Mail\Message is sent through the Mandrill service, and it contains HTML/text MIME parts which are encoded using either base64 or Quoted-Printable (which is often a good idea when using traditional SMTP), the message is received in its encoded form. This is because $part->getContent() returns an encoded version of the content.

The solution that worked for me was to switch to $part->getRawContent(). I'm not sure it is "best" and that it will not break other services (I can only test with Mandrill), but as I said it makes sense to me.

I specifically refer to a message that was created like this, for example:

$body = new MimeMessage();
$bodyText = new MimePart($text);
$bodyText->charset  = 'utf8';
$bodyText->encoding = Mime::ENCODING_BASE64;
$bodyText->type     = Mime::TYPE_TEXT;
$body->addPart($bodyText);

I think this is important because it allows the same messages to be sent either through traditional mail transport or through a SlmMail service.

[bakura10]

I really cannot merge is as it would require us to test again each provider. However I'm surprised by what you are saying, I'm using exclusively Mandrill and never encounter this bug. By the way, any reason for not using Mandrill templates? They are much more flexible, to my opinion, and defer this part to Mandrill.

[shevron]

I'm using Mandrill templates for some of my messages. I have a lot of legacy code that renders emails which are difficult to convert to Mandrill templates, and I was planning to use SlmMail as a quick way to send the same Message objects I currently send through Zend\Mail\Transport but enjoy Mandrill delivery and tracking features. All in all it works, but is not as trivial as I thought.

I also do not enjoy the idea of vendor lock-in, but I guess I have to live with it :)

Anyway the reason you may have not encountered it may be because you do not specify a transfer encoding on MIME parts as in my example above?

Feel free to merge or not. My workaround would be to not encode my messages for now but I'm not sure its the best solution.

[juriansluiman]

@shevron you have provided us with a case which fails currently. Can you provide a sample with a MimeMessage/MimePart which doesn't fail as well? We could check if an encoding is set on the part and then determine whether to use the raw or encoded part.

Also, what is the reason to use encoding on your messages? Ultimately, encoded messages should work just as fine as non-encoded messages, but I have never seen base64 encoded text parts before :) (I even doubt if that works with normal SMTP settings).

[shevron]

@juriansluiman just comment out the ->encoding = line from the broken example, and you get a working example:

$body = new MimeMessage();
$bodyText = new MimePart($text);
$bodyText->charset  = 'utf8';
// $bodyText->encoding = Mime::ENCODING_BASE64;
$bodyText->type     = Mime::TYPE_TEXT;
$body->addPart($bodyText);

Encoding MIME parts does work with normal SMTP, I have been doing it for years :P In any case it is up to MIME support in the client, not to SMTP servers. to decode it. AFAIK base64 and QP transfer-encodings are a part of the MIME standard, and it always worked for me. As for the reason to do it, in my specific current case its not mandatory, but in the past I have seen some mail clients break up, especially with multi-byte character encodings, and encoding the data is the best way to avoid those issues. I admit I keep doing it just to be on the safe side, and maybe its not a requirement anymore.

[roelvanduijnhoven]

I'll close this PR as it is from 2014!