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:[EMAIL PROTECTED]] > 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" <[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: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]>
