geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Javamail address parsing (again).
Date Thu, 12 Jan 2006 23:41:07 GMT

On Jan 12, 2006, at 3:24 PM, Rick McGuire wrote:

> Dain Sundstrom wrote:
>> On Jan 11, 2006, at 1:17 PM, Bruce Snyder wrote:
>>> Is it possible to look at the Sun implementation's source code to
>>> distinguish enforced vs. ignored rules?
>> That would make the code not clean room.
>> I propose we ask Sun for a formal definition of the parser for  
>> this class, and in a parallel track make an effort to try to match  
>> their bugs.  The code from the second track doesn't have to be  
>> perfect, but just good enough.  We simply let our users know that  
>> our goal with the "implement.sun.javamail.bugs=true" code is to  
>> emulate the sun bugs, and if they find something that produces  
>> different results for the same text, we consider it a bug.
> I'm becoming less and less convinced this is a good idea.  So far,  
> I've found many, many sun bugs in this code where they produce  
> results that are in conflict with with RFC822.  The API  
> documentation refers relaxed parsing rules, which says to me there  
> are addresses that would not be valid under RFC822, but javamail  
> will accept them based on the type of parsing requested.  I can  
> accept that.
> However, the great majority of the problems I've found have been  
> involved with internet addresses that RFC822 says ARE valid, but  
> the javamail code does not handle them properly.  And there are a  
> few situations where it appears the authors just chose to punt and  
> say "yeah, whatever".
> It appears that the solution is to write hacked code that mostly,  
> sorta, kinda does what it claims to do, or write a good parser,  
> then triple the size of the code trying to get all of the Sun bugs  
> to work properly.
> Working strictly from the RFC822 spec, I had a fairly nice parser  
> written that gave very good RFC822 compliance, but things turned  
> nightmarish when I discovered the sorts of Sun behaviors I had to  
> insert back in.  I think I've completely rewritten this code about  
> 5 times now, and am getting pretty close to the Sun "relaxed  
> rules".  Inserting some of the real bugs back in to the parsing  
> might pose similar problems.
> It really appears that this code somewhat "lost it's way  
> somewhere".  It's serving two purposes that are really at odds with  
> each other.  The first purpose, is to parse any internet address  
> that might appear in a received message.  For that purpose, the  
> code needs to accept any valid internet address as defined by  
> RFC822.  The Sun code does not currently do that, and making the  
> new version "bug compatible" would also not achieve that.
> The other purpose of the InternetAddress parser is to process email  
> addresses entered into applications and perform some validation on  
> the addresses.  This is where the "relaxed rules" come in to play,  
> and basically allows internet addresses that are not strictly  
> RFC822 compatible to pass.  Now for those, I'm relatively  
> comfortable that this can be made compatible.  It is very difficult  
> though, when the requirement becomes one of being both more and  
> less restrictive at the same time, with no good definition of the  
> what rules are being used.

Ok, how about we say, in "sun bug mode" we will parse all addresses  
that are valid RFC822 address or are sucessfull parsed by sun's  
javamail implementation?  This means that valid RFC822 addresses that  
sun's implementation rejects will be accepted by ours.  We would  
further would consider it a bug to reject addresses accepted by sun's  
implementation when in "sun bug mode".


View raw message