Re: [Evolution-hackers] There's no need to be so hard on iconv
- From: Jeffrey Stedfast <fejj novell com>
- To: Philip Van Hoof <spam pvanhoof be>
- Cc: evolution-hackers <evolution-hackers gnome org>
- Subject: Re: [Evolution-hackers] There's no need to be so hard on iconv
- Date: Thu, 11 Oct 2007 10:52:46 -0400
I have far better fixes in GMime that need to be ported to Camel.
Jeff
On Thu, 2007-10-11 at 12:14 +0200, Philip Van Hoof wrote:
> I also have this one, for example
>
> Subject: =?ISO-2022-JP?B?GyRCJSIlaiUsLUUtRRsoQg==?= (
> =?ISO-2022-JP?B?GyRCITchJiZYISYbKEI=?=)o =?ISO-2022-JP?B?GyRCIlwbKEI=?=
> =?ISO-2022-JP?B?GyRCIiglUSE8JXMbKEI=?= !!"
> =?ISO-2022-JP?B?GyRCISMhJhsoQg==?= :*: =?ISO-2022-JP?B?GyRCISYbKEI=?=
> =?ISO-2022-JP?B?GyRCISwheRsoQg==?=
>
> I know that the characters " (", ")o ", " !!" and " :*: " should not be
> there (at least, I think they shouldn't), I guess this is done by spam
> bots to confuse spamassassin (not sure, though).
>
> This check in the code (line 842 in camel-mime-utils.c) makes any such
> string become the base64 one. This is of course really not readable for
> normal human beings (although, it depends on what you call a normal
> one).
>
> 842: .. /* quick check to see if this could possibly be a real encoded word */
> 843: .. if (len < 8 || !(in[0] == '=' && in[1] == '?' && in[len-1] == '=' && in[len-2] == '?')) {
> 844: .. d(printf("invalid\n"));
> 845: .. return NULL;
> 846: .. }
>
> When just trying to decode the string, ignoring the check, it does work
> quite well. At least for this case.
>
> I'm attaching yet another patch that ignores this check.
>
>
> On Thu, 2007-10-11 at 11:52 +0200, Philip Van Hoof wrote:
> > In case iconv does not succeed in decoding for example the Subject
> > header, it returns the base64 encoded one. That is is obviously not
> > readable at all. The decoded one after base64 decoding (which did
> > succeed in my test case) or whatever iconv could recover from it, sounds
> > like a better option.
> >
> > This changeset (patch) on camel-mime-utils.c deals with the error
> > situation (in case iconv did not return -1) by returning what(ever)
> > iconv could recover from the string:
> >
> > http://tinymail.org/trac/tinymail/changeset/2830#file2
> >
> > I attached:
> >
> > svn diff libtinymail-camel/camel-lite/camel/camel-mime-utils.c -r 2829 > /home/pvanhoof/diff.diff
> >
> > This is the Subject line of my test target:
> >
> > Subject: =?ISO-2022-JP?B?GyRCM048QiRLOkdEY0Z8NWsbKEI=?=
> >
> > =?ISO-2022-JP?B?GyRCIzJLfDFfIUFGfEonJCQkRyQqRU8kN0NXJDckXiQ5ISMlYSE8GyhC?=
> > =?ISO-2022-JP?B?GyRCJWslXiUsJTglcxsoQg==?=
> >
> >
> > I also opened a bug for this one:
> > http://bugzilla.gnome.org/show_bug.cgi?id=485677
> >
> >
> > _______________________________________________
> > Evolution-hackers mailing list
> > Evolution-hackers gnome org
> > http://mail.gnome.org/mailman/listinfo/evolution-hackers
> _______________________________________________
> Evolution-hackers mailing list
> Evolution-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]