Subject: RE: Authentication (no longer Re: [Asrg] My Opinion...)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Mar 2003 09:12:55 -0800

Lets get away from that particular comparison and instead ask,
if the letter post becomes unsafe due to bio-terrorism, what
alternative do we have?

If there is a repeat attack (the sender is still at large,
there is a high likelihood of copy-cats) we may have to work
out a strategy that allows important mail, bills etc to be
transferred by letter post.

The only personal letter post I receive these days is 
postcards, birthday and Christmas cards. All the rest of 
my personal communication moved to telephone and email
years ago.

Devising a mechanism that allows bills to be sent electronically
is worth doing for its own sake. People are likely to pay
more promptly and there is a much reduced hassle factor.
I would like to be able to link outlook to money or quicken
so that every time a bill arrives from an authenticated
and authorized source I get the relevant notification.

If the need arose we could set up alternative mechanisms
for the elderly and those without internet to manage thier
money via ATMs and telephone links.

I can try to get the note I wrote on this as a contingency 
plan released if there is interest.

		Phill

> Please stop making comparisons like that in actual values. 
> Whatever the 
> amount of spam I receive its not worth one human life.
> 
> On Wed, 26 Mar 2003, Chris Lewis wrote:
> 
> > Brad Templeton wrote:
> > 
> > > I mean spam is a royal pain, but it's about 5 orders of 
> magnitude less pain
> > > than anthrax and letter-bombs.
> > 
> > We get a lot more than 5 orders of magnitude more spam than we get 
> > anthrax or letter bombs.
> 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kaitlin Duck Sherwood <[email-masked]>
Date: 26 Mar 2003 09:57:43 -0800

> and authorized source I get the relevant notification.

Certs and signatures are one way to authenticate; Richard Bliss came up
with another technique that doesn't have issues of key revocation and
recovery.  It does require something be built in to clients, which is a
serious drawback but might be feasible given enough time.

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
and drops any new content into the normal mail stream (so that you could
filter it into folders).  

For example, suppose I want to subscribe to the Floss Recycling
newsletter.  The Floss Recycling Web site gives instructions on the
subscription address and when the newsletter comes out (e.g. "Mondays at
3 PM PST).  I set up my email client to poll every Monday at 4 AM and to
drop the newsletter into my FlossRecycling folder.

Q: Why don't you just go to the Floss Recycling web site every Tuesday
morning?  
A: I could do that, but I'd rather have my software remember for me and
put it somewhere where I can easily see that I need to read it *and*
where I can save it for easy future reference.

Q: So what's one benefit of this?
A: Proof of delivery.  Say Bank of Fred wants to start sending me my
mortgage bill electronically.  If they send it by email, they have no
idea if it actually gets to me.  I could not pay my bill and claim,
"well, you never sent me a statement!" even if I got it.  

If Bank of Fred sets up a personalized pull feed for me instead, then
their server will have a record of when my client fetched the bill.  

(Yes, it needs to be secure, but passwords and SASL might be good
enough.  It's not clear that crooks have a strong incentive to see my
mortgage bill.)

Q: Any other benefits?
A: Well, it puts the unsub control firmly in the hands of the user -- I
don't have to hope that Bank of Fred will in fact unsub me.  It also
eliminates the problem of wanted messages getting false positive'd out
of my sight.

Q: So how on earth would this reduce spam?
A: One of the biggest problems that content analyzers (e.g.
SpamAssassin, spambayes) have is that legitimate commercial newsletters
can look an awful lot like spam.  If we can reroute all of the legit
mass mailers to this RSS-esque scheme, then the content analyzers can be
much more aggressive.

Q: Is RSS your clear and obvious choice for this?
A: Absolutely not.  My "expertise" in RSS is the product of only a few
hours wandering around the Web looking at various Web sites.  I feel
like RSS is off in this parallel universe that I really don't know
anything about.

In particular, it was not obvious to me how the RSS client would figure
out what was new since last checked and what was not.  

