Scripts send encrypted email to Spamcop

Hello,

  What I've found isn't 100% consistent with what you
explain below.  My
amavisd-maia did have the header=>randomiv setting in it,
and I've
verified that the mail in maia_mail table all has
"RandomIV" as the
first part of the text, but the gui still did not display
the mail.  My
process-quarantine-sub.pl script did need fixed in that
reguard.  After
having done so, I did a little testing, and the
"decrypted" data it was
using for both bayes training and reporting (which we don't
do, but..)
was corrupt, but using the crypt functions did
encrypt/decrypt properly
if everything was kept in memory, just not when stored
to/retrieved from
mysql.

  So as a test I converted my maia_mail.contents to type
blob ala "alter
table maia_mail change column contents contents blob;".
 Now the gui is
able to display (and I suspect recover, but I need to test
that) the
message correctly.  However process-quarantine-sub.pl still
doesn't seem
to work.  Still looking into it...



On Thu, 2006-10-26 at 13:15 -0700, Robert LeBlanc wrote:
> Jesse Norell wrote:
> > Ok, from Crypt::CBC man page it's noted:
> > 
> >        The "salt" header is now the
default as of Crypt::CBC version
> > 2.17. In all earlier versions "randomiv"
was the default.
> > 
> > Looking at the process-quarantine-sub.pl script,
it did not specify the
> > header type, and I was getting errors from it in
cron saying:
> > 
> >   "Ciphertext does not begin with a valid
header for 'salt' header mode"
> > 
> > That's easy to fix (and may be done in more recent
maia versions, I
> > don't know) by just adding the 'header' =>
'randomiv' to the
> > Crypt::CBC->new() initialization.
> > 
> > The amavisd-maia executable already had that done.
 With updating a
> > couple other settings there to their new names in
both executables, I
> > now have:
> > 
> >     $cipher = Crypt::CBC->new( {'key' =>
$key,
> >                                 'cipher' =>
'Blowfish',
> >                                 'literal_key'
=> 1,
> >                                 'padding' =>
'null',
> >                                 'header' =>
'randomiv'
> >                               } );
> > 
> > I'm guessing that might fix my bayes problem, and
possibly/probably your
> > reporting issue, too.  It did not make the gui
able to display the raw
> > message though .. still working on that one.  Any
ideas there?
> 
> In your case you're running Maia 1.0.0, which breaks
with Crypt::CBC
> 2.17 and later on two fronts--it breaks compatibility
with Mcrypt
> (addressed by ticket #280 in Maia 1.0.1) and it breaks
the decryption
> process in process-quarantine-sub.pl (addressed by new
ticket #368).
> 
> The #280 issue with Mcrypt affects the ability of the
PHP scripts to
> properly decrypt what Crypt::CBC encrypts.  With the
changes in
> Crypt::CBC 2.17, the "RandomIV" header was no
longer being prepended to
> the encrypted data, and at the PHP end of things the
Mcrypt library was
> relying on that "RandomIV" header to know
what to do with the data.  Not
> seeing the "RandomIV" header anymore, the GUI
had to assume that the
> data was not encrypted, which is why you're seeing
garbage in the mail
> viewer.
> 
> Adding the 'header' => 'randomiv' option was indeed
the fix for that
> issue, as implemented seven months ago in revision 956
> <https://secure.renaissoft.com/maia/changeset/956>. 
This fix was
> incorporated into Maia 1.0.1.  Note that 'literal_key'
=> 1 is the same
> as 'regenerate_key' => 0; the latter is just the
deprecated form of the
> former, which was introduced in Crypt::CBC 2.15.
> 
> The #368 issue is different however.  For some reason
that I'm
> investigating, with versions 2.17 and later of
Crypt::CBC an item
> encrypted and then decrypted with the same set of
options does not seem
> to decrypt, which suggests that a slightly different
set of options may
> be necessary at the decryption end now.  This issue
affects only the
> process-quarantine-sub.pl script, so both Bayes
training and spam
> reporting are broken when Crypt::CBC 2.17 or later are
used.  This is in
> spite of the fix from #280.
> 
> In short, #280 is responsible for the garbage you see
in the mail
> viewer; #368 is responsible for the ineffectiveness of
your Bayes database.
> 
> _______________________________________________
> Maia-users mailing list
> Maia-usersrenaissoft.com
> http://www.renaissoft.com/mailman/listinfo/maia-users
-- 
Jesse Norell - jessekci.net
Kentec Communications, Inc.

_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users