Subject: RE: spam

From: "Christian Huitema" <[email-masked]>
Date: Wed, 28 May 2003 10:56:21 -0700

> > The only question left is if there are any *technical* components to
> > doing so
> > (which would be the IETF's preserve), and, if so, what they are.
> 
> It surprises me that so many people are so eager to declare defeat
> before even trying the protocol route. (With current protocols defeat
> is pretty much inevitable.) 

There is an obvious issue with the protocol route: from a protocol point
of view, it is quite hard to distinguish unsolicited commercial e-mail,
which we would label spam, and unsolicited acceptable e-mail, which
could be more than welcome.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 28 May 2003 11:36:35 -0700

Christian Huitema wrote:
> There is an obvious issue with the protocol route: from a 
> protocol point of view, it is quite hard to distinguish 
> unsolicited commercial e-mail, which we would label spam, and 
> unsolicited acceptable e-mail, which could be more than welcome. 

Which is why we shouldn't even start down that path. The protocol needs
to be basic and simple, but place the bulk of the operational cost at
the origin rather than the current model of placing it at the receiver.
The system needs to let people that are willing to pay the cost at the
origin send whatever they want, but make it indisputably clear who/where
the origin is. The external mechanisms already exist to deal with the
social engineering once the originator can be pinned down.

Tony

---

From: David Morris <[email-masked]>
Date: Wed, 28 May 2003 11:33:03 -0700 (PDT)

> could be more than welcome.

I don't see where the commercial attribute has any significance.
Unsolicited BULK is what I label spam.  While I don't see the effort as
useful, detecting bulk email is probably easier than any attempt to
evaluate its purpose or (content beyond exceeding measures used to
detect the BULK nature).

Correct accurate labeling is a 2nd order solution which can be used to
reduce the people time impact via filtering, but filtering doesn't
eliminate resouce impacts such as consumption of scarce and/or costly
link bandwidth.

Protocol changes can deal with identification, authentication, trust
relationships, interoperable labeling, payment exchange, ... None of these
areas of new/improved protocols require any understanding of purpose or
content. [Perhaps even protocol support for interoperable wrapping of end
user spam nominations as documenation is collected and transfered about
the network.]

Dave Morris

---

From: Peter Deutsch <[email-masked]>
Date: Wed, 28 May 2003 11:56:53 -0700

g'day,

Christian Huitema wrote:
...
> could be more than welcome.

I've sat on this posting, give both the previous volume of the thread,
and the danger of getting too far into implementation discussions on a
general list, but I've seen several postings to the effect that "it's
hard to see what we could do at the protocol level". Personally, I think
the problem would benefit from a little lateral thinking, so here's my
cut at it. Those who tire of my ramblings, and don't want a quote from
Tom Lehrer and allusions to Queen Elizabeth and Francis Drake, should
hit "n" now...

Concepts such as Hashcash or other payment-oriented systems, in which
you try to impose a cost on the sender to screen out bulk mailers, are
interesting enough, but I think they're addressing the wrong problem.
I've personally come to the conclusion that to address this problem
(that is, the decision as to whether I want to accept a message from
you), I don't actually need to know who you are, or even what you're
trying to send me, and I certainly don't need to impose artificial costs
on you (since this looks too much like punishing the innocent for the
crimes of the guilty).

The heart of the issue seems to be:

    What I really need to decide is whether I
    should trust you enough to start accepting
    unsolicited email from you (or more generally,
    to start interacting with you for purpose x).

I don't know what Paul Vixie meant by his allusion to a
trusted-introducer model but I'd love to hear more about that, since
I've been working on something that sounds a lot like that and I'd like
to compare notes and seem how much reinventing of the wheel I'm
currently doing (and to thrash the deceased equine a bit, mail I sent to
him died in his maze of twisty little email filters, all the same, so we
seem to have yet another existance proof that this problem is imposing
costs on us and hurting our ability to use the Internet for useful work.
To quote Tom Lehrer, "but I digress").

One way I can learn whether I want to interact with you is to invest
some time building up a trust relationship with you (verifying you are
who say you are, etc). Another way would be for me to ask people I
already trust who might know you to issue you a reference.

My conclusion is that we need something along the lines of a
peer-to-peer trust authentication token system which would allow the
first time caller to authenticate him/herself to new MTAs by allowing
him/her to demonstrate his/her prior participation in existing trust
relationships. The idea is to build something more oriented towards
peer-to-peer relationship building, rather than the traditional PKI
central authority model we've seen so far.

In practice, I imagine it would be most practical, if we want to
interact with the traditional store-and-forward email system, for my
friends to issue signed, non-forgable "trust tokens" (I think I called
them "letters of marque" in a recent posting, since they convert
"pirates" to "honest businessmen and women", just as Queen Elizabeth did
with Francis Drake... ;-) The redeemer would hand a set of these trust
tokens to me on first contact (you could embed them in the mail header,
or we'd negotiate which trust tokens I accept when you connect, or I'd
publish a list in "son-of-DNS" which trust groups I'm currently
trusting, etcetcetc).

When I receive such a {set of) trust token{s}, I'd check them to see if
they really do come from folks I trust and otherwise satisfy my current
policy requirements (e.g. I may need at least three valid tokens, or I
may need at least two, including one from somebody in Sweden, etc), and
if so I could start granting the bearer interaction privileges. The
unlying assumption here is that trust is a transitive relationship, and
thus I'd allow myself to build up webs of such trust relationships by
accepting references and references from references, so I wouldn't have
to rely solely on a single, centralized PKI infrastructure.

Now, in practice, I'd like to be able to adjust my policies based upon
the qualitity of your references (say, requiring x references from group
a, but only y references from group b to begin transacting). This has
the beneficial side effect of putting the policy decision making into
the hands of the grantor of privileges. All I require from the issuer of
certificates are that I can prove they come from the issuer, and that
they contain certain information (such as issuer, issue date, TTL, etc)
- the decision about what to do when they're valid rests with the
redeemer.

Obviously I'd also need to be able to issue my own letters of marque,
once I've developed sufficient trust in you (say, after I've experienced
z satisfactory interactions without incident, or maybe when I click a
button in my MUA because I like what I'm getting). Instinct tells me
this "degree of good behaviour" could be quantified and automated, but
"electing to start trusting" is not something you need to do on every
message so need not be computationally easy. As a sidebar, the policies
I use in granting my trust certificates would go far in determining to
what degree they have later redemption value for others.

And finally, I'd like these letters of marque to be revocable in
something close to real time, since sometimes you get it wrong, and
sometimes folks go bad. This doesn't necessarily mean I want to be
contacted for every redemption (in fact, sometimes this will be
impractical) but assigning such tokens a TTL and/or a refresh time and
otherwise allowing some controls over redemption policy seems to be a
good idea.

Signing a record consisting of an ID, date and some other useful data
with a private key seems to be just the ticket here, since it can be
rapidly decrypted and checked but not easily forged. There is probably a
lot more to it that this, since I probably don't care much about the
cost of signing (something I wont do every interaction, only when
agreeing to issue a new letter of marque) but I definitely want forging
to be hard, and verifying to be cheap. This is classic public key stuff,
although it looks like it would be seful if you could show *both* that
you're Alice, *and* that you're a member of a specific group (ie. you
need to transmit two secrets, one you own and one you share with your
"trust buddies". This may be nothing more than using a group key to sign
your ID within your token (making it a secret shared only by the turst
ring), but it might also be nice if you can perhaps automatically get
the group secret when you've been accepted by enough members of the
group.

I remember work from the crypto community about sharing n parts of a
secret (that is, you need at least n parts of the secret to recreate it)
that could be relevant here, although I haven't gone back and tracked it
down yet. The idea would be that as you collect references, you collect
pieces of the secret and when enough folks trust you, you have the info
needed to start generating and issuing your own certificates as part of
the club. In my notes on this, I make reference to being able to
"blackball" a potential member, since issuing him an invalid token in
effect keeps him out of the club. This area needs more thought, but it
holds the promise of automating the implementation of membership
management, which could be nice...

I'm still chewing on what's suitable stuff to put into the token, but it
lends itself to a fair number of things, when you think about it. You
might add in there info about which domains to allow, which user names,
which protocols to allow, etc. The idea is to delineate the areas and 
scope for which trust would apply.

The storage of the needed public keys probably could go into a "son of
DNS" easily enough. Extensions to SMTP to request and redeem tokens
obviously would need some thought, although I suspect you could embed
the tokens in the mail header easily enough and thus perhaps not have to
mess with the wire protocol at all, at least in initial implementations
(you'd still need some way of requesting and/or issuing new trust
tokens, but that could be taken out-of-band to another protocol).  It
might even be better to make this a part of a whole new protocol, since
as Paul points out, the current architecture appears to have some
fundamental flaws and it may be time to stop patching it up and get on
with the new architecture. This is where I'd like to  calibrate myself
against what Paul alluded to, to see where he was going with that.

Note that this idea would have some interesting side effects (or should
I call them "social effects"?) You begin life in a cold, dark, lonely
world with little trust and less functionality but over time, you build
up useful relationships which can serve you well. Your "coin of the
realm" here is your own credibility, so trying to pass forged trust
tokens rapidly pollutes your swimming pool, while valuable trust
relationships would suck in more trustworthy folks and benefit from
positive networking effects. Today's great mailing list would be
tomorrow's "trust ring", where any mail from anyone trusted by your
"list buddies" is accepted, mail from random Taiwanese MTAs is rejected
or tarpitted.

The guy who issues the certificates that start the flood of spam into
your mailbox gets deprecated as an authority with a click of a button.
The spammer (or legitimate stranger) who can't prove his bone fides gets
shunted to the slow lane over near the tarpits until he can prove
himself over time. And over time, you can elect to promote well-behaved
strangers to friends, expanding your trust ring.

My instinct tells me there's something here worth pursuing, given the
magnitude and growth rate of the current spam problem, but I doubt that
the IETF general mailing list is a place to work on this, so I'm
interested to see where the discussion  goes once the flames die
down....

As I said, I've done some digging and found nothing exactly like this,
but Paul's casual remark suggests I'm missing something basic in the
literature (admittedly I haven't done an exhaustive search yet).
Pointers to the obvious work, or pointers to the obvious holes, would be
most welcome. And of course, pointers to the best mailing list for
follow-ups are probably a *really* good idea....

                        - peterd

-- 
---------------------------------------------------------------------
    Peter Deutsch                       [email-masked]
    Gydig Software

                        "Bungle..."
               "That's an 'i', you idiot..."
                  "Oh, right. 'Bingle..."

                            - Red versus Blue...

---------------------------------------------------------------------

---

From: John Stracke <[email-masked]>
Date: Wed, 28 May 2003 15:10:43 -0400

Tony Hain wrote:

>The protocol needs
Hmm.  It's pretty much in the nature of human-to-human communication 
that the receiver is always going to have higher humanpower costs than 
the sender (since it's easier to say something than to understand it); 
so the only way to shift the balance is to impose extra costs on the sender.

In other words, any group chartered to work on such a protocol would be 
*required* to be inefficient.  At last, a charter goal we know we can 
meet! :-)

-- 
/==========================================================\
|John Stracke      [email-masked]                   |
|Principal Engineer|http://www.centive.com                 |
|Centive           |My opinions are my own.                |
|==========================================================|
|A man's concepts should exceed his vocabulary, or what's a|
|metaphor?                                                 |
\==========================================================/

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 28 May 2003 13:14:38 -0700

At 11:36 AM -0700 5/28/03, Tony Hain wrote:
>The external mechanisms already exist to deal with the

This is good to hear. I thought that the international trusted 
micropayments that would be needed for such a sender-pays system was 
a problem that was yet to be solved.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Einar Stefferud <[email-masked]>
Date: Wed, 28 May 2003 13:33:22 -0700

Hello  Peter --

I hate to be the one to tell you that the following is provably false:

"The unlying (sic) assumption here is that trust is a transitive relationship," 

Which leaves a bit of a gapping hole in your entire logical build...

"A trusts B" and "B trusts C"  does not imply anything about "A trusting C".

Even though you might decide to act on this assumption, believing it is true.

If trust is as transitive as you suggest, then it must also be true that if:
A trust B, and B trust C, and C trust D, and ... ; then A must also trust Z.

When you prover the latter true, then you have a chance at correctness: 
But even that is only true for a chain of 25 relationships.

If this assumption is true, then you must be a very gullible person, 
which I somehow seriously doubt;-)...

Cheers...\Stef

At 11:56 -0700 5/28/03, Peter Deutsch wrote:
>if so I could start granting the bearer interaction privileges. *** The
>unlying assumption here is that trust is a transitive relationship, *** 
>and thus I'd allow myself to build up webs of such trust relationships
>by accepting references and references from references, so I wouldn't
>have to rely solely on a single, centralized PKI infrastructure.
>

---

From: [email-masked]
Date: Wed, 28 May 2003 22:34:01 -0400

> Even though you might decide to act on this assumption, believing it is true.

Mathematically provably true is a term used mostly by mathematicians - which
often means that what they come up with (being mathematicians(*) and thus often
disjoint from reality) is something that may be not usable.  There are a LOT
of transitive trust relationships that may not be *strictly* true, but are
close enough to trust billions of dollars with...

Every time I use a credit card, the entire scheme only works because the
vendor trusts the people at Visa to trust the bank to trust me to actually
pay the bill.  Now mathematically speaking, this scheme is a large crock
of concentrated fertilizer - but you add a few laws making it illegal to
use it to defraud, the various middlemen take 3-4%, write off 1% for bad
debt losses, and you have a system that 99% works and is widely accepted
because that last 1% is just too much effort for too little gain.

> which I somehow seriously doubt;-)...

The next time you walk into a delicatessen and hand the cashier a piece
of paper printed by some government, and walk out of there holding a
salami and several smaller-denomination pieces of paper and pieces of
metal, think about what size web of trust makes *that* transaction work.

/Valdis

(*) My degree is in math.  I'm allowed to say that. ;)

---

From: Peter Deutsch <[email-masked]>
Date: Wed, 28 May 2003 20:19:16 -0700

g'day,

> Which leaves a bit of a gapping hole in your entire logical build...

Not at all, since the assumption of transitive trust is used merely to
"prime the pump". Once you start to develop evidence that disagrees with
your assumptions, you are expected to change your trust rules
accordingly. That's actually the heart of the system.

For example, I might start off by trusting mail from a particular
mailing list, and all its participants (say, anyone from my family
mailing list). I would then accept trust tokens from anyone who submits
a valid token from anyone on that mail list. Of course, if anyone used
such a tokento feed me spam, I'd hit the "Junk This" button on my MUA,
which would in turn tell my MTA to remove both the sender and that trust
token from my "trusted" list.

Put simply, I'd use a rule that says something like "fool me once, shame
on you, fool me twice, shame on me".

Note that this wouldn't prevent any of the folks on that mailing list
from reaching me, it would only prevent my MTA from trusting the
offender's token in the future. You could even tune that by putting
additional policy info in the trust token (you could put in a "degree of
trust" number, indicating how well you know the bearer, for example).

Now, suppose I wanted to send mail to Paul Vixie. I might just try to
send him mail, but from recent experience, I would expect that to go
something like this: "Hi, Paul!", "Mail System Error - Returned Mail".

Hmmm...

So, my MTA checks Paul's list of trusted buddies in the new, improved
DNS++, but doesn't recognize anyone in the list as somebody who's issued
me a trust token recently. So, off it goes to the Token Oracle, and ask
her for a trust path between myself and Paul Vixie (trust me, this can
be done. I have a proof of this, but the margins of my screen are too
small to contain it. It's enough for the purposes of this exposition to
note that this is something that can be precomputed so it can be
obtained somewhat efficiently).

So, back comes the Oracle, with the path:

  Peter Deutsch -> Einar Stefferud -> Randy Bush -> Paul Vixie

In other words, there is a trust chain from Einer Stefferud (who trust
me), to Randy Bush (who trusts Einar), to Paul Vixie (who trusts Randy).

Well, that's okay then, since I have a trust token from Einar Stefferud,
because I earned a trust token from you last week and you'd kindly
supplied me with one. Okay, so my MTA again contacts Paul's MTA and
offers it the trust token I have from you, as well as the trust chain.
Now, Paul can elect to accept mail from me, since the path checks out
and the token's good, and we'd be in business. Parenthetically, his MTA
would add the trust token from Einar Stefferud to his keychain for the
next time somebody comes a'calling.

Of course, if Paul reads my mail and decides that I really am as much of
a bozo as he'd feared, he's free to hit *his* "Junk This" button. This
would revoke my credit, and your trust token to me in his eyes, so he's
free to go back and finish reading the IETF mailing list without any
further direct interruption me. If I really want to reach him again, I
could try to find other paths from the tokens I've got left, until
either I've used up all my friends and acquaintences in a vain attempt
to get Paul's attention, or perhaps until I finally (through constant
allusions to Tom Lehrer) convince Paul Vixie that I'm not so bad after
all ("heck," he says, "this guy's a dope, but I do like 'Poisoning
Pigeons in the Park'...")

So, trust can be assumed to be transitive to prime the pump. Where you
find that this assumption is not valid, you can use the evidence that
it's not to tune and adjust your list of trusted sources. It's this
tuning over time that would make them more effective and lead to the
predicted success of the technique. 

As a final observation, the transitive nature of the trust is not the
key part of the system. To me, it's the ability to put policy decisions
in the hands of the recipient based upon past experience with trusted
sources, without having those trusted sources participate in the
interaction in real time. This seems to offer simplicity and scaling,
and means we can build this beast and get it out without requiring such
things as a single globally populated PKI, or universal takeup on the
scheme (the degenerative case is to accept everything, as folks do today
- the benefits accrue to the participants proportional to their
participation, but it begins paying off the first time you reject an
unknown sender without a trust token).

So, in summary, trust may not be transitive, but it makes a useful axiom
to kick things off. To paraphrase somebody's point a few hundred
postings ago, something can be an axiom without being true... ;-)

				- peterd

                        "Bungle..."

                            - Red versus Blue...

---

From: Peter Deutsch <[email-masked]>
Date: Wed, 28 May 2003 20:58:34 -0700

g'day,

Oops, bad form to follow-up to your own posts, but I just want to make
sure I'm on record as being the first to notice that this is really just
another instantiation of the Six Degrees of Kevin Bacon. In honour of
this observation, my current working name for this system is "Bacon"
(for the hopefully obvious reason).

>   Peter Deutsch -> Einar Stefferud -> Randy Bush -> Paul Vixie

Sorry Randy, I'm going to drop you from the example. I think it's
funnier if it reads:

   Peter Deutsch -> Einar Stefferud -> Kevin Bacon -> Paul Vixie

And if you don't get this, go read:

   http://www-distance.syr.edu/bacon.html

			- peterd

                        "Bungle..."

                            - Red versus Blue...

---

From: Einar Stefferud <[email-masked]>
Date: Thu, 29 May 2003 01:14:43 -0700

Hi Peter -- 

Your two additional explanatory messages here were needed to explain 
how you deal with trust transitivity when trust is not simply transitive, 
but might serve to allow you to explore for a path that, when tested by 
trial and error, might find a working transitive case in reality, based 
on more information than the simple assumption of transitivity without 
testing it to obtain more information via additional information 
transmission channels.

So, now you are confirming what I understand about defining trust.

Information, per Shannon, is some specific bits which the recipient did 
not expect to receive.  On this definitional foundation he built a huge 
edifice of mathematics for computing a lot of stuff about the capacities 
of wires and other transmission media, and the design of telephone and 
other communications channels, including how many redundant bits are 
needed to detect and correct errors.

And Trust, per my friend Ed Gerck, is that information, obtained via 
some different channel (or channels), which is required to 
understand and to trust said received information bits that (per Shannon) 
were not specifically expected to be received.

So, what you have done to counter the fact that trust is simply not 
transitive, is to add more channels to the process of communication, 
to obtain the required trust information via other channels, which you 
also state "might not prove to induce the desired trust". 

In the specific case you have chosen, I expect that your target will not 
accept your "tokens" as I have been considered to be the most dangerous 
person on the Internet, per various people.  This means that I might not 
be considered to be trustworthy.

This condition of untrustworthy perceptions is OK with me, but in the 
context of this discussion, you may very well have not gotten your message 
to be accepted by Paul Vixie.

Maybe next time you will succeed, but so far, the odds are against you 
next time too;-)...

