atom feed46 messages in net.sourceforge.lists.courier-usersRe: [courier-users] RFC2045_ERR8BITHE...
FromSent OnAttachments
Ken NagorskiJan 16, 2002 2:35 pm 
Mark ConstableJan 16, 2002 6:49 pm 
Juha SaarinenJan 16, 2002 7:05 pm 
Aly S.P DharshiJan 16, 2002 7:12 pm 
Tomas FasthJan 17, 2002 1:19 am 
Odhiambo WashingtonJan 17, 2002 2:34 am 
Mark ConstableJan 17, 2002 3:11 am 
Marcus Felipe PereiraJan 17, 2002 6:22 am 
drea...@dreamwvr.comJan 17, 2002 7:33 am 
drea...@dreamwvr.comJan 17, 2002 7:52 am 
Gordon MessmerJan 17, 2002 8:07 am 
Aly S.P DharshiJan 17, 2002 8:11 am 
Papo NapolitanoJan 17, 2002 9:00 am 
Mark ConstableJan 17, 2002 12:26 pm 
Tomas FasthJan 17, 2002 1:47 pm 
Mark ConstableJan 17, 2002 3:35 pm 
Sam VarshavchikJan 17, 2002 3:53 pm 
Petr BurianJan 17, 2002 4:51 pm 
Marcus Felipe PereiraJan 18, 2002 6:26 am 
Alexei Batyr'Jan 18, 2002 9:01 am 
Roland SchneiderJan 18, 2002 9:24 am 
Bill WilliamsonJan 18, 2002 9:29 am 
Aly S.P DharshiJan 18, 2002 9:37 am 
William HueJan 18, 2002 9:58 am 
William HueJan 18, 2002 12:25 pm 
Petr BurianJan 18, 2002 1:09 pm 
William HueJan 18, 2002 1:42 pm 
YaremaJan 18, 2002 1:44 pm 
Sam VarshavchikJan 18, 2002 6:12 pm 
Mark ConstableJan 18, 2002 7:50 pm 
SysopJan 18, 2002 9:36 pm 
David EhleJan 18, 2002 9:55 pm 
Bill WilliamsonJan 18, 2002 10:01 pm 
Tomas FasthJan 19, 2002 9:41 am 
Tomas FasthJan 19, 2002 10:10 am 
Marcus Felipe PereiraJan 19, 2002 12:38 pm 
Mark ConstableJan 19, 2002 11:12 pm 
John LaurJan 20, 2002 1:21 pm 
Olivier PoitreyJan 21, 2002 2:46 am 
Alexei Batyr'Jan 21, 2002 5:37 am 
Olivier PoitreyJan 21, 2002 6:31 am 
Sam VarshavchikJan 21, 2002 8:14 am 
Stefan KrugerJan 23, 2002 8:21 am 
John KlossJan 23, 2002 8:30 am 
Sam VarshavchikJan 23, 2002 3:11 pm 
Chester WisniewskiJan 23, 2002 3:50 pm 
Subject:Re: [courier-users] RFC2045_ERR8BITHEADER and RFC2045_ERR8BITCONTENT
From:Tomas Fasth (tom@euronetics.se)
Date:Jan 17, 2002 1:47:41 pm
List:net.sourceforge.lists.courier-users

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.