-------- Original Message --------
Subject: Re: bug in TMDA 1.0 and prior
Date: Thu, 01 Jan 2004 23:30:06 -0500
From: Lloyd Zusman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Ronald,
You have made some good points in your posts, including the one I'm quoting here. If the most important thing to you is for people to thoughtfully consider your arguments, I have some suggestions for how you can improve the way you express these points.
Unfortunately, you are giving many of us the impression (which I hope is a false one) that the technical points you raise might be less important to you than to simply be publicly contentious.
I've interspersed a few comments to point out some more constructive, useful, and effective ways for you to express your technical arguments ...
"Ronald F. Guilmette" <[EMAIL PROTECTED]> writes:
In message <[EMAIL PROTECTED]>, you wrote:
[ ... ]
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.
You sound immature and childish here. A better way to express this would be this:
I disagree that Mailman is that widely used. I believe that Majordomo and Lsoft LISTSERV are used more. I've never even heard of Mailman.
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?
To make your final sentence sound better, leave off the "now was it?". Those three words serve no useful purpose, and they cause people to lose respect for you.
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''.
Again, you are clouding the technical issues you are trying to express by starting your last sentence with the immature "And I hope that I don't have to explain again how ..." Leave that off. Your use of "in any sense" also gives that same impression of you.
So no, it isn't a universal reference,
At least we agree on _something_.
Better if you said this:
I'm glad we agree on this.
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).
No problem here. You have refrained from _ad hominem_ characterizations, and these past two paragraphs of yours make you look a lot more mature and respectable. I applaud you here! Keep up the good work.
[ ... ]
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.
I'm afraid that you stumbled here, Ronald. You were starting to do well. By deliberately misquoting someone, even rhetorically to make a point, you are walking on thin ice to begin with. And to do it using the terms "stupid" and "obviously stupid" as you did, makes it appear like the most important thing to you is to try to pick a fight, and it looks as if you don't care if anyone takes your points seriously. The "you have a brain of your own, and I suggest you use it" just adds to that picture of you. Here's a better way to say this, if you indeed want it to be considered thoughtfully:
I know that some other software uses "bulk" for single-recipient messages, as well. However, I still believe that the word "bulk" is not appropriate in this case.
People will pay more attention to you if you write this way, Ronald. And the wording above doesn't detract from your technical points at all.
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".
You slipped again, Ronald, I'm afraid. Here are a couple of sentences in your previous paragraph that make you look childish:
"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."
"(Hopefully, you are smarter than them, and more immediately capablle of comprehending, after consulting your local New Webster's Dictionary, that one message != "bulk"."
Here's my suggested way of rewriting that paragraph:
I'll be happy discuss the matter with the Mailman folks. I'll go to Google and find out how to contact them. But in the mean time, whatever Mailman and other pieces of software might do, I'm hoping to convince you that TMDA should not be using "bulk". Let's keep discussing that here.
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.)
You did a good job here, Ronald. I applaud you again! You stuck to the issue at hand and refrained from insulting the people you're talking to. And you were very successful at expressing your desperation with the current state of email, which many of us share.
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.
You made a few good points here, but you stumbled again and let a number of childish things slip in. Here are my suggestions to make this better:
- Leave out "Why?", "Does it help anything to do that?", and "No, it doesn't. Quite the opposite." Just start with this:
I believe that using a null envelope sender address ... etc. ...
- Leave out the entire "You, and other people like you ..." paragraph. It sounds like once again you consider picking a fight to be more important than getting people to consider your points. Rewrite it like this:
The use of a null envelope hampers spam filtering efforts, and makes
them more difficult.- Completely leave out the paragraph starting with "I wouldn't mind so much of [sic] there was at least one ..." It sounds immature, and it's repetitious. Rewrite it like this:
I haven't come across any good reasons for doing this.
- Leave out "... any dummy can understand that ..." This is more of your immature-sounding writing. Rewrite the paragraph like this:
And in fact, it provides less information where I believe that MORE
information is necessary.- In the final paragraph, leave out the last part, starting with "... your use of them in the context ..." and going to the end of that paragraph. Again, this is an immature characterization of the reader which detracts from the points you are making. Try saying it this way:
Although the use of null envelope sender addresses might be more
convenient (software-wise) on the sending side, it makes things more
difficult on the recipient side, and that's what I'm objecting to
here.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?
Leave out all three of these paragraphs. They serve no purpose other than to mark you as being someone who is difficult to respect. But if you want to express something here, the following would work well:
When thinking about this, did you take the receiving side into consideration? If so, what was your reasoning?
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?
All three of your paragraphs are totally redundant, and your childish phrases such as "Of course you dont", "you are still in denial", "you just plain screwed this up", cause people to not want to read beyond them.
But sometimes repetition can serve a good purpose, so if you want to make your points here again, I would just use the second paragraph "as is", and rewrite the third paragraph slightly, as follows:
Is there some pragmatic functional advantage to anonymous envelope senders that perhaps I have not considered?
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'.
This is more immaturity. Rewrite it like this:
Consider the "vacation" program and other commonly used pieces of software that are able to avoid auto-responder loops without the use of a null envelope sender. Couldn't you utilize the tecniques that are used in these programs?
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.)
Your final parenthetical sentence makes people wonder about something: you have spent more time and effort in repetitive and often childish writing here than it would take to concisely make your technical arguments in the ietf-822 list. This gives the typical reader the impression that you care more about picking fights than to engage in constructive work. So leave out that final parenthetical sentence.
As a matter of fact, you would be well served to leave out all three sentences, and to rewrite this as follows:
Well, that's a good suggestion. I'll go to that list.
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.
More immaturity. Rewrite as follows:
No, I don't. And I'm sorry if I gave that impression here. I'll go there and bring this to their attention, and I'm optimistic that we can have a constructive discussion about this.
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?
All five paragraphs make you look like a teenager with a chip on your shoulder, who doesn't care if people take him seriously. Rewrite as follows:
Well, perhaps I'm missing something, but I truly believe that the draft has overlooked some important points.
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.
I wouldn't change anything here. Good job. I applaud you again for refraining from using personal insults!
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.
OOPS! You slipped up again, Ronald. You said almost the same thing that you said above, only this time, more childishly. If you feel the need to repeat your point, try it this way:
Well, as I mentioned, this is still just a draft for discussion, not an RFC that has to be followed. That's why I'm discussing it ... although I agree with you that the ietf-822 list is a more appropriate place, and I will be going there soon.
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.
Well, this contains some more childishness. Rewrite as follows:
Well, I guess I shouldn't have said, "There is no published RFC for breathing" in the first place, because I can see now from your reply that my comment was non-sequitur that is leading us down a less-than-constructive path. I take that back, and I apologize for stating that as I did.
I just feel that the use of a null envelope sender is not the right decision, for the reasons I've outlined. I'll take this up with the ietf-822 list. Thank you for your useful and constructive discussion.
In summary, Ronald, you made some well-thought-out arguments, but almost all of them needed to be rewritten to make them sound less immature. But you also expressed yourself very well in a few places above, and I sincerely praise you for that. Just take the thought process that went into writing those paragraphs that I applauded, and apply that process to your other writing. You'll see positive results almost immediately, in that you'll see people taking your technical arguments much more seriously.
Don't give up, Ronald ... I know you can do it!
Happy New Year
-- Lloyd Zusman [EMAIL PROTECTED]
_____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
-- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ gpg: 6401 D02A A35F 55E9 D7DD 71C5 52EF A366 D3F6 65FE * porthos grumbles ... stinking virus writers <slackd> it's not so much the virus writers out there as it is the high-quality virus-reading software people have installed today
pgp00000.pgp
Description: PGP signature-- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
