[ic] Safe.pm (was Re: [interchange-core] Encoding of mail headers)

[David Christensen]

On Mar 4, 2009, at 11:24 AM, Stefan Hornburg wrote:

> David Christensen wrote:
>> On Mar 4, 2009, at 9:27 AM, Stefan Hornburg wrote:
>>
>>> David Christensen wrote:
>>>> On Mar 4, 2009, at 2:52 AM, Stefan Hornburg (Racke) wrote:
>>>>
>>>>> According to RFC 2047 mail headers with characters other than US-
>>>>> ASCII needs
>>>>> to be escaped. Interchange fails to do so, resulting in emails
>>>>> delivered
>>>>> which will be tagged by Spamassassin with SUBJECT_NEEDS_ENCODING  
>>>>> and
>>>>> SUBJ_ILLEGAL_CHARS.
>>>>>
>>>>> I wrote a simple filter which addresses this problem:
>>>>>
>>>>> CodeDef mime_encode_words Filter
>>>>> CodeDef mime_encode_words Description Find MIME type of filename
>>>>> CodeDef mime_encode_words Routine <<EOR
>>>>>
>>>>> use MIME::EncWords;
>>>>>
>>>>> sub {
>>>>> 	return MIME::EncWords::encode_mimewords(shift);
>>>>> }
>>>>> EOR
>>>>>
>>>>> Of course the whole IC email infrastructure needs to be adjusted  
>>>>> to
>>>>> use
>>>>> this.
>>>> The Encode module also offers this capability, and has the  
>>>> benefit of
>>>> being core.  While we're doing this, we should revisit the body
>>>> encoding as well.  I definitely agree that this should be done.
>>>>
>>> How would this work with Encode?
>>>
>>> Regards
>>> 	Racke
>>
>>
>> use Encode qw(encode);
>>
>> sub mime_encode_header {
>>     return encode('MIME-Header',shift);
>> }
>>
>
> In addition to Mike's concern, it doesn't emit a header which  
> Thunderbird
> displays correctly:
>
> MIME:EncWords:
> Subject: =?ISO-8859-1?Q?Bestellbest=C3=A4tigung?= F-Shop
>
> Encode:
> Subject: =?UTF-8?B?QmVzdGVsbGJlc3TDg8KkdGlndW5nIEYtU2hvcA==?=
>
> Even with UTF-8 the ASCII characters should be legible.


There are two types of MIME Header encoding; Q which is a style of  
quoted-printable, and B which is binary (related to base64 IIRC).  I  
believe if you prefer the other style it could be selected instead;  
the B is the default because it is the more compact representation  
when there are larger numbers of non-ASCII characters.  Insofar as  
Safe is concerned, *encode could be aliased and imported as a  
Safe::Hole to resolve any *explicit* encoding issues.  Where this  
falls down is in the implicit encoding issues (such as when using utf8  
or binmode on output handles.

However, Safe also falls down with anything that isn't explicitly  
imported and evaluated in a single package (think any OO-style  
software).  AIUI, this is why there are the various aliasing into the  
compartment for $Scratch, $Tags, etc, as you can't access $Vend::Tags,  
etc.  This is a known limitation of Safe, and is what we're ultimately  
running up against, require issues aside.  Even if we were to untrap  
*all* operations, I don't think you can access other packages from the  
compartment, and AFAIK this is not a restriction that can be lifted  
while still using Safe.

I understand the reasons for using Safe originally, and for quick  
snippets and smaller blocks of code it works fine, but for anything  
which needs to access other packages than the current, it fails  
miserably.  What are the ultimate protections that Safe was intended  
to provide, and what would be the impact if we were to throw out the  
Safe containers?

Regards,

David
--
David Christensen
End Point Corporation
david at endpoint.com
212-929-6923
http://www.endpoint.com/