Subject: Re: Principles of Spam-abatement

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Mar 2004 16:23:20 +0900

Paul,

>> >> unfortunately, that act of communication _is_ the adverse side effect.
>> >> it tells the spammer that yours is an active, responsive email account.

PV> that's only true from the smtp perspective.  since smtp does not encode any
PV> aspect of consent, existence implies reachability.

rogue spammers are not concerned with consent.  they just want to know
that you and your address are alive.  feedback gives them that
informationl

PV>   however, since smtp is
PV> dead meat rotting in the sun waiting for us to figure out what to replace it

ready-fire-aim.  the dead meat is what the world uses today and will
continue to use for quite some time.  reports of its death are just a
tad premature.

When folks agree on the new mail transfer services that we need and
when we try to add them to smtp and fail, THEN we can have productive
discussions about a replacement transfer protocol.  until then, calls
for a new protocol very much constitute firing before aiming.

PV> with, smtp is not relevant in a discussion of "principles" which this claims
PV> to be.  (anyone who thinks that smtp can be upgraded to encode consent needs
PV> to spend a few more years Just Hitting Delete before you can sit at the
PV> grownups table.)

And everyone else needs to move from the generic reference to
"consent" on to something that is more concrete, as well as being
integrated into a full range of human uses for email.  It would be
nice to still have the baby around, after we have gotten rid of its
bath water.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 01 Mar 2004 08:55:33 +0000

> [smtp] is what the world uses today and will continue to use for quite
> some time.  reports of its death are just a tad premature.
> 
> discussions about a replacement transfer protocol.

well, except that that's not how dns was created, or http, or html, or
nntp, or xml, or rpc/xdr/nfs, or sip, or pgp, or jabber.  i guess that's
how a lot of people now think it should be done, but the counterexamples
are extensive, and so i'm not convinced that smtp will be replaced under
precisely the conditions you describe.

> until then, calls for a new protocol ... constitute firing before aiming.

i guess we'll all see how it turns out.

> integrated into a full range of human uses for email.

i'm pretty comfortable with www.dictionary.com's definition of "consent".

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Mar 2004 20:20:47 +0900

Paul,

>> discussions about a replacement transfer protocol.
PV> well, except that that's not how dns was created, or http, or html, or
PV> nntp, or xml, or rpc/xdr/nfs, or sip, or pgp, or jabber.

_New_ services get created in all sorts of ways and for all sorts of
reason.  However changing an existing, popular service is subject to
very different concerns than a new service.  In particular, it is
subject to careful attention to preservation of the installed base.

Facile assumptions that we will blithely move an installed base of 500
million people, to a new set of protocols, reminds me of a cliche
cartoon. It has a blackboard -- it's a very old cliche -- almost
filled with formulas, except for one blank strip that separates the
formulas into two sections. The board is being explained by one guy to
another. He is responding to a question, pointing to the blank space
and says "that? oh, that's where a miracle happens."

Switching 1/2 billion people requires quite a lot of force and time,
and so do the hundreds of thousands of implementors and operators who
have to make it happen.  They need clear and compelling incentives for
the considerable energy it will take and discomfort it will cause.

So far, claims that smtp needs to be replaced, to fix spam problems,
fail to provide anything more compelling than some strong emotions.

Let's remember that no action to date has reduced the global level of
spam.  So folks need to be a tad circumspect when calling for massive
infrastructure change for which there is no basis to guarantee
results.

>> integrated into a full range of human uses for email.

PV> i'm pretty comfortable with www.dictionary.com's definition of "consent".

Me too, for casual discussion, but it has nothing to do with technical
specification nor for careful understanding of the human and social
dynamics of messaging.

Really, Paul.  Pursuit of spam control needs far more detail and
deliberation.  It's urgent, but that's no excuse for being vague and
generic.

At a minimum, claims that we need to replace smtp need to include a
specific proposal that offers specific features absent from smtp. And
it needs to include a transition plan for those hundreds of thousands
of operators and 1/2 billion users.

d/

---

From: Paul Robinson <[email-masked]>
Date: Mon, 1 Mar 2004 12:08:24 +0000

> subject to careful attention to preservation of the installed base.

I think the point Paul Vixie was making was that saying we would discuss the new
protocol at all was not likely to happen. Already there is a mailing list over
at IMC for "mail-ng" where a lot of good ideas are being throw around. I expect
somebody is going to sit down and start writing code one day, and release it.
It will work over the existing infrastructure (e.g. use MXes from DNS records,
etc.) and address many of the concerns people have. If it does it well, it will
propogate and be used by more and more sites. There will be hook-ins for old
SMTP (in the same way that there were hook-ins for UUCP when SMTP came along),
and it will begin to propogate.

I very much doubt that the IETF will be in charge of any aspect of it.

What is important, is that we ensure that commercial interests that effectively
hands control of the mail infrastructure to a body with a commercial objective
does not happen. Ignoring such schemes (a la Microsoft and Yahoo!) will not
work - it will just make the IETF irrelevant.

Like it or not, it's time for all of us to get very serious, very quickly about
a replacement for SMTP. There is a clear need, the user requirements are
starting to firm up, and it's make or break time.
 
> million people, to a new set of protocols, reminds me of a cliche

We will not move anybody. We will provide a specification, programmers will
produce the code, ISPs and Software vendors will do the moving if their
customers request it.

> the considerable energy it will take and discomfort it will cause.

Is it just me, or is this just the IPv6 conversation again, but with "Mail"
replacing "IP"?
 
> fail to provide anything more compelling than some strong emotions.

The IMC list is producing some good ideas. I was due to collate them all into
one big document, but time has got the better of me, as has the several hundred
(maybe, thousand?) messages I need to go through to get all the ideas
captured.
 
> infrastructure change for which there is no basis to guarantee

Statistics have a reputation you know. It's impossible to put an accurate figure
on the amount of spam sent at a global level. Even if you could, that's not the
same figure as the amount that ends up in user's inboxes (some gets 550'ed,
some gets marked for deletion and filtered). We don't know the precise figures,
we can only guess. And we know that as a percentage, the signal-to-noise ratio
is pretty poor, from personal experience.

However, in my inbox, I get less spam confronting me on a daily basis than I did
6 months ago. My spam folder has grown considerably, but my inbox is relatively
clean. The problem is, the techniques I've used to make that so are beyond most
users, and it would seem, most ISPs.

-- 
Paul Robinson

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 1 Mar 2004 21:30:58 +0900

I think that considering that the time to deploy a new mail system will take longer than deploying IPv6 ... it make sense to deploy both together, I mean a new mail system WITH IPv6, possible using IPsec. I think it will be even faster than if we try to do now the deployment of IPv6, and tomorrow the deployment of the "new" email system ...

It could be also a nice value added for IPv6, that could help on the deployment.

I had this idea in my mind since a long time ago ... we just need to sit down and make out of it a nice architecture !

Regards,
Jordi

----- Original Message ----- 
From: "Paul Robinson" <[email-masked]>
To: "Dave Crocker" <[email-masked]>; "Dave Crocker" <[email-masked]>
Cc: "Paul Vixie" <[email-masked]>; <[email-masked]>
Sent: Monday, March 01, 2004 9:08 PM
Subject: Re: Principles of Spam-abatement

> users, and it would seem, most ISPs.

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: "Robert G. Brown" <[email-masked]>
Date: Mon, 1 Mar 2004 07:32:22 -0500 (EST)

> i'm pretty comfortable with www.dictionary.com's definition of "consent".

