[rt-devel] RT3: mail UTF-8 automatic conversion and GPG verification

[Guillaume Perréal]

Jesse Vincent a écrit :

>>But I managed to make it working, by postponing body parts conversion. Here's 
>>a summary of changes :
>>
>>- in RT::EmailParser, I redefined _PostProcessNewEntity() to convert and 
>>unfold only *main* headers. I'm hoping this will avoid getting butchered 
>>user-names from other mail plug-ins, though it will not mess with signature 
>>verification as main mail headers couldn't be (and thus aren't) signed.
>>    
>>
>do you then go and clean up headers later on?
>
_PostProcessNewEntity now calls RT:I18N::SetMIME*Header*ToEncoding 
instead of SetMIME*Entity*ToEncoding. From what I read from the code, I 
believe it only affect main headers.

I relie on RT::I18N::SetMIMEEntityToUTF8 to clean up the headers later, 
am I right ?

>>- in RT::Interface::Email, I redefined Gateway (sig!) to do the UTF-8 
>>conversion just after authentication (does it fail or pass). (I also changed 
>>a bit the way AuthStat and CurrentUser are assigned from plug-in return 
>>values).
>>    
>>
>What did you need to change? I'd love to see.
>
Firstly, I put an call to RT::I18N::SetMIMEEntityToUTF8 just after the 
authentication process.

Secondly, AuthStat and CurrentUser are only overwritten only if 
NewAuthStat is greater or equal to AuthStat. My purpose is that 
CurrentUser was not erased if a module returned an AuthLevel of 0 with a 
undef'ed user, preserving any preexisting authentication. For example, a 
filter module (say RT::Interface::Email::Filter::SpamAssassin) can now 
safely returns an AuthLevel of 0 and an undefined CurrentUser to let the 
message pass without erasing the return status of a previous plug-in 
(say RT::Interface::Email::Auth::MailFrom). In the original 
implementation of RT 3-0-4, specifying a @RT::MailPlugins like 
qw(Auth::MailFrom Filter::SpamAssassin) will leads in no user identified 
in all cases, as the output of Filter::SpamAssassin will erase the one 
of Auth::MailFrom. (by the way, I didn't manage to have 
Filter::SpamAssassin working without hacking it a bit).

>>- I rewrote the RT::Interface::Email::Auth::GnuPG from enhanced-mailgate's 
>>GetCurrentUserFromPGPSignature sub. The main change is to use the 
>>'--status-fd' option of GPG that allows to get an locale-independant, easily 
>>parseable status output.
>>    
>>
>Cool. you should also have a look at Mail::GnuPG.
>
I tried to use it in a first time but it poorly handles non-signed mails 
: it dies... So I was forced to catch the exception and parse it to 
guess if it was related to a non-signed mail or to any other error...

Plus, I had problem with the Mail::GnuPG in FastCGI mode : could not get 
anything from the output filehandles. I don't know what it is related to 
CGI::Fast (or FCGI), Mail::GnuPG or GnuPG::Interface.

>>I can post an archive with the two *_Local.pm files and the GnuPG.pm one if 
>>someone wants. But I mainly ask for comments about that. After that, I'll go 
>>on my way to integrate pseudo-headers handling in the Gateway sub.
>>    
>>
>I'd love to see your changes. Also, with your changes, does RT still
>pass a "make regression"? 
>
Didn't tried yet, didn't thought to. I fear this will be interesting... :-)

>I'd like to recommend that you implement the pseudoheader parsing as its
>own module, so that it can be reused by other components that might also
>want it, such as a CVS or Subversion integration.
>
I'll remember that, thanks.

Oh, a question : for now, the signed message is passed unchanged (UTF-8 
apart) and the signature is archived as an attachement (or at least as a 
text part) but I think this is quite unuseful and maybe misleading. As 
the UTF8 conversion will corrupt the signing, I wonder if I could strip 
of the signature part and replace the main body by the signed parts, 
that is changing the structure of the mail to have it looks as an 
ordinary mail. But I don't know if :
1) this is really a good thing to do,
2) this is easy to do (I'm not accustomed with MIME::Entity)

Any suggestion ?

-- 
Guillaume Perréal.

Responsable informatique,
Cemagref, groupement de Lyon,
France.

Tél: (+33) 4.72.20.87.87.
Fax: (+33) 4.78.47.78.75.
Site: http://www.lyon.cemagref.fr/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pallas.eruditorum.org/pipermail/rt-devel/attachments/20030818/aa797eb1/attachment.html