You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Oki DZ <ok...@pindad.com> on 2003/06/19 02:19:40 UTC
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(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)
at
org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:369)
at
org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:440)
at
org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:370)
at
org.apache.james.util.thread.ExecutableRunnable.execute(ExecutableRunnable.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.<clinit>(X11GraphicsEnvironment.java:125)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:140)
at
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:62)
at sun.awt.motif.MToolkit.<clinit>(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(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)
at
org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:369)
at
org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:440)
at
org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:370)
at
org.apache.james.util.thread.ExecutableRunnable.execute(ExecutableRunnable.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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
BTW, here is the version of the JVM.
okidz@bdg:~$ 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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Cesar Bonadio <bo...@picture.com.br>.
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: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re[2]: Matchers & X Window
Posted by james-subscribe <ja...@youwinit.com.ua>.
Hello Oki,
As far as i understand the problem is that javamail probably uses java.awt.Image...
In this case java VM tries to load libawt.so and this causes loading libX.
There are a lot of information about it on Suns forums but the most recent solution is
to run java in headless mode( available since v 1.4 )
Friday, June 20, 2003, 9:16:43 AM, you wrote:
OD> On Thu, 19 Jun 2003, Noel J. Bergman wrote:
>> By the way, v2.2.0a7 is available. :-)
OD> It's already installed and running. Too bad that I couldn't recreate the
OD> problem, so I guess, I'm just going to be waiting for it to happen again,
OD> and see the logs.
OD> BTW, it's already in the morning I think; time to sleep. (Just in case...)
OD> Oki
OD> ---------------------------------------------------------------------
OD> To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
OD> For additional commands, e-mail: james-user-help@jakarta.apache.org
--
Best regards,
james-subscribe mailto:james-subscribe@youwinit.com.ua
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Exception handling in James (was also "Matchers & X Window")
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Oki,
here is a summary of the situation.
IsInfected is part of a small set of matchers and mailets that either I wrote or someone else wrote and I modified/extended and, coming from other contributions, I considered correct and useful to make available. IsInfected in particular has been first written by Cesar Bonadio.
It is *not* part of the James project, although it could become in the future if of interest and agreed (and code cleaned). Because of this it is unrelated to James distributions and versions.
I'm now also helping in the James project, and I've become "sensible" to the issue of what and where catching Throwable-s. So I have made some small enhancements and fixes to James in this direction, starting from James version 2.2.0a5.
So, *just by chance being in those two sides*, it happens that I changed IsInfected from 1.1.5/15 to 1.1.6/16 to be in sync with the changes I introduced to James and available in James 2.2.0a5.
=============================================================================================
Now, a summary to the changes in James related to exception management, as could be of interest to all users. They were essentially a new feature, that Noel and I call "onException [control]" in other threads in james-dev, and a fix to a pre-existing situation that arose yesterday from your problem.
To recall (for the non Java programmers), here is the class hierarchy of Trowable:
Throwable
Exception
...
MessagingException
...
RuntimeException
...
Error
...
The major distinctions are (quoting from Sun Javadoc):
1) "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions."
A standalone program should just not catch it and terminate. A server application like James should catch it and, if "fatal" (i.e. of general scope and not just related to the processing of a single Mail object for example) should terminate, otherwise should recover as possible (for instance sending the offending/offended Mail object to the error processor) and continue.
2) "The class Exception and its subclasses are a form of Throwable that indicates conditions that a reasonable application might want to catch."
With the exclusion of RuntimeException-s (see below), an Exception arise when an un-anticipated "event", caused by "external agents" (like IO error) occurs that can and should be managed somewhere in the code stack.
The "best practice" should consist in having the code catch the exception as down as possible in the code stack and take an appropriate action as specifically as possible. Such action can also consist, if appropriate, in rethrowing up the exception or in embedding in a new exception and throw it. The java compiler helps, compelling a class either to catch an exception if thrown from below (unless it is a RuntimeException) or to declare a "throws".
3) "RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine. A method is not required to declare in its throws clause any subclasses of RuntimeException that might be thrown during the execution of the method but not caught."
It looks similar to Error above, but the key point here is that a RuntimeException is (or should be) a programming error: something that can be fixed in the code, as for example an IndexOutOfBoundsException that appropriate controls in the code can avoid.
4) MessagingException is "The base class for all exceptions thrown by the Messaging classes."
Very generic.
The key point for us is that the Matcher and the Mailet interfaces declare respectively the match(Mail) and the service(Mail) methods as throwing MessagingException. So it is the communication channel for exceptions between mailets and matchers and the rest of James.
Now, talking about matchers and mailets, there are three types of people involved in coding in a James environment: (i) the James developers, (ii) the Matcher and Mailet developers, and (iii) the administrators that deploy a server and maintain their own config.xml files.
The James developers, taken in a broad sense, can be considered as a coordinated group of people, and we can consider exception management in the James code as following the same guidelines (to improve/enforce/cleanup perhaps).
The James code invokes matchers and mailets, that can be foreign code. So James must protect itself from Throwable-s arising from below, from code that not necessarily follows all the rules. Each matcher or mailet follows its own exception management rules (those in the James distribution should be coherent with the rest of the James code.
At this level the following is anyhow always true: as said before, the Matcher and the Mailet interfaces declare respectively the match(Mail) and the service(Mail) methods as throwing MessagingException. As a consequence, when a matcher or a mailet gets an exception while processing a Mail object (not during initialization - this is another story) it can do the following things: if the exception is a MessagingException it can either catch it or let it flow up (to LinearProcessor, part of James' spool management); if the exception is any other Exception (but not some kind of RuntimeException), the java compiler forces the programmer either to catch it somewhere and take the appropriate action, or to embed in a new MessagingExceptionand and throw it up.
In the middle stays the administrator of the James server instance deployed, that coding his config.xml decides to use or not a specific matcher or mailet, and is coding a kind of "program" using <mailet match="..." class="...">, equivalent to if (...) {...}.
He is though, before James 2.2.0a5, unable to "code" its own exception management, and he may need to, as he is the only person knowing if matching because of an exception is bad or not etc. In 2.2.0a5 we added a mechanism (the "onException") that allows him to do that, optionally coding (the attribute values are case insensitive):
<mailet match="..." class="..." [onMatchException="{noMatch|matchAll|error|<aProcessorName>}"] [onMailetException="{ignore|error|<aProcessorName>}"]>
The default is equivalent to code on{Match|Mailet}Exception="error", that means sending to the error processor, as before.
This config.xml "code" catches any MessagingException thrown by the underlying matcher or mailet (that may embed any Throwable catched below), but if a RuntimeException or an Error flows up it will not be considered here. By the way, it is an open issue whether to catch here also RuntimeException or even Throwable: any comments?
A possible endless loop was introduced here, fixed in 2.2.0a6 (see http://archives.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache.org&msgId=739634). So don't use 2.2.0a5!.
An example taken from my system (using James 2.2.0a7 and it.praxis.james.jar 1.1.6/16) is the following:
<!-- Check for viruses -->
<mailet match='IsInfected="C:\Program Files\Common Files\Network Associates\VirusScan Engine\4.0.xx\scan" /analyze /noboot /nomem /noexpire /unzip /report %reportFile% %targetDir%\*.tt, D:\Viruscheck, false, 13' class="ToProcessor" onMatchException="noMatch">
<processor> virus </processor>
</mailet>
<!-- Check attachment extensions for possible viruses -->
<mailet match="AttachmentFileNameIs=*.exe,*.com,*.bat,*.pif,*.scr,*.vbs,*.eml,*.avi,*.mp3,*.mpeg,*.shs" class="Bounce" onMatchException="noMatch">
<inline>heads</inline>
<attachment>none</attachment>
<passThrough>false</passThrough>
<prefix>[REJECTED]</prefix>
<notice>
The Security Policy of XYZ Corp. does not allow to forward messages containing attachments having any of the extensions .exe, .com, .bat, .pif, .scr, .vbs, .eml, .avi, .mp3, .mpeg, .shs, therefore your message has been rejected.
Please don't reply to this e-mail as it has been automatically sent by the antivirus system.
Regards, Postmaster xyz.com
-----------------------------
</notice>
</mailet>
The onMatchException attributes were coded because some malformed messages, typical of viruses, are causing some javax methods to throw exceptions; my choice was to not match and continue, but it could be done differently, perhaps the first one using noMatch, and the second one sending to a special "may-contain-executables" processor, that bounces back a less "resolute" message.
Now, what happens if a RuntimeError flows up? It will not be catched at config.xml level, but JamesSpoolManager.process(MailImpl mail) will catch it and have the Mail object sent to the error processor.
Finally, what happens if an Error flows up? Before James 2.2.0a7, it was catched a level up in the stack, in JamesSpoolManager.run(), that was reporting the exception and leaving it in the spool (I said yesterday erroneously "lost", but is a kind of). This was a pre-existing problem.
This is what was happening to you.
In James 2.2.0a7 JamesSpoolManager.process(MailImpl mail) will catch any Throwable, and have the Mail object sent to the error processor.
JamesSpoolManager.run() still can catch Throwables that flow up from other spool related operations, but will no longer receive from below any Throwable originating from matchers or mailets.
This has been a long "summary", but I wrote it to fix some ideas, thinking that it can be useful to other James users (Marco, it may answer your questions about the "onException" control).
=============================================================================================
The IsInfected antivirus matcher and the JDBCBayesianAnalysis mailet in it.praxis.james.jar 1.1.6/16 just take advantage of this new onException feature.
Why you, Oki, got the java.lang.InternalError thrown up by the IsInfected matcher is another story, related to Sun code.
And whether or not IsInfected should try to scan "innocent" attachments like .gif files is still another story: could be an option or not to look for viruses hidden in "innocent" attachments, but has nothing to do with James development and support.
I hope that all this helps.
Vincenzo
> -----Original Message-----
> From: Oki DZ [mailto:okidz@pindad.com]
> Sent: venerdi 20 giugno 2003 8.17
> To: James Users List
> Subject: 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.
>
Based on what I said before, you could still get the exception, but the message would go to the "error" processor.
> BTW, it's already in the morning I think; time to sleep. (Just in case...)
>
> Oki
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
In 1.1.6 it is taken out.
> -----Original Message-----
> From: Oki DZ [mailto:okidz@pindad.com]
> 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: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > 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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Virus scanning (was RE: Matchers & X Window)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Virus scanning (was RE: Matchers & X Window)
Posted by tobe <to...@swipnet.se>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: filetype magic
Posted by "Noel J. Bergman" <no...@devtech.com>.
> you could get bytes into a machine in the guise of the image bytes of a
gif or jpeg.
> there could still be uses for it *IF* it became a way round anti-virus
software.
Yes, but the way I've suggested using it was as suppliment to a/v software,
not a replacement. Any mismatch would be a rejection, but a positive match
doesn't imply a free ride.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: filetype magic
Posted by Danny Angus <da...@apache.org>.
> Faking to be a desirable type won't achieve the
> goal. It would just be a corrupt file.
No it wouldn't, you could get bytes into a machine in the guise of the image bytes of a gif or jpeg.
OK thats not executable, but there could still be uses for it *IF* it became a way round anti-virus software.
d.
RE: filetype magic
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I feel compelled to mention that magic is only ever an informed guess,
> and I'm convinced that faking magic isn't beyond the ability of smart
> bad people, if theres a gain to be made.
True. But what would be the point? Faking to be an undesirable type would
be counter-productive. Faking to be a desirable type won't achieve the
goal. It would just be a corrupt file.
As I see it, checking the magic is just one way to keep someone from
slipping an executable in under the guise of a benign attachment.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
filetype magic
Posted by Danny Angus <da...@apache.org>.
I feel compelled to mention that magic is only ever an informed guess, and I'm convinced that faking magic isn't beyond the ability of smart bad people, if theres a gain to be made.
> > 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
RE: Virus scanning (was RE: Matchers & X Window)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Virus scanning (was RE: Matchers & X Window)
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
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:vincenzo.gianferraripini@praxis.it]
> 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:noel@devtech.com]
> > 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
> > JPEG 0xFFD8FFE0JFIF0x00
> > ELF 0x7FELF
> > Windows .EXE MZ
> >
> > /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: james-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Virus scanning (was RE: Matchers & X Window)
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
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:noel@devtech.com]
> 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
> JPEG 0xFFD8FFE0JFIF0x00
> ELF 0x7FELF
> Windows .EXE MZ
>
> /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: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Virus scanning (was RE: Matchers & X Window)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > 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
JPEG 0xFFD8FFE0JFIF0x00
ELF 0x7FELF
Windows .EXE MZ
/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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Virus scanning (was RE: Matchers & X Window)
Posted by Danny Angus <da...@apache.org>.
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.
Virus scanning (was RE: Matchers & X Window)
Posted by "Noel J. Bergman" <no...@devtech.com>.
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:danny@apache.org]
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by Danny Angus <da...@apache.org>.
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:noel@devtech.com]
> 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: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
RE: Matchers & X Window
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > 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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by tobe <to...@swipnet.se>.
>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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > 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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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:
<mailet match="IsInfected=clamscan %targetDir%,/var/tmp,false,1"
class="ToProcessor">
<processor>vscan</processor>
</mailet>
<processor name="vscan">
<mailet match="All" class="NotifyPostmaster">
<notice>From vscan.</notice>
</mailet>
<mailet match="All" class="ToRepository">
<repositoryPath> db://james/deadletter/vscan </repositoryPath>
</mailet>
<mailet match="All" class="Null">
</mailet>
</processor>
> 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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
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:sbrewin@synsys.com]
> 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: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by Steve Brewin <sb...@synsys.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
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:okidz@pindad.com]
> 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: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
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:okidz@pindad.com]
> 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
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD><TITLE>Message</TITLE>
> <META content=3D"text/html; charset=3Diso-8859-1" =
> http-equiv=3DContent-Type>
> <META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
> <STYLE>P.MsoNormal {
> FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in
> 0in 0pt
> }
> LI.MsoNormal {
> FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in
> 0in 0pt
> }
> DIV.MsoNormal {
> FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in
> 0in 0pt
> }
> A:link {
>
> The "3D" characters are not supposed to be there, and it might cause
> the MIME parser to be choked.
>
> Oki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE>P.MsoNormal {
FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in
0in 0pt
}
LI.MsoNormal {
FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in
0in 0pt
}
DIV.MsoNormal {
FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in
0in 0pt
}
A:link {
The "3D" characters are not supposed to be there, and it might cause
the MIME parser to be choked.
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by Danny Angus <da...@apache.org>.
> 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
Posted by Steve Brewin <sb...@synsys.com>.
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:danny@apache.org]
> Sent: 20 June 2003 21:49
> To: James Users List; Sbrewin@Synsys. Com; okidz@pindad.com
> 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:okidz@pindad.com]
> > Sent: 20 June 2003 02:29
> > To: James Users List; sbrewin@synsys.com
> > 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: james-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-user-help@jakarta.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by Danny Angus <da...@apache.org>.
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:okidz@pindad.com]
> Sent: 20 June 2003 02:29
> To: James Users List; sbrewin@synsys.com
> 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: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
Re: Matchers & X Window
Posted by Oki DZ <ok...@pindad.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
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:
<mailet match='IsInfected=" ......... ' class="ToProcessor" onMatchException="noMatch">
<processor> virus </processor>
</mailet>
or
<mailet match='IsInfected=" ......... ' class="ToProcessor" onMatchException="matchall">
<processor> virus </processor>
</mailet>
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:okidz@pindad.com]
> 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.<clinit>(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.<clinit>(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: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by Jason Webb <jw...@inovem.com>.
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:sbrewin@synsys.com]
> 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.<clinit>(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: james-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by Steve Brewin <sb...@synsys.com>.
> 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.<clinit>(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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Matchers & X Window
Posted by "Noel J. Bergman" <no...@devtech.com>.
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: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org