JAMES has always enforced RFC compliance. In the case of JAMES-642 (a request
to drop the RFC 2821 requirement that MAIL and RCPT addresses have brackets),
when this has come up on rare occasions, we have repeatedly and deliberately
rejected such requests. Now Norman, Stefano and Joachim are i
Noel J. Bergman wrote:
JAMES has always enforced RFC compliance. In the case of JAMES-642 (a request
to drop the RFC 2821 requirement that MAIL and RCPT addresses have brackets),
when this has come up on rare occasions, we have repeatedly and deliberately
rejected such requests. Now Norman,
Stefano Bagnara wrote:
> I don't agree that JAMES-642 is a request to drop RFC2821 requirement
> that MAIL and RCPT address have brackets: IMO is clear that this is a
> requirement for clients, not for servers!
RFC 2821 is a protocol for message transfer. Where this is different behavior
allo
Noel J. Bergman wrote:
My interpretation of Postal's Law applied to this issue is quite different:
An SMTP client MUST use the brackets.
An SMTP server COULD accept also addresses without brackets.
Section 3.3 makes clear in several places that the "<" and ">" are necessary delimiters, mentioni
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 define
Hi,
Noel J. Bergman schrieb:
or just
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
Jürgen Hoffmann wrote:
Hi,
Noel J. Bergman schrieb:
class="org.apache.james.smtpserver.FixMissingBrackets"/>
or just
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 p
+1, I fully agree to Stefanos view.
all non-strict, relaxed behavior should be commented out per default
and the related comment should include a strong warning.
Bernd
On 9/30/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Noel J. Bergman wrote:
> JAMES has always enforced RFC compliance. In
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 shoul
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
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 M
> 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 o
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 th
Hi Noel,
Noel J. Bergman schrieb:
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?
yes, this would be the handler that accepts those common violations to
th
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. N
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, w
Jürgen Hoffmann schrieb:
Hi Noel,
Noel J. Bergman schrieb:
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?
yes, this would be the handler that accepts tho
As far as I understand it (and I wrote the compiance statement on
http://james.apache.org/server/design_objectives.html) the position
need not change.
It is acceptable for us to build non-compliant behaviour into James to
support interoperability with "broken" implementations. However it
should a
Danny Angus wrote:
As far as I understand it (and I wrote the compiance statement on
http://james.apache.org/server/design_objectives.html) the position
need not change.
It is acceptable for us to build non-compliant behaviour into James to
support interoperability with "broken" implementations.
Hi Danny,
Danny Angus wrote:
It is acceptable for us to build non-compliant behaviour into James to
support interoperability with "broken" implementations. However it
should always be disabled by default so that operators make a
conscious decision to enable non-compliant behaviour.
Well, this
> 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 sam
Jürgen Hoffmann wrote:
>>> And another Handler, which allows common Bendings of the RFC.
>> Would this be the handler with switches to do things like fix
>> bogus addresses that lack brackets?
> yes, this would be the handler that accepts those common violations to
> the RFC. Starting with the mi
Jürgen Hoffmann schrieb:
Hi Danny,
Danny Angus wrote:
It is acceptable for us to build non-compliant behaviour into James to
support interoperability with "broken" implementations. However it
should always be disabled by default so that operators make a
conscious decision to enable non-complian
Hi Noel,
Noel J. Bergman schrieb:
why are you against an example inside the configuration file,
which is commented out by default?
I'm flexible. I just really don't like making it too easy for people to
violate the standards.
looks like we will find a compromise here ;)
Kind regards
Juer
Norman Maurer wrote:
Jürgen Hoffmann schrieb:
Hi Danny,
[...]
Kind regards
Juergen Hoffmann
First of all thx for this wonderfull mail. I needed 5 minutes to stop
laughting.. I think now my girlfriend really think im crayz ;-)
You really got it! Thats exactly the Story which every admin knows
First of all thx for this wonderfull mail. I needed 5 minutes to stop
laughting.. I think now my girlfriend really think im crayz ;-)
You really got it! Thats exactly the Story which every admin knows...
And yes I fully agree with you.
So i whould temporary add the patch posted at:
http://issues.a
On 05/10/06, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
does anyone see the need for a more formal vote about the patch and/or
the policy? if yes, please speak up now.
No.
The policy is a pragmatic one, the idea that the documentation be
hidden is flawed, it highlights neither the feature nor
Danny Angus wrote:
On 05/10/06, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
does anyone see the need for a more formal vote about the patch and/or
the policy? if yes, please speak up now.
No.
The policy is a pragmatic one, the idea that the documentation be
hidden is flawed, it highlights nei
Stefano Bagnara schrieb:
Danny Angus wrote:
On 05/10/06, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
does anyone see the need for a more formal vote about the patch and/or
the policy? if yes, please speak up now.
No.
The policy is a pragmatic one, the idea that the documentation be
hidden is
OTECTED]>
To: "James Developers List"
Sent: Wednesday, October 04, 2006 10:35 PM
Subject: Re: Change in policy to for JAMES to violate RFCs
[...cut...]
So you search the net. You know Java, you find JAMES. You read about it,
and hey, this is exactly what you need. So you download
, 3 Oct 2006 22:25:01 +0200
really I am surprised.
Thanks,
Guillermo
- Original Message - From: "Jürgen Hoffmann" <[EMAIL PROTECTED]>
To: "James Developers List"
Sent: Wednesday, October 04, 2006 10:35 PM
Subject: Re: Change in policy to for JAMES to violate
;[EMAIL PROTECTED]>
To: "James Developers List"
Sent: Thursday, October 05, 2006 9:10 PM
Subject: Re: Change in policy to for JAMES to violate RFCs
Hi Guillermo,
not only yours ;) ask Norman about it ;) and then ask yourself who I might
be ;)
kind regards
Jürgen
Guillermo Gr
: Thursday, October 05, 2006 9:10 PM
Subject: Re: Change in policy to for JAMES to violate RFCs
Hi Guillermo,
not only yours ;) ask Norman about it ;) and then ask yourself who I
might be ;)
kind regards
Jürgen
Guillermo Grandes schrieb:
Hi Jürgen,
Wow, you have described my life! :-)
[...
From: "Jürgen Hoffmann":
to Normans Luck, I am the Boss who actually heard of the RFC and actually
knows what JAMES is capable of. And I make the technology decisions AND I
have to bare with them. Plus I try to keep my Boss out of Normans Back,
when James gives us trouble at some installation
Next week is ApacheCon. Anyone up for a virtual hack-a-thon, using our IRC
channel?
--- Noel
Would be cool, but I'd have to plan that. What time slots would be available?
Bernd
-
To unsubscribe, e-mail: [EMAIL PROT
Bernd Fondermann schrieb:
Next week is ApacheCon. Anyone up for a virtual hack-a-thon, using
our IRC channel?
--- Noel
Would be cool, but I'd have to plan that. What time slots would be
available?
Bernd
I whould be intressted too ;-)
bye
Norman
-
All,
Please indicate your vote in the usual way (+1,0,-1) for the following:
The standards compliance policy statement on
http://james.apache.org/server/design_objectives.html is a pragmatic
one.
However the idea that the documentation be hidden is flawed, as it
highlights neither the feature no
Danny Angus schrieb:
All,
Please indicate your vote in the usual way (+1,0,-1) for the following:
The standards compliance policy statement on
http://james.apache.org/server/design_objectives.html is a pragmatic
one.
However the idea that the documentation be hidden is flawed, as it
highlights
+1
:-) wow, what a comeback!
Bernd
On 10/5/06, Danny Angus <[EMAIL PROTECTED]> wrote:
All,
Please indicate your vote in the usual way (+1,0,-1) for the following:
The standards compliance policy statement on
http://james.apache.org/server/design_objectives.html is a pragmatic
one.
However th
+1 BUT with a minor note: I think that "the documentation MUST contain
the following statement" and then a 6 sentece statement is too much as
the requirement. We'll probably have minor things that will need this
disclaimer and it would not make sense to paste 20 lines of comments
above every co
+1
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 05/10/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
So I think that we should simply add a small sentence and a
link/reference to the big statement.
Hope this can be considered in this vote.
Seems reasonable to me.
-
To
+1
Danny Angus schrieb:
All,
Please indicate your vote in the usual way (+1,0,-1) for the following:
The standards compliance policy statement on
http://james.apache.org/server/design_objectives.html is a pragmatic
one.
However the idea that the documentation be hidden is flawed, as it
highlig
:
false
false
Or anything that seems :-)
Thanks :-)
Guillermo
- Original Message -
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "james-server-dev"
Sent: Thursday, October 05, 2006 2:33 PM
Subject: [VOTE] Non compliance disclaimer (was: Change in policy to
+1 (but with a shorter note where it applies as suggested by Stefano)
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrailPhone: +45 25481225
Pilevænget 41Email: [EMAIL PROTECTED]
DK-8961 Allingåbro Web: www.widetrail.dk
-
Søren Hilmer schrieb:
> +1 (but with a shorter note where it applies as suggested by Stefano)
>
So any suggestion about how the "shorter version" should be lookin ?
bye
Norman
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
On 10/9/06, Norman Maurer <[EMAIL PROTECTED]> wrote:
So any suggestion about how the "shorter version" should be lookin ?
"The feature documented here permits James to handle messages which do
not comply with the following standards which James claims to implement:
RFC para Y.Y
Plea
47 matches
Mail list logo
