> [RFC 1939] doesn't prevent the use of the whole address, however doing so > would require changes to local delivery.
I believe I pointed out some of the code changes that would be necessary. If we're contemplating making a Release Build, it seems to me that it would be preferable to make those changes afterwards, rather than risk unintended consequences. I use MySQL, and have no intention of switching. My suggestion of HypersonicSQL was precisely to accommodate the reason you gave for the file system: "I would be very much against having any kind of third party software specified as a run-time dependancy for storage, hence the 100% java filesystem gets my vote even though I don't use it." Hypersonic SQL IS a 100% pure Java SQL engine that is already available as a Avalon service (see http://jakarta.apache.org/avalon/apps/apps/hsql/index.html). Since we already have a requirement on an Avalon container (Phoenix) for James, it didn't seem unreasonable to switch to a pure Java SQL engine from a pure Java file system. As I recall, someone recently posted the XML changes necessary for some version of James to work with Hypersonic SQL. Just a thought for consideration. Part of what drives that thought is listening to the various things people want to do with James in terms of additional requirements for user and mail information. By the time those are layered onto a file system driver, we might end up accidentally building a database layer. > it is better anti-spam practice not to indicate invalidity in a 550 message I believe that he was presupposing changes that would express validity. As for the anti-SPAM practices, I've seen suggestions to only permitting thoses sender that are authorized (e.g., via SMTP AUTH) to use the commands. --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
