Danny,
The essential problem is that an incoming header isn't necessarily legal
by RFC 822 (or followup RFC standards). What's happening here is that
there is an illegal To header on the incoming message. The To header
has the specific form "<Not Insured>". According to the assorted mail
RFCs, anything inside the angle brackets on a To header needs to be a
legal email address. Obviously, "Not Insured" is not. So when
NotifyPostmaster calls getRecipients(), the InternetAddress class chokes
on the parse and throws an exception.
But as far as NotifyPostmaster (or NotifySender for that matter) is
concerned, the legality of the headers shouldn't be an issue. Rather
these mailets should be getting the raw string headers of the message
being forwarded (be it to the Postmaster or to the Sender), putting them
into the message, and sending. The exception being generated is the
result of an exception when one of these headers is invalid - why should
these mailets care if the headers are valid?
This change in behavior requires additional public methods on the
MimeMessageWrapper class to ensure that the headers are properly loaded
before getting the raw strings, so it isn't a trivial change. It can be
done by overriding the getHeader methods of the MimeMessage class as
follows:
public string getHeader(String name)
{
if (headers == null)
{
loadHeaders();
}
return super.getHeader(name);
}
and similarly for the other getHeader method. You'd also want to clean
up some of the other methods in MimeMessageWrapper when making this
change. Then you'd modify NotifyPostmaster and NotifySender to call the
getHeader methods directly. That'll solve the immediate problem.
As I mention in the bug, a more serious problem is the hang/crash
reported. The Mailet API should be fairly bulletproof when it comes to
exceptions. I couldn't find an immediate reason why a hang/crash type
behavior was being observed even when this exceptional condition was
being triggered...
--Peter
> -----Original Message-----
> From: Danny Angus [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, July 28, 2002 1:45 PM
> To: James Developers List
> Subject: RE: DO NOT REPLY [Bug 9669] - Embedded whitespace in To
address
> field crashed James
>
> Peter, could you describe this in detail on the list, what kind of
> address,
> is this a compliance issue with RFC822, or a trim() problem, at what
point
> does James go off the rails, on receipt or during storage/processing.
>
> (as an aside a mail outlining bug submissions also helps communicate
the
> problem in a more conversational way)
>
> d.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: 28 July 2002 19:49
> > To: [EMAIL PROTECTED]
> > Subject: DO NOT REPLY [Bug 9669] - Embedded whitespace in To address
> > field crashed James
> >
> >
> > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9669>.
> > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> > INSERTED IN THE BUG DATABASE.
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9669
> >
> > Embedded whitespace in To address field crashed James
> >
> >
> >
> >
> >
> > ------- Additional Comments From [EMAIL PROTECTED]
> > 2002-07-28 18:49 -------
> > The immediate problem is the NotifyPostmaster mailet. Basically,
> > that mailet
> > is using methods of the MimeMessageWrapper class that do
> > validation on the
> > mail headers. In a situation like this one, that's not really
> > what you want.
> > It would be most desirable to get the raw headers, because that's
> > really all
> > you're interested in (note that the InternetAddresses are
immmediately
> > converted to Strings). A similar change to NotifySender is probably
in
> > order. This applies to both the From and assorted Recipient
addresses.
> >
> > Why this relatively minor problem should hang/crash the whole
> > system is a more
> > serious issue.
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:james-dev-
> [EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:james-dev-
> [EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
