Hi ,

first I like your idea ;-) I also think that this can be done without many duplicate code.We need only to call the *AnythingThatIsNotCompliantWillBeDropped* (I bet you mean reject.. Droppin whould be bad) before every CmdHandler. I don't think its too much diffrent from what we do now. Now we call every "core" filter before the cmd it belongs to.

I think the biggest problem is javamail which gives us many limitations. It's no secret that james has "proplems" with not fully rfc conform messages, while qmail, postfix etc deliver them without problems.

bye
Norman


Jürgen Hoffmann schrieb:
Hi Stefano,

I was thinking a bit, and came to a proposal. What about you have a RFC compliant *AnythingThatIsNotCompliantWillBeDropped* Handler. And another Handler, which allows common Bendings of the RFC.

IMHO if other RFC compliant Mailservers (i.e. postfix, qmail) allow this, James should allow this.

I am thinking about the same way HTML is able to distinct between transitional and strict.

Could this be a way to go? That way the behaviour is still configurable, as the user desires. Correct?

Kind regards


Juergen Hoffmann


Stefano Bagnara schrieb:
Jürgen Hoffmann wrote:
Hi,


Noel J. Bergman schrieb:
<handler command="MAIL,RCPT" class="org.apache.james.smtpserver.FixMissingBrackets"/>

or just

  <handler class="org.apache.james.smtpserver.FixMissingBrackets"/>


This approach sounds like a great solution to a common problem, and could be used for other rfc violations as well.

Kind regards

Juergen Hoffmann


We should pay attention to this kind of configurability/flexibility.
The risk is to end up with a config.xml that is more difficult to manage than a java file both for users (without java knowledge) and for developers (with java knowledge).

Often an "if (optionEnabled)" is much more clean for everyone than a so flexible system.

That said I'm still not convinced that this is an RFC violation (we are writing a server, not a client) and I would prefer a flag for the main handler. Either way I could live even with an additional handler but we should include it the way the current fastfail allow us now, and maybe refactor it to a custom handler later when the handlerchain architecture will let us to do so.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

!EXCUBATOR:1,4522291b53071281555411!


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

!EXCUBATOR:1,4522953f53076410667221!



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to