Ah, are we about to develop psmtp (psychic simple mail transport
protocol)?  The first mail protocol that can read my mind and see if I
"consent" to a particular communication before I (or rather, my mail
agent, since that's where one part of the abuse occurs) receive it?

That's a neat trick...

Logical analysis reveals that psychic filtering is what is required to
avoid any chance that I could get abusive email, e.g. spam, while still
permitting a full range of desired communications including those from
strangers, without extra "approval" steps (of which most
users/administrators will definitely not approve and which would let
spam through anyway, at least to the point where they have to see it and
not approve).

Or is "consent" a mnemonic for breaking the entire Internet into White
and Black lists with no grey sites whatsoever according to a common
standard, PRESUMING that I and all other users would consent (in fact
have consented, via inherited Acceptable Use agreements) to turn off all
internet access -- at least to those resources we control -- to those
that chronically abuse those resources?

The latter is not so crazy.  It is more or less what "enforcing existing
AU agreements" would be, were there an actual PROTOCOL for such
enforcement instead of an incomplete and inconsistent hodgepodge of AUs
with spotty enforcement and no way to make enforcement universal.  I've
called for something like this as an obvious first step to regulating
spam and other abuse in a couple of my earlier responses.  My attention
was drawn to:

  http://www.camblab.com/misc/univ_std.txt

which seems to be a very, very practical and immediately feasible way to
secure the protocols we have now.  Curiously, it works by formally
defining a process for converting the Internet into white (or at least,
very light grey:-) and blacklists of a sort and enfolding this into
effectively all internet services.  It has the delightful effect of
punishing the abusers and not the innocent, and of punishing (by
blacklisting) the SPs of chronic abusers (the ones who profit the most
from abuse) to precisely the point where they responsively police their
own networks or go out of business, whichever comes first, and of
permitting that "disconnection" to be done by anybody from a common list
rather than waiting for the SP's PoP provider to go through THEIR
various internal due processes (if any) and pull a plug that might be
making THEM a lot of money...to the discomfiture and waste of money
spent by everybody else.

This document puts forth a >>measure<< of abusive behavior that causes
us (the "Internet") to withdraw our >>consent<< for all kinds of
transactions and is the first step to a >>protocol<< that permits this
consent to be effectively immediately withdrawn from a common and
dynamic (in both directions, as black sites are policed white again).
In a consensual anarchy like the Internet, it is definitely the right
way to proceed, as for the first time newsletters such as Security Wire
Digest contain rumblings calling for and warning of government
regulation that (while certainly welcome with respect to certain forms
of abuse) can easily turn into the nose of a big, ugly, smelly camel
under the Internet tent.  Or end up endorsing a witless and expensive
solution to the great profit of some congressman's biggest donor.

Maybe I just like it because it agrees with my own point of view (the
definition of an intelligent person being "somebody who agrees with
you", after all:-).  It's worth a read.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:[email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 1 Mar 2004 07:55:14 -0700 (MST)

> From: Paul Vixie <[email-masked]>

> ...

That is the fatal flaw in the calls for technical mechanisms
"communicating consent" to fix spam.  Webster's definition of consent
also applies to keeping solicitors from knocking on your door and
bandits from mugging you on the streets.  What keeps enough of them
from lying about having your consent are the non-technical protocols
of the justice system.

No matter what additional token of consent that you require spammers
to present to demonstrate that you have agreed to their mail, either
spammers will be able to forge it or legitimate strangers won't be
able to obtain it without contacting you or your agents and ceasing
to be strangers.

The usual response to that (and one which I think you've suggested)
is to have a third party act as your agent.  But that is exactly
equivalent to the Microsoft/Verisign crypto authentication FUSSP.
Whether SMTP is involved is irrelevant; the fatal flaw of such agencies
applies to any messaging scheme.  It is that unless a mail identity
is practically unforgeable thanks to $10,000 costs or enforced legal
penalties, spammers will sign up for new identities as each is executed
for spamming.  If an identity costs less than $50/year and there are
no enforced laws against having as many identites as the recent spurt
of "Zhang Jung" and "Media Dreamland" domain names, it will be impossible
for your consent/identity/reputation agency to ensure that 1000 of the
next 1,000,000 applications are really Al Ralsky in disguise.

There are other problems with the "consent" or "identity" or "reputation
agencies" that are often talked about.  One is that giving Microsoft/AOL
a franchise to levy a $0.001 toll on or append an ad to every message
in the Internet is a Bad Thing unless you are stockholder.

These problems have nothing to do with SMTP.   You give aid and comfort
to the spammers and parasites on the spam problem by suggesting that
a replacement to SMTP might solve these non-technical problems with
"communicating consent."   You are implicitly supporting the worse
than snake oil being flogged as spam solutions by big outfits.

Vernon Schryver    [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Mon, 01 Mar 2004 15:22:57 +0000

> _New_ services get created in all sorts of ways and for all sorts of reason.

if you believe that ssh was a new service (compared to telnet) then i agree
with this perspective.  i think that you won't, though.  new ways of doing
old things can appear, and old ways of doing those same things can disappear,
and this is good and right and healthy.  smtp won't have to be declared dead
in order for me to stop using it when something better comes into existence.

it's worth remembering that mail was once transferred using the ftp protocol.

> deliberation.  It's urgent, but that's no excuse for being vague and

probably you should Just Hit Delete until yahoo "domainkeys" saves smtp, then.

> of operators and 1/2 billion users.

actually, they don't.  and, if you stack the problem grain to grain like
that, you'll never cut through.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 01 Mar 2004 17:57:40 +0000

> Ah, are we about to develop psmtp (psychic simple mail transport protocol)?

no.  but through a combination of open source and public benefit licensing,
we are eventually going to be able to tell whether a message was generated
by someone who was present and gave consent, or whether it's just wormware;
and whether the owner of an ip-using device intends to act as a mail server;
and whether a bond has been posted by this present/consenting sender and if
so how much; and whether there exists or not a trust path from the sender,
through their bank or school or employer or insurance company to the
recipient.  the internet doesn't care what your meatspace identity is and
anonymity is a necessary way of life -- but we do care very much whether
transitive trust exists.  "who you are" matters less than "who you know",
and this is true not just for messaging but also for web service accounts and
passwords, for trading and payments, and for so-called "social networking."

> ... document puts forth a >>measure<< of abusive behavior that causes
> us (the "Internet") to withdraw our >>consent<< for all kinds of ...

ok, so two weeks ago i grabbed a spare /16 and put database-writing "servers"
on ports 25 and 80, and watched for worm spoor.  i also hooked it up to a
ddns "blackhole zone" that i can use in postfix and apache to reject 
connections from addresses who have attempted to worm into this /16.  after
16 days of operation the zone has 149076 addresses in it and my spam volume
(nonrejected) is down 80%.  (now that arin has an experimental allocation
policy i hope to add more address space to the basin, and there's been some
thought given to publishing the data thus gathered via http://oarc.isc.org/.)

what this means is, needing a basis for withdrawing consent is just wrong,
and what we need is a basis for offering it.

all attempts to encode this kind of information in the message header or
payload, to date, have failed.  usually because it's a consortium of large
commercial enterprises seeking to monetize the trust paths, much as verisign
is now planning (see http://news.com.com/2100-7355-5163410.html?tag=nl).  i
don't expect to see another x509-like hierarchy succeed in the marketplace,
it's too brittle and too abuse-prone and too beneficial to early adopters
and monopolistic behemoths.  the real solution will be more pgp-like and
will have a hairball topology, for survivability and palatability reasons.

(and it's lots more likely to get built on top of jabber than on top of smtp.)

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 1 Mar 2004 11:41:06 -0700 (MST)

> passwords, for trading and payments, and for so-called "social networking."

The trouble with that is that trust is not and cannot be made transitive.

There is a finite chain of people that connects you with anyone you
care to name, with each person asserting any sort of trust you want
for the next person in the chain.  The chain that connects you with
Al Ralsky for the trust operator "the next person to corrently identifies
people" is probably shorter than 6 people.  The chain that connects
you with Ralsky for "next person to does not spam" is probably longer
than 6, but shorter than a couple dozen.  Even worse, the chain the
connects you to Al Ralsky for "the next person is not Al Ralsky" is
probably shorter than the first, short chain.

The notion of transitive trust makes as much sense as assuming that
all of the keys on the key rings of the people who will be signing PGP
keys at the IETF this week are of people who you can trust to not send
you mail you'd not want.

In the real world, there is nothing like transitive trust.  That's why
it is so hard to cash third-party checks.  The closest you can get to
transitive trust is something like the check clearing system, which
has only about 5 parties, with three (the two banks and the Federal
Reserve) so entangled that they can be considered a single outfit.
And check forgery remains a major problem.

If transitive trust could be made to work, then government security
clearances would be easy.  If it could work, we would have more than
3 credit reporting agencies, and we would not have so much machinery
to deal with their errors.  If transitive trust cannot be made to work
for those cases where there are major penalties for cheating, how can
you expect to make it work for mail, which no one values at more than
$30/year/seat?

You might say that you don't want fully transitive trust but only
to trust the people who know people you know.  If you want that
kind of mail system that does not carry message between strangers, 
you've already got it with any of the many kinds of whitelisting.

These problems with trust have nothing to do with the network protocols
involved.  They are fundamentally non-technical.  Talking about replacing
SMTP to implement transitive trust is at best a distraction.

---

From: Paul Vixie <[email-masked]>
Date: 01 Mar 2004 20:15:35 +0000

> clearances would be easy.  If it could work, we would have more than 3
> credit reporting agencies, and we would not have so much machinery to
> deal with their errors.  If transitive trust cannot be made to work for
> those cases where there are major penalties for cheating, how can you
> expect to make it work for mail, which no one values at more than
> $30/year/seat?

that's not an unreasonable question.  and yet, the meatspace world copes.
the thing cybertrust hasn't done is to take advantage of existing meatspace
relationships.  probably there's no way i'll ever have reason to trust you
but i'll bet my bank has ways of trusting your bank.  (or your school or
my insurance company or whatever.)  if you think in terms of pgp then trust
can't scale.  if you think in terms of the meatspace world and its millenia
of traditions and mechanisms, trust clearly can scale.

if your bond is only $30/year then i probably wouldn't trust you no matter
what my bank told me about your insurance company or what your insurance
company said about you.  remember, i don't want to know who you are, i only
want to know who you know.  if the world has no hooks into you then i would
withhold my consent.  presumably there are others who would only give consent
if your religion was the same as theirs or if your identity was known -- but
that all fits under the "all communications by mutual consent" banner.

> you've already got it with any of the many kinds of whitelisting.

no, i want it to be as big as meatspace.

> SMTP to implement transitive trust is at best a distraction.

unfortunately you're right about that last part.  smtp's major problem is its
unpleasant distinction between the transport and mailbox, and it *will* get
replaced with something that can carry trust indicators and deal with
multilevel agency.  but the real and larger work is the meatspace-sized trust
web, without which smtp is probably as good as e-messaging can ever get.
-- 
Paul Vixie

---

From: Dean Anderson <[email-masked]>
Date: Mon, 1 Mar 2004 15:42:41 -0500 (EST)

> agent, since that's where one part of the abuse occurs) receive it?

It seems that many of the people who consider themselves to be sitting at
the "grownup-table" really have a child-like ignorance of causality
constraints in their schemes.

I am always amused when people naively critcize SMTP for permitting spam,
as though changing the protocol would make people not want break the
rules.  I am also impressed by the people who think that people just
aren't taking the problem very seriously.

The list of the "Principles of Spam-abatement" is itself very naive. It
assumes that spammers are people who make money selling products.  
Certainly, there are some who would prefer people believed this.
Unfortunately, the (January) results coming back from the CAN-SPAM show
that 56% of the 95 top spammers are _fully_ compliant with the CAN-SPAM
act.  Yet few messages in my inbox are even partially compliant. This
gives one some idea of how much spam is being sent by viruses and "fake"
spammers: Quite a lot.  The genuine spammers are permission based, and
have honest opt-out facilities and aren't annoying anyone except the
radicals who can't abide their existance.

Any "solution" to spam has to stop the viruses that have no genuine
products or services to sell, no interest in finding out if they reach
real addresses, no concern for taxes, nor any regard for civil or criminal
law.

> <extract>
> *** Anonymous Bulk Email Software
>
> *** is a super fast bulk email software that sends out at speeds greater
> than 1,000,000 emails per hour* on a dedicated mailing server.
>
> *** has the capability to use Proxies and Relays and also to send
> directly.
>
> Some of the features include:
> Anonymous Mailing using Proxies
> Message Randomization to bypass Spam Filters
> Speeds over 850-950K emails per hour on Turbo Mode
> Up to 1000 Threads
> Unlimited Email List Size (up to 100 Million per file)
> HTML and Plain Text Emails
> Tag Macros to personalize and randomize emails
> Custom Headers ....... more on
> </extract>

The above description is for a product that violates the CAN-SPAM act,
which prohibits deceptive practices. But wait, it also claims to advertise
proxies and relays--that's something I know about:  Analysis of our logs
over a long period have only found anti-spammers scanning for relays.  We
know this because for one to scan for a relay, they have to include an
email address that recieves email. Setting up an "unused" mailserver
allows easy collection of the email addresses of those scanning relays.  
So far, all such scanning has been by anti-spam sites. So, this "spamware"
is not a truly genuine product--it is either a complete fraud (no
product), or a deception sold by "anti-spammers" to identify potential
spammers, or it is a group of people (anti-spammers) helping spammers
spam--presumably hoping to annoy people into helping their cause.

While it is harder to identify the people scanning for proxies, it is
still easy to detect such scanning, and stop the scanning. After stopping
the scanning, we are left with the technique of having the virus-infected
computer "phone home". However, this can also be used to identify the
operator.

Clearly, there are people out there trying to make the spam problem worse.
Paul Vixie told me (in email)  back in 1997 that it was his "goal to make
things worse", that anything that makes the spam problem worse, makes it
more likely that spam will be banned.  Undoubtedly, there are people who
have taken that goal too literally.  He's also said recently that he's
been in contact with the "script kiddies"  (who operate viruses) and that
they are mostly anti-spam. Yet almost all viruses send spam.  Any
realistic measure needs to consider how to stop those radical antispammers
and script kiddies who just want to annoy people until they "take spam
seriously".

Someone else wrote:
> Something along the lines of 'Know your enemy' comes to mind; get hold
> of such a product, reverse engineer it, find its weaknesses and nullify
> it.

People have been doing this for many years. Probably since 1994, but
certainly in earnest since 1996 or 1997.  No luck for a permanent
solution. It is just a whack-a-mole operation.

Someone else wrote:
> I am thinking that spam is and will remain a long-term battleground
> and it needs serious effort to counter, perhaps a Cert-like
> organisation, and we are just not putting in enough serious effort yet;
> perhaps the cost to us is not yet high enough to stir us to action.

Well, there have been very serious efforts, for a very long time, by very
smart people. These efforts are just not enough, and as information theory
shows, will never be "enough".

It is interesting that the same people who promised a technical solution
many years ago, and have failed after 7 or 8 years of trying to create a
permanent technical solution to spam, are still saying things like "we
need to change the protocol", or (essentially) "we need to have time
travel to block spam."

It is also interesting that the IEMCC proposal made in 1997, and now
basically implemented in the CAN-SPAM act, has shown that commercial
spammers are not the abusers. This is more than the radicals have come up
with in the intervening 7 or 8 years.

Its also apparent that we could have had the IEMCC proposal implemented 7
years earlier, were it not for a group of radical anti-spammers that
attacked AGIS and Cyberpromo with Distributed Denial of Service attacks.  
Had we done that, we would be focused on stopping the criminals operating
viruses and conducting abuse for the sake of abuse. If we had spent the
last 7 years doing that, then we would have far less junk that we call
spam.  Those radicals did "make it worse".  We have them to thank for our
spam.  The radicals were wrong years ago, are wrong now, and have been
making the problem worse, not better.  The first "Spam Abatement
Principle" needs to acknowledge that radical anti-spammers are a source of
the problem, and that these radicals shouldn't be "at the grownup table".

		--Dean

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 1 Mar 2004 14:05:36 -0700 (MST)

> From: Paul Vixie <[email-masked]>

> that's not an unreasonable question.  and yet, the meatspace world copes.

The real world copes only by having laws against enforced violations
of trust.  Until the first spammer goes to jail for breaking the laws
that have long made most current spam illegal, all talk of trust fixing
spam is academic.  If the activities of the ROKSO 200 really get them
real penalties, then talk of trust vs. spam becomes relevant, but only
for as one among many fixes for what is currently a trivial part of
the spam problem, the spam from people who are not criminals.

> relationships.  ...
>                                        ... meatspace world and its millenia

It is not trust that scales but police.  There is no transitive trust
in the real world.  There are only bi- and sometimes trilateral contracts
and lots of people with guns ready to punish those who break trust.  If
transitive trust were even in the real world, buying a house would not
be such a big expensive ritual with escrow, title insurance, and so
forth.  If trust "scaled" in the real world, it would be a lot easier
to get the title for your car converted from one state to another.

Some might offer title insurance as a model for stopping spam, but
only if they've never paid for it.

> that all fits under the "all communications by mutual consent" banner.

There are problems there.  First is that you are not talking about
anything that might be called "transitive" trust.  The word "transitive"
is wrong and misleading.  Please use something like "secondary trust"
or "bonding" or "letter of recommendation."  Second, as Dave Crooker
wrote, your "hooks" are too nebulous.

There's a cool and relevant article in the March-April 2004 issue
"American Scientist."  It concerns how religious groups manage to trust
their members.  The problem/analogy with your trust model is that mail
is not worth $30/year to anyone, not to mention self-mutilation.  How
much does a "check guarantee card" or real estate title insurance or
a jail bail bond cost?

> web, without which smtp is probably as good as e-messaging can ever get.

I do not agree, but mostly because I doubt that vastly larger goal
of "a meatspace-sized trust web."  Whether SMTP disappears doesn't
matter to me.  I was using email long before it appeared.

And I say again: every time you, with your standing, even whisper about
replacing SMTP with a protocol that carries trust tokens, you give aid
and comfort to spammers and the parasites using the spam problem.
Regardless of what you mean, they translate your words as "Paul Vixie
agrees that TOES/SPF/RMX/SMTP-AUTH/CalleriD/HashCash/E-postage/...
is the Final Ultimate Solution to the Spam Problem."

---

From: Dave Crocker <[email-masked]>
Date: Tue, 2 Mar 2004 12:55:21 +0900

Paul,

>> _New_ services get created in all sorts of ways and for all sorts of reason.
 PV> if you believe that ssh was a new service (compared to telnet) then i agree
PV> with this perspective.  i think that you won't, though.  new ways of doing
PV> old things can appear, and old ways of doing those same things can disappear,
PV> and this is good and right and healthy.

Interesting example. It would help if ssh had achieved Internet-scale
use and had displaced telnet. On the other hand, terminal-oriented
traffic used to dominate net statistics and now probably does not show
up in the top 5.

So it would help to see an example that showed massive displacement of
a very large, installed base, before we assume that switching email
protocols is that straightforward.

PV> smtp won't have to be declared dead
PV> in order for me to stop using it when something better comes into existence.

of course.  the is not about declarations.  it is about the challenge
of convincing 500 million people and perhaps 200,000 organizations, to
switch.

PV> it's worth remembering that mail was once transferred using the ftp protocol.

Indeed it was.  And it is worth noting that the protocol that replaced
it provided nearly the same service, other than the efficiency
enhancement of multiple addressees during a single transfer.  Users
saw no change to email semantics, only better performance for when
there were long address list.

However, I suspect you have in mind a change that is a tad more
disruptive to the end user service model than that.

But that is only a guess since there is no detailed proposal to
comment on.

(I also should not avoid the chance to make the trivial observation
that the scale of Internet operations was a tad smaller then.)

>> of operators and 1/2 billion users.

PV> actually, they don't.  and, if you stack the problem grain to grain like
PV> that, you'll never cut through.

It's difficult to see the superior basis for making wholesale changes
to a very large installed base. The current style people have, for
discussing any of this topic in public fora looks pretty much
identical to clinical hysteria.

ready, fire, aim.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Mar 2004 07:18:57 -0800

Paul,

PV> but i'll bet my bank has ways of trusting your bank.
...
PV> if your bond is only $30/year then i probably wouldn't trust you no matter
PV> what my bank told me about your insurance company or what your insurance

It depends upon what is being trusted and what the incentives are for
violating the trust.

Some trust does require a large, enforceable penalty for violations.
Other trust can work quite well based only on history.

A bank might give out small, unsecured loans based on that history, but
might require a big loan to be secured.

I might be willing to take a first-first email from someone who has a
history of not-spamming, without requiring that they suffer a penalty
(other than my reporting them to the third-party trust agency) if they
violate that.

d/

---

From: Paul Vixie <[email-masked]>
Date: Wed, 17 Mar 2004 15:33:22 +0000

> (other than my reporting them to the third-party trust agency) if they

no, you would not.

dave, you're not thinking of this as information warfare.  you have to.
every time you consider a plan, ask yourself "where are the loopholes?"
or "how can it be abused?"  (and, "what if 6 billion people did this?")

identities without history will be a dime a dozen, or cheaper.  spammers
with no history could trample your privacy all day long if you allowed it.

accepting incoming communication from someone the world has no hooks into
is off the table.  allowing the world to have its hooks in someone whose
identity you don't know (and could never find out) has to continue to work,
but anonymity and homelessness are not the same thing.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 17 Mar 2004 09:06:23 -0700 (MST)

> From: Paul Vixie 

> but anonymity and homelessness are not the same thing.

Stated that way, but perhaps with an unintended interpretation, I agree.
Every mail sender is "hooked" by an entity that the mail receiver knows
and that has its own reputation that can be checked today.  The ISPs
that own the IP addresses in every IP packet that Ralsky sends "have
their hooks" in Ralsky.   You can decide whether the implicit no-spam
guarantee from that "hooking" agency is sufficient by checking your own
blacklist or the blacklists of others via DNS or BGP.

All of the possible good and bad aspects of any possible "trust" or
"reputation" system are already present in the current system.  

  - If you say that you can't trust ISPs to check that a new customer
     is not Al Ralsky in disguise or one of his proxies, then you must
     say the same about any other organization.

  - If you say that ISPs cannot check the reputation of new customers
     for a $30/month account, then you must say the same about any other
     organization.

  - If you say that you cannot trust ISPs to terminate the accounts of
     spammers, then you must say that you cannot trust any other outfit
     to revoke the PKI cert or other assurance for spammers. 

  - If you trust some of those other outfits to revoke their virtual
     letters of introduction and recommendation, than you must be
     willing to trust some ISPs to do the same and terminate accounts.

  - If you say that third party organization could assure you that a
     mail sender is not a spammer, then you must agree that an ISP
     could check with that organization before adding a password to a
     RADIUS server or or turn on a DSLAM, and that an ISP could terminate
     an account when that third party revokes is assurance.

  - You can be anonymous on the Internet only if your ISP protects you.
     No one is homeless on the Internet.  The SYN-ACK for your SYN to
     port 25 must get back to your source IP address home at your ISP.

The connection between you, the spam or mail target, and the ISP that
has its hooks in the mail sender is better than any PKI or crypto
related system could possibly be.  It is not only much cheaper than
anything Microsoft/Yahoo/AOL/Verisign would sell, but technically more
reliable.  IP address spoofing was practically impossible for spam
even before RFC 1948 and related defenses, because it was too hard and
unreliable if you need to make 10,000,000 successfully spoofed ISN
predicted TCP connections per day.  On the other hand, we all knew
even before the bogus "Microsoft Corporation" certs or the discovery
that those bogus certs could not be revoked that commercial PKI is eyewash.

If you believe that "reputation" or "trust" systems might help the
spam problem, then the only room for improvement is in the trust query
protocol.  DNS is a screw driver being used as a hammer in DNS blacklists.
However, this is merely a matter of optimization or elegance.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 17 Mar 2004 10:11:27 -0600

On 3/17/2004 9:33 AM, Paul Vixie wrote:

> identities without history will be a dime a dozen, or cheaper.
> spammers with no history could trample your privacy all day long if you
> allowed it.
> 
> accepting incoming communication from someone the world has no hooks
> into is off the table.

Not applicable to sales@ or emergency@ type mailboxes.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Ed Gerck <[email-masked]>
Date: Wed, 17 Mar 2004 08:47:07 -0800

> Not applicable to sales@ or emergency@ type mailboxes.

Why? Should someone arrive at your Sales or Emergency window
in your office, naked, what would you do? 

"Off the table" is IMO the correct action for an email address
that is naked -- i.e., that has no verification information.

Note that this is nothing new. We already do this with IP numbers.
If you send me a packet with a non-verifiable source IP there 
will be no communication possible. Why should it be different 
with email addresses?

Cheers,
Ed Gerck

---

From: Paul Vixie <[email-masked]>
Date: 17 Mar 2004 17:18:46 +0000

> However, this is merely a matter of optimization or elegance.

so, it's possible that there is some overlap between my universal privacy
goals, and my support for the long-awaited dnssec extensions, and my support
for the procket/juniper/cisco/paix/nasa/verio/shepfarm/isc multicast
deployment effort.
-- 
Paul Vixie

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 17 Mar 2004 12:25:45 -0500

> However, this is merely a matter of optimization or elegance.

I had some preliminary conversations with blacklist operators about 
this. There wasn't any interest in making a better protocol, but some 
people did expressed a need to document the existing one.

Yakov

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 17 Mar 2004 11:40:26 -0600

> in your office, naked, what would you do? 

uh, public nudity is (mostly) criminal, so not a good analogy, although
comparisons to a "no shirt, no shoes, no service" policy statement would
be getting there.

A better analogy is with new checking accounts. Many places won't accept
checks numbered below 1000, since they indicate that the account has not
established a track record. Other places will accept the checks after
verification, other places will accept them with thumbprint or some other
identifier. In all these cases, the organization is able to determine its
risk limits and act accordingly.

I'm not going to get sucked into this endless debate, but it is equally
tyrannical to require everyone use some kind of hard trust as it is to
require everyone use no trust (what we are moving away from, in blobbish
fashion and pace). There must be consideration for exceptions; the
swimming pool snack bar probably cannot enforce a "no shirt..." policy.

Property rights (of which I am a big advocate) "work" because they can be
selected and enforced at the owner's scale; people can put up "no
trespassing" or "no solicitation" or "no hunting" or "no shirt..." signs
to advertise their chosen policies. The same kind of mechanism is needed
for property protection to work in networking as well.

> will be no communication possible. Why should it be different 

Verification is different from trust. My position is that you need to be
able to validate and verify before you can successfully apply any kind of
trust (otherwise the trust is meaningless). Paul's message that I replied
to was specifically describing a minimum threshold of trust (it was akin
to the "no checks below #1000" position).

---

From: Dean Anderson <[email-masked]>
Date: Wed, 17 Mar 2004 13:00:47 -0500 (EST)

When you cannot trust people like Paul Vixie and Bill Manning to terminate
sites that are engaging in plainly obvious and egregious defamation and
harrassment claiming that IP address space is hijacked when a quick check
of the registry indicates that it isn't, then you also can't trust them to
be in charge of a trust system.  They are people who have asked others to
trust them. They are people who have said that trust is important.  They
are people who have said ISP's should have AUP's, and should enforce them
against abusive users.

The world certainly has its hooks into them.  Yet, we find that they are
associated with court-proven liars and other disreputable people, who have
their own spiteful agenda, and they aren't even embarrassed by that
finding.  We find them misleading their subscribers, for example by
blocking companies outside of their criteria, or just completely falsely
for spite.

This type of thing hasn't happened just once, but many times, by many
blacklist operators.

Quite obviously, we can't have a trust based system, because the 
anti-spammers are even less trustworthy than the spammers.

		--Dean

---

From: John Leslie <[email-masked]>
Date: Wed, 17 Mar 2004 14:04:58 -0500

> "reputation" system are already present in the current system.  

   Not so.

>   say the same about any other organization.

   ISPs operate in a _very_ different business environment than, say,
UNICEF.

>   for a $30/month account, then you must say the same about any
>   other organization.

   ISPs offering $30-per-month service are very likely losing money
(and worrying who to lay off next). Your bank, OTOH, is probably
doing nicely on less than $30-per-month service charges. Also, some
ISPs have no reason to worry much about their reputation, because
they have in effect a government-mandated near-monopoly.

>   letters of introduction and recommendation, then you must be

   Ah, yes, but _which_ ISPs?

> - If you say that third party organization could assure you that
>   a mail sender is not a spammer, then you must agree that an ISP
>   could check with that organization before adding a password to
>   a RADIUS server or or turn on a DSLAM, and that an ISP could
>   terminate an account when that third party revokes is assurance.

   The first part is actually true: I think we'd actually see that
if such third-party services come into common use. :^)

   The second part (terminating) is not true, IMHO. There's a real
danger of getting sued for that, not to mention the loss of revenue.
However, donning Pangloss's hat, I do hope that they might activate
some port-25 bandwidth-limiting. ;^)

> If you believe that "reputation" or "trust" systems might help
> the spam problem, then the only room for improvement is in the
> trust query protocol. DNS is a screw driver being used as a
> hammer in DNS blacklists.

   Current DNS blacklists are, IMHO, trying to do an impossible job.

> However, this is merely a matter of optimization or elegance.

   I disagree: it's a matter of biting off more than you can chew.

--
John Leslie <[email-masked]>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 17 Mar 2004 11:12:51 -0800

Hello folks,

"Eric A. Hall" wrote:

> uh, public nudity is (mostly) criminal

Too bad!  Actually, what is often proscribed
is lewd behavior, and nudity is often wrongly
considered lewd.

Anyway it's awfully difficult to really
reconcile nudity with criminal behavior.

Regards,
Charlie P.

---

From: "Robert G. Brown" <[email-masked]>
Date: Wed, 17 Mar 2004 14:00:00 -0500 (EST)

(A bunch of beautifully said things that I agree with fully)

> However, this is merely a matter of optimization or elegance.

The one other place that I think there COULD be room for improvement is
to make the process of identifying sites that are originating spam or
viruses more rapid and automatic, and to create a better/more formal set
of rules responding to a site (or an entire SP subnetwork) postmaster.
Such work might actually spell out all the steps between reporting and
being blacklisted.

Right now I think it is safe to say that "most users" don't know
anything about "postmaster" addresses.  Nor do they know how to read a
mail header (or they may be using a MUA that doesn't present the full
header even as an option).  Finally, complaining about spam takes time,
especially when you have a lot and have to write an actual message about
each one one at a time.  Consequently 99+% of all users are effectively
prevented from reporting spam to the hosting SP of the originator by a
mix of inertia, ignorance, and inability.

No wonder the SPs feel that they can ignore the problem -- instead of a
million pieces of spam generating a million complaints and burying the
poor postmaster admins of the enabling SP in an emergency consisting of
rapidly filling mail spool files and writing procmail rules to handle
them all so they can extract real communications from all the spam
complaints, they get ten reports of spam, maybe, from ten hardnosed old
timers who can read a mail header and care enough to report them (maybe
because they make it through their filters). I no longer bother -- if I
have to generate a complaint message per piece that my filters identify,
I'll never get ANY work done.

If every ten pieces of spam sent out of an SPs network -- even every 100
pieces -- generated a complaint message to postmaster with headers laid
out that clearly identified the offending host/client, I think that it
would provide SPs with a real incentive, AND the tools, to address the
problem.  

I don't know if this is a problem that could be addressed in protocol,
but it might be.  I can think of several things that an MTA (or MUA)
might do to facilitate a spam-bounce.

  a) Preparse the header so that the entire delivery path is the primary
content of the message, with the message itself added (header intact) as
an attachment.

  b) Return the complaint as mail to postmaster of the originating
network with a special error code that would allow it to be counted and
digested easily.  One doesn't want to create a new kind of DoS attack on
postmaster, and making it easy and automatic to return a complaint COUNT
of some sort on otherwise identical content can help prevent that while
making it easier for SP admins to deal with mounting complaint levels.

  c) Work out what to do about relays and proxies, again to prevent
man-in-the-middle DoS more than anything else.  One site should not be
able to generate mail that it "forwards" with fictitious headers and
evil content so that it appears to come from some hapless but innocent
network.

  d) Take steps to ensure that SPs run a postmaster address, and maybe
