headers
Jonathan de Boyne Pollard | 1 Mar 2004 11:59

Re: Goal: easier cpu parsable opt out tags

BW> Even better, IMO, would be the following.
BW> 
BW> * Users do not want to "un-subscribe" from something that they
BW> never subscribed to in the first place. The default policy 
BW> should be for subscription and un-subscription to be entirely
BW> under the control of the recipient, such that no third party 
BW> can "subscribe" or "un-subscribe" them to anything.

Trying to subtly bring them around to IM2000, are you ?  (-:

<URL:http://homepages.tesco.net./~J.deBoynePollard/Proposals/IM2000/CaseStudies/public-mailing-list.html>

BW> * Users want to be able to trivially blacklist any given sender.

Blacklisting senders is of course a major weapon in IM2000.

BW> It's still not entirely effective, though, because any given
BW> person can create an unlimited number of sender identities 
BW> from which to spam. 

... which implies a degree of complicity on the part of the message
store and, of course, simply causes the recipient to escalate to 
the next step in the IM2000 ostracism process - the one that gives
message store owners reason to exercise a degree of control over
senders.

<URL:http://homepages.tesco.net./~J.deBoynePollard/Proposals/IM2000/CaseStudies/lucy-reading.html>
Permalink | Reply | 0 comments |
headers
Jonathan de Boyne Pollard | 5 Mar 2004 17:59

Re: Goal: easier cpu parsable opt out tags

BW> Even better, IMO, would be the following.
BW> 
BW> * Users do not want to "un-subscribe" from something that they
BW> never subscribed to in the first place. The default policy 
BW> should be for subscription and un-subscription to be entirely
BW> under the control of the recipient, such that no third party 
BW> can "subscribe" or "un-subscribe" them to anything.

Trying to subtly bring them around to IM2000, are you ?  (-:

<URL:http://homepages.tesco.net./~J.deBoynePollard/Proposals/IM2000/CaseStudies/public-mailing-list.html>

BW> * Users want to be able to trivially blacklist any given sender.

Blacklisting senders is of course a major weapon in IM2000.

BW> It's still not entirely effective, though, because any given
BW> person can create an unlimited number of sender identities 
BW> from which to spam. 

... which implies a degree of complicity on the part of the message
store and, of course, simply causes the recipient to escalate to 
the next step in the IM2000 ostracism process - the one that gives
message store owners reason to exercise a degree of control over
senders.

<URL:http://homepages.tesco.net./~J.deBoynePollard/Proposals/IM2000/CaseStudies/lucy-reading.html>
Permalink | Reply | 0 comments |
headers
Jonathan de Boyne Pollard | 5 Mar 2004 18:44

Re: SPF is harmful. Adopt it.

m> So then where is IM2000 available?

If someone were asking _you_ a "Where is ... ?" question on any of these
mailing lists, wouldn't "Always try a Google Web search before posting to the
list." be your first response ?  (-:
Permalink | Reply | 1 comment |
headers
Jonathan de Boyne Pollard | 5 Mar 2004 18:49

Re: Inexpensive anti-spamware/anti-verminware tactic

JCB> I'm still on the fence about im2000 though.  

You shouldn't be.  It has been separately re-invented in various places on
Usenet no less than three times in the past fortnight alone.  (And those are
just the places where someone else has replied saying "You've just re-invented
IM2000.")  It's an idea whose time has come.

JCB> But djb, among others, already "admit" that it requires external
JCB> efforts (law enforcement, mainly) to truly "work as advertised".

I doubt that he's said that.  I haven't read anything where he has said that. 
And, in any case, it isn't even true as far as I can see.

JCB> And when I imagine how it'd actually be deployed, over the same
JCB> breadth and depth of audience as present SMTP email has, it 
JCB> seems to me like it'd end up having pretty much the same
JCB> weaknesses as SMTP has today, or will have as SMTP is
JCB> incrementally improved.

No, it won't.  The whole point of IM2000 is that by design it does not have
one, particular, very basic flaw of SMTP-based Internet mail.  The notion that
you are buying into, that SMTP will improve in the future and will end up just
as good as IM2000, is a false one.  The two have a very fundamental
architectural difference, which happens to be the nub of the problem.  No
amount of "improvement" to the SMTP-based system will change that fundamental
difference.

Moreover, it is unlikely that SMTP-based Internet mail will improve.  Most of
the changes to it in recent years have (in the long run) damaged, rather than
improved, it.  I don't see that trend reversing.  Indeed, given how many
(Continue reading)

Permalink | Reply | 58 comments |
headers
James Craig Burley | 6 Mar 2004 02:16
Favicon

Re: Inexpensive anti-spamware/anti-verminware tactic

>JCB> I'm still on the fence about im2000 though.
>
>You shouldn't be.  It has been separately re-invented in various places on
>Usenet no less than three times in the past fortnight alone.  (And those are
>just the places where someone else has replied saying "You've just re-invented
>IM2000.")  It's an idea whose time has come.

I agree with everything in that paragraph except the first sentence
and the implication that, just because lots of people think it's a
good idea, I should therefore accept it.

Let's say, hypothetically, I have substantial resources ($$, time,
expertise, willing and obedient slaves, whatever ;-) available to
throw at whatever project(s) I decide are most beneficial to the world
community -- the "Internet" being my main focus in this context.

Rather than throw substantial weight behind whatever is the latest,
greatest idea that "just about everyone" believes is what is needed to
solve certain problems, I'll investigate and decide for myself.

After all, the landscape is littered with the graves of all sorts of
ideas "whose time has come" in the minds of many who have separately
re-invented them.

Heck, your anti-anti-UBM page is a testament to exactly that
understanding: *many* people have independently come up with all sorts
of anti-UBM measures (C/R and SPF are two IMO noxious ones that come
to mind).  But you (IMO correctly) rebuke the *measures* without being
unduly influenced by the sheer weight and enthusiasm of their
proponents.
(Continue reading)

Permalink | Reply | 57 comments |
headers
mw-list-im2000 | 6 Mar 2004 04:56
Picon

Re: SPF is harmful. Adopt it.

On Fri, Mar 05, 2004 at 05:44:33PM +0000, Jonathan de Boyne Pollard wrote:
> m> So then where is IM2000 available?
> 
> If someone were asking _you_ a "Where is ... ?" question on any of these
> mailing lists, wouldn't "Always try a Google Web search before posting to the
> list." be your first response ?  (-:
> 

So you must have something more recent than implied by

   I've fleshed out the concept so that it is implementable and I'm
   implementing it for myself by writing some softwares. When I manage
   to set up reasonably permanent recipient notification agents and
   message stores for my mail, I'm going to switch to it completely
   and not look back.

In your original message, 

http://marc.theaimsgroup.com/?l=qmail&m=107793691631371&w=2

you advised the poster JC to set up the IM2000 services, and I assumed
you are referring to an available package ready for download and
installation.  Since google failed me, perhaps you want to tell me
explicitly the download URL.

Thx,

Mate

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan de Boyne Pollard | 6 Mar 2004 15:47

Re: SPF is harmful. Adopt it.

It's probably best to have this discussion in the forum dedicated to it, 
partly because others can contribute but also not least because you may well 
have a better chance of reaching me here than via SMTP-based Internet mail.  
Therefore:

%%> Even ideas of moving the costs to the sender are defeated in
%%> the new era when the majority of the spam is sent through
%%> "cracked" Windows machines. What does the spammer care if
%%> the Windows box bears the cost?

JdeBP> I've seen this argument once before.  It's wrong.  It is 
JdeBP> based upon a fundamental misconception of what is being done.
JdeBP> The point is not to move the costs to the sender in order to
JdeBP> penalise the sender.  Sending is cheap, after all.  We want 
JdeBP> it to remain cheap.  The point is to move costs _off the
JdeBP> recipient_, because incurring disproportionate costs for the
JdeBP> recipient is the whole nub of the UBM problem.  Having an army
JdeBP> of unwitting or complicit third parties for sending UBM does
JdeBP> _not_ defeat a "sender stores" architecture.  The recipients
JdeBP> still don't end up paying for the mail.

%%> But how does this framework address the biggest cost of all 
%%> which is person time sorting through the emails?   The main 
%%> option mentioned seems to be blacklisting message stores.

I'm not sure that the fact that people have to read messages is something 
that we can, let alone should, be trying to eliminate.  What an IM2000 
system does is provide weapons to recipients in order to punish, by 
ostracism, those who have sent undesirable mail, and to deter, by threat of 
ostracism, senders and their agents (i.e. message store owners) from sending
(Continue reading)

Permalink | Reply | 30 comments |
headers
Charles Cazabon | 6 Mar 2004 16:54
Picon

Re: SPF is harmful. Adopt it.

Jonathan de Boyne Pollard <J.deBoynePollard <at> Tesco.NET> wrote:
> > What am I missing?
> 
> You are missing the facts that 
>     (a) recipients don't have to honour notifications at all;
>     (b) sending a notification doesn't (by design) convey any of the actual 
>         message content that the sender wants the recipient to read;
>     (c) you have to count the bandwidth used to transmit the message to
>         those recipients that _do_ choose to read it, as well;
>     and
>     (d) this isn't about penalising senders, since we want to _take
>         advantage of_ the fact that sending is cheap not eliminate it, 
>         but about reducing costs to recipients.

This perhaps bears repeating (and even re-stating in simpler language), as it
is both the most powerful and most misunderstood/underappreciated feature of
IM2000.  I'll try stating it in terms of an example that demonstrates the power
that IM2000 gives to /recipients/:

I am <joe <at> camel.example.net>.  I receive a notification that says, in essence,
"you have message ID X waiting to be picked up from server
foobar.example.com".  The first time this happens, I'll likely do the
following:

1) Connect to the message store.
2) Tell it to not send me any more notifications about message X.
3) Retrieve only the "summary" headers of the message (i.e. who it's from, the
date, the subject, message-id:, and references:).

If, based on (3), the message looks like spam, the process ends here.
(Continue reading)

Permalink | Reply | 29 comments |
headers
James Craig Burley | 6 Mar 2004 17:54
Favicon

Re: SPF is harmful. Adopt it.

Ah, a nice meaty example indeed!  I'll contrast it with the potentials
for existing SMTP protocol, extending the "ecosystem" that surrounds
it with mechanisms that largely parallel what IM2000 would require (or
at least imply) for IM2000 to be work as advertised.

>I am <joe <at> camel.example.net>.  I receive a notification that says, in essence,
>"you have message ID X waiting to be picked up from server
>foobar.example.com".

My SMTP server receives a delivery attempt.  It either temporarily
rejects it before, or after, the DATA phase; either way, it notifies
me in almost the exact same fashion, except the notification I receive
says, in essence, "you have message ID X waiting to be delivered again
by server foobar.example.com".

>The first time this happens, I'll likely do the
>following:
>
>1) Connect to the message store.

That'd be the local SMTP message store -- an important difference,
since it means that if the remote message store was temporarily
inaccessible, I'd be stuck (in IM2000-land, but not in SMTP-land).

On the other hand, my *local* message store would have to keep track
of delivery attempts in SMTP-land.  With IM2000, I gather, there'd be
no such need; it's really my local MUA that would keep track of these
(which it'd have to do to some extent anyway with SMTP improved along
these lines).
(Continue reading)

