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 "Noel J. Bergman" <no...@devtech.com> on 2006/09/30 15:48:46 UTC
Change in policy to for JAMES to violate RFCs
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 in favor of permitting the behavior.
I am against supporting specification violations, even as an option, except *maybe* in the case that there is such a widespread issue that everyone's transport capabilities are compromised. Postal's Law doesn't mean to ignore mandated behavior. RFC 2821 is quite clear that the brackets must always be present for MAIL and RCPT. Are we as a community changing to say that specification compliance is no longer important?
As for a possible solution, the "fast fail" chain is really about in-protocol plug-ins, not just fast fail. If someone wants to write a command handler to repair defective addresses for MAIL and RCPT, that's their option. JAMES is open source. If someone wants to violate the specification, they can manage their own changes.
--- 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>.
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. However it
> should always be disabled by default so that operators make a
> conscious decision to enable non-compliant behaviour.
>
> The argument against non-compliance is that as increasingly more
> non-compliant behaviours become accepted they enforce an undocumented
> "dark" standard which implementors will struggle to understand and
> implement. directly countering the purpose of published
> interoperability standards.
>
>
> d.
Wow, I moved around website documents plenty of times and I never read
it. It's a shame!
Btw I fully agree with the objectives described there.
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 Danny Angus <da...@gmail.com>.
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 always be disabled by default so that operators make a
conscious decision to enable non-compliant behaviour.
The argument against non-compliance is that as increasingly more
non-compliant behaviours become accepted they enforce an undocumented
"dark" standard which implementors will struggle to understand and
implement. directly countering the purpose of published
interoperability standards.
d.
On 03/10/06, Bernd Fondermann <be...@googlemail.com> wrote:
> +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 <ap...@bago.org> wrote:
> > 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 and Joachim are in favor of permitting the behavior.
> >
> > 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!
> >
> > Clients issue that commands, not servers.
> >
> > > I am against supporting specification violations, even as an option, except *maybe* in the case that there is such a widespread issue that everyone's transport capabilities are compromised. Postal's Law doesn't mean to ignore mandated behavior. RFC 2821 is quite clear that the brackets must always be present for MAIL and RCPT. Are we as a community changing to say that specification compliance is no longer important?
> >
> > 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.
> >
> > It is not so clear that accepting a MAIL FROM or an RCPT TO without
> > brackets is a violation to the RFC. It is for sure a violation to send
> > that commands.
> >
> > I would agree with your position if we were talking about sending the
> > branckets in the MAIL FROM our remote delivery issue when sending an
> > email: this would be a "specification violations".
> >
> > The same thing would be if the specification said "the server MUST NOT
> > accept MAIL FROM: " with not compliant attributes: this thing has not
> > been written in the specification, so we are compliant anyway.
> >
> > As another example, the RFC say:
> > | Several commands (RSET, DATA, QUIT) are specified as not permitting
> > | parameters. In the absence of specific extensions offered by the
> > | server and accepted by the client, clients MUST NOT send such
> > | parameters and servers SHOULD reject commands containing them as
> > | having invalid syntax.
> >
> > As you can see they enforce the client to operate in a specific way, but
> > say the the server "SHOULD" reject badly composed commands instead of
> > using a "MUST reject".
> >
> > So I think that I never changed my mind on specification compliance: we
> > seem to have a different Idea on what does it mean to be specification
> > compliant.
> >
> > Imho the key is interoperability: adding the feature does not make James
> > non-compliant and give it more interoperability, so I put a +1.
> >
> > > As for a possible solution, the "fast fail" chain is really about in-protocol plug-ins, not just fast fail. If someone wants to write a command handler to repair defective addresses for MAIL and RCPT, that's their option. JAMES is open source. If someone wants to violate the specification, they can manage their own changes.
> > >
> > > --- Noel
> >
> >
> > Well saying that the user can write code to alter the behaviour is not a
> > solution: we are an opensource project, using this reasoning we could
> > close every JIRA issue saying that the user can fix it. The can also
> > write their own smtp server...
> >
> > Stefano
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
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 Guillermo Grandes <gu...@gmail.com>.
Hi Jürgen,
Wow, you have described my life! :-)
See also mail:
Subject: Re: [jira] Commented: (JAMES-648) Corrupted MIME message [...]
Sent: Tue, 3 Oct 2006 22:25:01 +0200
really I am surprised.
Thanks,
Guillermo
----- Original Message -----
From: "Jürgen Hoffmann" <jh...@byteaction.de>
To: "James Developers List" <se...@james.apache.org>
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 it, test it a bit,
> and say woohooo this is what I need. This is in most cases only the first
> step. The next burden is, that you have to tell your boss about it. He
> says "Nah, why should I change something that is working?" The Admin says,
> "because it can do what postfix does, ... AND MORE!" Boss: "Well ok, let
> us give it a try."
> That described, the sysadmin installs JAMES, gets it up and running, and
> shows his boss. Boss is pleased until the next morning. The freaking
> automatic E-Mail is missing, "Admin! The billing did not run, I did not
> receive the status Mail!!! Check this immediatly!". The Admin checks, the
> Job ran, but no Mail. WHY Lord WHY? "Oh I know, I installed the James
> Server. Let me check the Logs." "Hmmm, there is it. Aha, it is not RFC
> compliant. Boss, I found the problem! The Status Mail was not RFC
> Compliant!" Boss: "Huh? What the ... well, then fix it!" That said, he
> keeps thinking "What is the RFC?"
> So the Admin goes on, and checks the configuration, maybe he missed
> something. nope, everything there. So he opens up a bug report. He gets
> told "This is no Bug, this is a feature!". He suggests "Can we make it
> configurable? I really love James, and would really like to use it... I
> even wrote a patch!" The Commiters say "Hey, cool yes. We can do that ...
> wait, no we can't, because we break the RFC, and we really do not want
> that, sorry"
>
> So the Admin goes, tells his boss, what he was told, and the Boss says
> "Well, if we cannot do it with JAMES, put the other stuff back online!"
> The Admin tries to consider James one more time, "... but Boss, the nice
> Extensibility, Mail Processing" Boss: "Admin! Enough of that Nonsense! You
> said it could do what the old setup did, and MORE! Not LESS! Leave it with
> the old setup!".
[...cut...]
> 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 Guillermo Grandes <gu...@gmail.com>.
mmm... well, I have imagination... both are byteaction....
family?
the "evil" boss?
the suffered sysadmin?
another suffered developer?
the reincarnation of Elvis?
ok, ok, I surrender :-)
Have a nice day! :-)
Guillermo
----- Original Message -----
From: "Jürgen Hoffmann" <jh...@byteaction.de>
To: "James Developers List" <se...@james.apache.org>
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 Grandes schrieb:
>> Hi Jürgen,
>>
>> Wow, you have described my life! :-)
>>
>> [...cut...]
>>> That described, the sysadmin installs JAMES, gets it up and running, and
>>> shows his boss. Boss is pleased until the next morning. The freaking
>>> automatic E-Mail is missing, "Admin! The billing did not run, I did not
>>> receive the status Mail!!! Check this immediatly!". The Admin checks,
>>> the
>>> Job ran, but no Mail. WHY Lord WHY? "Oh I know, I installed the James
>>> Server. Let me check the Logs." "Hmmm, there is it. Aha, it is not RFC
>>> compliant. Boss, I found the problem! The Status Mail was not RFC
>>> Compliant!" Boss: "Huh? What the ... well, then fix it!" That said, he
>>> keeps thinking "What is the RFC?"
>> [...cut...]
>>
>>> 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 Guillermo Grandes <gu...@gmail.com>.
> 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 installations.
hehehehehehe... :-)
well, well, it already supposed it :-)
Then I am happy that you are the Norman's Boss :-)
> As I showed my Boss is *not* really a technology person :)
Then, my Boss is like your Boss ("RF... what?"). Oops! :-)
> And as I believe that there are other lifeforms in the universe, I knew
> there was some admin that must have the same problems we have :)
Yes, sometimes I would like to return to be an amoeba (joke). :-D
Greetings,
Guillermo
---------------------------------------------------------------------
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,
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 installations.
As I showed my Boss is *not* really a technology person :)
And as I believe that there are other lifeforms in the universe, I knew
there was some admin that must have the same problems we have :)
Kind regards
Juergen
Guillermo Grandes schrieb:
> mmm... well, I have imagination... both are byteaction....
> family?
> the "evil" boss?
> the suffered sysadmin?
> another suffered developer?
> the reincarnation of Elvis?
> ok, ok, I surrender :-)
>
> Have a nice day! :-)
> Guillermo
>
> ----- Original Message ----- From: "Jürgen Hoffmann" <jh...@byteaction.de>
> To: "James Developers List" <se...@james.apache.org>
> 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 Grandes schrieb:
>>> Hi Jürgen,
>>>
>>> Wow, you have described my life! :-)
>>>
>>> [...cut...]
>>>> That described, the sysadmin installs JAMES, gets it up and running,
>>>> and
>>>> shows his boss. Boss is pleased until the next morning. The freaking
>>>> automatic E-Mail is missing, "Admin! The billing did not run, I did not
>>>> receive the status Mail!!! Check this immediatly!". The Admin
>>>> checks, the
>>>> Job ran, but no Mail. WHY Lord WHY? "Oh I know, I installed the James
>>>> Server. Let me check the Logs." "Hmmm, there is it. Aha, it is not RFC
>>>> compliant. Boss, I found the problem! The Status Mail was not RFC
>>>> Compliant!" Boss: "Huh? What the ... well, then fix it!" That said, he
>>>> keeps thinking "What is the RFC?"
>>> [...cut...]
>>>
>>>> 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
>
> !EXCUBATOR:1,452561fe53071523320701!
---------------------------------------------------------------------
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 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! :-)
>
> See also mail:
> Subject: Re: [jira] Commented: (JAMES-648) Corrupted MIME message [...]
> Sent: Tue, 3 Oct 2006 22:25:01 +0200
>
> really I am surprised.
>
> Thanks,
> Guillermo
>
> ----- Original Message ----- From: "Jürgen Hoffmann" <jh...@byteaction.de>
> To: "James Developers List" <se...@james.apache.org>
> 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 it, test it a
>> bit,
>> and say woohooo this is what I need. This is in most cases only the first
>> step. The next burden is, that you have to tell your boss about it. He
>> says "Nah, why should I change something that is working?" The Admin
>> says,
>> "because it can do what postfix does, ... AND MORE!" Boss: "Well ok, let
>> us give it a try."
>
>> That described, the sysadmin installs JAMES, gets it up and running, and
>> shows his boss. Boss is pleased until the next morning. The freaking
>> automatic E-Mail is missing, "Admin! The billing did not run, I did not
>> receive the status Mail!!! Check this immediatly!". The Admin checks, the
>> Job ran, but no Mail. WHY Lord WHY? "Oh I know, I installed the James
>> Server. Let me check the Logs." "Hmmm, there is it. Aha, it is not RFC
>> compliant. Boss, I found the problem! The Status Mail was not RFC
>> Compliant!" Boss: "Huh? What the ... well, then fix it!" That said, he
>> keeps thinking "What is the RFC?"
>
>> So the Admin goes on, and checks the configuration, maybe he missed
>> something. nope, everything there. So he opens up a bug report. He gets
>> told "This is no Bug, this is a feature!". He suggests "Can we make it
>> configurable? I really love James, and would really like to use it... I
>> even wrote a patch!" The Commiters say "Hey, cool yes. We can do that ...
>> wait, no we can't, because we break the RFC, and we really do not want
>> that, sorry"
>>
>> So the Admin goes, tells his boss, what he was told, and the Boss says
>> "Well, if we cannot do it with JAMES, put the other stuff back online!"
>> The Admin tries to consider James one more time, "... but Boss, the nice
>> Extensibility, Mail Processing" Boss: "Admin! Enough of that Nonsense!
>> You
>> said it could do what the old setup did, and MORE! Not LESS! Leave it
>> with
>> the old setup!".
>
> [...cut...]
>
>> 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
>
> !EXCUBATOR:1,45250be653071648660548!
---------------------------------------------------------------------
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 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 statement is fine, isn't it? And it reflects what everybody
wants, right? We have compliance configured by default, with the option
to enable the handling of common RFC violations.
The question at hand is, what do you want to achieve. Is it to be the
strictest Mailserver out there, only allowing RFC compliant conversations?
Noel suggested, that the documentation to configure non-RFC compliance
should neither be inside the configuration file, nor in the website.
Is this really what you want? Who are you programming JAMES for? The
afore mentioned design objectives only speak about the server itself,
not about the context it will be used with, or what for.
The Truth is, JAMES is an E-Mail Server and as such, it is used to do
conversations, and to process and deliver E-Mail. In a perfect world,
each client and server vendors would have read the RFC, and obeyed it to
the bitter end, just like you do. Experience shows, that everyday Life
is different. There are buggy implementations out there, that send bogus
Mails and such. If James cannot deliver those, people are not going to
use it.
If it is possible, to configure James, to accept non-compliant E-Mails,
but the Documentation is burried in some big ancient
*NotToBeOpenedOrBeDoomed* Tomb, people are not going to use it. Just
today, another James enthusiast has turned its back on James, because he
cannot use it in an everyday world scenario!
So who do you write the software for? Is this just a project that is
existing, to proof that it is possible to obey to all RFC Rules? Is it
just a Proof of Concept?
I have finished a couple of projects in the past couple of years. My
biggest goal was it, to program software, that people can use, and that
makes their day-to-day life easier, not harder.
Imagine yourself being a sysadmin. You use Microsoft IIS, qmail, or
postfix at the moment. The Software is doing its Job, but you could
extend it here and there. So you look into the qmail source and think
"What the Heck? Who is this Bernstein Freak and what was he thinking?"
then you look into postfix and think hey, this looks better, but C is
far to complex for my easy tasks. Then you try to look at IIS and ...
well nothing to be tweaked legally there ;).
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 it, test it a
bit, and say woohooo this is what I need. This is in most cases only the
first step. The next burden is, that you have to tell your boss about
it. He says "Nah, why should I change something that is working?" The
Admin says, "because it can do what postfix does, ... AND MORE!" Boss:
"Well ok, let us give it a try."
That described, the sysadmin installs JAMES, gets it up and running, and
shows his boss. Boss is pleased until the next morning. The freaking
automatic E-Mail is missing, "Admin! The billing did not run, I did not
receive the status Mail!!! Check this immediatly!". The Admin checks,
the Job ran, but no Mail. WHY Lord WHY? "Oh I know, I installed the
James Server. Let me check the Logs." "Hmmm, there is it. Aha, it is not
RFC compliant. Boss, I found the problem! The Status Mail was not RFC
Compliant!" Boss: "Huh? What the ... well, then fix it!" That said, he
keeps thinking "What is the RFC?"
So the Admin goes on, and checks the configuration, maybe he missed
something. nope, everything there. So he opens up a bug report. He gets
told "This is no Bug, this is a feature!". He suggests "Can we make it
configurable? I really love James, and would really like to use it... I
even wrote a patch!" The Commiters say "Hey, cool yes. We can do that
... wait, no we can't, because we break the RFC, and we really do not
want that, sorry"
So the Admin goes, tells his boss, what he was told, and the Boss says
"Well, if we cannot do it with JAMES, put the other stuff back online!"
The Admin tries to consider James one more time, "... but Boss, the nice
Extensibility, Mail Processing" Boss: "Admin! Enough of that Nonsense!
You said it could do what the old setup did, and MORE! Not LESS! Leave
it with the old setup!".
To make my point clear. I really like the way you guys care about the
design of james. But really. In everyday life, it is hard enough to get
people to really like your product. And for the people liking your
product, it is a lot of work, to put JAMES to work inside a grown
Environment.
Fact is, most people already have a Mailserver. If you exchange it with
some other box, the new box has to do a better job, than of what the old
box did. Why else would one change it, right?
So sometimes, as a programmer, you have to step aside, from your own
desires of a product, and see the people using the piece of software,
that use it to solve their problems, and not to create them new ones.
Make their life easier, and more and more people will use this great
piece of software you have developed for them (not you).
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>.
Danny Angus wrote:
> On 05/10/06, Bernd Fondermann <be...@googlemail.com> 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 the issue.
> IMHO It should be highly visible, and contain a simple disclaimer.
> perhaps such as...
>
> "Certain features allow Apache James to handle mail which has been
> constructed or sent by a broken piece of software.
> This feature permits James to handle messages which do not comply with
> RFC XXXX para Y.Y
> This feature has been disabled by default because James developers
> intend that James itself complies with the relevant published
> standards in the form in which it is distributed.
> The James project's policy is to encourage the developers of other
> email software to comply with published standards. It is only by all
> parties conforming to published standards that interoperability can be
> guaranteed, this is a fundamental feature of the internet.
> You are free to enable this feature which has been developed for your
> benefit as carefully as any of James' other features."
>
> d.
+1
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 Norman Maurer <nm...@byteaction.de>.
Stefano Bagnara schrieb:
> Danny Angus wrote:
>> On 05/10/06, Bernd Fondermann <be...@googlemail.com> 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 the issue.
>> IMHO It should be highly visible, and contain a simple disclaimer.
>> perhaps such as...
>>
>> "Certain features allow Apache James to handle mail which has been
>> constructed or sent by a broken piece of software.
>> This feature permits James to handle messages which do not comply with
>> RFC XXXX para Y.Y
>> This feature has been disabled by default because James developers
>> intend that James itself complies with the relevant published
>> standards in the form in which it is distributed.
>> The James project's policy is to encourage the developers of other
>> email software to comply with published standards. It is only by all
>> parties conforming to published standards that interoperability can be
>> guaranteed, this is a fundamental feature of the internet.
>> You are free to enable this feature which has been developed for your
>> benefit as carefully as any of James' other features."
>>
>> d.
>
> +1
>
> Stefano
+1
Norman
---------------------------------------------------------------------
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 Danny Angus <da...@gmail.com>.
On 05/10/06, Bernd Fondermann <be...@googlemail.com> 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 the issue.
IMHO It should be highly visible, and contain a simple disclaimer.
perhaps such as...
"Certain features allow Apache James to handle mail which has been
constructed or sent by a broken piece of software.
This feature permits James to handle messages which do not comply with
RFC XXXX para Y.Y
This feature has been disabled by default because James developers
intend that James itself complies with the relevant published
standards in the form in which it is distributed.
The James project's policy is to encourage the developers of other
email software to comply with published standards. It is only by all
parties conforming to published standards that interoperability can be
guaranteed, this is a fundamental feature of the internet.
You are free to enable this feature which has been developed for your
benefit as carefully as any of James' other features."
d.
---------------------------------------------------------------------
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 Bernd Fondermann <be...@googlemail.com>.
> 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.apache.org/jira/browse/JAMES-642 . We can move it later..
+1, although I don't like doing something temporary and starting
discussing that minor thing all over again in a few weeks.
does anyone see the need for a more formal vote about the patch and/or
the policy? if yes, please speak up now.
Bernd
---------------------------------------------------------------------
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>.
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...
> And yes I fully agree with you.
> So i whould temporary add the patch posted at:
> http://issues.apache.org/jira/browse/JAMES-642 . We can move it later..
>
> bye
> Norman
+1
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 Norman Maurer <nm...@byteaction.de>.
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-compliant behaviour.
>
> Well, this statement is fine, isn't it? And it reflects what everybody
> wants, right? We have compliance configured by default, with the
> option to enable the handling of common RFC violations.
>
> The question at hand is, what do you want to achieve. Is it to be the
> strictest Mailserver out there, only allowing RFC compliant
> conversations?
>
> Noel suggested, that the documentation to configure non-RFC compliance
> should neither be inside the configuration file, nor in the website.
>
> Is this really what you want? Who are you programming JAMES for? The
> afore mentioned design objectives only speak about the server itself,
> not about the context it will be used with, or what for.
>
> The Truth is, JAMES is an E-Mail Server and as such, it is used to do
> conversations, and to process and deliver E-Mail. In a perfect world,
> each client and server vendors would have read the RFC, and obeyed it
> to the bitter end, just like you do. Experience shows, that everyday
> Life is different. There are buggy implementations out there, that
> send bogus Mails and such. If James cannot deliver those, people are
> not going to use it.
>
> If it is possible, to configure James, to accept non-compliant
> E-Mails, but the Documentation is burried in some big ancient
> *NotToBeOpenedOrBeDoomed* Tomb, people are not going to use it. Just
> today, another James enthusiast has turned its back on James, because
> he cannot use it in an everyday world scenario!
>
> So who do you write the software for? Is this just a project that is
> existing, to proof that it is possible to obey to all RFC Rules? Is it
> just a Proof of Concept?
>
> I have finished a couple of projects in the past couple of years. My
> biggest goal was it, to program software, that people can use, and
> that makes their day-to-day life easier, not harder.
>
> Imagine yourself being a sysadmin. You use Microsoft IIS, qmail, or
> postfix at the moment. The Software is doing its Job, but you could
> extend it here and there. So you look into the qmail source and think
> "What the Heck? Who is this Bernstein Freak and what was he thinking?"
> then you look into postfix and think hey, this looks better, but C is
> far to complex for my easy tasks. Then you try to look at IIS and ...
> well nothing to be tweaked legally there ;).
>
> 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 it, test
> it a bit, and say woohooo this is what I need. This is in most cases
> only the first step. The next burden is, that you have to tell your
> boss about it. He says "Nah, why should I change something that is
> working?" The Admin says, "because it can do what postfix does, ...
> AND MORE!" Boss: "Well ok, let us give it a try."
>
> That described, the sysadmin installs JAMES, gets it up and running,
> and shows his boss. Boss is pleased until the next morning. The
> freaking automatic E-Mail is missing, "Admin! The billing did not run,
> I did not receive the status Mail!!! Check this immediatly!". The
> Admin checks, the Job ran, but no Mail. WHY Lord WHY? "Oh I know, I
> installed the James Server. Let me check the Logs." "Hmmm, there is
> it. Aha, it is not RFC compliant. Boss, I found the problem! The
> Status Mail was not RFC Compliant!" Boss: "Huh? What the ... well,
> then fix it!" That said, he keeps thinking "What is the RFC?"
>
> So the Admin goes on, and checks the configuration, maybe he missed
> something. nope, everything there. So he opens up a bug report. He
> gets told "This is no Bug, this is a feature!". He suggests "Can we
> make it configurable? I really love James, and would really like to
> use it... I even wrote a patch!" The Commiters say "Hey, cool yes. We
> can do that ... wait, no we can't, because we break the RFC, and we
> really do not want that, sorry"
>
> So the Admin goes, tells his boss, what he was told, and the Boss says
> "Well, if we cannot do it with JAMES, put the other stuff back
> online!" The Admin tries to consider James one more time, "... but
> Boss, the nice Extensibility, Mail Processing" Boss: "Admin! Enough of
> that Nonsense! You said it could do what the old setup did, and MORE!
> Not LESS! Leave it with the old setup!".
>
> To make my point clear. I really like the way you guys care about the
> design of james. But really. In everyday life, it is hard enough to
> get people to really like your product. And for the people liking your
> product, it is a lot of work, to put JAMES to work inside a grown
> Environment.
>
> Fact is, most people already have a Mailserver. If you exchange it
> with some other box, the new box has to do a better job, than of what
> the old box did. Why else would one change it, right?
>
> So sometimes, as a programmer, you have to step aside, from your own
> desires of a product, and see the people using the piece of software,
> that use it to solve their problems, and not to create them new ones.
> Make their life easier, and more and more people will use this great
> piece of software you have developed for them (not you).
>
> 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...
And yes I fully agree with you.
So i whould temporary add the patch posted at:
http://issues.apache.org/jira/browse/JAMES-642 . We can move it later..
bye
Norman
---------------------------------------------------------------------
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 Bernd Fondermann <be...@googlemail.com>.
+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 <ap...@bago.org> wrote:
> 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 and Joachim are in favor of permitting the behavior.
>
> 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!
>
> Clients issue that commands, not servers.
>
> > I am against supporting specification violations, even as an option, except *maybe* in the case that there is such a widespread issue that everyone's transport capabilities are compromised. Postal's Law doesn't mean to ignore mandated behavior. RFC 2821 is quite clear that the brackets must always be present for MAIL and RCPT. Are we as a community changing to say that specification compliance is no longer important?
>
> 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.
>
> It is not so clear that accepting a MAIL FROM or an RCPT TO without
> brackets is a violation to the RFC. It is for sure a violation to send
> that commands.
>
> I would agree with your position if we were talking about sending the
> branckets in the MAIL FROM our remote delivery issue when sending an
> email: this would be a "specification violations".
>
> The same thing would be if the specification said "the server MUST NOT
> accept MAIL FROM: " with not compliant attributes: this thing has not
> been written in the specification, so we are compliant anyway.
>
> As another example, the RFC say:
> | Several commands (RSET, DATA, QUIT) are specified as not permitting
> | parameters. In the absence of specific extensions offered by the
> | server and accepted by the client, clients MUST NOT send such
> | parameters and servers SHOULD reject commands containing them as
> | having invalid syntax.
>
> As you can see they enforce the client to operate in a specific way, but
> say the the server "SHOULD" reject badly composed commands instead of
> using a "MUST reject".
>
> So I think that I never changed my mind on specification compliance: we
> seem to have a different Idea on what does it mean to be specification
> compliant.
>
> Imho the key is interoperability: adding the feature does not make James
> non-compliant and give it more interoperability, so I put a +1.
>
> > As for a possible solution, the "fast fail" chain is really about in-protocol plug-ins, not just fast fail. If someone wants to write a command handler to repair defective addresses for MAIL and RCPT, that's their option. JAMES is open source. If someone wants to violate the specification, they can manage their own changes.
> >
> > --- Noel
>
>
> Well saying that the user can write code to alter the behaviour is not a
> solution: we are an opensource project, using this reasoning we could
> close every JIRA issue saying that the user can fix it. The can also
> write their own smtp server...
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
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>.
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: 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:
>> 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, mentioning (for example): "a mailbox and domain, always surrounded by "<" and ">" brackets". Furthermore, section 4.1.2 allows no misinterpretation. Those are REQUIRED characters. There is no ambiguity in the specification.
It is no ambiguos but this is a requirement for who WROTE that commands.
If we wrote that commands we MUST follow the specification.
>> It is not so clear that accepting a MAIL FROM or an RCPT TO without
>> brackets is a violation to the RFC.
>
> I disagree.
Well, we may disagree, this is not a problem, BUT we cannot generalize
about supporting or not supporting specification violations.
So we are not disgressing about allow or not specification violation,
but we are comparing our interpretations of an RFC and the Postal's Law
applied to it.
I don't think that voting +1 JAMES-642 means that I'm voting +1 on a
specificaion violation. And this is why.
Btw I can live even without having a rule of thumb for this issues: we
can vote for each of them so we don't have to discuss our
interpretations but simply count votes.
>> So I think that I never changed my mind on specification compliance: we
>> seem to have a different Idea on what does it mean to be specification
>> compliant.
>
> Well, that's a good thing. We're agreeing that spec compliance is still mandatory.
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 (see for example the
multihomed MX issue a.k.a. "singleIPperMX" option in dnsserver).
And I also think that interpreting the RFC about topics already covered
by 99% of servers should deserve some sort of attention to what the much
OLDER 99% of servers did regarding this issue. Often where the RFC was
not clear enough the world ends up defining a de-facto standard.
And, again, about our bracket issue I could change my mind if anyone can
bring me examples where we would fail to deliver a message or deliver a
message to the wrong destination because of this relaxed interpretation:
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?
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>.
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 allowed for clients and servers, it so indicates, as you noted elsewhere.
> 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, mentioning (for example): "a mailbox and domain, always surrounded by "<" and ">" brackets". Furthermore, section 4.1.2 allows no misinterpretation. Those are REQUIRED characters. There is no ambiguity in the specification.
> It is not so clear that accepting a MAIL FROM or an RCPT TO without
> brackets is a violation to the RFC.
I disagree.
> So I think that I never changed my mind on specification compliance: we
> seem to have a different Idea on what does it mean to be specification
> compliant.
Well, that's a good thing. We're agreeing that spec compliance is still mandatory.
As for an acceptable change, I suggested twice:
> we have a place in the code path where a plug-in could repair invalid addresses.
> We should not pollute our code with specification violations. If [we] want to
> help the user, [let's write] a sample command handler for MAIL and RCPT that
> repairs the addresses before the real handlers are called.
As previously, noted, that would be a worthwhile exercise on our part to make sure that our implementation of the protocol handler mechanism and configuration is flexible enough to support the notion, even if the plug-in, itself, is rather bogus. I am opposed to polluting the main handlers to logic to deal with spec violations.
--- 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>.
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 and Joachim are in favor of permitting the behavior.
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!
Clients issue that commands, not servers.
> I am against supporting specification violations, even as an option, except *maybe* in the case that there is such a widespread issue that everyone's transport capabilities are compromised. Postal's Law doesn't mean to ignore mandated behavior. RFC 2821 is quite clear that the brackets must always be present for MAIL and RCPT. Are we as a community changing to say that specification compliance is no longer important?
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.
It is not so clear that accepting a MAIL FROM or an RCPT TO without
brackets is a violation to the RFC. It is for sure a violation to send
that commands.
I would agree with your position if we were talking about sending the
branckets in the MAIL FROM our remote delivery issue when sending an
email: this would be a "specification violations".
The same thing would be if the specification said "the server MUST NOT
accept MAIL FROM: " with not compliant attributes: this thing has not
been written in the specification, so we are compliant anyway.
As another example, the RFC say:
| Several commands (RSET, DATA, QUIT) are specified as not permitting
| parameters. In the absence of specific extensions offered by the
| server and accepted by the client, clients MUST NOT send such
| parameters and servers SHOULD reject commands containing them as
| having invalid syntax.
As you can see they enforce the client to operate in a specific way, but
say the the server "SHOULD" reject badly composed commands instead of
using a "MUST reject".
So I think that I never changed my mind on specification compliance: we
seem to have a different Idea on what does it mean to be specification
compliant.
Imho the key is interoperability: adding the feature does not make James
non-compliant and give it more interoperability, so I put a +1.
> As for a possible solution, the "fast fail" chain is really about in-protocol plug-ins, not just fast fail. If someone wants to write a command handler to repair defective addresses for MAIL and RCPT, that's their option. JAMES is open source. If someone wants to violate the specification, they can manage their own changes.
>
> --- Noel
Well saying that the user can write code to alter the behaviour is not a
solution: we are an opensource project, using this reasoning we could
close every JIRA issue saying that the user can fix it. The can also
write their own smtp server...
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org