james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: cvs commit: jakarta-james/src/java/org/apache/james James.java
Date Sun, 29 Sep 2002 01:14:37 GMT


> Not that I mind the checking, but things like this:
>  +            username = localusers.getRealName(originalUsername);
> are *supposed* to have been checked earlier in the pipeline.  This was
> part
> of the dicussion a few weeks back with Serge regarding bounce handling
> Local and Remote delivery.

I don't see anywhere these things are being checked.  Can you be more

The contracts of these methods are very clear that they can (and will)
return null in certain circumstances.  As I read the code, that means
that James will generate spurious NPEs in these circumstances.  I'd far
rather run the check and generate a meaningful exception.

Actually, this is an area I really want to bulk out a bit in version
3.0.  Right now the LocalDelivery mailet doesn't attach any specific
info about the error encountered - it just routes the mail to the ERROR
processor.  IMHO, that's a problem.  
>  +                if (forwardTo == null) {
> I wonder if it is better to throw the exception or to store the mail
> the
> mailbox for which the forwarding address is missing (a typical
> issue when there is both a flag and a data value involved).
Personally, I
> think I'd have gone for a warning, and stored the e-mail, rather than
> throwing the exception and having to bounce the e-mail.
> Your thoughts on that subject?

IMHO it must be a failure to deliver.  A warning is woefully

The fact that every email address accepted by the server (ignoring
mailet processing for the moment) has an actual mailbox is an artifact
of the implementation, and not one that's a particularly good artifact.
Most mail servers allow you to create accounts that are used exclusively
for forwarding or aliases.  It's only a peculiarity of the James
implementation that links actual mailboxes to email addresses.

Consider the following use case.  I have a mail administrator at a
medium sized business, with ~100 users.  Bob requests that three email
addresses (info@business, sales@business, opportunities@business) be set
up to forward to Bob.  The administrator is using a custom rev of James
(not surprising, as it's an open source project) and he's introduced a
bug.  He manages to produce a couple of correct forwards, but
opportunities@business has a null forward.  Bob never notices, because
he's getting email from two of his three forwards.  Senders don't try
other avenues of contact, because they don't receive a bounce.
Administrator has no particular reason to look at the logs, and maybe he
doesn't have it set to record warnings.  So the mails are "delivered" in
one sense, but in any meaningful way they're lost to the ether.

In general, this condition should never fail.  Honestly, this is a
contract that should be enforced by the User object.  Failing on this
condition implies corrupted internal state, and thus is a very serious
problem.  It's not sufficient to deliver the email to a mailbox that
isn't expected to have any mail in it and log a warning about such a
serious problem.  


To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message