On Wed, 26 Mar 2003 11:23:18 -0800
Chuq Von Rospach <chuqui(_at_)plaidworks(_dot_)com> wrote:
On Wednesday, March 26, 2003, at 10:29 AM, Matt Sergeant wrote:
Q: Okay, what's the idea? A: Add something RSS-like to email
clients, where the client occasionally (and infrequently) polls
"subscribed" sites for new content
Hopefully Richard Bliss might not mind the credit for this idea going
elsewhere... http://www.newsgator.com/ (and that's probably not the
first implementation - just a very nice looking one).
It's not. Credit for RSS stuff probably circles back to Dave Winer,
among others. But the blogs have taken RSS onto their own, and a bunch
of folks are doing interesting things with RSS and that enables people
to do nice things with RSS aggregators. it's just starting to peek
over the horizon for most folks, but it's been building for a year or
more. Fascinating stuff.
Absolutely. I'm using Aaron's rss2email setup (as locally hacked) to
dump RSS feeds into my mail spool and thus thru procmail for key
word/signal/interest/etc filing. Very neat stuff.
It helps mitigate one of my biggest gripes about the high volume
discussion list, as well as enable people to keep an eye on what I
call "2nd tier" lists -- the interruption of e-mail being a push
technology, and the reality that most e-mail lists don't warrant being
pushed into people's eyeballs. With RSS, people can choose to pull
things on their schedule. Ultimately, I hope/expect the two
technologies to merge to allow people to manage their information
streams to their preferences.
I view this not as a transport problem, but a filtering and presentation
problem. It doesn't matter how or when the data gets to my system in
general terms, it matters how and when it is brought to my attention,
and what tools I have to readily pace and present that data to me.
Computers have all the time in the world and utter freedom to handle
scheduling asynchronously from me. I see no reason I need to build
automated systems wrapped around my archaic notions of time when that's
a UI/presentation/MVC problem.
I think it's an excellent idea, but not something we can force on
list sources. It's also worth noting that it's only for one-way
communication, so it doesn't help mailing lists.
Oh, sure it does. A bunch of us on the mailman dev lists hashed out
this stuff months ago, and one of us (out of the foxhole, Lawrence)
actually went an implemented a system that seems really pretty
good.
Eeek!
With Mailman as your email core, and web archives (based around
MHonarc) and RSS, you have a nice distribution setup. He then grafted
TDMA onto the front end, effectively whitelisting all of his mail
lists. So on the return mail, you can either subscribe, or you can go
through a challenge/response to get your message posted.
Some rapid high points, if you want details, ask:
1) Lists are run thru Mailman. This is significant only in the degree
and extent that TMDA directly supports reading Mailman subscriber
lists.
2) List traffic is archived via MHonArc which generates PHP pages (see
http://www.kanga.nu/archives/) The PHP pages have a reply feature
which generates messages with proper In-Reply-To and References
headers, as well as properly quoted messages bodies. See:
http://www.kanga.nu/archives/Meta-L/2001Q2/msg00134.php for an example
of a message written this way.
3) TMDA is setup in front of all lists, and all role addresses, using
the subscriber rosters for the lists as de facto whitelists. TMDA
then passes all subscriber mails straight thru to the list, but mail
from non-subscribers is held until confirmed (at which point you can
whitelist or not).
Results:
No more problems with posters from non-subscribed addresses. They
have a subscription to _GET_ mail and to define an allowed posting
address. They can (trivially) define additional allowed posting
addresses by just posting from them and confirming the post to get on
the whitelist. You're now essentially back in the old days of the
1980s when we could safely run open lists.
Almost all SPAM disappears. They don't confirm. How much is all? I
used to get 50+ spam per day per role address, and that's not counting
virus mail. Since installing this TMDA-based system its down to
single digits in the last year for spam and virus mail together for
ALL my role addresses combined..
either way, no spam, no moderator intervention, and users don't have
to go through the hassle of subscribing to post occasionally,
especially if they read it via RSS or web.
I haven't yet exported my list archives as an RSS feed. That's coming.
The current approach which is still in dev is:
Mailman list gated bi-directionally to moderated local newsgroup.
NNTP access is available with the spool containing the entire history
of the list (list members who want to data mine love this idea)
TMDA in front of the lists and inn2 etc as above.
Searchable web archives of newsgroup ala GMane (well, different
implementation).
Posting from web archives ala above.
Export of web archives via RSS/RDF with built-in URLs to the Reply-To
pages on the web archives.
Something I'm currently actively considering doing is having a
TMDA-filter in front of inn2 and rewriting all messages as they are
requested. Background:
TMDA allows for a number of special address types, the most useful of
which (for me) are:
-- Dated addresses which work for only a defined period, after which
they fall back to confirmation required, or auto-discard.
-- Sender addresses which work only for the specified sender address
after which they fall back to confirmation required or auto-discard.
What I'm considering is using TMDA to generate dated addresses to
replace all the email addresses in messages at request time (leaving
GECOS fields intact). The dated addresses would then auto-forward to
the original address within the date rage, and drop back to confirmation
required outside the date range.
It was one of the things that started changing my mindset on
whitelists, seeing how they could really enable open but secure
communication channels without the increasingly bizarre "anti spam"
restrictions us mail-list geeks have been coming up with to try to
keep the spammers at bay.
I have a couple thousand list members that have been subjected to my
experiments with TMDA. As they are primarily online game designers,
they're a rather technically savvy audience, even if not a terribly
Internet or email savvy group. In the last year plus since deploying
the above (not the rewrites, the list fronting etc) I've had zero
complaints or accusations of its being too complex, too invasive, too
confusing, or too difficult. In fact, I've received multiple
compliments, especially from my less technical members as to how easy
and obvious the process is.
Background stats for the last year plus:
To date I've had ~40 addresses confirm thru TMDA.
8 valid posts from 7 different addresses were not confirmed.
Breakdown:
-- Four reposted their messages from already
confirmed/subscribed addresses.
-- In one case a misconfigured mail systems at his ISP put an
invalid Return-Path on his messages so the TMDA confirmation queries
bounded.
-- One stated that he'd reconsidered his message after reading it in
the confirmation request, and had decided to not post it.
-- In the final case the domain fell off the net before I was able
to query/investigate.
Almost a dozen members have exclaimed at various lengths how easy,
simple, etc the system was (a few had previously stated how concerned
they were by it -- none that had expressed such a prior concern,
didn't also exclaim its simplicity and ease).
Total number of spam and virus email caught by the system in the last
year without human intervention or attention: more than 130,000.
Total number of spammers who successfully confirmed thru TMDA: One.
To handle I merely moved her address (richannm(_at_)attbi(_dot_)com for those
interested) from the whitelist to the blacklist.
Using TDMA basically kills any chance of forged header mail getting
through, so suddenly, your armed camp of a mail list doesn't need all
that barbed wire any more.
This is partially due to TMDA authenticating on envelope AND From:.
there was some talk of adding these features to Mailman down the road,
but it's still in talk stage. But he's got it up and running, and it
works, and one of these days, I plan on going down that same path.
Those that want to experiment I run a list expressly for this purpose:
test(_at_)kanga(_dot_)nu(_dot_) Email there and you'll receive a confirmation
message
etc.
It really shows what whitelists can do once you get over the "how dare
you ask ME for ID?" mental state -- and yes, it took me a while to get
over it, too... But once I did, I realized whitelists could make
various aspects of life much easier on all side, especially compared
to fuzzy gif schemes and all that other stuff.
<nod> I don't like non-automatic whitelist methods for interpersonal
mail. Making sure that my message gets thru to JoeBlow in general is
just not that important to me. However for discussion groups and more
formalised settings its very much worth it to me. I want that message
to get to the list, and thus the list populace, while I may not care in
particular whether that weird Chuq guy gets it or not.
That's one of the reason I'd like to see a recipient-specific MUA and
MTA agnostic consent token system which allows revocation without sender
consent. That's one of the reasons I asked the RCPT TO bundling
question. If we drop RCPT TO bundling and use TMDA-like sender-specific
consent tokens which have to be expressed in a mail header for automatic
receipt...
Think about it. The subscription handshake with a list or marketing
division automatically acquires and maintains the consent token. The
recipient can at any time revoke the token, or any tokens relating to
a sender address. Tokens can be date limited and can automagically be
updated/renewed by the same acquisition method, etc etc etc. All
that's needed is a little bit of email robot support in the MUA,
perhaps some complicity from the LDA and/or MTA for efficiency, and
some not-very-hard UI work for the users.
The other thing I'd like to see is a way to make the Received: header
trail validly auditable, but I haven't finished working that idea thru
my noggin yet. However, were it done and sufficiently widely deployed
it would effectively identify the sources of spam (in the network sense)
for appropriate real-world targeting (I don't believe that spam can be
handled with purely technical solutions as the definition of spam is
explicitly subjective).
Lawrence, want to explain your stuff in more detail and point people
at where they can find out more?
Err, umm, as in more than the above? There's a HOWTO I wrote which is
in the Mailman user FAQ (http://www.python.org/cgi-bin/faqw-mm.py) which
I think got picked up by the TMDA FAQ as well (haven't checked), my
MHonArc RCs, scripts and PHP bits are available at ftp.kanga.nu, and
err, my consulting rates are reasonable and I'm susceptible to flattery.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(_at_)kanga(_dot_)nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg