[IETF] Re: Adding [ietf] considered harmful

[Gene Gaines]

At last a meaningful remark, quoting from below (far below)...

> I cannot believe we are even having such a dumbass debate.

With apologies, I do not appreciate is the number of individuals
who have made observations based on their "personal experience"
concerning the SPAM subject.  Trading war stories does not
contribute to meaningful technical work, and in fact works
to the detriment of the IETF.

Gene Gaines
[EMAIL PROTECTED]
Sterling, Virginia USA

On Thursday, December 18, 2003, 12:00:37 PM, Mark wrote:


> Keith-

>> Putting [foo] in the subject header is just another example of this
>> trend.  Sure, it might be useful to people with dysfunctional MUAs,
>> and there are a lot of those people out there. There were once a lot
>> of people whose MUAs couldn't do "reply all", too.

> This is just wrong.

> "From" lines and "Reply-to" and whatever are headers that are meant to
> be processed by computers.  So, you can say all you want about how dumb
> MUAs do or do not process these (and how intermediate mail servers
> should keep their mits off).  Now, humans use these lines, too.  So,
> call them dual use.

> The subject line, on the other hand, is just for people.  Sure we can
> make programs and filters grok them to classify mail if there is some
> standard format (e.g., i-d actions).  But, fundementally subject lines
> are for humans, not computers.  So, comparing subject line munging to
> reply-to munging seems to me to pretty much apples and oranges.

> You might read the above as supporting your point that we should not add
> "[ietf]" to subject lines because subject lines are not for computers
> (or "dysfunctional MUAs") to process.  However, I think the correct
> interpretation is that it is OK for the mail server to add these tags
> **and** they may aid the entities that the subject line is actually for
> in the first place (humans).  Hence, they are fine.

> allman


> (I cannot actually believe I am sending a non-snide comment in this
> thread.  Someone should slap me.  I read through the whole thread last
> night.  Every message was dumberer than the previous one (probably
> including this one!).  I was literally laughing out loud.  I cannot
> believe we are even having such a dumbass debate.  But, it was like a
> wreck on the highway and I could not stop rubber-necking.  If we have
> this much trouble about 6 characters in the subject line then we might
> as well forget that problem statement thingy.  Really.)




-- 

Re: Hashing spam

[jfcm]

On 04:19 19/12/03, Keith Moore said:
Content-Transfer-Encoding: 7bit

It just strikes me as highly unlikely that a WG would ever change course
because of what would look like random comments from outsiders -- it's
not consistent with the dynamics of a WG, or with human nature.
and that just might be one of our biggest problems, in a nutshell.
True. From experience, the only real way I discovered to make a WG to
change its mind is to give it a rewarding R&D spirit and to work together
on experimentation, with a reverse pyramidal spirit. I mean: you say the
WG is to _solve_ a user documented problem with a real solution as a
demo, from a starting point (user documented so the target is not disputed
within the WG). Every outsider is welcome to explore new ways from
that staring point. these ways and blocking points are kept documented
in a sucess/failures/mailestones tree. So people may either try other
avenues or to fix failures. Also to compare global results between solution.
Often moving a failure within the tree makes it a solution.
What I find frustrating with the RFC system is that nothing final, proven,
validated at a given time so you can build on top. Only projects are final.
I would prefer a lore recipes orieted system where people could also say
"this is the way I do it (or updated it): feel free to help and copy". It 
would
have probably the same technical initial results but it would be more
rewarding and less blocking. WG would be dynamic clubs where to
concert about development, experimentations and compatibilities.

jfc