IMAP support
Can anyone elaborate on James's IMAP support? The website doesnt say much. I know it's not going to be classed as stable, but is it usable? Is anyone sucessfully using IMAP? I'm using james as our mail server, and people want to be able to use IMPs folders. IMP works fine with POP3, but doesnt have sent items/deleted items/etc. Thanks, Daniel.
Abuse or Configuration
I am having major problems with James. Every minute a new log file is generated. I only found this out last night when my server notified me that I was almost out of disk space. I noticed in about three hours nearly 30 GB of log files had been generated. I shut down James in an effort to investigate. The two log files that are the culprits are the spool and mailet log files. A mailet is generating errors and logging each ToRepository. See below Listing One five entries of one of the mailet log files. Youll notice that the timestampt is all 10:25:34. There is actually about 150 entries each second. It takes several minutes (15-20) for a mailet log file to get to max capacity and start a new log file. The spool log file is much different. The spool log file is generating the error found in Listing Two nearly 150 times a second. Once a minute a new 10 MB file is created. In the course of writing this email 6 where generated. What could be the problem? Is James in a loop? Is my James being abused by a spammer? I cant figure it outPlease help! Listing One: 19/03/04 10:25:34 INFO James.Mailet: ToRepository: Storing mail Mail1079693860218-98 in file://var/mail/error/ 19/03/04 10:25:34 INFO James.Mailet: ToRepository: Storing mail Mail1079693983078-99 in file://var/mail/error/ 19/03/04 10:25:34 INFO James.Mailet: ToRepository: Storing mail Mail1079693860218-98 in file://var/mail/error/ 19/03/04 10:25:34 INFO James.Mailet: ToRepository: Storing mail Mail1079693983078-99 in file://var/mail/error/ 19/03/04 10:25:34 INFO James.Mailet: ToRepository: Storing mail Mail1079693983078-99 in file://var/mail/error/ Listing Two: 19/03/04 10:24:54 ERROR spoolmanager: Exception in JamesSpoolManager.run sun.io.ByteToCharEUC_CN.getIndex1()[S java.lang.NoSuchMethodError: sun.io.ByteToCharEUC_CN.getIndex1()[S at sun.nio.cs.ext.EUC_CN$Decoder.init(EUC_CN.java:50) at sun.nio.cs.ext.EUC_CN.newDecoder(EUC_CN.java:38) at java.lang.StringCoding$CharsetSD.init(StringCoding.java:166) at java.lang.StringCoding$CharsetSD.init(StringCoding.java:157) at java.lang.StringCoding.decode(StringCoding.java:213) at java.lang.String.init(String.java:320) at javax.mail.internet.MimeUtility.decodeWord(MimeUtility.java:741) at javax.mail.internet.MimeUtility.decodeText(MimeUtility.java:493) at org.apache.james.core.MimeMessageWrapper.getSubject(MimeMessageWrapper.java:508) at org.apache.james.transport.mailets.NotifyPostmaster.service(NotifyPostmaster.java:182) at org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:413) at org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:436) at org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:366) at org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:47) at org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:80)
RE: Abuse or Configuration
Which JVM? If 1.4.2, you *must* update to the very latest. There was a bug in all other versions of 1.4.2 that caused a decode error. In any event, the loop is being caused by an exception in the error processor. If you use the current James test build, you can use this: mailet match=All onMailetException=ignore class=NotifyPostmaster ... /mailet You won't get the notification, but you won't get the loop, either. Actually, you should not get a loop like that, period. I think that was a bug we've already fixed. --- Noel -Original Message- From: Brandon Smith [mailto:[EMAIL PROTECTED] Sent: Friday, March 19, 2004 12:45 To: 'James Users List' Subject: Abuse or Configuration I am having major problems with James. Every minute a new log file is generated. I only found this out last night when my server notified me that I was almost out of disk space. I noticed in about three hours nearly 30 GB of log files had been generated. I shut down James in an effort to investigate. The two log files that are the culprits are the spool and mailet log files. A mailet is generating errors and logging each ToRepository. See below Listing One five entries of one of the mailet log files. You'll notice that the timestampt is all 10:25:34. There is actually about 150 entries each second. It takes several minutes (15-20) for a mailet log file to get to max capacity and start a new log file. The spool log file is much different. The spool log file is generating the error found in Listing Two nearly 150 times a second. Once a minute a new 10 MB file is created. In the course of writing this email 6 where generated. What could be the problem? Is James in a loop? Is my James being abused by a spammer? I can't figure it out.Please help! Listing One: 19/03/04 10:25:34 INFO James.Mailet: ToRepository: Storing mail Mail1079693860218-98 in file://var/mail/error/ 19/03/04 10:25:34 INFO James.Mailet: ToRepository: Storing mail Mail1079693983078-99 in file://var/mail/error/ 19/03/04 10:25:34 INFO James.Mailet: ToRepository: Storing mail Mail1079693860218-98 in file://var/mail/error/ 19/03/04 10:25:34 INFO James.Mailet: ToRepository: Storing mail Mail1079693983078-99 in file://var/mail/error/ 19/03/04 10:25:34 INFO James.Mailet: ToRepository: Storing mail Mail1079693983078-99 in file://var/mail/error/ Listing Two: 19/03/04 10:24:54 ERROR spoolmanager: Exception in JamesSpoolManager.run sun.io.ByteToCharEUC_CN.getIndex1()[S java.lang.NoSuchMethodError: sun.io.ByteToCharEUC_CN.getIndex1()[S at sun.nio.cs.ext.EUC_CN$Decoder.init(EUC_CN.java:50) at sun.nio.cs.ext.EUC_CN.newDecoder(EUC_CN.java:38) at java.lang.StringCoding$CharsetSD.init(StringCoding.java:166) at java.lang.StringCoding$CharsetSD.init(StringCoding.java:157) at java.lang.StringCoding.decode(StringCoding.java:213) at java.lang.String.init(String.java:320) at javax.mail.internet.MimeUtility.decodeWord(MimeUtility.java:741) at javax.mail.internet.MimeUtility.decodeText(MimeUtility.java:493) at org.apache.james.core.MimeMessageWrapper.getSubject(MimeMessageWrapper.java: 508) at org.apache.james.transport.mailets.NotifyPostmaster.service(NotifyPostmaster .java:182) at org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:413) at org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java: 436) at org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:366) at org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute(Executabl eRunnable.java:47) at org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:8 0) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tracking each piece of mail through the system
Ive got a situation where some legit mail is being categorized as spam. I run a few of the default spam blockers that come with James. But I cant figure out which one is causing a spam hit. Im familiar with all the various logs. But there doesnt appear to be a single routing log that tracks a note through all the processors/matchers/mailets. Am I missing something? Is there an easy way to enable some sort of tracking log? Thanks. Jerry
Planned v2.2.0a16 Test Build
The primary effort has been to merge the two main branches of James, but
there has been considerable other development on James. The following are
expected for a test build that should be posted shortly. There are more
changes already pending the merger.
--- Noel
- Applied Apache License v2.0.
- AbstractQuotaMatcher now handles Sender properly
- AbstractStorageQuota matcher now handles aliases properly
- More information are made available through JMX.
- Bugfix: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=JAMES-152
- Bugfix: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=JAMES-151
- Bugfix: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=JAMES-150
- Bugfix: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=JAMES-149
- MBoxMailRepository
- list() verifies the first message before returning, just in case file
changed.
- Changed interface to the callback object to explicitly indicate
whether the operation is finished or not.
- Changed to read lines instead of characters. Both I/O
mechanisms are still supported. Jason Webb is working on a
BufferedRandomAccessFile class, which preliminary tests suggest
results in 20x performance improvement.
- Added more DEEP_DEBUGGING messages to help with development.
- Changed to rely upon the index. findMessage will reload the
keys (once) if selectMessage fails.
- Pre-size the index based upon file size.
- Use finally{} to ensure that files are closed.
- Minor formatting fixes to log messages.
- The mbox repository now uses two digit numeric days in the mbox
mail separator. This will make the mbox repository more standards
compliant and fix problems with some 3rd party IMAP/POP3 servers
- FromRepository Mailet
- Correct handling of boolean parameter
- Add FromRepository mail attribute to make it easy to detect
messages that have been spool from a repository. THIS IS AN
EXPERIMENTAL CHANGE. Both the attribute name and the value
should probably change. Possibly the latter should be a URI
for the repository or the message.
- Bugfix: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=JAMES-142
- Added support for a flexible retry schedule to RemoteDelivery.
This commit also includes a concurrent change to SpoolRepository so
that accept() is a one-step process that returns the Mail, rather
than an unsynchronized two-step process. Another related change is
that accept() takes a filter object to control the next message to
be returned, rather than hardcoding the algorithm.
- Fixed unexercised bug in File Repository code.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
