> Steve Brewin wrote: > > - I also discovered that some Mailets and Matchers do not > anticipate a null > > sender so injectors such as fetchmail have to supply > something, or reject > > the mail, or the Mailets and Matchers have to be changed to > determine what > > to do when the sender is unknown, or we will get > NullPointer exceptions.
Currently the org.apache.james.core.MailImpl tolerates a null sender, but as mentioned above, some Mailets and Matchers do not. Is there a good reason why null senders should be tolerated? If not, it would make a lot of sense to guard Mailets and Matchers from this issue by ensuring that Mail objects with a null sender are never created. We could either... - Throw an exception - Fix up such Mails by assigning a default sender There are pros and cons with both approaches but the fix up approach would not break existing code and is better than the current situation where every Matcher and Mailet has to check and make its own decisions. These decisions are normally a matter of policy made be the Mailet API hosting environment ane should not be made by the Matchers or Mailets. The spec. (ie: Javadoc) for org.apache.mailet.Mail interface would need tightening to indicate that getSender() should never answer null. Is this likely to have an impact outside of James? -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
