Kevin, The Javadoc for StringTerm says...
"This class implements the match method for Strings. The current implementation provides only for substring matching. We could add comparisons (like strcmp ...). ". ...So, there is no support for searching using regular expressions on Addresses, the "text/*" parts of the message body, headers, subjects, etc. contrary to your expectations. Also, a JavaMail MimeMessage does not support the received date so you cannot match on it. Processing in the mailet chain already meet your minimum requirements, as you can perform SubjectIs and SubjectStartsWith matching with current James matchers. Of the other meaningful searches, only sent date and message body search lack equivalent matchers. Both would be simple to write and generally useful. By having one matcher per test rather than one matcher supporting several tests, the current matcher syntax will suffice and you do not need to worry about "the <and><or> logic". It seems the real driver for wanting to do this in fetchmail rather than in the mailet chain is to avoid fetching messages you have reposted to the message store. But, when you say "I must NOT fetch any emails that were sent to the mailbox by my application" do you really mean "I must NOT reprocess"? If so there isn't really an issue with dealing with these in mailets. If you really mean "NOT fetch", then I assume that you are expecting... a) A message sent from James to a local domain to end up back in the MessageStore. It won't unless you hack the mailet chain to divert (selected?) local mail to remote delivery. b) Something else to read the message otherwise there is no point reposting them. But what? How will he/she/it know to only read messages with certain subject prefixes? Why can't the processed messages simply be sent to another mailbox so that there is no need to filter at all? In any event, you can't currently repost fetched emails back to the same message store. fetchmail has loop detection built in which will bounce messages that have passed through already (it will have the X-fetched-from: header attached that is used to check for looping messages). You would need to write a mailet that removes the X-Header. A RemoveHeader mailet would be generally useful if you do choose to write one. I'm sure your business process would be best achieved far more flexibly in the mailet chain. You just need to rework your implementation of what is required a little. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