come up with things like Jeff Chase was proposing to continuously
measure their responsiveness to spam/virus-class bounce messages and
globally blacklist the worst (least responsive) offending SPs.  Etc.

Right now enabling SPs are insulated from any kind of RFC-based
responses or complaints about spam because MUA's and MTA's have no
predefined protocol for generating such a response in a constructive
way.  Most complaints/bounces that are automatically generated by
antivirus software or reported by humans (I've read plenty of both:-(
are hopeless and de facto useless without several rounds of
communications, and sometimes not even then: the humans don't even know
what a mail header IS and often have no way of knowing or suspecting
that the From address is bogus or sending in the real header so it can
be parsed by the SP postmaster.  Antivirus software developers should
know better (damn it!) but even THEY don't bother to parse the header or
include the header in the stupid bounces they generate, or validate
any sort of correspondance between originating host and From address.

So even though one could argue that adding a real protocol layer for a
preformatted, standardized, spam/virus bounce is not strictly necessary
because all the information is already IN the header, doing it anyway
might codify and standardize a complaint so that the complaint "always"
contains the essential information and so that a complaint to the right
target is "easy" to generate (can even be generated automatically).  It
could then guide the development of compliant tools that can deal with
this for ignorant humans using stupid MUAs and maybe even (presumably)
smarter AV programmer humans as well.

   rgb

---

From: "Robert G. Brown" <[email-masked]>
Date: Wed, 17 Mar 2004 15:10:01 -0500 (EST)

> risk limits and act accordingly.

Which is really pretty silly, right?  Since anybody will print you
checks that start with any number you like, completely legally.  In
fact, you can print your own checks with any number(s) you like,
completely legally, as long as the bank information at the bottom is
there and is correct and you actually own the account in question and
don't commit fraud or pass bad checks.

This kind of silly response is no obstacle to a criminal or spammer; it
is merely an inconvenience (a pain in the ass) to the innocent.  It also
leaves one with all sorts of catch-22 problems -- one cannot get a "track
record" until one is let onto the track, and one cannot get onto the
track without a track record.

Besides, this is all talking about >>IP numbers<<, right, since we all
AGREED that user "identies" were transient artifacts and impossible to
regulate.  In the checking account metaphor above, on the internet I can
print a new check with whatever numbers you like for each and every
transaction, and back it up with a shiny new driver's license and any
other "identification" tokens you require unless and until you create a
huge government bureaucracy to regulate it and harsh laws to punish
abuse.  Sort of like the ones we have for real driver's licenses and
checking accounts and human identities.  Banking (and other human
metaphors) are not correct for addressing IP number trust.  It's more
like can you trust the current residents of this neighborhood or that
house down the street...when you never get to see them, only their
masks.

And IF we're talking about IP addresses, we can pretty much stop
talking.  As Vernon has repeatedly pointed out, "trust"-like facilities
at the IP level are either ALREADY THERE and proving to be moderately
ineffective against spam or run square against the economics and
realities of the SP business.  We cannot do anything silly like "not
trust" a new IP number assigned by an SP to a new customer "until they
have a track record".  Trusted has to be the default or the Internet and
a variety of business become impossible and incredibly burdensome on the
innocent (far more so than spam).  But I don't care if you agree -- as
you note, you can "not trust" any parts of IP space you choose according
to any criterion you select, within your own hosts or networks.  Just
don't blame anybody else when things stop working because you've punched
a hole through a path to a critical service or human.

> to the "no checks below #1000" position).

