james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.de>
Subject Re: Change in policy to for JAMES to violate RFCs
Date Thu, 05 Oct 2006 05:43:55 GMT
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..


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message