*Interoperability Rule Number One:* Be strict in what you send and lenient in what you accept.
Peter M. Goldstein wrote:
It makes it possible to write applets that are in violation of spec. Which is a good reason to not support the "functionality".
IMHO, this view is incorrect. It is not the business of the JAMES development community to attempt to be the RFC police of the SMTP world. If people want to write cheap hacks to meet a goal, who are we to say (without any knowledge of the circumstances) that their particular situation does not warrant the tradeoff?
The goal of any development team should be to make their app as useful and robust as possible. Robustness is about dealing with errors in such a way that service is still provided in the most adverse conditions possible. This includes resource shortages/outages and also spec violations.
There are a large number of widely used mail clients and servers out there that are in violation of spec (though maybe not this particular issue). If we carry this attitude when dealing with them, then JAMES will have problems talking to them. This will make JAMES less useful.
I think that Serge's issue should be fixed, assuming that it can be done without putting us in violation of the spec ourselves. (Post 2.1 release, of course.)
Cheers
ADK
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
