At 3:45 PM -0400 10/24/00, Jim Trigg wrote:
>What is VERP? That's an acronym I haven't seen before.
here's a reasonable explanation:
Basically, it's setting the return envelope to encode subscriber info
in it for bounce processing -- but to be honest, we're de facto
extending that to include all aspects of e-mail customization. At the
base level, it's sending out individual messages to every person on a
mail list as opposed to bulk-mailing to a list.
>That sounds nice, except that 50-75% of mail readers in common use
>cannot filter based on the Sender: header, let alone any particular
>header. They can filter on: To, From, Subject, Reply-To, or "any
so we shouldn't use any technology everyone can't use? We shouldn't
put the hooks into things to encourage other client programmers to
accept and use them?
you have to move things forward or they stagnate or die. Especially
in a case like this, where if they don't want to take advantage of
it, they don't have to. But should we not do this for the people who
do have the capability because some folks don't?
(in case it's not obvious, I don't but taht approach. I don't add
gizmos to my systems because they exist, but I don't hold back just
because some subset can't take advantage of them, either)
>Which is exactly the problem with using "List-ID" to identify that
>it's not personal email and should be sent to a separate sorting
but this is a case where the MLMs have to take a lead in promoting
the RFC. the clients aren't going to support it until the MLMs do
(why should they?), the MLMs have to put it out there so the client
programmers will know it makes sense to support it. Same with the
>Jim appears to be arguing from a perspective of "if the remailing
>agent isn't the originator, I care more about the remailing agent
>than the destination." I'm looking for a middle ground, but failing
>to find something that satisfies all of the requirements (short of
>writing my own MUA, and that's not a useful answer).
Interesting point, but let me take it in a slightly different
direction (oh, damn. Chuqui's gonna throw out another analogy). We
have those three pieces of data: who's it from, who's it to, and how
did it get there? From is simple -- the author goes in the from line.
We're arguing about which piece ought to be in the to:/Cc: line. The
person being sent the mail, or the list delivering it.
And sitting back and thinking about it a bit more, the answer
probably ends up "it depends".
If you view the MLM as the postman, does it make sense to put the
postman's name on the envelope instead of the final receipient?
Taht's effectively what most MLMs do today.
I now realize there's a nasty wrinkle in all this. I've been thinking
primarily from the point of view of announcement style lists (since
that's where most of my work is these days) -- that is literally the
on-line version of that Restoration Hardware catalog I used earlier.
However, with discussion lists, it's less clear. If you coerce the To
line, you lose the linkage back ot the list for replies, unless you
choose to include a coerced Reply-To. No, I won't go there. But you
have to have some linkage back to the list, which is where the postal
analogies break down. Restoration hardware doesn't get involved in
lengthy discussions with their catalog recipients via postal mail.
So it really looks like we're all right here, depending on
circumstance. you have:
announcement lists: Coerce To to end user, since they aren't intended to reply.
discussion lists: Coerce to: to end user, Coerce reply-to to list if
you want to noodge stuff through the list. Don't Coerce either if you
want to leave it up to the user where to reply.
I'd say, now that I think about it, that for most of my discussion
lists, I'd rather NOT coerce To/Reply-To on discussion lists than
coerce it just to make the To: line "right". But for
announcement-type lists, I still think coercing the To: line to the
end user is a win.
In other words, it's a dessert topping and a floor wax.
Chuq Von Rospach - Plaidworks Consulting (mailto:email@example.com)
Apple Mail List Gnome (mailto:firstname.lastname@example.org)
Be just, and fear not.