Stefano Bagnara wrote:
> I don't think that voting +1 JAMES-642 means that I'm voting +1 on a
> specificaion violation. And this is why.
> Yes, and anyway I think that adding optional, disabled by default
> features to increase functionality or interoperability on topics not so
> clearly defined by the RFC is a good thing
As I have said, if we want to add a command handler to repair the invalid
addresses, I would be OK with it -- hecl, I even favor it because it forces us
to make sure that the implementation of chaining is as flexible as I intended
for it to be -- but I am not OK with polluting the main code.
<handler command="MAIL,RCPT"
class="org.apache.james.smtpserver.FixMissingBrackets"/>
or just
<handler class="org.apache.james.smtpserver.FixMissingBrackets"/>
since the list of supported commands should be picked up from the
CommandsHandler. As I said, this is a check to make sure that we can do this
sort of thing.
Mind you, I'd prefer if the package were something like
org.apache.james.smtpserver.specviolations.FixMissingBrackets, to call
attention to the fact that this is a spec violation. And the only place it
should exist is in source control, the tarballs and the docs. Never in a
sample config file!
> > (see for example the multihomed MX issue a.k.a. "singleIPperMX" option
> > in dnsserver).
That's less of a concern, and if we had more modular support for sending, I'd
want it pulled from the main code body.
> in poor words rfc people added this mandatory brackets for MAIL
> FROM/RCPT TO parameters: why did they introduced the brackets?
> what problem was they trying to fix?
This isn't the correct forum for that discussion, since none of us were on that
working group. :-)
If someone reminds me, I can ask Lisa when I see her next week (in a week) at
ApacheCon.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
