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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