So, for all intentions and purposes, trust is not simply transitive.

In part this is because it assumes a single channel, while additional 
channels are required because trust information cannot be meaningfully 
sent via the same channel as carried the information to be trusted.

This is why people typically laugh when a salesman says "Trust Me!"
Because they intuitively know that self assertion of trustworthiness 
has no value.

Cheers...\Stef

PS:  In this case, it is good that you did follow-up on your own message.
     ...\S

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 May 2003 14:12:15 +0200

On woensdag, mei 28, 2003, at 19:56 Europe/Amsterdam, Christian Huitema 

> could be more than welcome.

Detecting spam is hard, as spamminess is in the eye/mailbox of the 
beholder. However, I see no reason why we can't detect unsollicited 
bulk email for reasonable definitions of "sollicited" and "bulk".

To see whether a messsage would be welcome (sollicited) we can simply 
see if we know the source. This can be done end-to-end 
cryptographically or by trusting that a known MTA has checked the 
previous MTA and so on until we reach the MTA that verified the source. 
In order to detect bulk email we simply count the number of messages 
received from each MTA we're in contact with.

Then it's simply a question of rate limiting the number of messages 
accepted from unknown MTAs and/or redirecting unknown MTAs to a trusted 
MTA or an MTA that's in the position to do better anti-spam filtering.

