In message <[EMAIL PROTECTED]>, you wrote: >"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...
In the first place, no, I think you are confused about that. Ever hear of Majordomo? No? How about Lsoft LISTSERV? Mailman, whatever the hell it is, probably isn't even in the top ten, in terms of marketshare. In the second place, I think that you just proved my point for me. Yea, sure, *mailing list messages* should be labeled with "Precedence: bulk", because they _are_ bulk messages that get sent to MANY recipients. But that wasn't what we were discussing, now was it? We _were_ talking about one-shot auto-response messages. And I hope that I don't have to explain again how those don't qualify as being in any sense ``bulk''. >So no, it isn't a universal reference, At least we agree on _something_. > 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' I have. If that is indeed what they are using as a Precedence value for their *single recipient* automated response messaages, then such messages, when issues by Mailman, just won't make it past my spam filter (and probably won't make it past an increasing number of others). >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. :-) I don't accept your ``I'm going to keep on doing obviously stupid things until the other guy stops doing obviously stupid things'' conditionality. You have a brain of your own, and I suggest that you use it. One-shot single recipient messages are NOT bulk. Period. End of story. Nontheless, I am always willing to spend a few electrons and a few of my own cycles trying to educate various goofballs that can't seem to figure out the proper way to use e-mail headers, even when it is obvious. So if you tell me how to contact those Mailman folks, I am willing to discuss the matter with them. But as I say, the outcome of that should have no bearing at all on what _you_ elect to do. (Hopefully, you are smarter than them, and more immediately capablle of comprehending, after consulting your local New Webster's Dictionary, that one message != "bulk". >> 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. Each to his own. If you were getting flooded like I am, then you might start to accept more desperate solutions too. (And I am not alone. A _lot_ of people are getting desperate about e-mail these days. A lot of us just need to try, however lamely, to keep it useful for at least a few more months until the entire medium dissolves into utter chaos and anarchy.) >> 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, Why? Does it help anything to do that? No, it doesn't. Quite the opposite. Using a null envelope sender address on a given message actually provides LESS information to the person, and to the MTA, and to the spam filter that will receive the message. Less information means less capability, on the receiving side, to try to differentiate good (solicited) e-mail from bad (unsolicited) e-mail. You, and other people like you who are also misusing the null envelope sender address construct are actively hampering spam filtering efforts, and making them harder. I wouldn't mind so much of there was at least one adequately considered REASON for doing this, but there isn't. Nobody has ever put forward any reason why null envelope sender addresses MUST be used, in any given context, and nobody has even ever put forward any theory, vague or otherwise, which might serve as the basis for arguing that the use of null envelope sender addresses have any greater utilitarian value than explicit envelope sender addresses. And in fact, any dummy can understand that in most contexts (this one included) it is better to have MORE information to work with, rather than less. Although your use of null envelope sender addresses may be in some way ever-so-slightly more convenient (software-wise) on the sending side, your use of them in the context of auto-responses tends to support the view that you really don't give a damn about _recipient side_ considera- tions... something that you and spammers seem to have in common. >so we arrived at that opinion independently, that there is no >reason <> has to be used for only one purpose (MTA diagnostic >messages). And you are basing that opinion on what, exactly? Pure whim? Apparently. Hay now! Here's a novel idea! Rather than coming up with goofy opinions based on nothing whatsoever, why don't you _think_ about the pragmatic functional implications of what you are doing, e.g. on the receiving side? >I still see no reason why it can't be used for other types >of auto-responses. Of course you don't. Because you are still in denial over the fact that you just plain screwed this up. As I have already said, from the point of view of the RECEIVING side, more information is clearly better than less. Even if some recipients, and/or their software agents are not able to make any good use of the additional information, there are going to be those who _can_ make use of the additional information. So provide it. It doesn't cost you anything to do so, so why shouldn't you provide it. Is there some pragmatic functional advantage to anonymous envelope senders that I am not aware of? >Its purpose is to reduce auto-responder loops, and >it does this quite effectively. That's bull pucky. Other people and other autoresponders are able to avoid loops without using null envelope senders, thank you very much. Just because YOU may not know how to do this, that doesn't mean that it is impossible, or even very difficult. Maybe you should find a nearby UNIX system and type `man 1 vacation'. >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. I haven't because I have been busy on other things. But if you want me to, I will. (I hate having to take time out from my other work to correct other people's idiotic ideas, but I will if you insist.) >You can say everyone there is also an idiot, No. I don't. I'm sure that most of the people there are smart and would see this as a problem immediately if someone such as myself just brought it to their attention. > 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 Name three. So far, the only ones we know are you and that other bozo that wrote that draft (_without_ bothering to seek any outside input before he submitted it to IETF). Why didn't this clown at least have the good sense to run his draft past the people on the spamtools list before submitting it? He clearly doesn't have the sense that god gave a doughnut. Does he like not know that there is a spam problem on the Internet, or what? >> 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 It doesn't govern anything. It is just a draft for discussion, and a flawed one at that. Anyway, with respect to e-mail, the IETF doesn't call the shots anymore. Microsoft and AOL do. The IETF is largely irrelevant at this point. >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. For the last time, it is just a draft for discussion. It _isn't_ an RFC that either should be or must be followed. If you insist on following it, even when it is blatantly stupid and counterproductive, then the responsibility for THAT stupidity is your's, not the IETF's, and not that of the bonehead who wrote that draft. >> 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. You aren't following any ``standard'' so don't try to use that lame excuse. You are following one bonehead's screwy idea of what is correct, and that bonehead hasn't even provided any logical basis for his beliefs. Where I come from, we call that religion. _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