RSS does have a big attraction because using it might get rid of a
chicken-and-egg problem.  There's enough content out there that uses RSS
that just the current RSS activity would add competitive advantage to an
RSS-enabled client.  That might make it easier to convince the client
manufacturers to add RSS capability.  (Again, I'm pretty clueless about
RSS.  I might be completely off-base here, and would be very interested
in hearing if that's true.)

Q: Why do you think that you can convince any client vendors to do this?
A: I have *cough* some influence on the email portion of Chandler, the
Open Source Application's PIM.  If RSS is a reasonable vehicle for the
Bliss Technique, then I would like to stuff RSS capability into
Chandler.  (No promises on *when*, however -- there are a lot of things
to put into Chandler.  The more people clamor for a feature, however,
the more likely it will go in.)

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 26 Mar 2003 18:29:45 +0000

On Wednesday, Mar 26, 2003, at 17:57 Europe/London, Kaitlin Duck 

> and drops any new content into the normal mail stream (so that you 

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).

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. But I think it's still 
got a great deal of merit.

Matt.

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 26 Mar 2003 11:23:18 -0800

> 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.

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.

> 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. 
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.

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. 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. 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.

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. 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.

Lawrence, want to explain your stuff in more detail and point people at 
where they can find out more?

---

From: [email-masked] (Justin Mason)
Date: Wed, 26 Mar 2003 13:35:51 -0800

> drop the newsletter into my FlossRecycling folder.

Kaitlin,

As a datapoint: I receive RSS gated through my mail already (I use Aaron
Swartz' rss2mail script as my blog-reading app, basically), so I can vouch
that this is a good way to receive "newsletters". ;)

Also, I put up a MailMan-to-RSS gateway at http://taint.org/mmrss/ a year
and a bit ago; I hear MM are now looking into producing RSS directly from
their archiver, which is great news.

Summary: I'm well interested in this stuff, and I think it could fly (if
the bulk mailers can be convinced).

--j.

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 26 Mar 2003 13:55:06 -0800

Justin, I owe you a couple of beers. You just paid for my time spent in 
this list... (grin. seriously). that script's something I was looking 
for to adapt for my stuff.

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 26 Mar 2003 22:14:41 +0000 (GMT)

On Wed, 26 Mar 2003, Chuq Von Rospach wrote:

> among others.

Dave likes to *ahem* steal credit for RSS, but it was actually Netscape 
who came up with RSS. But this is a digression. I meant the idea of using 
RSS for email pull, not the credit for RSS itself. Not that this matters 
one iota.

> But the blogs have taken RSS onto their own, and a bunch 

4 years ;-) But yes, the applications of RSS are quite extensive.

> through a challenge/response to get your message posted.

Neat. Sounds a lot like the work I did on O'Reilly's WebBoard to add RSS
distribution back in 2000 (just in case anyone decides to patent this: I
still have the cvs archives). That meant you could get access to the
discussion groups via NNTP, email, Web browser, or some alternate
interface by pulling RSS files. Shame O'Reilly decided to close their
software division before we finished it ;-)

I'd very much like to see this mailman extension finished.

Matt.

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 26 Mar 2003 14:23:19 -0800

> RSS for email pull, not the credit for RSS itself. Not that this 

I'd point out the "among others", but point taken. RSS has been around 
longer, but I think integrating it into Manila was one thing that gave 
it momentum.

> 4 years ;-) But yes, the applications of RSS are quite extensive.

I've only been really watching RSS and CDF and stuff for 18 months, and 
I first discovered it about 2 years ago. What went on before, I haven't 
really researched yet...

> still have the cvs archives).

damn. (grin)

>  That meant you could get access to the

which basically mimics what I did for the Apple lists in 1998, minus 
the RSS. and when I realized that of the many users only 12 were using 
the NNTP interface, I stopped supporting it. Some of them are still 
pissed at me, but from a time perspective, the cost per user was too 
high. Now, I'm looking at redoing all my archives in a nice, 
self-configuring way, adding RSS feeds to them, and than cloaking email 
addresses out of them for safety sake. And then after lunch, deal with 
the posting side of it.. (grin)

---

From: mathew <[email-masked]>
Date: Wed, 26 Mar 2003 20:54:35 -0500

This goes back to the suggestion from myself and others, earlier on.

Once you've moved the mailing list traffic to an RSS-like "pull" 
system, you take the next step, and move all e-mail traffic to it.

Now for someone to send you e-mail, they send you the bare URL of their 
RSS feed from them to you.

The advantage over the current system is that when an ISP closes off an 
account used for spam, all the spam that was sent with that account 
gets un-sent, so those who didn't download it yet never see it.

In addition, it puts the bandwidth burden of spam on the site that's 
used to send it, rather than on the recipients, hopefully making it too 
expensive to leave your mail system insecure.