So if I'm an AOL user with my own dial-up MTA and I want to send you a 
message, the Microsoft MTA doesn't know me so it either takes a chance 
and accepts messages at a low rate, it tells me "why don't you deliver 
this message to your ISP's MTA and have them forward it", "deliver this 
message to mx13.spamwashers.com" or "we can't accept your message, 
submit your remarks using our web form" or "submit a public key signed 
by at least two organizations listed on trustedmailers.microsoft.com".

So will this be enough? It won't get rid of all unsollicited email, 
commercial or otherwise. But the improved accountability should make 
life much harder for every type of spammer.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 29 May 2003 12:20:10 -0400

> on you (since this looks too much like punishing the innocent for the

I'm curious why you think Hashcash doesn't work.  Personally, I think
a scheme where (a) you provide a crypto signature which proves who you
are that you are someone that I trust to send me something useful,
*OR* (b) you have to send me some token which proves that you have
spent 120 seconds worth of CPU time calculating it, would work
perfectly.  That way, someone can still send me unsolicited mail
asking for help with e2fsck, or some other aspect of the Linux kernel,
but a spammer simply won't be able to afford the necessary CPU time to
send vast numbers of SPAM.  And regular correspondents with me
wouldn't could simply send a PKI authenticated token to avoid needing
to do the necessary CPU-burning calculations.  (And this is an
optimization anyway; someone who is sending me a human generated
message can generally easily afford the 2 minutes worth of CPU time
before their mailers can deliver the message to my mail host.)

						- Ted

---

From: John Stracke <[email-masked]>
Date: Thu, 29 May 2003 20:36:55 -0400

Theodore Ts'o wrote:

>someone who is sending me a human generated
But what CPU? The machines with which I routinely send mail range from a 
200MHz handheld to a 2GHz*2 desktop.  I would be unhappy with a protocol 
that required me to run my handheld's CPU at full speed for 2 minutes 
(the battery life isn't so hot); but that level of hashcash would 
require only 6 seconds from my desktop, which is probably too little to 
be a deterrent.  And, if it were targetted at making my *desktop* take 2 
minutes, then the handheld would take about 40, which is totally 
unacceptable.

The whole hashcash idea has two major flaws.  The most obvious is 
Moore's Law (you'll have to keep doubling the bar every 18 months, which 
means email will get more and more expensive for people who don't 
upgrade their CPUs).  The other is that all it proves is that *somebody* 
spent those CPU cycles.  Spammers already steal resources to send their 
messages; what's to stop them from sending out stealth worms that use 
the victim's machine to do hashcash calculations?

-- 
/===========================================================\
|John Stracke      [email-masked]                    |
|Principal Engineer|http://www.centive.com                  |
|Centive           |My opinions are my own.                 |
|===========================================================|
|There are footprints on the moon. No feet, just footprints.|
\===========================================================/

---

From: John Kristoff <[email-masked]>
Date: Thu, 29 May 2003 22:34:27 -0500

> (the battery life isn't so hot); but that level of hashcash would 

Rather than actually force the remote CPU be run for 2 minutes, the
receiving SMTP host can force the TCP window to 0 for 2 minutes.  This
could be coupled with a RBL list, but instead of a blackhole, it would
be more like a realtime pushback list (RPL), which has some nice
properties of punishing known abusers, but not causing complete
collateral damage to innocent parties.

John

---

From: Paul Vixie <[email-masked]>
Date: 30 May 2003 18:43:13 +0000

> ..., but instead of a blackhole, it would be more like a realtime
> pushback list (RPL), which has some nice properties of punishing known
> abusers, but not causing complete collateral damage to innocent parties.

the definitions of your words "known", "abusers", and "innocent" are highly
subjective and are known to vary considerably from one recipient to the next.

y'all have got to stop trying to save smtp, and just agree to move on.  smtp
was an ivory tower thing and it isn't working well down in the fields.
-- 
Paul Vixie