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]