I have to confess that at this stage I forget what the objections were 
that people came up with :-(  How's that taxonomy of proposed solutions 
coming? I feel it's past time to start cataloging all the proposals on 
the web, assigning them names, and collecting the objections.

mathew

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 26 Mar 2003 21:16:55 -0500

At 8:54 PM -0500 3/26/03, mathew wrote:
>Now for someone to send you e-mail, they send you the bare URL of 
>their RSS feed from them to you.

Pull is a great idea, and if we can persuade mailing list operators 
to offer it as a choice, that's great.

But it's not email.  It doesn't have a number of the necessary 
attributes for person-to-person email.
- it requires a server that is up all the time
- it requires storing outgoing email for an indefinite amount of time
- it completely the destroys the go-online, fetch, go-offline model
 From a resource and operational standpoint it looks an awful lot like 
running a web server.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 26 Mar 2003 22:03:31 -0800

On Wednesday, March 26, 2003, at 06:16  PM, Kee Hinckley wrote:
> Pull is a great idea, and if we can persuade mailing list operators to 
> offer it as a choice, that's great.
>
> But it's not email.

No, but it solves THAT problem nicely. I better be careful, or I'll use 
the words "hammer" and "nails" soon. and it helps solve some of the 
e-mail problems, becaues the more you can take this kind of content out 
of the email stream, the easier it is to focus on other issues. 
Effectively, moving this stuff to RSS would whitelist it for us, which 
simplifies the problem we're trying to solve.

>   It doesn't have a number of the necessary attributes for 
> person-to-person email.

not intended to. it's a one to many solution. but a lot of email IS one 
to many.

> - it requires a server that is up all the time

not really. Good RSS readers will retry over time. It needs a server 
that's moderately well connect and moderately useful, but it'd work 
nicely over a dialup for personal stuff.

> - it requires storing outgoing email for an indefinite amount of time

why? RSS generally doesn't do that. it stores the last "N".

> From a resource and operational standpoint it looks an awful lot like 

well, that's because you're running a web server.

---

From: J C Lawrence <[email-masked]>
Date: Wed, 26 Mar 2003 23:57:13 -0800

On Wed, 26 Mar 2003 22:03:31 -0800 

> nicely over a dialup for personal stuff.

Additionally now that we're inventing whole new transports and formats
there's also nothing to say that the RSS feed wouldn't be available via
BitTorrent or a distributed gnutella-like protocol, thus requiring very
little in the way of connectivity of the original server.  Heck, all we
have to do is add conversational supports and we have NNTP redux.

</cynic>

> why? RSS generally doesn't do that. it stores the last "N".

ObNote: This assumes that the RSS feed is statically generated and not
the result of a (complex) query.  Neither need be true (and neither is
true in the case of systems I'm currently building).

> well, that's because you're running a web server.

Gack!

</cynic dammit>

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 27 Mar 2003 09:26:51 -0500

At 10:03 PM -0800 3/26/03, Chuq Von Rospach wrote:
>not intended to. it's a one to many solution. but a lot of email IS 
>one to many.

I don't disagree.  However there have been a number of proposals made 
to this list that assumed it would be a drop-in replacement for all 
email.

>nicely over a dialup for personal stuff.

Not for the average end-user.  For someone who was conscious that 
they were running a service, and made an effort to be online a 
reasonable amount of the time, yes.  We've had this discussion on a 
previous thread wrt a proposal to make email end-to-end instead of 
store and forward.

>why? RSS generally doesn't do that. it stores the last "N".

True, but RSS also usually points at a web server that has the rest 
of the messages.  Again--primarily an issue if you are trying to 
replace N to N, not so much for 1 to N.

>>From a resource and operational standpoint it looks an awful lot 
>>like running a web server.
>>
>

Precisely.  Again, primarily an issue only if you are trying to 
replace something other than a mailing list.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Chuq Von Rospach <[email-masked]>
Date: Thu, 27 Mar 2003 07:37:50 -0800

On Thursday, March 27, 2003, at 06:26  AM, Kee Hinckley wrote:

> Not for the average end-user.

But the users we're talking about already aren't running those 
services. Or if they are, it's as a yahoogroup. So I see that as a 
non-issue. Although frankly, some of the stuff being done with MacOS X 
shows ways we can make it point and click friendly for them, too.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 27 Mar 2003 08:45:43 -0700 (MST)

> From: Chuq Von Rospach <[email-masked]>

> ...
> ...

Who is we and what is our prblem, kemo sabe?

Collaboration, text messaging, and information sharing mechanisms
other than mailing lists sound interesting, but here they are as
relevant as flamewars about who is really behind SPEWS or lying about
whether SPEWS listed all of UUNET.  For better or worse, we're supposed
to fix the hammer that is email so that it drives fewer crooked spam
nails.  If the word "hopeless" fits expecting 500,000,000 users and
30,000,000 system administrators to install new email software to fix
spam (it does fit), then what is the word for expecting many of those
500M people to switch to something that is not email?

Would it make sense for this mailing list to conclude with "spam can't
be fixed, so stop using email"?  Perhaps so, but discussions of the
replacement for email would be off-topic.

I've found the talk of RSS interesting, but it seems off-topic here.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Matt Sergeant <[email-masked]>
Date: Thu, 27 Mar 2003 16:16:33 +0000

On Thursday, Mar 27, 2003, at 15:45 Europe/London, Vernon Schryver 

> Who is we and what is our prblem, kemo sabe?

TINW.

The problem (ok, just one of the problems) is to stop spam without 
harming legitimate business needs to get their subscriber info out.

To make this relevant to the DCC, the DCC marks bulk mail. If you could 
get legit bulk mailers (newsletters) to switch to pull, then more of 
the bulk mail is spam, and this makes the DCC more of an effective tool 
to combat spam.

I don't think it's irrelevant here at all. We all acknowledge that we 
need a multiple of solutions (no single solution), and this might 
fulfill some needs here.

Matt.

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 27 Mar 2003 17:57:24 +0100

On Thu, Mar 27, 2003 at 04:16:33PM +0000, Matt Sergeant wrote:
> If you could 
> get legit bulk mailers (newsletters) to switch to pull,

They won't.
There already is a "pull" method, it's called HTTP and it doesn't work.
Think about a weekly newsletter. You surf the Web, find it interesting
and subscribe. You get it delivered each week straight to you mailbox.
Would you use the "pull" method and visit the website every week, just
to pull? Would you come back, if there is one issue that isn't too
interesting?
Nearly every company I know of has their product infos ready for "pull".
But they use push mailinglists to contact their customers and refresh
their memory and deliver information just in time and when it's
relevant.
They won't want to loose that instrument.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: J C Lawrence <[email-masked]>
Date: Sat, 29 Mar 2003 14:54:23 -0800

On Wed, 26 Mar 2003 11:23:18 -0800

>>> 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

> 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.

> 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

> actually went an implemented a system that seems really pretty

Eeek!

> 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 ([email-masked] 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:.

> 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:
[email-masked].  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.

---

From: mathew <[email-masked]>
Date: Sat, 29 Mar 2003 19:27:31 -0500

> - it requires a server that is up all the time

So does conventional e-mail. With current e-mail systems, I fail to get 
the mail if my messaging server (at my ISP) is down. With e-mail pull, 
I fail to get the mail if the sender's messaging server (at his ISP) is 
down. In addition, I won't get mail from people I don't know that I 
need to poll unless my messaging server at my ISP is up. A small 
tradeoff in reliability, but one I think I'd take to cut spam.

I mean, the web often requires that both my ISP and the appropriate web 
site have their servers operational when I want to read a web page. Yet 
people still use the web.

> - it requires storing outgoing email for an indefinite amount of time

The current system requires storing incoming e-mail for an indefinite 
amount of time.

Both of these are the whole point of the system. The whole idea is to 
move the storage, uptime and network requirements to the sender's 
messaging server, so that it's easier to take action against abuse, and 
so that server operators suffer direct consequences if they fail to 
secure their systems.

> - it completely the destroys the go-online, fetch, go-offline model

Not really. It just means that my mail client would go online, fetch my 
e-mail from a dozen different systems instead of just one, then 
disconnect.

mathew

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 29 Mar 2003 18:47:39 -0700 (MST)

> From: J C Lawrence <[email-masked]>

> > When I sign up to any source of bulk mail, I only sign up for that
> > particular stream of mail from that particular source.  I do not sign
> > up for anything else, no matter what any third party might think, even
> > if that third party provides content that is published in the list.
>
> While that may be what you intend to do, that is not apparent from your
> actions, and even more so, that is not implied by the information you
> reveal should you post to that list.  This is simple information theory
> stuff.

"Information theory stuff" is stuff and nonsense in this context.  If
you want to talk about Shannon's work and so forth, we could, but such
talk would have nothing to do with the charter of this mailing list
or this digression.

> In the general case when you post to the forum you reveal yourself,
> willy nilly, to all the members of that forum at that time, and (very
> likely) everybody who may every find or discover that forum for the rest
> of time (archives and associative bleed being what they are).  Those are
> the explicit audiences to whom you've provided your contact data.  If
> that doesn't describe what you want to do, then DON'T DO THAT.
> Attempting to retroactively assign riders or etiquette contracts
> regarding your provided data is unlikely to work.
> ...

That position is indistinguishable from spammers who claim that
publishing an address is tantamount to soliciting anything they care
to send you, until you opt-out, and that any future publication of
your contact information is a new request to be spammed back to the
19th Century.  Please note that I am not saying you are a spammer,
but only that those words express perfectly the position of spammers
that they have the right to spam you if you don't hide your address.

I think subscribing or contributing to a mailing list amounts to
nothing more than subscribing or contributing to a mailing list.
In the absense of explicit agreement to the contrary, subscribing
to a mailing list does not solicit any mail from anyone except from
that mailing list.

It is reasonable for a stranger to assume that you at least tolerate
non-bulk, polite, private messages on any topic that the sender
reasonably believes interests you.  That the sender infers your interest
from a web page, netnews article, mailing list submission, business
card, roadside sign, or mental telepathy is irrelevant.  Submitting
something to a mailing list does not grant anyone any right to send
you mail that they would not already have without your submission.

However, that permission can be assumed to extend only to non-bulk,
polite message and only in the absense of knowledge to the contrary.
That permission to send mail to you be withdrawn at any time with no
more notice than an SMTP status message or an email message.

>   Note: Such an approach makes it difficult to fork a thread off-list.

There are cases where the only discussions that are possible are public
because there is insufficient mutual regard for private discussions.
Despite such problems, public discussions can be fruitful.

Public statements do not obligate you to private discussions with anyone.

To put it another way, if you think your response to someone's public
remark is inapprorpriate for the public forum, then you should consider
the possibility that you shouldn't make it in private.

In yet other words, are you really advocating the notion that I must
receive bulk noise about keys because I've subscribed to this mailing
list?  If so, what about urgent messages about escrow accounts in Nigeria?

---

From: Kee Hinckley <[email-masked]>
Date: Sat, 29 Mar 2003 22:48:25 -0500

At 7:27 PM -0500 3/29/03, mathew wrote:
>So does conventional e-mail. With current e-mail systems, I fail to 
>get the mail if my messaging server (at my ISP) is down. With e-mail 
>pull, I fail to get the mail if the sender's messaging server (at 
>his ISP) is down. In addition, I won't get mail from people I don't 
>know that I need to poll unless my messaging server at my ISP is up. 
>A small tradeoff in reliability, but one I think I'd take to cut 
>spam.

Currently you have a single point of failure that is close to you on 
the network.  It's down infrequently, and when it is, you simply wait 
and it comes up.

With pull you are relying on the availability of dozens, hundreds or 
even thousands (depending on how much email you get) of different 
servers scattered across the world.  You go from a situation where 
all of your email is there most of the time, to one where some of 
your email is never there most of the time.

>I mean, the web often requires that both my ISP and the appropriate 
>web site have their servers operational when I want to read a web 
>page. Yet people still use the web.

Different expectations of service, and different scale.  I get mail 
from far more servers than I surf in a given day.

>The current system requires storing incoming e-mail for an 
>indefinite amount of time.

Nope.  Only until the end user picks it up.

>
>Both of these are the whole point of the system. The whole idea is 
>to move the storage, uptime and network requirements to the sender's 
>messaging server, so that it's easier to take action against abuse, 
>and so that server operators suffer direct consequences if they fail 
>to secure their systems.

I understand that that is the goal.  However you need to look not 
just at what it does to spammers, but what it does to normal mail 
users.  And what it does in that case is make email delivery less 
reliable.

>Not really. It just means that my mail client would go online, fetch 
>my e-mail from a dozen different systems instead of just one, then 
>disconnect.

No. You go online.  Get a list of different email systems, decide 
which ones you  want to fetch, and then go online again to fetch them.

And that points out the biggest flaw of the system.  Not only have 
you not stopped the spammers (sure, they need to find a host 
somewhere, or lots of hosts, but that's not that big a deal).  But 
you've made it *way* harder for me to tell whether something is spam. 
The initial "you have mail" message doesn't provide enough 
information.  I can no longer use content filters on it.  Instead I 
have to go try and fetch it.  The spammer is sure to have an 
overloaded server, so now I'm not only going to try and fetch it--but 
try multiple times!
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Chuq Von Rospach <[email-masked]>
Date: Sat, 29 Mar 2003 22:53:24 -0800

On Saturday, March 29, 2003, at 04:27  PM, mathew wrote:

>  With e-mail pull, I fail to get the mail if the sender's messaging 
> server (at his ISP) is down.

Or if the network between us is down, or if the server is overloaded 
because someone who didn't know any better something to everyone in his 
address book 100 times.

If someone forwards the mail, who's server is responsible for it? What 
server (if any) keeps the message for future reference? What if it's a 
person who never deletes his e-mail? Or reads it 1000 times (DOS 
attack?). How long does a server have to keep a message to be read? 
What if the message is forwarded? what if the person posts a URL to 
access it to slashdot?

How does e-mail pull work in large environments where you have round 
robins, load forwarders, and large strings of MX relays today? How 
about through firewalls?

I hate to say it, but email pull seems like a bad idea with a lot of 
complexity for questionable improvement. It might make more sense if it 
could be stored until I tell my server to go and get it from your 
server, but even then, how does that scale?

---

From: J C Lawrence <[email-masked]>
Date: Sun, 30 Mar 2003 00:32:34 -0800

On Sat, 29 Mar 2003 18:47:39 -0700 (MST) 

>> While that may be what you intend to do, that is not apparent from
>> your actions, and even more so, that is not implied by the
>> information you reveal should you post to that list.  This is simple
>> information theory stuff.

> "Information theory stuff" is stuff and nonsense in this context.  

I'll disagree as I find it critical to the accurate definition and
design of protocols.

> If you want to talk about Shannon's work and so forth, we could, but
> such talk would have nothing to do with the charter of this mailing
> list or this digression.

I don't see the discussion of IF as on-topic for this list, but its
applications to the topics of this list most certainly are.

>> likely) everybody who may every find or discover that forum for the
>> rest of time (archives and associative bleed being what they are).
>> Those are the explicit audiences to whom you've provided your contact
>> data.  If that doesn't describe what you want to do, then DON'T DO
>> THAT.  Attempting to retroactively assign riders or etiquette
>> contracts regarding your provided data is unlikely to work.  ...

> 19th Century.  

True, and that's part of my point.  I may not like or agree with the
view, and its certainly not one I practice, but their logic is sound.
The only difference between the two positions are arbitrary OOB value
decisions that are not demonstrated by the data in any fashion.  More
simply, wouldn't a system which does state (or enforce) the expectations
of the poster be better than the current please-guess-nicely approach?

We already know that we are dealing with people who are not operating on
the same social assumptions and mores as we, and that we have no direct
method of either communicating our expectations in a manner such that
they'll be honored, or in making them use our data in the manner we
wish.  It seems inescapable that the appropriate response is to provide
data which only operates within the expectations/contracts we desire.

> Please note that I am not saying you are a spammer, but only that
> those words express perfectly the position of spammers that they have
> the right to spam you if you don't hide your address.

Thanks.  I get enough of that as a list operator.

> nothing more than subscribing or contributing to a mailing list.  In
> the absense of explicit agreement to the contrary, subscribing to a
> mailing list does not solicit any mail from anyone except from that
> mailing list.

I was careful in my original text to distinguish between joining a list
and posting to a list.  The former case I firmly believe to be a
properly protected state (and is something I'm very careful of on my
lists due to a number of situations where the simple fact that someone
is subscribed is uncomfortably revealing).  The latter (posting) is far
less clear without applying cultural arbitraries as discussed above.

> reasonably believes interests you.  That the sender infers your
> interest from a web page, netnews article, mailing list submission,
> business card, roadside sign, or mental telepathy is irrelevant.
> Submitting something to a mailing list does not grant anyone any right
> to send you mail that they would not already have without your
> submission.

Aye, there's the social corollary to the protocol rule of, 'Be
conservative in what you emit and generous in what you accept', to the
end of, "Post messages which others can experience easily, and be
willing to experience any message."  However, I see that as a tangent to
tool-building for a solution.

> There are cases where the only discussions that are possible are
> public because there is insufficient mutual regard for private
> discussions.  Despite such problems, public discussions can be
> fruitful.

<nod>

> Public statements do not obligate you to private discussions with

No, but it is easy (if not valid) to assume a social structure which
defines that a participant in public discussion may be reasonably
approached for private discussion.

> list?  If so, what about urgent messages about escrow accounts in

Social etiquette versus technical contract.  Teaching manners, let alone
cultural models and expectations is not easy as it assumes a context
which is frequently not present.  Don't enforce your mores on a group
to which they don't apply.

  BTW: On that score don't expect me to stop ranting against top
  posting, or to allow it on any of my lists.  I pick limits on where I
  live up to what I write.

Geeks, and this encludes me, tend to readily compartmentalise their
lives and interests.  Thus they view their behaviour and activities on
List-X as distinct and effectively unrelated to their behaviour and
activities on List-Y, and they in turn deconstruct and compartmentalise
the social expectations and mores which relate to those sub-divisions in
the same way.  Problem is that the majority of the rest of humanity
doesn't tend to work that way.  Hang out on some non0-technical lists on
Yahoo or Topica for a while.  Right or wrong (I'd argue that is a style
point) they take a much more whole-person approach wherein a person's
participation on the list is holistic, and involved more or less all of
that individual, warts, off-topic oddities, and all.  As such game lists
have regular discussions on baby diaper selection, teen-pop idol bra cup
size, IRS legitimacy urban legends, and fauz virus warnings.

However, this is getting way off topic.

Problem.  Definition.  Solution.  Implementation.

---

From: mathew <[email-masked]>
Date: Mon, 31 Mar 2003 22:05:27 -0500

On Saturday, Mar 29, 2003, at 22:48 US/Eastern, Kee Hinckley wrote:
>> pull, I fail to get the mail if the sender's messaging server (at his 
>> ISP) is down. In addition, I won't get mail from people I don't know 
>> that I need to poll unless my messaging server at my ISP is up. A 
>> small tradeoff in reliability, but one I think I'd take to cut spam.
>

If we assume that most messaging servers are down infrequently, then I 
still don't see the problem. If one sender's messaging server is down, 
I don't get his mail until his server comes back up.

> servers scattered across the world.  You go from a situation where all 
> of your email is there most of the time, to one where some of your 
> email is never there most of the time.

Well, the web is like that, and people find it reliable enough to be 
useful.

The question is how the reliability of a pull-based system would 
compare to the reliability of the current system. Don't forget that 
although email pull would degrade my ability to receive mail from users 
whose messaging servers are badly maintained, it would *increase* my 
ability to *send* mail to those same users, because once they were 
regular correspondents of mine their software would still be able to 
poll my reliable server even when their ISP's broken server was down.

I suspect some simulations would need to be done to work out whether 
the overall outcome would be better or worse, and how much better or 
worse it would be.

> from far more servers than I surf in a given day.

Maybe you should try an RSS feed reader. :-)

