At 9:31 PM -0600 2/10/2000, Mike Nolan wrote:
> Chuq, it would not surprise me if some percentage of your subscribers
> think HTML is the virus that causes AIDS.
I think I understand your sentiment here (and if not, we'll pretend I
do and not get into it...), but we've found, for whatever it's worth,
that the more naive the user, the more you can guarantee they're
using an HTML capable mail reader, even if they don't realize it.
Newer users don't often get hooked up to lynx and mailx.
> The solution I would like is a subscription process which recognizes
> whether a new subscriber can handle HTML or not and sends HTML-based
> messages out in HTML or plaintext, accordingly. However, I'm not sure that
> current subscription protocols have the ability to do that level of
> discrimination yet.
Funny you should mention that. You're right, you really can't tell.
You can't even assume that the mail client someone uses to subscribe
is the one they'll use to read mail, even if the mail client
identifies itself in the mail header. Not with all of the forwarding
systems out there, and if your lists are like mine, 10-15% of your
list forwards to someone through hotmail, and up to 20% of your list
goes through SOME forwarding/webmail system, whether it's hotmail,
bigfoot, yahoo, or name your favorite.
I'd love to do this. I have people who'd really, really love to have
it. Someday, I'll figure out a way, at least for some class of users.
But -- it's actually fairly easy to fix this, especially with VERP
technology. Simply sign someone up to HTML, ship out the HTML in a
MIME part, and in the message outside of the MIME area, put a "if you
see this message, then your mail client doesn't support HTML"
warning, and with VERPing, you can even include an encoded URL they
can use to tweak your database with a single click. I wish I could
say I thought this up, but Infobeat does most of this, and I think
it's a neat way to handle it -- especially if you add in the fix-me
URL with user encoding in it. that, IMHO, removes almost all of the
issue with whether to set people up with HTML or not, because they
can easily switch back if we break something.
now, for discussion lists like Michelle's or the ones I run, it's
still an issue, but if you really wanted, you could run parallel
lists, one HTML, the other textonly and run through demime, and
simply make sure stuff gets posted to both. In fact, now that I think
about it, maybe when I make the move to Sympa I'll do just that.
> And that doesn't necessarily deal with users who read
> mail from multiple locations,
Which is a very large number.
> though many of them are sophisticated enough
> that if a no-HTML subscription option was available they could choose
> for themselves.
Given how endemic hotmail is, and how widely it's used by the
techno-naive, that's not a safe assumption. Trust me on that.
> I'm almost to the point where I would like a web-based subscription
>form, with
> appropriate security measures to guard against automated mass attacks and
> e-mail confirmation, of course.
Funny, I'm not convinced the "of course" is a given. email
confirmations aren't a panacea. The busier the list, the more
necessary they are, but you have to be careful you aren't just moving
the problem to soe other place.
> And if I use cookies, I could then
> permit web-based users to post to my lists.
you know,there's a nice idea in there.
> Right now my web readers are
> read-only unless they subscribe via e-mail.
that's one reason I moved my web archives to web crossing. The
downside is that it uses it's own validation setup. The good news is
that it allows for external and LDAP authentification, so I can
(someday) write my own subscription/membership module and export
mailing list data and web authentifications out to everything from a
single source. Which'd be really cool.
--
Chuq Von Rospach - Plaidworks Consulting (mailto:[EMAIL PROTECTED])
Apple Mail List Gnome (mailto:[EMAIL PROTECTED])
And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"
