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::SetMIMEHeaderToEncoding
instead of SetMIMEEntityToEncoding. 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:
: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::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::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 :
- this is really a good thing to do,
- 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/