Mark, I think you're right, but your moment of disappointment seem to affect your judgement. It's a couple of patched lines of source code, nothing more. So what's the issue? Are you unable to compile a patched source tree yourself? Are you forbidden to tamper with open source by your employer? Do you have a policy of only installing binaries as distributed by a official distributor? I don't know about you but for me, the power of open source lies in precisely this: If you're unhappy with an author's point of view, go on and modify the source yourself, optionally share it with the community, and go on with your life. You can always argue with the author, but it's pointless to threaten to "abandon" his/her software unless s/he adhere to your point of view. S/he probably couldn't care less. To be specific, Courier is Sam, Sam is Courier. Courier is what Sam likes it to be. He is the supreme ruler in his little kingdom. It's not his fault that you consider to abandon his creation in favor of another similar creation. It's how you evaluate your own options. Maybe Sam will budge on this issue at some time in the future. Until then, you can still use courier-mta if you just can accept to maintain a patched courier-mta until Sam decides to add this configuration option into his source code tree.
Just my 2 (euro) cent. <tomas/> Mark Constable wrote: > On Fri, 18 Jan 2002 03:00, Papo Napolitano wrote: > >><RANT> >>WTF is going on with you ppl??? >>The question asked was "Is there any reason I can't just do a make >>install?", not "which mta is the best?" >></RANT> >> > > Thank you for answerring Kens original question. > > The reason he asked the question under this Subject, and the > other ~OT replies, are all relevant for this thread. The "which > mta is the best?" is in the context of replacing courier-mta to > fix a stupid "rule" that has a NEGATIVE impact of those responsible > for installing and managing this software. It's a bizarre situation > that I am compelled, even forced, to change software I am otherwise > completely happy with, even excited about because it solved my > greatest need to have authentication out of MySQL in a natural way > without... dare I say, patches and hacks. Finally I can manage > email resources for over a dozen servers and 6K clients sanely > and was looking forward to exploring couriermlm next. > > This issue is not going to go away. The more wisespread courier-mta > becomes the MORE this is going to become an issue and even in this > thread it's obvious quite a number of people avoid this "problem" > by using a different MTA (as well as for other misc reasons). > > The only argument I've seen for strict RFC compliant binary > attachement checking is that it's "the right thing to do" and it > _may_ allow client MUAs to crash. If that happens then the original > sender and the recipient can be "blamed" for using lame software > whereas the way things stand now... the MTA in the middle is > FORCING a policy upon ISPs and their clients that squarely puts > the MTA at "fault" as the culprit causing a "problem" where dodo > clients pretty (and obnoxious) backgrounds and attachements do not > appear as the client was led to expect. For me and others not using > courier-mta, this is/was a show stopper. If the clients MUA happens > to crash it's THEIR problem, get another MUA... the way things are > now it is the ISP in the middles problem... get another MTA ! > > The answer is so shit simple it's almost embarrasing to have to > even put it in words. If the official courier-mta distribution > could apply a (what!) 4 line patch and offer a run-time config > option to disable this checking then I suspect a lot more people > could happily run courier-mta... and these contentious messages > and threads will dissapear from this mailing-list. > > As for postfix and exim, I'm sure they are fine MTAs but in our > case our client data is firmly embedded in MySQL tables and I'm > not prepared to undo that (it took 5 years to get it so) and I > don't know if or how these other MTAs can do that whereas I do > have sendmail setup to use the same tables and could switch back > to it fairly easily. I would, however, much prefer to make a > simple call (ie; my choice) to simply edit esmtpd and uncomment > IGNORE_RFC2045=1 and have no more of these moronic complaints > coming from our clients. > > --markc > > _______________________________________________ > courier-users mailing list > [EMAIL PROTECTED] > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users > _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
