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
