You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Jürgen Hoffmann <jh...@byteaction.de> on 2006/10/03 10:34:24 UTC
Re: Change in policy to for JAMES to violate RFCs
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Change in policy to for JAMES to violate RFCs
Posted by Stefano Bagnara <ap...@bago.org>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Change in policy to for JAMES to violate RFCs
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara wrote:
> The problem with the specific issue of missing brackets is that I don't
> consider that supporting them (when acting as server) is not a
> specification violation.
Too many negations.. maybe I've lost someone...
The short "non negative" version is:
I think that supporting MAIL FROM and RCPT TO without brackets is NOT a
specification violation but simply a relaxed implementation of the
specification.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Change in policy to for JAMES to violate RFCs
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>> as I said I don't know enought the current handlerchain architecture
>> (maybe noone does, because it is in branch since 2 months and not
>> completed yet).
>
> The only reason why the handler chain is in the sandbox is because you convinced Norman that until it supported DATA, which he's waiting on me to do since no one else knew how, that it shouldn't be merged.
Uh?? I convinced Norman to avoid merging something that was not-working?
I think Norman was smart enough to decide himself to not break the
trunk. Short-living branches are not branches that are merged as-is as a
time-bomb. If they don't work or they works worse than the main trunk
they cannot be applied. I can't see any other way to work.
I really don't understand what could have been my role in such a delay:
I've taken myself out of this conversation, I never said how the
handlerchainv2 should have worked and so on: I just don't want to work
on something you already are working on, so I simply waited.
So please stop saying this kind of things, because it is annoying.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Change in policy to for JAMES to violate RFCs
Posted by "Noel J. Bergman" <no...@devtech.com>.
> as I said I don't know enought the current handlerchain architecture
> (maybe noone does, because it is in branch since 2 months and not
> completed yet).
The only reason why the handler chain is in the sandbox is because you convinced Norman that until it supported DATA, which he's waiting on me to do since no one else knew how, that it shouldn't be merged.
I'll deal with it soon. Next week is ApacheCon. Anyone up for a virtual hack-a-thon, using our IRC channel?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Change in policy to for JAMES to violate RFCs
Posted by Stefano Bagnara <ap...@bago.org>.
I like your suggestion: I've not thought at it enough to understand
wether this will make us to duplicate all of our code or not, but
generally speaking your proposal make sense.
The problem with the specific issue of missing brackets is that I don't
consider that supporting them (when acting as server) is not a
specification violation.
As an example this change already involve the MAIL and the RCPT
handlers. You would start having 2 MAIL Handlers and 2 RCPT handlers,
for only this specific support... not sure that this will be good, but
as I said I don't know enought the current handlerchain architecture
(maybe noone does, because it is in branch since 2 months and not
completed yet).
Stefano
Jürgen Hoffmann wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Change in policy to for JAMES to violate RFCs
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jürgen Hoffmann wrote:
> What about you have a RFC compliant *AnythingThatIsNotCompliantWillBeDropped*
> Handler.
+1
I've seen some mail servers that use strict RFC compliance as an anti-SPAM measure.
> And another Handler, which allows common Bendings of the RFC.
Can you elaborate? Would this be the handler with switches to do things like fix bogus addresses that lack brackets?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Change in policy to for JAMES to violate RFCs
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,4522291b53071281555411!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Change in policy to for JAMES to violate RFCs
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We need only to call the *AnythingThatIsNotCompliantWillBeRejected*
> before every CmdHandler.
Just make it a CommandsHandler and MessageHandler, with configuration largely automatic from there. That will cause it to self-maintain.
Amusingly, the FixWhatWeFeelLikeFixing handler can do the same thing, and be inserted prior to the above, which means that the enforcement will follow the fixing, ensuring that anything not fixed is still enforced.
Some things I have noticed being checked include the normal RFC2822 headers, so bogus messages that do not have the normal headers are rejected. Not saying that's a good idea. I just happened to come across a server that does it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Change in policy to for JAMES to violate RFCs
Posted by Norman Maurer <nm...@byteaction.de>.
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: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>> !EXCUBATOR:1,4522291b53071281555411!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,4522953f53076410667221!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org