Mailer Extension, again

I’ve been actively ignoring all the traffic about recent problems
with the Mailer Extension until today. I had done preliminary testing
and nothing was throwing errors so I figured all was well before I
released our converted site live.

Now I’ve got a real and configured mail server behind the site to
test against I discovered a problem.

Though my forms return “email_html” page parts and don’t also have an
“email” part or anything like that, the email that I get in response
is encapsulated in “text/plain” and won’t display at all in my email
client unless I got to view Raw Source of message.

The content of these forms and output email_html parts have not been
touched through this conversion. The below two emails are generated
by each version of the Mailer thing respectively –

Mailer Extension email in Pastie which shows-up as a blank message in
my email client unless I look at the Raw Content of the message then
I see this (* note line 41):

http://pastie.caboo.se/37563
Line 41: Content-Type: multipart/alternative;
boundary=mimepart_45c3ba4744994_eb9…fdbb90756334

From the older Email Behavior which does display as expected in my
email client (* note line 33):

http://pastie.caboo.se/37567
Line 33: Content-Type: multipart/mixed;
boundary=mimepart_4581bf35ab0e3_657…fdbbd21a01862

I started digging into the Mailer Extension code but thought I’d ask
around to see if anyone knows enough about email formats or the code
in the extension to give me a hand. This sure seems like a bug to me.

Any help is appreciated.

Yey! We’re finally have everything converted-over to mental (just in-
time to miss the first RC :wink:

Loren J.
www.fn-group.com

Loren,

That was my change. Back last March when I was developing a Rails
application that needed to send email, I dissected various
gracefully-degrading emails that I got in my inbox. I found that, for
most email clients, the multipart/alternative type with a text/plain and
a text/html part seemed to be the most compatible. I’m willing to
change that assumption, however, and the code, if you have a better
solution. I searched a lot and didn’t find any reliable reference for
how they should be formatted, so I reverse-engineered it.

Sean

Sean,

Yeah since I wrote that message I’d done some looking around:

http://www.freesoft.org/CIE/RFC/1521/18.htm

And will look into it more this afternooon.

I need to follow through the code and my page to see why my the plain
text version is blank, as on first glance in the code it looks like
it’d have a default list of the fields at least.

Then I’ll look into why Mac Mail isn’t choosing the HTML version as
it did in a multipart/mixed message…

If I see any reason to change things in the code I’ll write-back with
my suggestion. Right now as far as I can see the raw multipart/
alternative message looks correct except the missing plain/text content.

Thanks,

Loren

Loren,

From those references it seems I have it backwards; the plaintext version
should go first. But you’re right, it doesn’t explain why your ‘email’
or
‘email_plain’ doesn’t render.

Sean

Oops, actually easier said then done… I’m checking out the Mailer
Extension via svn:externals to Mental and will have to detach from
the mothership to test this which I’ll do depending on your answer.

The change of ordering that parts is a really straight forward swap
at lines 256-262 of mailer_page.rb

I don’t know if it’ll solve my problem but if it needs to happen
anyway…

When do you think you’ll get to that?

L

That makes sense however it still doesn’t answer why the html version
isn’t being preferred by Mac Mail (not checked with any other clients
yet). . .

I’ll rearrange the order of the parts and re-send to see that
magically fixes it.

L

Later today probably; I’ll be helping John and the rest of the core team
with the 0.6 RC. Watch the changelogs at
http://dev.radiantcms.org/radiant/timeline if I don’t get back to you.

Sean

Thanks and np,

I forget, “this is the day” :slight_smile:

Honestly I don’t think changing the order of the parts will fix my
problem anyway, though it does look like it should happen anyway.

Finally,

I manually re-arranged the plain and HTML parts in a test message and
opened it up directly in Mac Mail. Yep… that definitely fixes it.