"Ronald F. Guilmette" <[EMAIL PROTECTED]> writes: > 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?
Mailman is one of, if not the most widely used mailing list manager on the Internet, serving out millions of messages/day. So no, it isn't a universal reference, but the fact that after all this time, and after all these messages, no one has had a problem with their single-recipient use of 'Precedence: bulk' does point to how insignificant this ``bug'' really is. Even though I don't have as strong an opinion on this issue as you do, I'll make you a deal. If you convince the Mailman folks to use 'Precedence: junk' in their single-recipient messages instead, I'll consider changing this in TMDA as well. We'll go out on a limb together. :-) > 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. I'm not as comfortable with false positives as you are apparently. > 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. I was using a null envelope sender in TMDA before that draft was written, so we arrived at that opinion independently, that there is no reason <> has to be used for only one purpose (MTA diagnostic messages). I still see no reason why it can't be used for other types of auto-responses. Its purpose is to reduce auto-responder loops, and it does this quite effectively. Next, no one has objected to the clause in the draft that allows use of <> during a year or so of discussion and review on the ietf-822 mailing list. You can say everyone there is also an idiot, etc, but at some point you'll just have to stop pouting and accept that many intelligent and knowledgeable people simply don't share your opinion on the matter. > 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.) But it's the closest thing we have to an RFC to govern auto-responder behavior. I'm not blindly following the document; I happen to agree with it, and TMDA was doing most of what it describes before it was even written. If you don't agree with it, please use the proper channels to get it amended. Venting on this list will do nothing to change it. > There is no published RFC for breathing, so I guess that you should > stop doing that now, since there is no RFC for it. My breathing or not breathing does not cause problems for other human beings. Software systems that don't follow standards become incompatible with other software systems. Trying to coerce individual implementors to rebuff standards will only create an interoperability nightmare. _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