Permalink | Reply | 28 comments |
headers
Andy Bradford | 6 Mar 2004 18:47

Re: SPF is harmful. Adopt it.

Thus said James Craig Burley on 06 Mar 2004 16:54:06 GMT:

> (And, again,  this can't be done  at all in IM2000-land  if the remote
> message store  is unavailable. I know  a message is waiting  for me; I
> just can't see it. I think that'd be very frustrating.)

How is this different from temporarily deferring the message in SMTP and
then  having the  sender's  SMTP server  go down  while  you decide  you
actually want it? Oh I see,  you scanned the message once already during
DATA and stored a local copy even though you told the sender's server to
defer  and retry  again  later? Now  you have  duplicate  copies of  the
message floating around.  Obviously you couldn't reject  the message the
next time it  tries to be delivered  so you would have to  accept it and
then discard it since you presumably  already have a copy, thus doubling
your SMTP bandwidth on messages that you want.

Did I  just misinterpret what  you suggest? If  this isn't what  you are
suggesting, then  having an SMTP  server that you  told to defer  and an
IM2000 message store go down are essentially the same.

Andy
--

-- 
GnuPG ID 0xA63888C9 (D2DA 68C9 BB2B 26B4 8204  2219 A43E F450 A638 88C9)
[-----------[system uptime]--------------------------------------------]
 10:47am  up 81 days, 13:16,  4 users,  load average: 1.01, 1.07, 1.08
Permalink | Reply | 1 comment |

Gmane