You have to be able to quantify "trust" as well, in order to be able to
use it as a filtering criterion.  I fear that your metaphor is exact --
it is NO more difficult for a spammer to achieve whatever level of
"trust" is required for acceptance for long enough to spew than it is
for me to ask the bank to start the checks for my brand new checking
account at #2000 "since of course some merchants won't take them
otherwise".  Or going home and printing some new ones.

Somebody (Dean?) pointed out that if you can really solve the problem of
"trust" at the electronic level, scalably and more or less for zero
marginal cost, you're missing the real point.  These are the SAME
problems that are incredibly difficult to solve in the financial
industry where the penalties are large and expensive, laws that severely
punish identity theft artists and check forgers are vigorously enforced,
and where instruments for reasonably reliably affirming identity (photo
drivers' licenses, passports, birth certificates all abound and are
tightly constrained by law and expensive government agencies and
services.  It's hard to trust even paper money, let alone that some
stranger is who they assert themselves to be.

In that sense it is an excellent milieu to look for metaphors to the
network/spam/identity problems, just as paper spam and phone spam are
also good places.  If you can solve one, you can solve the other IF you
are willing to pay similar costs.

So next time anyone wants to advance a human-scale metaphor for a trust
model, please a) ensure that it actually is relevant and WORKS (check
numbering obviously is less than useless); b) discuss the costs.  Human
identification mechanisms are awesomely expensive and still don't
prevent identity theft, forgery, and all sorts of abuse.  And they don't
apply to IP number trust.

