Re: [ic] MIME header confusion for some mail clients (Eudora/PINE)

[Mike Heins <mikeh@minivend.com>]

Quoting Randy Moore (ramoore@axion-it.net):
[snip beginning of nice analysis]
> So, I looked for a way to change this header to
> Content-Type: multipart/mixed; BOUNDARY ......
> 
> Which (I believe) lets the mail client treat each MIME block separately.
> 
> In the "sub mime" code in Interpolate.pm, I found that there is an option 
> called "attach_only", which if set would change the Content-Type appropriately.
> 
> After much experimenting, I realized that setting the "attach_only" option 
> in my [tag op=mime] tags in 'etc/report' will not help because some other 
> call to the 'sub mime' subroutine is setting this first MIME tag.
> 
> I found it in Order.pm, at line 1877:
> $mime = Vend::Interpolate::mime('header', {}, '') if $use_mime;
> 

This is correct.

> But from this there is no run-time way of setting the "attach_only" option.
> 
> I can (and did) change this line to:
> $mime = Vend::Interpolate::mime('header', {attach_only => 1}, '') \
> 	if $use_mime;
> 
> This worked perfectly for me, but is clearly not what was intended for 
> general use.
> 
> BTW, I know I could simply remove all the MIME tags from 'etc/report' and 
> Eudora would get along just fine, but I'm interested in a more universal 
> solution here (a demo that works for everyone).
> 
> So does any one know of a general solution out of this? I don't know what 
> (if any) problems there would be if the default Content-Type were changed 
> from multipart/alternative to multipart/mixed.

Multipart alternative allows you to default the first part of the message
display to text display without having to operate on the attachement. In 
other words, a text part followed by one or more attachments.

My mail client handles them just fine.

> 
> Suggestions anyone?

Update the current hacked-up MIME I did 5 years ago to use a real module
like MIME_Lite. If you want to see how far we have come in coding
standards, look at the mime() and send_mail() routines. Yuck. 8-)

I anticipate we will be doing this soon; we are working on a total
payment/routing/mail update for 4.8 and this can be part of it. (For
instance, we will be removing the dependency on a mailer program that
uses -t and probably make Mail::Send or somesuch available.)

I am always hesitant to Yet Another Module, but luckily this
is an infrequently done operation that can only be "require"ed when
needed. And we can modularize the current stuff to be a fallback in
case people don't have those modules.

-- 
Red Hat, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.7621 fax 7501 <heins@akopia.com>

Research is what I'm doing when I don't know what I'm doing.
-- Wernher Von Braun

_______________________________________________
Interchange-users mailing list
Interchange-users@lists.akopia.com
http://lists.akopia.com/mailman/listinfo/interchange-users