Re: Matchers & X Window
BTW, here is the version of the JVM. [EMAIL PROTECTED]:~$ java -version java version "1.4.1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.1-01) Java HotSpot(TM) Client VM (build Blackdown-1.4.1-01, mixed mode) Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
Looks like something not in the class loader's path. And I have no idea why. I don't have X11 installed on any *nix system. Strictly headless servers. But my guess is that the JVM saw that you have a DISPLAY, and wanted to pop-up a dialog. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matchers & X Window
On Wed, Jun 18, 2003 at 11:19:46PM -0400, Noel J. Bergman wrote: > Looks like something not in the class loader's path. And I have no idea > why. I don't have X11 installed on any *nix system. Strictly headless > servers. Neither I have. > But my guess is that the JVM saw that you have a DISPLAY, and > wanted to pop-up a dialog. It just happened recently; my suspicion is on the texts "generated" by Internet Explorer when you select a page, and then copy & paste from it. The following is an example: --=_NextPart_001_0021_01C33669.8506FEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
RE: Matchers & X Window
Oki, What happened is that the matcher tried to get the content of an attached object (a .gif) to write it decoded to a temp file to have the antivirus later scan it; the javax.mail.internet.MimeBodyPart.getContent(MimeBodyPart), for doing that, tried a path that for any reason threw an exception, which could be ignored (a .gif is not a virus). Which is the Specification-Version and Implementation-Version in the manifest file of the it.praxis.james.jar? Until 1.1.5/15 the exceptions were ignored, and the matcher was simply logging to the mailet.log (look at it and let me know) and not matching; since 1.1.6/16, 2003-06-16, the matcher is logging to mailet.log and then throwing up a MessagingException that embeds the original exception, and JamesSpoolManager until James 2.1.n receives it and sends the message to the error processor. Since James 2.2.0a6 you can trap it in your config.xml coding: virus or virus Strangely, the it.praxis.james.matchers.IsInfected.dumpPart(IsInfected.java:418) entry in the stack trace should be 416 instead of 418. Let me know if it is consistent with your case. Vincenzo > -Original Message- > From: Oki DZ [mailto:[EMAIL PROTECTED] > Sent: giovedi 19 giugno 2003 2.20 > To: James Users List > Subject: Matchers & X Window > > > Hi, > > Recently I installed the IsInfected matcher (from www.mailet.org), and > yesterday had the following error: > 18/06/03 23:01:24 ERROR spoolmanager: Exception in > JamesSpoolManager.run null > java.lang.NoClassDefFoundError > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:140) > at java.awt.Toolkit$2.run(Toolkit.java:712) > at java.security.AccessController.doPrivileged(Native Method) > at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:703) > at > com.sun.mail.handlers.image_gif.getContent(image_gif.java:76) > at > javax.activation.DataSourceDataContentHandler.getContent(DataHandl > er.java:745) > at > javax.activation.DataHandler.getContent(DataHandler.java:501) > at > javax.mail.internet.MimeBodyPart.getContent(MimeBodyPart.java:564) > at > it.praxis.james.matchers.IsInfected.dumpPart(IsInfected.java:418) > at > it.praxis.james.matchers.IsInfected.match(IsInfected.java:250) > at > org.apache.james.transport.LinearProcessor.service(LinearProcessor > .java:369) > at > org.apache.james.transport.JamesSpoolManager.process(JamesSpoolMan > ager.java:440) > at > org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager > .java:370) > at > org.apache.james.util.thread.ExecutableRunnable.execute(Executable > Runnable.java:89) > at > org.apache.james.util.thread.WorkerThread.run(WorkerThread.java:125) > 18/06/03 23:01:24 ERROR spoolmanager: Exception in > JamesSpoolManager.run Can't connect to X11 window server using ':0.0' > as the value of the DISPLAY variable.java.lang.InternalError: Can't > connect to X11 window server using ':0.0' as the value of the DISPLAY > variable. > at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) > at > sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:125) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:140) > at > java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsE > nvironment.java:62) > at sun.awt.motif.MToolkit.(MToolkit.java:72) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:140) > at java.awt.Toolkit$2.run(Toolkit.java:712) > at java.security.AccessController.doPrivileged(Native Method) > at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:703) > at > com.sun.mail.handlers.image_gif.getContent(image_gif.java:76) > at > javax.activation.DataSourceDataContentHandler.getContent(DataHandl > er.java:745) > at > javax.activation.DataHandler.getContent(DataHandler.java:501) > at > javax.mail.internet.MimeBodyPart.getContent(MimeBodyPart.java:564) > at > it.praxis.james.matchers.IsInfected.dumpPart(IsInfected.java:418) > at > it.praxis.james.matchers.IsInfected.match(IsInfected.java:250) > at > org.apache.james.transport.LinearProcessor.service(LinearProcessor > .java:369) > at > org.apache.james.transport.JamesSpoolManager.process(JamesSpoolMan > ager.java:440) > at > org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager > .java:370) > at > org.apache.james.util.thread.ExecutableRunnable.execute(Executable > Runnable.java:89) > at > org.apache.james.util.thread.WorkerThread.run(WorkerThread.java:125) > > Question is, why James asked for a connection to the X window server? > > Thanks in advance, > Oki > > > - > To unsubscribe, e-mail: [EMAIL P
RE: Matchers & X Window
This could be the original reason for the exception being thrown deep in the stack (com.sun.mail.handlers.image_gif.getContent), although the exception should have been in this case a java.io.UnsupportedEncodingException, that is always ignored in the matcher, that simpy continues looking for the next attachment. Vincenzo > -Original Message- > From: Oki DZ [mailto:[EMAIL PROTECTED] > Sent: giovedi 19 giugno 2003 9.34 > To: James Users List > Subject: Re: Matchers & X Window > > > On Wed, Jun 18, 2003 at 11:19:46PM -0400, Noel J. Bergman wrote: > > Looks like something not in the class loader's path. And I have no idea > > why. I don't have X11 installed on any *nix system. Strictly headless > > servers. > > Neither I have. > > > But my guess is that the JVM saw that you have a DISPLAY, and > > wanted to pop-up a dialog. > > It just happened recently; my suspicion is on the texts "generated" by > Internet Explorer when you select a page, and then copy & paste > from it. The following is an example: > --=_NextPart_001_0021_01C33669.8506FEC0 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > Message > http-equiv=3DContent-Type> > >
Re: Matchers & X Window
On Thu, Jun 19, 2003 at 09:51:27AM +0200, Vincenzo Gianferrari Pini wrote: > javax.mail.internet.MimeBodyPart.getContent(MimeBodyPart), for doing > that, tried a path that for any reason threw an exception, which > could be ignored (a .gif is not a virus). It happened twice today; I looked into the attachments, they had images (not sure, jpeg, gif; looks like gif, though). > Which is the Specification-Version and Implementation-Version in the > manifest file of the it.praxis.james.jar? Manifest-Version: 1.0 Created-By: NetBeans IDE Specified-By: it/praxis/james/it.praxis.james.jarContent Specification-Version: 1.1.5 Specification-Vendor: Praxis Calcolo S.p.A. Implementation-Vendor-Id: it.praxis Extension-Name: it.praxis.james Implementation-Version: 15 Implementation-Vendor: Praxis Calcolo S.p.A. > Until 1.1.5/15 the exceptions were ignored, and the matcher was > simply logging to the mailet.log (look at it and let me know) and not > matching; at com.sun.mail.handlers.image_gif.getContent(image_gif.java:76) at javax.activation.DataSourceDataContentHandler.getContent(DataHandler.java:745) at javax.activation.DataHandler.getContent(DataHandler.java:501) at javax.mail.internet.MimeBodyPart.getContent(MimeBodyPart.java:564) at it.praxis.james.matchers.IsInfected.dumpPart(IsInfected.java:418) at it.praxis.james.matchers.IsInfected.match(IsInfected.java:250) Looking at the exceptions, I think it's the MIME parser (ie: MimeBodyPart.getContent()) that had problems, not the matcher. > it and sends the message to the error processor. Since James 2.2.0a6 > you can trap it in your config.xml coding: I'm currently using 2.2.0a4. > Let me know if it is consistent with your case. I hope you'd have time to test that cut & paste from IE (to Outlook), and then send the message via James (and take a look closely at those "3D" characters). Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
> Can't connect to X11 window server using ':0.0' > as the value of the DISPLAY variable.java.lang.InternalError: Can't > connect to X11 window server using ':0.0' as the value of the DISPLAY > variable. > at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) > at > sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment > .java:125) > Running on Solaris right? The Solaris implementation of AWT requires a display device and by default uses DISPLAY 0:0. According to Sun this is not a bug and will not be fixed. Look on Sun's site for various workarounds. Code wise, its best to steer well clear of AWT! -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matchers & X Window
On Thu, Jun 19, 2003 at 10:01:53AM +0200, Vincenzo Gianferrari Pini wrote: > java.io.UnsupportedEncodingException, that is always ignored in the > matcher, that simpy continues looking for the next attachment. So, what is the quick fix? I have uncommented the mailet element that has the matcher. BTW, it's too bad that there are programs that generate non-conforming HTML. Thanks in advance, Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
The other option is to use a virtual X framebuffer (Xvfb) and use that as DISPLAY 0:0 It does work, but it's not very stable > -Original Message- > From: Steve Brewin [mailto:[EMAIL PROTECTED] > Sent: 19 June 2003 09:29 > To: 'James Users List' > Subject: RE: Matchers & X Window > > > > Can't connect to X11 window server using ':0.0' > > as the value of the DISPLAY variable.java.lang.InternalError: Can't > > connect to X11 window server using ':0.0' as the value of > the DISPLAY > > variable. > > at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) > > at > sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment > > .java:125) > > > Running on Solaris right? The Solaris implementation of AWT > requires a display device and by default uses DISPLAY 0:0. > According to Sun this is not a bug and will not be fixed. > > Look on Sun's site for various workarounds. > > Code wise, its best to steer well clear of AWT! > > -- Steve > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
Nothing happens to me (JVM 1.4.0_02 under Win2K). Have you set scanAlways to true or false in your IsInfected invocation? When you get the exception, what happens to the mail message: is it sent to destination or sent to the error processor? Vincenzo > -Original Message- > From: Oki DZ [mailto:[EMAIL PROTECTED] > Sent: giovedi 19 giugno 2003 10.44 > To: James Users List > Subject: Re: Matchers & X Window > > > On Thu, Jun 19, 2003 at 10:01:53AM +0200, Vincenzo Gianferrari Pini wrote: > > java.io.UnsupportedEncodingException, that is always ignored in the > > matcher, that simpy continues looking for the next attachment. > > So, what is the quick fix? I have uncommented the mailet element that > has the matcher. BTW, it's too bad that there are programs that > generate non-conforming HTML. > > Thanks in advance, > Oki > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
Vincenzo You will not get the problem under Win2K, its Solaris specific. Looking at the stack trace, its triggered when... it.praxis.james.matchers.IsInfected.dumpPart(IsInfected.java:418) invokes... javax.mail.internet.MimeBodyPart.getContent(MimeBodyPart.java:564) ...while processing a .gif part. As graphic parts can't carry viruses, is it necessary to get the content at all? Not doing so would circumvent the problem and speed things up too. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
Steve, I know; the logic of the matcher is though to offload any attached part, independently of the filename extension, and have it scanned. This to find also viruses hidden under wrong extensions. It could be *optionally* changed to scan only known file extensions, and would be a good thing to do. I'm waiting to rewrite the matcher as a mailet, as in this case it is easier (more readable) to control using init parameters. This is regarding the cause of the exception being thrown. - There is a second issue: the exception in the release of the matcher used by Oki (it.praxis.james.jar 1.1.5/15) was expected to be caught and ignored, in the last release (it.praxis.james.jar 1.1.6/16) was expected to be thrown up embedded in a MimeMessage and caught by LinearProcessor, thrown up and caught by JamesSpoolManager.process(Mail), that would (up to James 2.2.0a4) be finally caught and the message would have been sent to the "error" processor. In James 2.2.0a5 would have created an endless loop because of a bug in JamesSpoolManager.service(Mail) (introduced by me - so upgrade from 2.2.0a5 to 2.2.0a6 please), and in James 2.2.0a6 would either have been optionally managed by the new config.xml "onException" feature, or been sent to the "error" processor as always. But here comes the new situation: in that specific environment (Solaris etc) a java.lang.InternalError exception has been thrown. It is *not* a subclass of Exception, and as such would have been caught as described, but an *Error*, subclass of *Throwable*. In this case it was caught another level up in the stack - JamesSpoolManager.run() - and the message was thrown away IMO this is an error in sun.awt.X11GraphicsEnvironment.initDisplay(Native Method), that should have thrown any subclass of Exception, (not even a RuntimeException), but never an Error. But we must deal with it, and have the message not being lost. I will continue this discussion posting a reply to another thread already going on in the james-dev list. Vincenzo > -Original Message- > From: Steve Brewin [mailto:[EMAIL PROTECTED] > Sent: giovedi 19 giugno 2003 12.02 > To: 'James Users List' > Subject: RE: Matchers & X Window > > > Vincenzo > > You will not get the problem under Win2K, its Solaris specific. > > Looking at the stack trace, its triggered when... > > it.praxis.james.matchers.IsInfected.dumpPart(IsInfected.java:418) > > invokes... > > javax.mail.internet.MimeBodyPart.getContent(MimeBodyPart.java:564) > > ...while processing a .gif part. > > As graphic parts can't carry viruses, is it necessary to get the > content at > all? Not doing so would circumvent the problem and speed things up too. > > -- Steve > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matchers & X Window
On Thu, Jun 19, 2003 at 10:58:50AM +0200, Vincenzo Gianferrari Pini wrote: > Have you set scanAlways to true or false in your IsInfected invocation? It is set to false. > When you get the exception, what happens to the mail message: is it > sent to destination or sent to the error processor? The message stays in the spool. So, it gets processed again and again, filling up the spoolmanager log. Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matchers & X Window
On Thu, Jun 19, 2003 at 11:01:40AM +0100, Steve Brewin wrote: > invokes... > > javax.mail.internet.MimeBodyPart.getContent(MimeBodyPart.java:564) > > ...while processing a .gif part. > > As graphic parts can't carry viruses, is it necessary to get the content at > all? Not doing so would circumvent the problem and speed things up too. Yes, it would be great if the MIME part dumper could skip the image files; I mean, the matcher skips the files (ie: not putting the part files in the temporary directories) if they are images. Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
> The message stays in the spool. So, it gets processed again and again, > filling up the spoolmanager log. If I have time to do a test build tonight, will you have time to test it? If so, what is your timeframe? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matchers & X Window
On Thu, Jun 19, 2003 at 02:12:49PM +0200, Vincenzo Gianferrari Pini wrote: > This to find also viruses hidden under wrong extensions. It could be > *optionally* changed to scan only known file extensions, and would be > a good thing to do. It would be great if they (file extensions or scan them all) are put on options. > There is a second issue: the exception in the release of the matcher > used by Oki (it.praxis.james.jar 1.1.5/15) was expected to be caught > and ignored, Makes me wonder why the messages stay in the spool. The following is what I have: vscan From vscan. db://james/deadletter/vscan > in the last release (it.praxis.james.jar 1.1.6/16) was > expected to be thrown up embedded in a MimeMessage and caught by > LinearProcessor, thrown up and caught by > JamesSpoolManager.process(Mail), that would (up to James 2.2.0a4) be > finally caught and the message would have been sent to the "error" > processor. I think it's time to upgrade the matcher. > as described, but an *Error*, subclass of *Throwable*. In this case > it was caught another level up in the stack - JamesSpoolManager.run() > - and the message was thrown away Do you think that James should have a better exception handler? I think it should. Well, in my case, the problem caused a filled up log file. Not quite a big deal, but having to clear up the spool when such messages come in, that would be pretty tedious. > IMO this is an error in > sun.awt.X11GraphicsEnvironment.initDisplay(Native Method), that > should have thrown any subclass of Exception, (not even a > RuntimeException), but never an Error. Sun should be noticed I believe; a simple cut & paste, and the JVM gets an internal error is not quite a good view. Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
> > as described, but an *Error*, subclass of *Throwable*. In this case > > it was caught another level up in the stack - JamesSpoolManager.run() > > - and the message was thrown away > Do you think that James should have a better exception handler? If that above were correct, I'd agree. However, that isn't what happens. The exception is caught and the message is not discarded. > Well, in my case, the problem caused a filled up log file. We should identify the cause of that loop. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matchers & X Window
On Thu, Jun 19, 2003 at 09:28:46AM +0100, Steve Brewin wrote: > Running on Solaris right? I'm running Linux. > The Solaris implementation of AWT requires a > display device and by default uses DISPLAY 0:0. According to Sun this is not > a bug and will not be fixed. I see; so it's a feature. I have to install the X server, I guess. Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matchers & X Window
On Thu, Jun 19, 2003 at 08:04:38PM -0400, Noel J. Bergman wrote: > If I have time to do a test build tonight, will you have time to test it? I'm currently going to install the following: Specification-Version: 1.1.6 Implementation-Vendor-Id: it.praxis Extension-Name: it.praxis.james Implementation-Version: 16 > If so, what is your timeframe? According to the timestamp of your messages, there is 11-hour time difference; should have been practical to have the test build. Due to the time diff., your tonight would be my afternoon, correct? I'l be here at work. Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matchers & X Window
On Thu, Jun 19, 2003 at 08:04:38PM -0400, Noel J. Bergman wrote: > If I have time to do a test build tonight, will you have time to test it? I'm not so clear about the test build; is it newer than the 1.1.6? BTW, I think it would be great if the "subject altering" feature is put on options too. I believe that inserting "[no virus]" on each message is a bit superfluous; we already have the X- header line inserted. But somebody might need it, so having an option would be neat. Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
> I'm not so clear about the test build; is it newer than the 1.1.6? Don't confuse James with Vincenzo's anti-virus code. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
> > If I have time to do a test build tonight, will you have time to test it? > I'm currently going to install the following: > Specification-Version: 1.1.6 > Implementation-Vendor-Id: it.praxis That is Vincenzo's personal matcher, and not part of a James distribution. I will update the James test build with the exception handling fixes that were put in today. I'm starting the build now. It should be online in about 30 minutes or so. Look for a7. I'm GMT -5. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matchers & X Window
On Thu, Jun 19, 2003 at 10:59:54PM -0400, Noel J. Bergman wrote: > I'm starting the build now. It should be online in about 30 minutes or so. Downloading... > Look for a7. OK. Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matchers & X Window
On Thu, Jun 19, 2003 at 10:39:38PM -0400, Noel J. Bergman wrote: > Don't confuse James with Vincenzo's anti-virus code. Hey, I have just recently been back to this list, slow down please. Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
> Hey, I have just recently been back to this list, slow down please. :-) To clarify, then. If you download it from here, it is part of James. If you down it from Marco Tedone's Jamailet project, or Vincenzo's personal collection of matchers/mailets, it isn't part of James. Which is not to say that it isn't good code or supported (by them). Point being simply that when we post a new test build of James, that has nothing to do with whether or not third party code is also updated. By the way, v2.2.0a7 is available. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
On Thu, 19 Jun 2003, Noel J. Bergman wrote: > By the way, v2.2.0a7 is available. :-) It's already installed and running. Too bad that I couldn't recreate the problem, so I guess, I'm just going to be waiting for it to happen again, and see the logs. BTW, it's already in the morning I think; time to sleep. (Just in case...) Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
In 1.1.6 it is taken out. > -Original Message- > From: Oki DZ [mailto:[EMAIL PROTECTED] > Sent: venerdi 20 giugno 2003 3.50 > To: James Users List > Subject: Re: Matchers & X Window > > > On Thu, Jun 19, 2003 at 08:04:38PM -0400, Noel J. Bergman wrote: > > If I have time to do a test build tonight, will you have time > to test it? > > I'm not so clear about the test build; is it newer than the 1.1.6? > BTW, I think it would be great if the "subject altering" feature is put > on options too. I believe that inserting "[no virus]" on each message > is a bit superfluous; we already have the X- header line inserted. But > somebody might need it, so having an option would be neat. > > Oki > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matchers & X Window
On Fri, Jun 20, 2003 at 09:06:27AM +0200, Vincenzo Gianferrari Pini wrote: > In 1.1.6 it is taken out. Has just been installed. Oki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
Guys, Using java 1.4 you can set the system property java.awt.Headless=true to allow you to use much, but not all, of AWT in a headless system. I can't remember what doesn't work, I know it's things that aren't appropriate to a headless system like Component and its sub-classes, but awt.Image and all that related drawing functionality works, and so it should. Be warned though, the actual quality of images drawn, particularly font rendering, is noticably not as good, and if you are serious about using graphics contexts there is really no substitute for using a native context, i.e. X on *nix. d. > -Original Message- > From: Oki DZ [mailto:[EMAIL PROTECTED] > Sent: 20 June 2003 02:29 > To: James Users List; [EMAIL PROTECTED] > Subject: Re: Matchers & X Window > > > On Thu, Jun 19, 2003 at 09:28:46AM +0100, Steve Brewin wrote: > > Running on Solaris right? > > I'm running Linux. > > > The Solaris implementation of AWT requires a > > display device and by default uses DISPLAY 0:0. According to > Sun this is not > > a bug and will not be fixed. > > I see; so it's a feature. I have to install the X server, I guess. > > Oki > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
RE: Matchers & X Window
So Sun have moved from their previous dumb position at last. It really should be java.awt.Brainless=false. And yes, the situation applies to all *nix like systems, my mistake. -- Steve > -Original Message- > From: Danny Angus [mailto:[EMAIL PROTECTED] > Sent: 20 June 2003 21:49 > To: James Users List; [EMAIL PROTECTED] Com; [EMAIL PROTECTED] > Subject: RE: Matchers & X Window > > > Guys, > Using java 1.4 you can set the system property > java.awt.Headless=true to allow you to use much, but not all, > of AWT in a headless system. > > I can't remember what doesn't work, I know it's things that > aren't appropriate to a headless system like Component and > its sub-classes, but awt.Image and all that related drawing > functionality works, and so it should. > Be warned though, the actual quality of images drawn, > particularly font rendering, is noticably not as good, and if > you are serious about using graphics contexts there is really > no substitute for using a native context, i.e. X on *nix. > > d. > > > > > -Original Message- > > From: Oki DZ [mailto:[EMAIL PROTECTED] > > Sent: 20 June 2003 02:29 > > To: James Users List; [EMAIL PROTECTED] > > Subject: Re: Matchers & X Window > > > > > > On Thu, Jun 19, 2003 at 09:28:46AM +0100, Steve Brewin wrote: > > > Running on Solaris right? > > > > I'm running Linux. > > > > > The Solaris implementation of AWT requires a > > > display device and by default uses DISPLAY 0:0. According to > > Sun this is not > > > a bug and will not be fixed. > > > > I see; so it's a feature. I have to install the X server, I guess. > > > > Oki > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matchers & X Window
As graphic parts can't carry viruses, is it necessary to get the content at all? Not doing so would circumvent the problem and speed things up too. How do you know it is really a graphic? All you know is that the mime-type description has been set to image/gif. It might have a file-name that ends in ".exe" and then it depends on how the client handles that. /tobe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
> So Sun have moved from their previous dumb position at last. It really > should be java.awt.Brainless=false. And yes, the situation applies to all > *nix like systems, my mistake. Don't be too harsh, I admit that it is odd that they didn't do this sooner, but there are good reasons why not to produce headless graphics. Mostly on the basis that AWT is a GUI toolkit, and a GUI is no use on a headless machine. It seems they accepted the position that the primitives were of value on headless systems manipulating graphics for export to other machines and wrote limited but 100% java implementations for use where native ones weren't available. d.
RE: Matchers & X Window
> > As graphic parts can't carry viruses, is it necessary to get the content at > > all? Not doing so would circumvent the problem and speed things up too. > How do you know it is really a graphic? All you know is that the > mime-type description has been set to image/gif. It might have a > file-name that ends in ".exe" Then why not add an optional check to make sure that the type matches the file extension (if present) based upon a mime type map? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matchers & X Window
As this is Vincezo's code and not James' this rant is just my 2c.. I'm not sure that omitting to scan *any* part is a good idea. I know this isn't apache software, but if it was I'd veto introducing any security loophole based on hearsay or speculation and not published research. Unless you guys know a lot more than me about virus detection I don't see how you can confidently predict what might be carrying a dangerous payload, just because it looks tastes and smells like an image doesn't mean that it is. Isn't that the virus writers idea to slip a payload through your security masquerading as innocent data. Just because *we* can't see what harm it would cause doesn't mean that it really is benign. Surely the reason why virus detection co's recommends you regularly scan everything, Norton AV scans gifs on my hd. I don't pretend to know much about it but you don't have to speculate much either to work out what would happen if binary data could be slipped through in mail as a .gif and somehow activated by some other exploit. If there are issues with certain mime types then that is a bug that needs fixed for security reasons, and not something we should even consider working around if it is going to produce a loophole, however small, in the AV scanning. As far as I can make out it is the attitude in resolving conflict that functionality is more important than security which gives M$ such a hard time. I urge caution. d. > -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: 21 June 2003 15:47 > To: James Users List > Subject: RE: Matchers & X Window > > > > > As graphic parts can't carry viruses, is it necessary to get > the content > at > > > all? Not doing so would circumvent the problem and speed > things up too. > > > How do you know it is really a graphic? All you know is that the > > mime-type description has been set to image/gif. It might have a > > file-name that ends in ".exe" > > Then why not add an optional check to make sure that the type matches the > file extension (if present) based upon a mime type map? > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: Matchers & X Window
Hello Oki I had the same problem developing a WebMail application using javamail the solution is: 1- Unjar the mail.jar file: 2- go to META-INF directory 3- alter ther file mailcap and comment the line image/gif;; x-java-content-handler=com.sun.mail.handlers.image_gif to #image/gif;; x-java-content-handler=com.sun.mail.handlers.image_gif its a good idea to do that to the jpeg line too 4- save the file 5- create the mail.jar again, pay attention to the options that you use to recreate the jar you need the options that use the META-INF directory that you just changed 6- put the mail.jar file back That is it > On Fri, Jun 20, 2003 at 09:06:27AM +0200, Vincenzo Gianferrari Pini wrote: > > In 1.1.6 it is taken out. > > Has just been installed. > > Oki > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Virus scanning (was RE: Matchers & X Window)
Danny, Imagine a .EXE/.COM program that was infected, but didn't carry the actual payload. The payload is in a separate image attachment, hoping to sneak through. The anti-virus scan doesn't see the signature in the executable, doesn't scan the image, the virus boot then loads the payload from the image (don't you hate untrusted code being able to mark pages executable?), and the virus is activated. I would check MIME type, file extension, and most importantly the magic, to make sure that they all match. Any failure to match would be suspect, regardless of what the A/V program says. I think you misunderstood my earlier point. In fairness, it wasn't clear as I had stated it. --- Noel -Original Message- From: Danny Angus [mailto:[EMAIL PROTECTED] Sent: Saturday, June 21, 2003 11:31 To: James Users List Subject: RE: Matchers & X Window As this is Vincezo's code and not James' this rant is just my 2c.. I'm not sure that omitting to scan *any* part is a good idea. I know this isn't apache software, but if it was I'd veto introducing any security loophole based on hearsay or speculation and not published research. Unless you guys know a lot more than me about virus detection I don't see how you can confidently predict what might be carrying a dangerous payload, just because it looks tastes and smells like an image doesn't mean that it is. Isn't that the virus writers idea to slip a payload through your security masquerading as innocent data. Just because *we* can't see what harm it would cause doesn't mean that it really is benign. Surely the reason why virus detection co's recommends you regularly scan everything, Norton AV scans gifs on my hd. I don't pretend to know much about it but you don't have to speculate much either to work out what would happen if binary data could be slipped through in mail as a .gif and somehow activated by some other exploit. If there are issues with certain mime types then that is a bug that needs fixed for security reasons, and not something we should even consider working around if it is going to produce a loophole, however small, in the AV scanning. As far as I can make out it is the attitude in resolving conflict that functionality is more important than security which gives M$ such a hard time. I urge caution. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Virus scanning (was RE: Matchers & X Window)
Noel, Yeah thats exactly the kind of thing, now I think of it. d. > I would check MIME type, file extension, and most importantly the > magic, to > make sure that they all match. Any failure to match would be suspect, > regardless of what the A/V program says. I think you misunderstood my > earlier point. In truth I must have done, I *still* wouldn't like to trust that those things weren't being hijacked though, even the magic. Or I should say that I might take that decision/risk for myself but wouldn't want to release software that contained the assumtion, particularly not anti-virus software. d.
RE: Virus scanning (was RE: Matchers & X Window)
> > I would check MIME type, file extension, and most importantly the > > magic, to make sure that they all match. Any failure to match > > would be suspect, regardless of what the A/V program says. I > > think you misunderstood my earlier point. > In truth I must have done, I *still* wouldn't like to trust that those > things weren't being hijacked though, even the magic. Exactly. So if an attachment has MIME type T then it should have one of the known extensions for MIME type T and it should have the correct magic. That way if an attachment claims to be MIME type "image/jpeg", then it must have an extension of .jpeg, jpg or jpe, AND have a magic value of 0xFFD8FFE0JFIF0x00. If it has a magic value of something else, e.g., 0x7FELF or MZ, then it should be rejected *regardless of the anti-virus scan*. A simple set of magic is: Format Magic PNG 0xD3PNG GIF GIF89a JPEG0xFFD8FFE0JFIF0x00 ELF 0x7FELF Windows .EXEMZ /usr/share/[misc/]magic has a collected set to use with the file command (Windows users, see: http://www.alaska.net/~royce/pub/solaris/MAGIC). The pertinent aspects of the file command could be re-implemented in Java. The purpose would be to prevent someone from slipping an executable by as a non-executable, since most operating systems load by magic, not extension or MIME type. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Virus scanning (was RE: Matchers & X Window)
This "magic number" topic is quite new to me :-) I've looked aroung with Google, but didn't find any link really explaining what it's all about. Do you have any good one to suggest? Thanks, Vincenzo > -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: domenica 22 giugno 2003 1.01 > To: James Users List > Subject: RE: Virus scanning (was RE: Matchers & X Window) > > > > > I would check MIME type, file extension, and most importantly the > > > magic, to make sure that they all match. Any failure to match > > > would be suspect, regardless of what the A/V program says. I > > > think you misunderstood my earlier point. > > > In truth I must have done, I *still* wouldn't like to trust that those > > things weren't being hijacked though, even the magic. > > Exactly. So if an attachment has MIME type T then it should have > one of the > known extensions for MIME type T and it should have the correct > magic. That > way if an attachment claims to be MIME type "image/jpeg", then it > must have > an extension of .jpeg, jpg or jpe, AND have a magic value of > 0xFFD8FFE0JFIF0x00. If it has a magic value of something else, e.g., > 0x7FELF or MZ, then it should be rejected *regardless of the anti-virus > scan*. A simple set of magic is: > > Format Magic > PNG 0xD3PNG > GIF GIF89a > JPEG0xFFD8FFE0JFIF0x00 > ELF 0x7FELF > Windows .EXEMZ > > /usr/share/[misc/]magic has a collected set to use with the file command > (Windows users, see: http://www.alaska.net/~royce/pub/solaris/MAGIC). The > pertinent aspects of the file command could be re-implemented in Java. > > The purpose would be to prevent someone from slipping an > executable by as a > non-executable, since most operating systems load by magic, not > extension or > MIME type. > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Virus scanning (was RE: Matchers & X Window)
Noel J. Bergman wrote: I would check MIME type, file extension, and most importantly the magic, to make sure that they all match. Any failure to match would be suspect, regardless of what the A/V program says. I think you misunderstood my earlier point. In truth I must have done, I *still* wouldn't like to trust that those things weren't being hijacked though, even the magic. Exactly. So if an attachment has MIME type T then it should have one of the known extensions for MIME type T and it should have the correct magic. That way if an attachment claims to be MIME type "image/jpeg", then it must have an extension of .jpeg, jpg or jpe, [snip] Try telling a Mac-user (or a Unix-user) that he *must* put a file-extension on the filename ;-) As far as I know, only Windows and VMS require a file extension in the filename. But I think we are all talking about the same thing, all parts have to be scanned, and a general mailet should not (even cannot) have any knowledge of the specifics of it. /tobe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Virus scanning (was RE: Matchers & X Window)
After reading your http://www.alaska.net/~royce/pub/solaris/MAGIC link I see what it is all about. But is there any formal or informal organization that keeps a list like that up to date? Regarding the discussion on this thread, I think that there are two different issues here: 1) Should a mailet or a matcher like IsInfected scan everything or not. 2) Should it identify "malformations" in a message, including innocent or "guilty" alterations of the extension / MIME type / magic matching, but not excluding other checks. Regarding point 1), as a user I prefer to scan everything, but if the A/V program like MCAfee's Virusscan allows the user to choose whether or not scan everything or just "dangerous" extensions or choosen extensions, it is up to the user. As the matcher/mailet has to offload the attachment to a directory to have the A/V do that, having it look at the extension is only a matter of performance (why offload a JPEG if later on I ask the A/V to ignore it?). Currently IsInfected offloads everything and what to do is left to the command line string passed to the A/V, so I think it is safe and could be made more performing. Point 2) instead should be done in a kind of IsMalformed matcher or CheckCompliance mailet, whose outcome can be used in config.xml to take an appropriate action. As its operation could require an overhead already used in the IsInfected or equivalent matcher or mailet, it is again only a matter of performance doing such work only once while scanning for viruses. Vincenzo > -Original Message- > From: Vincenzo Gianferrari Pini > [mailto:[EMAIL PROTECTED] > Sent: domenica 22 giugno 2003 10.23 > To: James Users List > Subject: RE: Virus scanning (was RE: Matchers & X Window) > > > This "magic number" topic is quite new to me :-) > > I've looked aroung with Google, but didn't find any link really > explaining what it's all about. Do you have any good one to suggest? > > Thanks, > > Vincenzo > > > -Original Message- > > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > > Sent: domenica 22 giugno 2003 1.01 > > To: James Users List > > Subject: RE: Virus scanning (was RE: Matchers & X Window) > > > > > > > > I would check MIME type, file extension, and most importantly the > > > > magic, to make sure that they all match. Any failure to match > > > > would be suspect, regardless of what the A/V program says. I > > > > think you misunderstood my earlier point. > > > > > In truth I must have done, I *still* wouldn't like to trust that those > > > things weren't being hijacked though, even the magic. > > > > Exactly. So if an attachment has MIME type T then it should have > > one of the > > known extensions for MIME type T and it should have the correct > > magic. That > > way if an attachment claims to be MIME type "image/jpeg", then it > > must have > > an extension of .jpeg, jpg or jpe, AND have a magic value of > > 0xFFD8FFE0JFIF0x00. If it has a magic value of something else, e.g., > > 0x7FELF or MZ, then it should be rejected *regardless of the anti-virus > > scan*. A simple set of magic is: > > > > Format Magic > > PNG 0xD3PNG > > GIF GIF89a > > JPEG0xFFD8FFE0JFIF0x00 > > ELF 0x7FELF > > Windows .EXEMZ > > > > /usr/share/[misc/]magic has a collected set to use with the file command > > (Windows users, see: > http://www.alaska.net/~royce/pub/solaris/MAGIC). The > > pertinent aspects of the file command could be re-implemented in Java. > > > > The purpose would be to prevent someone from slipping an > > executable by as a > > non-executable, since most operating systems load by magic, not > > extension or > > MIME type. > > > > --- Noel > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Virus scanning (was RE: Matchers & X Window)
> Try telling a Mac-user (or a Unix-user) that he *must* put a > file-extension on the filename ;-) If there isn't an extension, then it doesn't need to match. :-) > As far as I know, only Windows and VMS require a file extension in the > filename. Actually, that's part of the problem. Although the "front end" of Windows cares about extensions, if I recall correctly, the loader only cares about the file format. For example, you could hack the registry to and create a new executable file extension fairly easily. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Virus scanning (was RE: Matchers & X Window)
> After reading your http://www.alaska.net/~royce/pub/solaris/MAGIC > link I see what it is all about. For those who don't understand, yet, this might help: http://www.halley.cc/ed/linux/newcomer/filename.html > is there any formal or informal organization that keeps a list > like that up to date? Christos Zoulas (christos astron com) is the current maintainer. The latest code is available from ftp://ftp.astron.com/pub/file. > 1) Should a mailet or a matcher like IsInfected scan everything or not. > if the A/V program like MCAfee's Virusscan allows the user to choose > whether or not scan everything or just "dangerous" extensions or > choosen extensions, it is up to the user. Agreed. But as Danny says, if there were a virus scanner as part of the James distribution, the default should be as strict as possible. I suggest that you consider doing the same in your examples, although hopefully your legal liability is limited in Italy. > 2) Should it identify "malformations" in a message, including innocent > or "guilty" alterations of the extension / MIME type / magic matching, > but not excluding other checks. > should be done in a kind of IsMalformed matcher or CheckCompliance mailet And can be done in native Java code, if someone does the port, without having to go through the overhead involved in the external anti-virus scan. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