Don't get me wrong -- I do think that there is something to be said for
focussing on IP numbers (NOT humans) and "trust" (if that's what you
want to call blacklisting).  I jut think Vernon, and Dean, and Jeff are
all correct.  The IETF will not fix spam in protocol.  Spammers will
work around and through any holes left available.  SPs leave holes.
Until they stop doing so spam will continue.  This isn't QUITE an
impasse -- but suggestions need to focus on this particular kernel and
become concrete and less metaphorical.  I think we are all agreed that
IF SPs really tried to police their IP spaces the spam problem would be
ameliorated to some degree.  Even Vernon said as much, and Vernon seems
to be both insanely realistic and perhaps a touch, shall we say,
cynical?

So:

 A) Let's stop talking about trust models as if they extend to humans.
We aren't talking about trusting the "sender" of any message; we are
talking about trusting the IP number of the originating host of that
message, or alternatively the DNS owner of the subnet blocks where that
IP number resides (the SP).

 B) Trust is going to be the default.  This is OK because network
addresses have sufficient persistence in time and are sufficiently
difficult to change and are hierarchically organized.  Besides, the
network will rapidly break if trust isn't the default.

 C) No solution will work until the SPs buy in.

 D) SPs >>might<< buy in if spam reporting is streamlined, spam
reporting is independently tallied, blacklist decisions were made on the
basis of an open and clearly defined process and on the basis of
publically available data (e.g. the number of spam reports made back to
a given subnet in a given time window).  Jeff thinks this is a place to
start work and I agree.

 E) We're really talking about all forms of local-origin mail-based
network abuse, not just spam.  Virus reporting and response is in the
same category -- done haphazardly in an expert-friendly fashion (if done
at all).  As Dean has pointed out, many spam agents are architecturally
identical to viruses and sometimes appear to BE viruses, long out of
control of their creators and hawking products that no longer exist with
links to dead webspaces.

I personally think that "trust" is the wrong metaphor for a
trusted-default network.  D) is the meaty one above.  If there is
anything that the IETF CAN do to help cut this particular knot, it is to
create a relatively simple extension to mail that facilitates reporting
mail abuse, and collection of abuse reports by multiple parties for
tallying and blacklist decisions.  This puts real pressure on the SPs to
clean up their nets.  I'm not even sure that this pressure would be
necessary if spam were reported agressively and in a timely way and with
the data required to actually RESOLVE the complaint included IN the
complaint (note that Dean, obviously an expert, has to work to extract
it from certain bounces -- what hope does an ordinary user have?). Most
SP admins I've met or talked to are decent humans and take managing
their networks seriously.  Give them the tools to police their networks
and I think they'd prove responsive.

   rgb

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 17 Mar 2004 13:26:21 -0700 (MST)

> for the procket/juniper/cisco/paix/nasa/verio/shepfarm/isc multicast

DNSSEC would be a Good Thing(tm) on its own merits, but I don't see
any direct connection between it and a replacement for DNS blacklists.
Of course a replacement would start without reasonable authentication.
If you insist on using DNS screwdrivers as SMTP authorization hammers,
then DNSSEC blacklists would be a minor improvement.  DNS has the wrong
sorts of caching as well as the wrong sort of data for a reputation
database.  You want answers better than 32 bit number (PTR RR) or an
ASCII string (TXT RRT).

I don't see what multicast has much to do with my SMTP server asking
my chosen (and hired) clearinghouse about the reputation of the owner
the IP address of an SMTP client.  Some sort of anycast might be a
good optimization.  I guess anycasting can be seen as a form of
multicasting.  Is that what you mean?

] From: Yakov Shafranovich <[email-masked]>

] I had some preliminary conversations with blacklist operators about 
] this. There wasn't any interest in making a better protocol, but some 
] people did expressed a need to document the existing one.

People with working code and large customers bases rarely choose to
replace a servicable solution like the current DNS blacklist kludge
with a proper solution, no matter how much more elegant.

