You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Danny Angus <da...@apache.org> on 2002/07/28 22:44:42 UTC
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: bugzilla@apache.org [mailto:bugzilla@apache.org]
> Sent: 28 July 2002 19:49
> To: james-dev@jakarta.apache.org
> 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 farsight@alum.mit.edu
> 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:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: DO NOT REPLY [Bug 9669] - Embedded whitespace in To address field crashed James
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Hontvari,
That's a very interesting question. I haven't had a chance to run any
experiments yet. As I mention in my email, the Mailet API should be
bulletproof - no matter what exceptions are thrown, the threads should
not die and the server should remain functional. I don't know if that's
the case or not. Obviously we want the server to be robust against bad
headers and other malformed messages.
--Peter
> -----Original Message-----
> From: Hontvari Jozsef [mailto:hontvari@solware.com]
> Sent: Sunday, July 28, 2002 4:05 PM
> To: James Developers List
> Subject: Re: DO NOT REPLY [Bug 9669] - Embedded whitespace in To
address
> field crashed James
>
> Does this mean that anybody can crash the mail server by sending a
> malformed
> email?
>
> ----- Original Message -----
> From: "Peter M. Goldstein" <pe...@yahoo.com>
> To: "'James Developers List'" <ja...@jakarta.apache.org>
> 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:danny@apache.org]
> > > 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: bugzilla@apache.org [mailto:bugzilla@apache.org]
> > > > Sent: 28 July 2002 19:49
> > > > To: james-dev@jakarta.apache.org
> > > > 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 farsight@alum.mit.edu
> > > > 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:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <mailto:james-dev-
> > > help@jakarta.apache.org>
> > >
> > >
> > > --
> > > To unsubscribe, e-mail: <mailto:james-dev-
> > > unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail: <mailto:james-dev-
> > > help@jakarta.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DO NOT REPLY [Bug 9669] - Embedded whitespace in To address
field crashed James
Posted by Hontvari Jozsef <ho...@solware.com>.
Does this mean that anybody can crash the mail server by sending a malformed
email?
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
To: "'James Developers List'" <ja...@jakarta.apache.org>
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:danny@apache.org]
> > 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: bugzilla@apache.org [mailto:bugzilla@apache.org]
> > > Sent: 28 July 2002 19:49
> > > To: james-dev@jakarta.apache.org
> > > 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 farsight@alum.mit.edu
> > > 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:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:james-dev-
> > help@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:james-dev-
> > unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:james-dev-
> > help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: DO NOT REPLY [Bug 9669] - Embedded whitespace in To address field crashed James
Posted by Danny Angus <da...@apache.org>.
> 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?
I can see this point now, that it should be OK to get the illegal raw header
for any other purpose than creating a mailheader from it.
> 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...
Quite.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: DO NOT REPLY [Bug 9669] - Embedded whitespace in To address field crashed James
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
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:danny@apache.org]
> 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: bugzilla@apache.org [mailto:bugzilla@apache.org]
> > Sent: 28 July 2002 19:49
> > To: james-dev@jakarta.apache.org
> > 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 farsight@alum.mit.edu
> > 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>