ALL, Please don't feed the troll!
If Ronald doesn't like TMDA, he doesn't have to use it. Problem solved. Nobody is twisting his arm and making him use TMDA. More than a few of us have been using TMDA for close to 3 years, and have seen it grow from release to release. And when problems or bugs came up, Jason and Tim and countless other contributors were happy to hear them and work to address those issues. However, I have never seen anyone bring up an issue with an attitude as rude and incompetent as Ronald has. He could have very easily brought up his issues for discussion without needing to be so rude and condescending about it. Perhaps his goal here is to simply to start some controversial argument for the sake of having nothing better to do. But please stop feeding him with excuses to continue this thread with his lack of respect and maturity, and his obvious need to use language that is inappropriate. --- "Ronald F. Guilmette" <[EMAIL PROTECTED]> wrote: > > In message <[EMAIL PROTECTED]>, you wrote: > > >As discussed, there is no standard for Precedence, and no single > >common practice for use of it. Some auto-responders use 'junk' for > >single-recipient messages, while others use 'bulk'. TMDA has chosen > >'bulk' because 'junk' presents a risk that the former does not have. > > That's just horse shit, and I suspect you know it. > > You are pulling this alleged `risk' out of your own ass. You don't > have > any empirical data to support your silly theory that there are some > un- > known and unspecified filters out that which are blocking > "Precedence: bulk". > And even if you found some obscure and rarely used filter that did in > fact do that, you don't have any empirical data to support your silly > theory that "Precedence: junk" is blocked by filters more frequently > than > is "Precedence: bulk". > > >BTW, Mailman also uses 'bulk' in a single recipient context, for > >example, when it answers help requests. > > So you found a grand total of _one_ other mail-related package that > happens > to implement the exact same bug as you have implemented, and now, on > that > basis, you are declaring this other buggy package (Mailman) to be THE > universal reference for, and Holy Grail of e-mail usage standards? > > Clue: It isn't. It is just another package that has implemented the > exact same bug that TMDA has implemented. > > >Because of these discrepencies, no filter should rely on the value > of > >Precedence. > > Well, welcome to the Real World. > > The spam problem is bad enough now that a LOT of different criteria > that > are somewhat less than 100% reliable _are_ being used as a basis for > mail > filtering. > > >It's one thing to merely detect its presence in order to > >inhibit an auto-responder loop, but any further analysis is risky. > > Welcome to the Real World. > > Life is risk. > > >> 3) Last and worst, this message was sent using a null envelope > sender > >> address (represented here by "MAILER-DAEMON" which is how my own > >> local mail server interprets and re-writes null envelope sender > >> address). > > > >TMDA's use of a null envelope sender is perfectly in check with > >section 3.3 of the IETF draft `` Recommendations for Automatic > >Responses to Electronic Mail'' which you obviously have not read. > > I have read it, and it is a piece of garbage. > > The guy who wrote it is an idiot. He is just as ignorant with > regards > to proper usage of envelope sender address conventions as you guys > are. > > The only good news is that (thank God) that is just a draft for > comment. > It most certainly _is not_ an RFC. (Nor shall it ever be one until > that > particular part of it is corrected.) > > >> Because TMDA automated response messages fail to follow > >> well-established existing practice, not in one, or two, but in ALL > >> THREE of the different ways noted above, those messages, unlike > >> automated response messages from other and more well crafted > >> software, will NOT make it past either my filter, or other > >> intelligent junk filters that make some attempt to allow in > >> legitimate automated response messages. > > > >In fact, each of the ``screw-ups'' you mention have no backing in > >standards, > > There is no published RFC for breathing, so I guess that you should > stop > doing that now, since there is no RFC for it. > > Please proceed, at your convenience. > > >Overall, please do your homework before making such vicious and > >unsubstantiated criticisms. > > Please do your homework and find out what actual existing common > practice > is with respect to e-mail and automatically-generated e-mail messages > before you go off half-cocked, relying _only_ on the published RFCs, > and then write some software product that generates automated > responses > which, although perfectly consistant with the minimal requirements of > the RFCs, is nontheless perfectly INCONSISTANT with the majority of > actual practice. > _____________________________________________ > tmda-users mailing list ([EMAIL PROTECTED]) > http://tmda.net/lists/listinfo/tmda-users __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