Replacing the DNS blacklist kludge with something better today would
be little more than arranging the deck chairs.  What's needed is to
patch the hole in the hull, or for more ISPs to do as Earthlink has
done in recent years and get serious about dealing with spam.  Earthlink
is far from perfect, but they are far better than they were and far,
far better than other outfits.  For example, as far as I can tell,
today an SMTP connection from Comcast is likely to be carrying spam,
while a connection from Earthlink probably isn't.  If you don't have
your own traps, see the numbers at http://www.senderbase.org/ 
or the better but less immediate numbers at http://spamhaus.org/

} From: "Robert G. Brown" <[email-masked]>

} ...
} The one other place that I think there COULD be room for improvement is
} to make the process of identifying sites that are originating spam or
} viruses more rapid and automatic, and to create a better/more formal set
} of rules responding to a site (or an entire SP subnetwork) postmaster.
} Such work might actually spell out all the steps between reporting and
} being blacklisted.

I strongly disagree.  There is and can be nothing better than the IP
address of the SMTP client for identifying the orgin of a mail message.
Some will object that's not the origin, but they're generally repeating
the nonsense and lies of ISPs trying to duck blaim for supporting
spammers.  The practical origin of a paper letter is wherever the
postals service, FedEx, etc.  accepts it, no matter whether you wrote
it while standing in the post office, at home, at work, or in an
airplaine 35,000 feet above practically unknowable real estate.

Yes, I've heard about UUCP, SMTP relays, smarthosts, and so forth and
so on.  As far as your SMTP server is concerned, a good, sufficient,
and necessary definition of the origin of a mail message is the IP
address of the sending SMTP client.  It doesn't matter whether the
sending IP address is an open proxy on a Comcast network, a system in
China, or Dell Computers' "newsletter" senders.  The IP address as
good as anything else could be, and already available.  It's only
defect is that it makes ISPs responsible for taking Ralsky's money.

} If every ten pieces of spam sent out of an SPs network -- even every 100
} pieces -- generated a complaint message to postmaster with headers laid
} out that clearly identified the offending host/client, I think that it
} would provide SPs with a real incentive, AND the tools, to address the
} problem.  

I used to say that, but then I saw that even (or especially) the worst
ISPs can figure out how to connect postmaster@ to /dev/null or to an
autoresponding ignorebot that lies about the responsibility of the ISP.

| From: John Leslie <[email-masked]>

| > - If you say that you can't trust ISPs to check that a new customer
| >   is not Al Ralsky in disguise or one of his proxies, then you must
| >   say the same about any other organization.
|
|    ISPs operate in a _very_ different business environment than, say,
| UNICEF.

Possibly true but certainly irrelevant.

| > - If you say that ISPs cannot check the reputation of new customers
| >   for a $30/month account, then you must say the same about any
| >   other organization.
|
|    ISPs offering $30-per-month service are very likely losing money
| (and worrying who to lay off next). 

True and relevant, but only in the sense that any outfit that might
sell trust assurances might have trouble doing it for $30/month.

|                                     Your bank, OTOH, is probably
| doing nicely on less than $30-per-month service charges. 

If that is true, then an ISP could do the same.  I think it is true
only in a facile and fundamentally false sense.  My banks makes money
on more than my explicit service fees, which are approximately $0/year.

|                                                          Also, some
| ISPs have no reason to worry much about their reputation, because
| they have in effect a government-mandated near-monopoly.

No matter how often anyone says that, it remains false.  By now the
base motives for that old nonsense should be considered.  Outside some
totalitarian regimes, there are no monopolies of any sort on real real
Internet access.  There are monopolies on some imitation Internet
servcies at price points that some claim are related to basic human
rigts, while expecting us to ignore the fact that the $15-$35/month
point they claim necessary to protect their basic human right to send
mail is 10 or 100 times too high for the vast majority of humanity.

| > - If you trust some of those other outfits to revoke their virtual
| >   letters of introduction and recommendation, then you must be
| >   willing to trust some ISPs to do the same and terminate accounts.
|
|    Ah, yes, but _which_ ISPs?

Currently the ISPs certified by your choice among your personal
blacklists, the SBL, CBL, XBL, SPEWS, MAPS, ORDB, etc.

| ...
|    The second part (terminating) is not true, IMHO. There's a real
| danger of getting sued for that, not to mention the loss of revenue.

The second part of that is relevant.  An ISP that refuese to terminate
a spammer for fear of lost revenue does not have any IP addresses
that many of us want conencted to our SMTP servers,

The first part is nonsense spread by spammers and dishonest, spam-friendly
ISP spokeslime.  ISPs have no problems terminating customers with less
than minimal evidence.  Within the last 10 days, I watched a business
customer, not merely a home end-luser, get cut off by a major ISP with
telco connections for some time because it failed to respond to a report
of mine.  Of course an ISP must be careful to avoid breaking contracts
and so forth, but that does not prevent termination.  Why else is the
spam advertising "bulletproof hosting" common?

---

From: Dean Anderson <[email-masked]>
Date: Wed, 17 Mar 2004 15:48:05 -0500 (EST)

> content of the message, with the message itself added (header intact) as

This is true now.  Many people don't know how to parse the headers, but it 
obeys a specific syntax and is machine parseable.

> making it easier for SP admins to deal with mounting complaint levels.

This is possible now, and SpamCop does this. The problem with SpamCop is
that they alter the message, making it useless.  SpamCop complaints are
routinely deleted as a result.  I usually forward them on to customers
with an FYI that we don't consider such to be a valid complaint, but they 
may want to be aware of what someone said.

> evil content so that it appears to come from some hapless but innocent

Relays don't add ficticious headers, nor do they add evil content.  They
may place their (true) headers on top of ficticious headers.  They cannot
verify that the headers given are accurate.  This is true of all relays, 
open or closed.

Proxies are another story. I don't know of any genuine reasons to run open
proxies, though closed proxies (web caches) are clearly useful. I don't
know of anyone claiming they are useful. But neither does that mean they
have no use.  However, as a service provider, I would say this much:  If a
customer found a useful reason to have an open proxy, then I would only
insist that they keep logs of its use. This is easy to place in a contract
or AUP.

>   d) Take steps to ensure that SPs run a postmaster address, and maybe

There is already a BCP for this. Rarely is this a problem.

> globally blacklist the worst (least responsive) offending SPs.  Etc.

How would you define "responsiveness"? Does it mean getting an 
auto-responder message?  Does it mean getting a message saying something 
had been done?  You cannot give out certain information about customers.  
Basically, all you can do is send an auto-responder message and a notice 
that the ticket was closed.  That doesn't indicate what happened, nor does 
it indicate who the spammer was, or if the ISP agreed they were a spammer.  
Sometimes the action is obvious if, say, a website disappears. But how do 
you know they took action against a dialup customer?  You can't.

"Continuous measurement" is the same as a DOS attack.  A ping flood is a
continous measurement of the bandwidth available and its responsiveness.  
That's why there is a -f option to ping.  Unauthorized measurements are
illegal.

> way.  

???  I'm not sure what you mean. By the time you -read- a spam, it is
delivered, and the SMTP protocol has long since finished.  Spam isn't the
only kind of abuse that an ISP responds to. The abuse@<isp> works pretty
well, since you can forward the complained-of message. There are some
things I'd like MUA's to do, such as include the whole headers(some MUA's
do, some MUA's don't), but that isn't an RFC issue, either.

> Most complaints/bounces that are automatically generated by

Yes, it would be good to send the entire headers.   

But users should know that the from: header can be forged. They should
also know some other things about email and the internet, such as don't
open attachments you aren't expecting. If you get an unexpected
attachment, ask the person if they sent it. This is an education problem.

		--Dean

---

From: Paul Vixie <[email-masked]>
Date: 17 Mar 2004 21:36:30 +0000

[email-masked] (Vernon Schryver) writes:

> ... but I don't see any direct connection between [DNSSEC] and a
> replacement for DNS blacklists.

i know.  but you asked about trust query protocols, not about blackhole
lists.  as the creator of the first blackhole list, let me just say,
"they don't scale."

> I don't see what multicast has much to do with my SMTP server asking my
> chosen (and hired) clearinghouse about the reputation of the owner the IP
> address of an SMTP client.  Some sort of anycast might be a good
> optimization.  I guess anycasting can be seen as a form of multicasting.
> Is that what you mean?

no.  for one thing, this is not (at heart) an smtp problem.  more later.
-- 
Paul Vixie

---

From: Doug Royer <[email-masked]>
Date: Wed, 17 Mar 2004 14:39:52 -0700

>verify that the headers given are accurate.  This is true of all relays, 
Sounds like his first point - fix it so they are checkable. If I am 
going to relay
for X number of domains, it seems reasonable that we share some kind
of shared key or password so they the headers they pass me can be verified.

>attachment, ask the person if they sent it. This is an education problem.
There is (1.0) legal spam and (2.0) illegal spam.

Illegal spam can be (2.1) advertisements or (2.2) viruses.

(1.0) Is most often traceable using the headers and content.
          This is getting easier to stop and there can be things done
          to make it easier - a computer parseable unsubscribe link and
           a standard protocol to unsubscribe.

(2.1) Often is traceable by the content, and almost never by the headers.
          Content filters and blacklists of some kind can catch these 
and throw
          them in the trash or hang-up when the content matches a URL that
          somehow blacklisted.

(2.2) Is for a virus scanner to catch and is almost never traceable.
 
There are things the IETF can do to help with the spam problem (1.0).

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

---

From: "Robert G. Brown" <[email-masked]>
Date: Wed, 17 Mar 2004 17:21:42 -0500 (EST)

> defect is that it makes ISPs responsible for taking Ralsky's money.

I AGREE with this.  There is a bit of difficulty associated with just
which IP address in a chain of delivery hops is the actual point of
origin, but at least at this point I generally trust that forwarding
hosts really are just forwarding hosts when I look at a header to see.
To be concrete (pulling a note at random out of the garbage for the
week):

---

From: "Robert G. Brown" <[email-masked]>
Date: Wed, 17 Mar 2004 18:18:29 -0500 (EST)

> obeys a specific syntax and is machine parseable.

Of course.  To both -- many people don't know how to parse the headers.
I'd estimate some 499,950,000 of the half a billion users of mail.  So
the CAPABILITY of parsing the headers exists, but not even AV vendors
(who should know how and know better) do it.