> Nope.  Only until the end user picks it up.

Uh, that's an indefinite amount of time. I might not log in to collect 
my mail for several months.

In both the current setup and e-mail pull, the server holding the mail 
can stop holding it once the recipient has downloaded it. What's the 
difference?

> which ones you  want to fetch, and then go online again to fetch them.

If the decision process is fast enough--and it probably will be--then 
you just have a dual-threaded e-mail client.  Most offline newsreaders 
work that way--download the headers, autoselect a bunch of articles on 
the fly, and download those articles, then disconnect. All in one cycle.

> And that points out the biggest flaw of the system.  Not only have you 
> not stopped the spammers (sure, they need to find a host somewhere, or 
> lots of hosts, but that's not that big a deal).  But you've made it 
> *way* harder for me to tell whether something is spam. The initial 
> "you have mail" message doesn't provide enough information.  I can no 
> longer use content filters on it.  Instead I have to go try and fetch 
> it.  The spammer is sure to have an overloaded server, so now I'm not 
> only going to try and fetch it--but try multiple times!

Which is a big problem why? It's not going to chew up your bandwidth, 
you can set retrieval timeouts as short as you want to limit your 
dialup session to, and the CPU and disk overhead of failing to make a 
connection is minimal. I'd make that payoff to get rid of most spam.

mathew

---

From: mathew <[email-masked]>
Date: Mon, 31 Mar 2003 22:22:24 -0500

OK, now we're getting into nit-picking details.

On Sunday, Mar 30, 2003, at 01:53 US/Eastern, Chuq Von Rospach wrote:
> because someone who didn't know any better something to everyone in 
> his address book 100 times.

If the network between us goes down, then the mail doesn't get 
delivered until the network goes up again. Just like if the network 
between the sender's SMTP server and my mail server goes down with the 
present system, the mail doesn't get delivered.

If an idiot sends something 100x to everyone in his address book, 
that's unsolicited bulk e-mail, so the fact that I don't receive it is 
a feature.

> If someone forwards the mail, who's server is responsible for it?

Treat a forwarded e-mail as a regular e-mail that just happens to 
contain an encapsulated message in the body. In other words, the same 
as at present, the forwarder's mail server is responsible for delivery.

>  What server (if any) keeps the message for future reference?

What server (if any) keeps my e-mail for future reference now?  None, 
that I know of.

>  What if it's a person who never deletes his e-mail?

Then his hard disk fills up.

>  Or reads it 1000 times (DOS attack?).

Yes, if he has a broken mail client that doesn't download and cache the 
mail, he might fetch it lots of times. Just like a broken web client 
might fetch the same image every time it's included on any web page on 
your site.

If it turned out to be that big of a problem, you could limit the 
number of times your mail server allowed any given message to be 
downloaded.

>  How long does a server have to keep a message to be read?

How long does an SMTP server have to keep retrying to transmit a 
message?  Configurable parameter.  We can argue over what the default 
should be, but I don't see that it needs to be decided right now.

>  What if the message is forwarded?

You already did that one.

>  what if the person posts a URL to access it to slashdot?

See above re: limiting number of times a message can be downloaded.

> robins, load forwarders, and large strings of MX relays today?

Same way almost any other Internet protocol works. SMTP is an unusual 
special case in that it had its own methods of controlling network 
topology. Now that so much traffic flows through other point-to-point 
protocols like HTTP, firewalls and switches are equipped to let you set 
up "smart" routing based on protocol, source, destination, and so on.

Sure, you wouldn't just be able to translate your MX setups and e-mail 
backbones to a set of firewall settings automatically, but that doesn't 
mean you couldn't set up equivalent functionality.

>  How about through firewalls?

Well, you'd need to have a public messaging server outside the firewall 
that people could contact to fetch mail your users sent, just like you 
currently have a public web server so people can fetch pages your users 
author. You'd also need a notification-receiving server, like your 
current SMTP server.

> complexity for questionable improvement.

Yes, well, a lot of things on the Internet are a bad idea with 
questionable performance. The web, IRC, Java, ...

Seriously, though, I don't see it as much more complex than running a 
web server plus an SMTP server.

mathew

---

From: Chuq Von Rospach <[email-masked]>
Date: Mon, 31 Mar 2003 20:11:47 -0800

> present system, the mail doesn't get delivered.

But now, with MX records, when a connection comes up, the servers 
coordinate delivery. As I understand it, the system you're proposing is 
doing it at the client level, so updates only happen when the user is 
asking for them. For an unstable connection, that reduces the 
likelihood of successful delivery significantly.

> that's unsolicited bulk e-mail, so the fact that I don't receive it is 

but it still causes network and server prolems, so dealing with the 
side effects is necessary. Systems can't assume perfect conditions.

> What server (if any) keeps my e-mail for future reference now?  None, 

anyone currently on an IMAP server, or on POP with "leave on server" 
turned on. So, would a user require to pull it and copy it to "my" 
server, or does it stay on that server, like it would on a USENET or 
IMAP server? 0

> Then his hard disk fills up.

not if the email he's never deleting lives on your server, because 
that's where it was accepted from and still stored.

> Yes, if he has a broken mail client that doesn't download and cache 
> the mail, he might fetch it lots of times. Just like a broken web 
> client might fetch the same image every time it's included on any web 
> page on your site.

okay, so you're seeing this as some client-driven version of a suck 
feed. you could make it work, but it's not how I'd do it. You're better 
off layering on what we already have, using some variation of the ETRN 
command -- but then you still have to have some way to tell the other 
side there's mail waiting to receive. so aren't we simply setting up a 
system to send email to tell someone there's email being sent?