OFFTOPIC Re: [Mailman-Users] Archive URL in postings (2.1b3)

[John Buttery]

* Chuq Von Rospach <chuqui at plaidworks.com> [2002-10-29 12:30:06 -0800]:
> On Tuesday, October 29, 2002, at 11:33  AM, John Buttery wrote:
> 
> >  "Lie" is kinda an interesting way to put it, but I think we all know
> >what he means.  How can you say that readdressing a mail (which is what
> >you're doing here) isn't a "lie" the way he's referring to it?  It's in
> >plain black and white.
> 
> we aren't re-addressing. We're standardizing the way the existing 
> addresses are presented.

  Sorry, I should have specified that I was defining "re-addressing" as
precisely that...although I would use the word "rearranging" rather than
"standardizing".  :)

> >>um, interesting philosophy. I don't buy it. Not for a moment.
> >
> >  Well, OK then, how would you differentiate this new behaviour from a
> >hypothetical message I might have sent pre-upgrade that _did_ have your
> >address in the To: and the list in the CC:?  Hint: you can't.
> 
> sure I can. If it went through the list server, it has a List-ID 
> attached. So it's clear which one came from where.

  Hmm, good point.  I still don't think it justifies the change, but
you're right.  You could make the argument that someone may get the list
posting and then wonder what happened to the other mail (the one that
was sent directly to them, as indicated by the To: field), but I guess
that's pretty nitpicky.

> >(Of
> >course, I acknowledge that sending a copy directly to a person who is
> >already subscribed to the list is a bit silly/redundant,
> 
> See, I don't agree with that, either. I've explained how I take 
> advantage of this in my filtering to continue discussions I'm involved 
> in without having to paw through all my list mail...

  I would say the "correct" (notice my use of quotes to denote opinion)
way to handle that situation would be to have your MUA identify the
messages you're interested in, in the list mailbox's listing...rather
than depending on getting a copy to your main inbox; I guess both our
points are valid here, though.

> >  Saying you "don't buy" something that someone has stated is their
> >opinion/feeling is indefensible.  :)
> 
> yeah, but when a situation is arguably a subjective decision in the 
> first place, sometimes it's all you get.

  Hah!  Touche.  :)

> >  When two mails are sent out, I'll get one filtered into my folder for
> >the list, and the other one sent to my main inbox; that's the way the
> >sender intended it, and that's the way I want it.
> 
> and if you filter on list-id, that's how you'll get it no matter who 
> does what to the to/cc/bcc. If you DON'T filter on list-id, you depend 
> on the end users doing what you expect them to do. That's a filtering 
> method guaranteed to fail randomly.
> 
> filtering list mail based on to/cc is a flawed approach. to argue that 
> we can't break what's broken by definition is a flawed argument. IMHO.

  Yeah, you're right about that.  Personally I configure procmail to
filter on every single header I can for each list, even though it's
overkill, so I'm not really affected by it...I was just making the
argument in principle, but it doesn't stand up.  (Except maybe for users
of Outlook* and other broken MUAs, but I'm already pretty tired of those
programs' authors' antics from being on the mutt mailing list for so
long...)

> >  True...but should be unecessary.
> 
> but it is, because it's the ONLY reliable filtering tool you have. the 
> others depend on people doing what you consider "right", so they fail 
> when those users don't. If anything, this new header format 
> rationalizes that so decisions by the end users can't break the 
> filtering, if you absolutely MUST use to/from/cc for some reason.

  That's a good point, and a solid argument for making the feature
configurable (as opposed to not having it at all).  Sort of like lists
that mangle the subject line to help out those same MUAs.  *cough* :)

> >Colorization of lines (based on whether your exact address is in the
> >headers somewhere) in a message index is another, and List-ID won't 
> >help
> >you on that one. :)
> 
> and if you'll notice, I haven't refuted that one. it's a point that 
> needs consideration.

  Well, this is kind of a lame way to make a point (I'm referring to
what I'm about to say, not what you said), but you could argue that
people who would turn on this sort of personalization to bootstrap their
MUA's inferior filtering capabilities are not likely to be able to take
advantage of the finer points of stuff like index colorizing, so it's a
moot point.  :p
  Personally, I think this particular eventuality would be addressed
excellently by putting YACV in there to make this particular behaviour
separate from the rest of the personalization. 

> >  But really, this is all getting away from the original philosophical
> >point that an address that a message was not sent to should not be 
> >faked
> >into the headers.
> 
> I'd argue whether that's true.
> 
> I guess I'm arguing that it's the end of the days of "bulk" mail, and 
> the beginning of the days of "mass" mail. There are significant 
> semantical differences and advantages. To use paper-mail analogies, 
> it's time to move from sending out everything to "Resident", and start 
> adding enough intelligence to the system so that it actually shows up 
> with your name on it.

  I completely see what you mean by that, but I think it's wrong.  :)
For most lists, anyway.  Maybe I just have an overly pragmatic mind, but
I see a real, discernable difference between "the list" and "the members
of the list".  I don't, and don't want to, think of this mailing list as
a set of people, I want to think of it as "the list".  Hmm, that doesn't
make any sense at all, does it?  Well, maybe I can't put my finger on
it, but there's something about having my actual address in the To:
field that fundamentally changes the way I see a message.  Funny how the
little things pop up.  I understand that the logic to put a person's own
address on each mail is more technologically advanced, but I just don't
think it should be done that way.
  Don't get me wrong, I fully support this feature as an option (as I
support _any_ feature as an option)...I'm sure there's times when it's
appropriate.  Just keep it away from me, please.  :) 

-- 
------------------------------------------------------------------------
 John Buttery
                                     (Web page temporarily unavailable)
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-users/attachments/20021031/b660ed0b/attachment.pgp