Does this mean that anybody can crash the mail server by sending a malformed
email?
----- Original Message -----
From: "Peter M. Goldstein" <[EMAIL PROTECTED]>
To: "'James Developers List'" <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 12:09 AM
Subject: RE: DO NOT REPLY [Bug 9669] - Embedded whitespace in To address
field crashed James
>
> 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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
