"null sender" is explicitly mentioned in the smtp rfcs, so it is intuitive if the null sender corresponds to (java) null. A counter argument could be if null has another meaning, i.e. if it indicates unknown/not assigned, but then the null pointer cannot be eliminated for that reason. The null sender could be indicated by a special state of MailAddress, but I guess it would cause the same amount of problems, some mailets wouldn't check for the special state when they should. If you really mean a default value, e.g. postmaster, that is not a good idea, important information would be lost.
----- Original Message ----- From: "Steve Brewin" <[EMAIL PROTECTED]> To: "'James Developers List'" <[EMAIL PROTECTED]> Sent: Thursday, April 22, 2004 10:27 PM Subject: Should null senders be accepted? (was RC2?) > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