> may want to be aware of what someone said.

So what you are saying is, that this CAN be done and even is being done,
but it isn't done correctly and consistently and isn't widely available.
I agree.  In fact, I think that this is potential work for the IETF --
define a way for it to be done correctly and consistently (which
wouldn't be too difficult, I imagine) via a protocol.  Then SpamCop
could fix their tool, SpamAssassin could add a compliant interface,
Joe's Spam Seal (not yet written) could be written to comply with the
protocol and abuse@ or postmaster@ addresses could actually AUTOMATE a
response process based on consistent completely reported problems.  This
lowers their cost and makes it easier and more likely that they'll take
effective action.

As you say, if you get insufficient information, there is little that
you can do even with the best of will as the manager of an ISP with too
little time and too many things to fill it.  You probably don't have
time or energy to engage in the "please resend your complaint with the
full header and message attached" game (known to administrators
everywhere, and not just in regard to mail:-).

> insist that they keep logs of its use. This is easy to place in a contract

Again, precisely.  So what this means is that if I set up a mail server
and send a lot of spam from it all with a header that is forged UPstream
from my host, I obscure my host as its true point of origin.  I can pick
on a hapless host somewhere far away and make it look like the spam
originates from THEIR network, and one would have to compare traffic
logs on the two hosts and/or intermediary hops to determine which of us
is lying.

This makes for an interesting "attack" -- send egregious spam purporting
to come from somebody you hate or some network you are in competition
with, in a messages with multiple relays.  Somebody with a big view of
the hand might finally figure out what was happening, but proving it
would be, well, "difficult" doesn't begin to describe it, given that all
the log data on both sides could be easily forged.

Again, there might be work for the IETF here that could help IF this
becomes a problem or as a preemptive measure now.  There are ways to do
this -- signing a key with a local secret and adding it to the message,
for example -- that even if you didn't have a universal PKI for all
participating hosts would make forging headers for openly fraudulent
reasons easy to catch.  You can forge the upstream route, but you cannot
forge the upstream keys, and the last common host whose key can unlock
their MTA-added tag is left holding the responsibilty bag.

> There is already a BCP for this. Rarely is this a problem.

In the US.  Try hitting the postmaster of 7.197.76.17, and good luck
communicating with the postmaster of the brazilian relay in my previous
reply.  (This is picking nits -- actually I agree that what can be done
largely has been done, but it would be lovely to be able to extend
overseas with a little more ease, to get a bit poetic...;-)

> you know they took action against a dialup customer?  You can't.

No, I think that responsiveness has to be measured by the level of spam
reported as originating within the site -- results.  I don't think this
is that difficult, actually.  Vernon pointed out that once earthlink got
serious about controlling spam, the reduction in traffic was very
apparent.

If the IETF has any role here (and it may not) it might be to codify the
process of blacklisting ISPs that aren't serious as they are revealed.
You've pointed out several times that abuse of blacklists is pretty easy
as things stand.  It shouldn't be.  And people like you who have bad
experiences with the previous non-process should be the ones who end up
agreeing that whatever schema that might be proposed is fair and
equitable and not likely to punish ISPs who are doing their best.

> do, some MUA's don't), but that isn't an RFC issue, either.

Why not?  SPAM is a major networking problem.  Reporting spam and
viruses (at the MTA or MUA level, as filters can work at either one) is
only going to be effective if it is easy to report spam and if the
reports are consistent and contain the information needed to combat
spam.  Most MUA's cannot help users to report, and users definitely
cannot help themselves.  If MUA writers tried to add a reporting
capability now, they'd botch it by coming up with a dozen different
formats and effectively precluding the creation of automated tools on
the other end to facilitate processing the complaints at minimal cost.

