Re: Broken images in mails
Adding a point for corrupted images is sounding better and better. I disagree. To check out what happens I converted a JPG picture into a GIF file and sent it to myself. One time I converted it with IrfanView and the second time with PaintShop Pro. Both GIF files had the result giftopnm: EOF or error reading data portion... So I produced a corrupt (?) image, but it was not spam. I have no idea what is wrong and how it could be fixed. Only this: a GIF file seems to be divided into several blocks. Perhaps one block (perhaps the last block) is too short and does not match to its block header (if any exists?). Perhaps it is possible to read out the correct block length from a header and fill the block with 00h to get a valid GIF file. Ah... I just found that there is a program named GIFFIX. I should try it out. -- View this message in context: http://www.nabble.com/Broken-images-in-mails-tf2071676.html#a5978451 Sent from the SpamAssassin - Users forum at Nabble.com.
Re: Broken images in mails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Plenz wrote: Adding a point for corrupted images is sounding better and better. I disagree. To check out what happens I converted a JPG picture into a GIF file and sent it to myself. One time I converted it with IrfanView and the second time with PaintShop Pro. Both GIF files had the result giftopnm: EOF or error reading data portion... So I produced a corrupt (?) image, but it was not spam. I have no idea what is wrong and how it could be fixed. Only this: a GIF file seems to be divided into several blocks. Perhaps one block (perhaps the last block) is too short and does not match to its block header (if any exists?). Perhaps it is possible to read out the correct block length from a header and fill the block with 00h to get a valid GIF file. Ah... I just found that there is a program named GIFFIX. I should try it out. FuzzyOcr will try to invoke Giffix if an image is broken. If giffix does not completely fail, then it will only give a low score for the picture being corrupted. If it isn't able to fix the image at all, then it will give a higher score. Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE7sVkJQIKXnJyDxURAv29AJ9i/LjlLx1me4TZiwRrSuD0KasBYQCfagl2 95Nt5kXjo3v+WO7i2jngnCk= =XN3X -END PGP SIGNATURE-
Discourage broken content (was: Broken images in mails)
--On Friday, August 25, 2006 12:05 AM -0700 Plenz [EMAIL PROTECTED] wrote: I disagree. To check out what happens I converted a JPG picture into a GIF file and sent it to myself. One time I converted it with IrfanView and the second time with PaintShop Pro. Both GIF files had the result giftopnm: EOF or error reading data portion... So I produced a corrupt (?) image, but it was not spam. I think we should discourage all broken content in email and on the web. At one time we could assume that broken content was an honest mistake and make an attempt at fixing it. But with the rise of malicious content attempting to exploit bugs in content handlers (like overruns in image libraries), we should simply reject anything that fails to pass validation, on the assumption that's it out to get us. This includes not just broken images but also broken HTML, which is so commonly used to conceal spam. We need to stop giving a free pass to broken content creation software just because it's popular. When someone sends you broken content, you should react the same way you would if they sent you documents on dirt-smeared paper. Stop letting your emperor walk around naked.
Re: Discourage broken content (was: Broken images in mails)
On Friday 25 August 2006 11:20, Kenneth Porter wrote: We need to stop giving a free pass to broken content creation software just because it's popular. When someone sends you broken content, you should react the same way you would if they sent you documents on dirt-smeared paper. Stop letting your emperor walk around naked. Actually there is very little broken content IMAGE software out there in any modern mailer, even microsoft crapware does not break images. The image corruption is intentional, and may be malicious (not JUST spam). So I agree with you there. Broken html is another issue, because there is broken, and there is simply lame (lazy) html. Which of the several versions of the standards are you going to impose? The agreed upon standards? or the defacto ones? -- _ John Andersen pgpqrnYNR3Yfg.pgp Description: PGP signature
RE: Discourage broken content (was: Broken images in mails)
I think we should discourage all broken content in email and on the web. But who is to decide what is broken. Just because giftext/giffix/gocr/etc. fail to parse it, doesn't necessarily mean it's broken. The software may be buggy (note the patches on the download page needed to make these utilities work properly with legitimate images). Howard
Re: Discourage broken content (was: Broken images in mails)
On Friday 25 August 2006 11:33, Kash, Howard (Civ, ARL/CISD) wrote: I think we should discourage all broken content in email and on the web. But who is to decide what is broken. Just because giftext/giffix/gocr/etc. fail to parse it, doesn't necessarily mean it's broken. Yes, by definition, it DOES mean its broken. -- _ John Andersen pgpqkudEyt5sv.pgp Description: PGP signature
RE: Discourage broken content (was: Broken images in mails)
Yes, by definition, it DOES mean its broken. So when then giftext author made an error in assuming every image would have a global colormap, he redefined the GIF specification so that any that don't are no longer valid? Howard
Discourage broken configs (was: Discourage broken content (was: Broken images in mails)
On 25-Aug-06, at 3:20 PM, Kenneth Porter wrote: --On Friday, August 25, 2006 12:05 AM -0700 Plenz [EMAIL PROTECTED] online.de wrote: I disagree. To check out what happens I converted a JPG picture into a GIF file and sent it to myself. One time I converted it with IrfanView and the second time with PaintShop Pro. Both GIF files had the result giftopnm: EOF or error reading data portion... So I produced a corrupt (?) image, but it was not spam. I think we should discourage all broken content in email and on the web. At one time we could assume that broken content was an honest mistake and make an attempt at fixing it. But with the rise of malicious content attempting to exploit bugs in content handlers (like overruns in image libraries), we should simply reject anything that fails to pass validation, on the assumption that's it out to get us. This includes not just broken images but also broken HTML, which is so commonly used to conceal spam. We need to stop giving a free pass to broken content creation software just because it's popular. When someone sends you broken content, you should react the same way you would if they sent you documents on dirt-smeared paper. Stop letting your emperor walk around naked. I would, and do, go even further and discourage broken Server/DNS configurations. I've downright had it with all this crap hitting my server. I'm now doing checks right at the MTA and if the sending server fails any hostname, HELO, domain name, SPF etc., checks they don't even get to my content filters. The biggest thing we have in our favour is that the spambots are mostly broken or running on machines that will fail most of these checks. For legitimate email, I send an message to the admins responsible for the broken configs with my log entries explaining why their email was blocked. It's up to them to fix it if they want to send email my way. I know this isn't practical in an environment where you're administering hundreds or thousands of accounts, and I feel your pain, but I think it's time we encouraged proper and correct server and DNS configurations so we can use all the tools at our disposal to our advantage. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740
Re: Broken images in mails
On Fri, 25 Aug 2006, Plenz wrote: Adding a point for corrupted images is sounding better and better. I disagree. To check out what happens I converted a JPG picture into a GIF file and sent it to myself. One time I converted it with IrfanView and the second time with PaintShop Pro. Both GIF files had the result giftopnm: EOF or error reading data portion... So I produced a corrupt (?) image, but it was not spam. I had similar results. As soon as I installed FuzzyOcr, I saw a whole series of legit messages the log going back and forth between two users, all getting FUZZY_OCR_CORRUPT_IMG. I didn't look at the messages, but one assumes they were somebody's e-mail signature with a GIF in it or something. Ideally, users wouldn't include corrupt images in messages, but it does happen, so I thought a score of 3.0 for FUZZY_OCR_CORRUPT_IMG was too harsh. I set it to 2.0 at my site. FuzzyOcr is still catching the bad stuff, and I feel less nervous that a minor file format infraction might cause false positives. Also, there is the small matter that just because giftopnm doesn't recognize it doesn't mean it's invalid. Are we sure that giftopnm recognizes 100% of all possible items that occur in GIF files? - Logan
Re: Discourage broken content (was: Broken images in mails)
On Friday 25 August 2006 11:40, Kash, Howard (Civ, ARL/CISD) wrote: Yes, by definition, it DOES mean its broken. So when then giftext author made an error in assuming every image would have a global colormap, he redefined the GIF specification so that any that don't are no longer valid? One presumes adherence to the standard. If the image does not adhere to the standards for gif then it is broken. These are easily seen to be broken with any standard gif viewer, usually with trash along the bottom edge. You are addressing a temporal problem, in a beta product, and using that developmental shortcoming as a justification for allowing broken image in mail. -- _ John Andersen pgpbYP09mKPsY.pgp Description: PGP signature
Re: Discourage broken configs (was: Discourage broken content (was: Broken images in mails)
From: Gino Cerullo [EMAIL PROTECTED]
On 25-Aug-06, at 3:20 PM, Kenneth Porter wrote:
--On Friday, August 25, 2006 12:05 AM -0700 Plenz [EMAIL PROTECTED]
online.de wrote:
I disagree. To check out what happens I converted a JPG picture
into a GIF
file
and sent it to myself. One time I converted it with IrfanView and the
second time with PaintShop Pro. Both GIF files had the result
giftopnm: EOF or error reading data portion... So I produced a
corrupt
(?) image, but it was not spam.
I think we should discourage all broken content in email and on the
web.
At one time we could assume that broken content was an honest
mistake and make an attempt at fixing it. But with the rise of
malicious content attempting to exploit bugs in content handlers
(like overruns in image libraries), we should simply reject
anything that fails to pass validation, on the assumption that's it
out to get us.
This includes not just broken images but also broken HTML, which is
so commonly used to conceal spam.
We need to stop giving a free pass to broken content creation
software just because it's popular. When someone sends you broken
content, you should react the same way you would if they sent you
documents on dirt-smeared paper. Stop letting your emperor walk
around naked.
I would, and do, go even further and discourage broken Server/DNS
configurations.
I've downright had it with all this crap hitting my server.
I'm now doing checks right at the MTA and if the sending server fails
any hostname, HELO, domain name, SPF etc., checks they don't even get
to my content filters. The biggest thing we have in our favour is
that the spambots are mostly broken or running on machines that will
fail most of these checks.
For legitimate email, I send an message to the admins responsible for
the broken configs with my log entries explaining why their email was
blocked. It's up to them to fix it if they want to send email my way.
I know this isn't practical in an environment where you're
administering hundreds or thousands of accounts, and I feel your
pain, but I think it's time we encouraged proper and correct server
and DNS configurations so we can use all the tools at our disposal to
our advantage.
I am with you right up until the moment my head says, Who defines
proper content? Then I come back to email format rwars and say
Fahgeddit.
One man's cilantro spice is another man's intolerable bitterness.
Do we try to force the bitterness on the other man or do we try to
accommodate? Who gets to define how much we must tolerate? It's
purely an rwar issue when you apply this to formatting wars. It is
best to do what YOU will and not get evangelistic about it. If you
do characters like me get contrary.
{^_^} Joanne, The Stubborn
Re: Discourage broken configs (was: Discourage broken content (was: Broken images in mails)
I think we should discourage all broken content in email and on the
web.
At one time we could assume that broken content was an honest
mistake and make an attempt at fixing it. But with the rise of
malicious content attempting to exploit bugs in content handlers
(like overruns in image libraries), we should simply reject
anything that fails to pass validation, on the assumption that's it
out to get us.
This includes not just broken images but also broken HTML, which is
so commonly used to conceal spam.
We need to stop giving a free pass to broken content creation
software just because it's popular. When someone sends you broken
content, you should react the same way you would if they sent you
documents on dirt-smeared paper. Stop letting your emperor walk
around naked.
I would, and do, go even further and discourage broken Server/DNS
configurations.
I've downright had it with all this crap hitting my server.
I'm now doing checks right at the MTA and if the sending server fails
any hostname, HELO, domain name, SPF etc., checks they don't even get
to my content filters. The biggest thing we have in our favour is
that the spambots are mostly broken or running on machines that will
fail most of these checks.
For legitimate email, I send an message to the admins responsible for
the broken configs with my log entries explaining why their email was
blocked. It's up to them to fix it if they want to send email my way.
I know this isn't practical in an environment where you're
administering hundreds or thousands of accounts, and I feel your
pain, but I think it's time we encouraged proper and correct server
and DNS configurations so we can use all the tools at our disposal to
our advantage.
I am with you right up until the moment my head says, Who defines
proper content? Then I come back to email format rwars and say
Fahgeddit.
One man's cilantro spice is another man's intolerable bitterness.
Do we try to force the bitterness on the other man or do we try to
accommodate? Who gets to define how much we must tolerate? It's
purely an rwar issue when you apply this to formatting wars. It is
best to do what YOU will and not get evangelistic about it. If you
do characters like me get contrary.
{^_^} Joanne, The Stubborn
A great and a wonderful idea until you have users paying you for
e-mail service and you start bouncing their mails because someone or
some program has a bug in it that they have no control over and they
lose that email from their employer, client or whatever and I can
assure you that they will find another provider right quick.
===[George R. Kasica]===+1 262 677 0766
President +1 206 374 6482 FAX
Netwrx Consulting Inc. Jackson, WI USA
http://www.netwrx1.com
[EMAIL PROTECTED]
ICQ #12862186
Re: Broken images in mails
On Wed, 9 Aug 2006, decoder wrote: Hrm. How much, if any, image processing is duplicated across the imageinfo/OCR/fuzzyOCR plugins? It might be a benefit to merge them and expose some options to control which tests are performed. Well, for example with gif, FuzzyOCR first checks what file type it has with magic bytes. So it can easily say for example the content type does not match the file format, lets say if the file format is gif, but content type says jpeg. This is important so you dont use giftopnm on a jpeg or vica-versa. Secondly, FuzzyOCR invokes giftopnm, if the gif is corrupted, this program fails. The plugin could therefore catch this error and knows then that the gif is not a proper gif. Currently, before using giftopnm, giffix is used to fix any broken gif files, it also reports errors to STDERR. The plugin could catch these as well to know if the gif was faulty or not. So the plugin would know if either the content-type doesn't match, or if the picture is corrupted somehow, from the helper program outputs. Could the image-size calculation stuff from the ImageInfo plugin be merged into this? I was envisioning all of those tests in a single plugin, with configuration options to control whether or not the OCR itself (fuzzy or not) takes place and whether the size analysis takes place and... There are lots of analyses that can be made of images; should there be multiple plugins, or should there be a more generic ImageAnalysis plugin (that perhaps has its own support for plugins...)? How many times do you want to do the image extract/paste-together/convert processing for a given message? -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The difference is that Unix has had thirty years of technical types demanding basic functionality of it. And the Macintosh has had fifteen years of interface fascist users shaping its progress. Windows has the hairpin turns of the Microsoft marketing machine and that's all.-- Red Drag Diva ---
Re: Broken images in mails
On Wed, 9 Aug 2006, John D. Hardin wrote: Could the image-size calculation stuff from the ImageInfo plugin be merged into this? I was envisioning all of those tests in a single plugin, with configuration options to control whether or not the OCR itself (fuzzy or not) takes place and whether the size analysis takes place and... There are lots of analyses that can be made of images; should there be multiple plugins, or should there be a more generic ImageAnalysis plugin (that perhaps has its own support for plugins...)? How many times do you want to do the image extract/paste-together/convert processing for a given message? Is there a way there could be one plugin to do the image decoding and N plugins to do various forms of analysis? That seems like the cleanest way. Of course, this presupposes that all the different analysis plugins need access to the same set of data. And it presupposes that one plugin can create data for another plugin to use. I don't know that either of those is necessarily true. - Logan
Re: Broken images in mails
Logan Shaw wrote: On Wed, 9 Aug 2006, John D. Hardin wrote: Could the image-size calculation stuff from the ImageInfo plugin be merged into this? I was envisioning all of those tests in a single plugin, with configuration options to control whether or not the OCR itself (fuzzy or not) takes place and whether the size analysis takes place and... There are lots of analyses that can be made of images; should there be multiple plugins, or should there be a more generic ImageAnalysis plugin (that perhaps has its own support for plugins...)? How many times do you want to do the image extract/paste-together/convert processing for a given message? Is there a way there could be one plugin to do the image decoding and N plugins to do various forms of analysis? That seems like the cleanest way. Of course, this presupposes that all the different analysis plugins need access to the same set of data. And it presupposes that one plugin can create data for another plugin to use. I don't know that either of those is necessarily true. Have you noticed how impressively short both of this plugins are? The only significant function they have in common is decoding the image attachments which is already handled by SA core modules. I'm assuming that SA only decodes an attachment once and reuses it for any plugin that needs it.
Re: Broken images in mails
On Wed, Aug 09, 2006 at 04:42:15PM -0500, Stuart Johnston wrote: which is already handled by SA core modules. I'm assuming that SA only decodes an attachment once and reuses it for any plugin that needs it. Yes -- the decode run happens once and the result is stored in the tree node/object which future decode calls will simply return. Also, SA only decodes the attachment if it's requested, so things that aren't ever checked, like application/* are never decoded. :) -- Randomly Generated Tagline: M: Can anyone tell us the lesson that has been learned here? S: Yes Master, not a single one of us could defeat you. M: You gain wisdom child ... - The Frantics pgpsKG6x9PzLb.pgp Description: PGP signature
Re: Broken images in mails
On Wed, 9 Aug 2006, Theo Van Dinter wrote: On Wed, Aug 09, 2006 at 04:42:15PM -0500, Stuart Johnston wrote: which is already handled by SA core modules. I'm assuming that SA only decodes an attachment once and reuses it for any plugin that needs it. Yes -- the decode run happens once and the result is stored in the tree node/object which future decode calls will simply return. Also, SA only decodes the attachment if it's requested, so things that aren't ever checked, like application/* are never decoded. :) Actually, when I suggested the idea of splitting image plugins into 1 decoder and N analyzers, I was referring to the image decoding (from GIF, JPEG, PNG, etc. into raw pixels) rather than the MIME decoding (from MIME message part into GIF, JPEG, PNG, etc.). Of course, this idea could be extended into other file types that might be converted, as well. Since there have been some spams with the real payload inside an MS Word attachment, it might be worthwhile to run an MS Word to text converter inside SpamAssassin once, then run various plugins to do their own analysis of the decoded content (for example, check it against Bayes, check for certain keywords, etc.). - Logan
Re: Broken images in mails
On Wed, 9 Aug 2006, Logan Shaw wrote: On Wed, 9 Aug 2006, Theo Van Dinter wrote: On Wed, Aug 09, 2006 at 04:42:15PM -0500, Stuart Johnston wrote: which is already handled by SA core modules. I'm assuming that SA only decodes an attachment once and reuses it for any plugin that needs it. Yes -- the decode run happens once and the result is stored in the tree node/object which future decode calls will simply return. Also, SA only decodes the attachment if it's requested, so things that aren't ever checked, like application/* are never decoded. :) Actually, when I suggested the idea of splitting image plugins into 1 decoder and N analyzers, I was referring to the image decoding (from GIF, JPEG, PNG, etc. into raw pixels) rather than the MIME decoding (from MIME message part into GIF, JPEG, PNG, etc.). aolMe, too./aol The ImageAnalysis framework would check the images for corrupt native formats, convert them to a raw format, (perhaps) paste them together if needed, and provide the filenames to the custom analysis plugins (e.g. OCR). Of course, this idea could be extended into other file types that might be converted, as well. Since there have been some spams with the real payload inside an MS Word attachment, it might be worthwhile to run an MS Word to text converter inside SpamAssassin once, then run various plugins to do their own analysis of the decoded content (for example, check it against Bayes, check for certain keywords, etc.). I'm smelling a generic attachment analysis framework here, with switching possibly based on MIME types? (One of the analysis steps could be confirming that the actual file type matches the MIME type...) register_analysis_plugin IMAGE/* ImageAnalysis.pm register_analysis_plugin APPLICATION/X-MSWORD WorddocAnalysis.pm analysis_plugin_option ImageAnalysis.pm ENABLE_FUZZY_OCR analysis_plugin_option ImageAnalysis.pm ENABLE_SIZE_CHECKING and so forth... -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The difference is that Unix has had thirty years of technical types demanding basic functionality of it. And the Macintosh has had fifteen years of interface fascist users shaping its progress. Windows has the hairpin turns of the Microsoft marketing machine and that's all.-- Red Drag Diva ---
Broken images in mails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello there, as I recently mentioned in the FuzzyOcr Thread, I found quite a lot mails that contain broken or corrupted gifs. I found one type that lets convert calculate extremely long and then fails, but with giftopnm it works after it spits out some errors. The other type doesn't work with both, they both say the image is corrupted and don't convert anything, but my browser is fully able to view it. (And yes, I made sure these are really gifs, file says so) Here's an example: samples # giftopnm viagra2.gif giftopnm: EOF or error reading data portion of 194 byte DataBlock from file samples # convert viagra2.gif pnm:- convert: Corrupt image `viagra2.gif'. samples # file viagra2.gif viagra2.gif: GIF image data, version 89a, 353 x 262 But I can view it perfectly. Does anyone know what this could be caused by and a tool which can reliably convert these to pnm? Another question that I would have in mind is, if that was intended to happen... Best regards Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE2F6ZJQIKXnJyDxURAlAqAJwPEvWVasgljWXaXSMty79MmSEMcwCbBp2I DxU9fM/qCWQPgMVp/2lGSXI= =AZAd -END PGP SIGNATURE-
Re: Broken images in mails
--On Tuesday, August 08, 2006 11:51 AM +0200 decoder [EMAIL PROTECTED] wrote: as I recently mentioned in the FuzzyOcr Thread, I found quite a lot mails that contain broken or corrupted gifs. Until we have a better answer, I'd reject anything with an unrecognizable format. It might be an attempt to exploit an overflow bug in an older copy of IE. Similarly, I'm a fan of validating HTML and rejecting broken stuff, but that would reject a lot of stuff created by MS software. OTOH
Re: Broken images in mails
On Tuesday 08 August 2006 01:51, decoder wrote: But I can view it perfectly. Does anyone know what this could be caused by and a tool which can reliably convert these to pnm? Another question that I would have in mind is, if that was intended to happen... Best regards Chris Are you sure its perfect? I've seem many of these where they are intentionally corrupting the last portion (bottom edge) of the image so as to avoid simple size or hashing techniques. The ones I saw were the same image visually, but the bottom edge was intentionally corrupted beginning at different offsets. -- _ John Andersen pgpyRtbVYwjpH.pgp Description: PGP signature
Re: Broken images in mails
On Tue, 8 Aug 2006, John Andersen wrote: Are you sure its perfect? I've seem many of these where they are intentionally corrupting the last portion (bottom edge) of the image so as to avoid simple size or hashing techniques. The ones I saw were the same image visually, but the bottom edge was intentionally corrupted beginning at different offsets. Adding a point for corrupted images is sounding better and better. -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- If someone has a gun and is trying to kill you, it would be reasonable to shoot back with your own gun. -- the Dalai Lama, May 15, 2001 ---
Re: Broken images in mails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John D. Hardin wrote: On Tue, 8 Aug 2006, John Andersen wrote: Are you sure its perfect? I've seem many of these where they are intentionally corrupting the last portion (bottom edge) of the image so as to avoid simple size or hashing techniques. The ones I saw were the same image visually, but the bottom edge was intentionally corrupted beginning at different offsets. Adding a point for corrupted images is sounding better and better. Definetly a good idea... I will try to add this feature in the next release of FuzzyOcr (v.2.1) then. I am also thinking about scanning all attachments, no matter if the content type specifies image or not (in the current version 2.0, only attachments that have image in their content type are scanned with format auto-detection) because for example outlook always displays the image, no matter if the content type is what/ever or image/blah... :( Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE2Q2dJQIKXnJyDxURAu7kAKDJLt19AywH0aZSbHNRKpLYvgtpCgCfWG+8 EhKhLMk12XQ8cC8vOJy6FY0= =/GO+ -END PGP SIGNATURE-
Re: Broken images in mails
On Wed, 9 Aug 2006, decoder wrote: John D. Hardin wrote: Adding a point for corrupted images is sounding better and better. Definetly a good idea... I will try to add this feature in the next release of FuzzyOcr (v.2.1) then. I'd suggest a better place would be the imageinfo plugin - corrupt/clean has little to do with whether or not the image contains text, and what that text is. -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- If someone has a gun and is trying to kill you, it would be reasonable to shoot back with your own gun. -- the Dalai Lama, May 15, 2001 ---
Re: Broken images in mails
--On Wednesday, August 09, 2006 12:18 AM +0200 decoder [EMAIL PROTECTED] wrote: I am also thinking about scanning all attachments, no matter if the content type specifies image or not (in the current version 2.0, only attachments that have image in their content type are scanned with format auto-detection) because for example outlook always displays the image, no matter if the content type is what/ever or image/blah... :( Do any legitimate senders do this? Perhaps we can throw extra points at misleading content types.