Perhaps not an RFC, but a standard is most definitely needed, and it
needs to be both articulated and discussed in an open RFC-like process.
And there are already RFC's that address this, e.g. RFC 2635.  It is
just that this RFC reads like spam for the beginner (intended for users,
a sort of anti-spam howto) and doesn't spell out anything like a uniform
protocol for reporting spam TO the abuse@ address it suggests MTAs
maintain.  Lacking this (and due to the fact that nobody reads RFCs but
techie nerds; others don't even know what RFC stands for) the document
isn't horribly useful to a software designer wanting to actually design
TOOLS that might be portable and consistent.

> attachment, ask the person if they sent it. This is an education problem.

Users SHOULDN'T have to know ANYTHING but that if they fill in an
address here and write a message and click this little button it goes
where you want it to.  The fact that they do is a failure in design.  It
may be a failure we cannot fix, but it is a failure.  Kids send mail.
Old ladies send mail.  Stupid people can send mail.  The process should
be robust and idiot proof AT THE TOP LEVEL, although that is indeed not
an IETF issue, it is a software design issue.

The IETF issues are to places where by specifying particular ways of
handling certain problems according to a clearly spelled out protocol,
they enable software designers to write software that FIX these flaws
that is consistent and interoperable.  Reporting spam would clearly be
much more effective if it were done in a standardized way.  If
standardized report formats existed, software designers would have a
clear roadmap for adding reporting features to MTAs that my kids, that
old ladies, that stupid people could use without even knowing that a
"mail header" exists.  It enables other software designers to write
tools for the other end to preparse traffic to abuse@ addresses into
efficient, condensed reports so that instead of getting 1000 different
messages reporting one spam incident (which yes, one would be tempted
to pipe into /dev/null) one gets ONE message reporting 1000 different
complaints of ONE spam incident (with many targets).

Get it to where ISP admins can whack those moles efficiently and easily,
and they might just have at the mole-heads in their subnets with a will
and a way.

   rgb

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 17 Mar 2004 16:20:23 -0700 (MST)

> From: "Robert G. Brown" <[email-masked]>

> >From [email-masked]  Sun Mar 14 15:28:51 2004
> Return-Path: <[email-masked]>
> Delivered-To: [email-masked]
> Received: from pohl.acpub.duke.edu (pohl.acpub.duke.edu [152.3.233.64])
>         by mail.phy.duke.edu (Postfix) with ESMTP id B5A33A77F7
>         for <[email-masked]>; Sun, 14 Mar 2004 15:28:51 -0500 (EST)
> Received: from 152.3.233.64 ([200.215.92.74])
>         by pohl.acpub.duke.edu (8.12.10/8.12.10/Duke-5.0.0) with SMTP id
> i2EK4b0
> 3030509;
>         Sun, 14 Mar 2004 15:04:57 -0500
> Received: from [7.197.76.17] by 152.3.233.64; Mon, 15 Mar 2004 02:01:00
> +0600
>
> Here I'm pretty sure that pohl.acpub.duke.edu (also 152.3.233.64) is
> telling the truth about where it received the message from and isn't
> forging the previous hop because its administrator(s) are local and
> accountable and their address resolves.  This particular example is
> interesting in that as far as I can tell from registry information,
> 7.197.76.17 doesn't exist and there is no route to it.  The
> 200.215.92.74 address is a relay in brazil.  Neither of them seems
> promising in terms of being able to report the spam.

I disagree: 
  1. pohl.acpub.duke.edu is not an external relay for you.  It is your
     system, even if you don't have a root password or any account on it.

  2. 200.215.92.74 is not just a misconfigured relay, because it used the
     spam trick of using the IP address of its target for its HELO value.
     It might be an "owned" box with a trojan or it might be worse.

  3. the Received line pointing to 7.197.76.17 is obviously silly
      nosnense for more than one reason.  Let's not educate the 
      listening spammers on the details.

  4. you don't need to know why I claim #2 or #3 to properly report
      that spam.  All you need is a tool that will pick out the only
      IP address that matters from the only Received header you can
      trust, the top one, and send a report.  There are several common
      tools that do exactly that.  Some involve commands lines, but
      most are point-and-click.  Their defects are mostly that they try
      to do more, such as detecting hosts of spamvertised URLs.

  5. #2-#4 are irrelevant.  Whether Comite Gestor da Internet no Brasil
      hears about the spam fountain at 200.215.92.74 is none of your
      concern unless you have an unhealthy obsession with spam.  All
      you should care is that by hosting that spam fountain, all hosts
      in 200.128/9 are less likely to be able to send mail to
      pohl.acpub.duke.edu and mailqueue1.duke.edu

  6. Yes, I am a certifiable expert on at least some unhealthy obsessions
      with spam.

> To even START to "fix" this problem, postmaster has to work on the relay
> and be responsive.  The relay host manager has to know that their access
> to the entire Internet will be effectively terminated if they don't have
> a working postmaster address and are not responsive to spam.  The
> communication mechanism that reports spam has to both include the key
> information about times, addresses, and so forth AND has to function
> independent of knowledge and degree of expertise of the user.  I know
> what I'm doing (at least, to a point:-) and I'm daunted by the prospect.
> Most users wouldn't even know what all those words I just used mean...

NO!  Nothing significant has changed since Steve Wolfe stopped being
the bogyman we used to frighten lusers into not being naughty.

   - all that is needed to fix this problem is for the operators of
      mailqueue1.duke.edu and pohl.acpub.duke.edu to have reasonable
      counts of the spam from 200.128/9 and take action, or to delegate
      those actions to the SMTP trust vendor of their choice (currently
      DNS blacklists).

   - If Comite Gestor da Internet no Brasil is a reputable outfit,
      then it will do as bazillions of other repubutable outfits,
      including Duke University, have long done, and detect and deal
      with its spam problem, without your let, leave, hindrance,
      assistence, notice, help, or nagging.

   - Purely for extra credit, someone might try to forward an unmodifed 
      copy of that spam with complete headers to [email-masked],
      [email-masked], and/or [email-masked].  If the recipient can't
      figure out purely from the copy of spam what to do, then that's
      not our problem.  At most 200.128/9 we should disconnnected from
      the Internet that we use by adding to our blacklists.  If someone
      at Duke finds a need to receive mail from 200.128/9, you might
      review that blacklist entry or punch a hole in the blacklist.

Apologists for spam friendly ISPs including those who claim to believe
that $360/year is a fair price for a fundamental human right will say
that ISPs can't stop spam unless everyone reports it.  That claim is
nonsense.  When it comes from ISPs, it is a bald faced lie; it is
possible even for a raw IP bandwidth ISP to detect spam.

> So I have to say again -- there may be IETF work that could be done
> here.  It shouldn't be this difficult, and there needs to be a whole
> structure erected to make mail administrators accountable at some level.
> And ultimately, we may all have to be willing to pull the plug on

No, simply forwarding completely and faithful copies is more than sufficient.

> 17.76.215.200.in-addr.arpa domain name pointer BrT-S4-1-2-22-bnuce300.brasiltelecom.net.br.

I can't get a PTR RR for 17.76.215.200.in-addr.arpa.  Whether you use
reverse-DNS and whois or whois on the IP address is a minor, irrelevant
technical detail.  (Yes, I know Ralsky and others play games with PTR RRs.)

> and effectively cut them off from the Internet if they don't police
> their relays and e.g. refuse to accept mail from unregistered hosts.
> Only thus can we forge a chain of responsibility back to the SPs that
> they cannot easily evade.

We don't need any "chains of responsibility."  EIther Brasiltelecom
deals with its spam or it doesn't, just like the zillions of other
outfits that do not have the reputation of a Brasiltelecom, Comcast,
or UUnet.  How Brasiltelecom manages that trick is none of our business,
unless we are customers or employees.

> I just don't think that the idea has been fully tested yet.  To properly
> test it, a certain amount of infrastructure would have to be built --
> not a horrible lot, actually, but some.  And the process of complaining
> in a standardized way would need to be made "one click easy". ...

NO!  If Duke or AOL want to do that for its users, then fine.  If not,
that's also fine.  All that matters is that you accept responsibility
for your own incoming spam and deal with it by cutting off the sources.
You don't need any "infrastructure" to add to a sendmail access_db
or a router firewall.  (I've heard that AOL has a "this-is-spam" button.)

> > than minimal evidence. 

> Yes, I don't quite understand why people keep talking about suits and
> such. 

We all know why people go on about suits and such.  It is because they
have something personal to lose if spammers are routinely terminated.
That is variously cheap services subsidized by the lack of an abuse
desk at their ISP, services subsidized by revenue from spammers, a
desire to get rich or at least famous by flogging a Final Ultimate
Solution to the Spam Problem (FUSSP), a job at a spam haus of an ISP,
or a job at a spammer.
I realize this observation is impolitic, but it's past time to be
honest about the motives for the persistent nosense about spam.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 18 Mar 2004 00:17:36 -0500

> lists.  as the creator of the first blackhole list, let me just say,

Are you saying that a new secure scalable trust query protocol be help? 
What about the inherent resistance of existing people to change?

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 18 Mar 2004 00:51:30 -0500

> smarter AV programmer humans as well.

We have a closed subgroup in the ASRG for discussions of exactly this 
kind of stuff (http://asrg.sp.am/subgroups/abuse_reports.shtml). But we 
haven't gathered that much interest which makes us think that not 
everyone considers this a great idea.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 18 Mar 2004 00:39:59 -0500

...
> lowers their cost and makes it easier and more likely that they'll take

We are actually soliciting volunteers in the ASRG specifically for this 
kind of work - protocols and formats for abuse reporting to be discussed 
in a closed subgroup separate from the main ASRG list 
(http://asrg.sp.am/subgroups/abuse_reports.html). So far, we haven't 
gotten much interest :(

> everywhere, and not just in regard to mail:-).

If part of the protocol and format states that specific information is 
required, you can discard non-compliant reports solely on the basis of 
being non-standard. Or you can just discard them :)

> overseas with a little more ease, to get a bit poetic...;-)

There has been a proposal in the ASRG from someone about storing contact 
data for abuse departments in the rDNS tree the same way there is a 
responsble RR type for forward DNS. So far hasn't seen much interest...

> equitable and not likely to punish ISPs who are doing their best.

A general BCP on blacklists and how to properly apply them would be 
higly useful. Another BCP on how to properly manage a blacklist would be 
useful as well. Both have been floated in the ASRG, no one volunteered :(

> TOOLS that might be portable and consistent.

We are soliciting volunteers for discussions of these type of issues in 
a closed subgroup of the ASRG. So far some of the ISPs are interested, 
but we don't have enough people to hold a coherent discussion on a 
mailing list. MUA authors haven't been interested so far :(

Yakov

---

From: Paul Vixie <[email-masked]>
Date: Thu, 18 Mar 2004 05:57:07 +0000

> > ... you asked about trust query protocols, not about blackhole

more of a "new trust system" than what you said.  one thing to chew on is,
there are many orders of magnitude more potential bad actors than potential
good ones.

> What about the inherent resistance of existing people to change?

there's no way to get existing people to change... against their will.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 18 Mar 2004 01:19:04 -0500

william(at)elan.net wrote:
> On Thu, 18 Mar 2004, Yakov Shafranovich wrote:
> 
> 
>>Paul Vixie wrote:
>>
>>
> This excuse is used as stop sign for number of new idea or protocol change 
> in case of IETF. Don't listen to it - propose the ideas and work on them, 
> if its truly good - it should be at least attempted.
> 

Thanks :)

> As far as trust protocol or whatever, this is very far from mainstream and 
> current mechanisms are either within group of geeks using PGP or large 
> corporations that use S/MIME and need it for their internal policies.
> It has not entered society at large so we still have time to come up with 
> something good that will make it worth it for that to happen. 
>  

The discussions here, on the main ASRG list, in ietf-mxcomp and 
smtp-verify subgroup of the ASRG are currently dancing around this issue 
of trust and trust protocols. I would like to converge all of these 
discussions into one single forum, possible the ASRG.

Yakov

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 17 Mar 2004 23:19:45 -0800 (PST)

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Mar 2004 17:21:24 -0500 (EST)

On Wed, 17 Mar 2004, Doug Royer wrote:

> going to relay for X number of domains, it seems reasonable that we
> share some kind of shared key or password so they the headers they pass
> me can be verified.

The premise that relays add ficticious headers and evil content is wrong.

But header checking would not be practical. It quickly becomes: "I am
going to relay for some domains. The domains I am going to relay for are
unknown in advance (or very much in advance) because the customer may add
new domains. Further, that customer may themselves relay for some number
of unknown domains."

The description I gave of reasons that RMX won't work also applies. You
may have to relay for other domains.

The problem is very similar to, but much, much larger than the BGP route
registries' configuration databases.  There are about 140,000 or so
advertised network number prefixes, and providers change their routing to
other providers relatively infrequently compared with end users. The Route
registry, in principle, allows one to automatically generate router
configurations based on the what routes might be advertized by which AS
numbers.  In practice, it hasn't been such a success, though it does have
it's proponents.  It sounds much better in theory than it does in
practice.

Trying to do the same for millions of domains would be impractical, since 
the routing of those domains is even less static than the network routes 
between service providers.

At the end of this, all you find out is that spammers will stop using
forged headers. But quite a lot of spam these days doesn't have any forged
headers.  Indeed, it seems that spammers/abusers have lost interest in
adding forged headers, as they have lost interest in open relay abuse.

There is a related point that the IP addresses in the forged headers
appear to be chosen randomly. So some percentage of these will not be
routed, and will not be allocated. One could easily implement a check
which simply tested all the IP addresses in the headers for routability.
Of course, spammers would stop picking addresses at random, and would
simply start selecting random addresses from the route tables.  Such a
test is obviously not worth implementing.

>            a standard protocol to unsubscribe.

CAN-SPAM prescribed the use of unsubscription methods, and 56% of spammers
were fully compliant in January, and 95% were partially compliant in
January.  I've been using the links on some spam from genuine spammers,
(eg tekmailer.com). They've been providing a mail-to url and an http url
for unsubscription.  These are already computer parsable.

However, the hard part is to distinguish the genuine spammers from the
fake spammers. I've been able to do this in most cases by examining the
headers and the company--genuine spammers won't have any forgeries at all,
and looking up information on them will turn up the fact that they are a
real company.  Fake spammers have web sites, too, and their unsubscribe
links result in further mail bombing.  But so far I've been able to pick
them out, as they have to fake something, else they'd be real.

> (2.1) Often is traceable by the content, and almost never by the headers.

This isn't true. After the abuser has injected the message, the subsequent
headers will be true.  So abuse is traceable by the headers back to the
SMTP injection point. Forged headers are always detectable, since they try
to make one believe that mail was handled by a machine IP address that
didn't actually handle the message.  It is easy to see where the authentic
recieved headers stop and the forged headers start.  However, one can (and
SpamCop does**) forward a complaint to the responsible party for each
listed relay and domain.  Those parties can then determine by looking at
the message and their logs if their users were responsible for the
message.

If the message was injected by an open proxy, you can trace back to the 
open proxy. You may not be able to trace beyond that, but that isn't an 
SMTP protocol or relay issue.

For example, if the received header in a message appears to have a dialup
machine as relay, it is probably unlikely that the dialup really is a
relay.  The ISP responsible for the dialup IP will know this straight
away, and will know that its customer is responsible. (Of course, the
customer may not be a spammer, but may simply have a virus).  Every
genuine relay will also be in the message, and the owners of those relays
know they are relays.  Often it is obvious that they are genuine relays
and their headers are also genuine, and they indicate from where the relay
recieved the message.

The only problem is that anti-spammers often have little knowledge of how
or when relays insert headers, and in their ignorance, can't distinguish
between fake headers and genuine headers.  Protocol changes can't correct
ignorance.

> There are things the IETF can do to help with the spam problem (1.0).

**Again, SpamCop has merely demonstrated that certain processes are 
possible. They have demonstrated themselves to untrustworthy since they 
alter the message.  Technical competence doesn't equate to honesty and 
integrity.