Subject: [Asrg] Back to the charter

From: "Gary Feldman" <[email-masked]>
Date: Wed, 5 Mar 2003 20:42:15 -0500

I'm finding the large amount of discussion, albeit interesting,
also depressing, as it doesn't seem directed towards making
progress.  So let me try to get back to the earlier question
concerning the charter:

1. On the use of "Consent-Based Communication" 

The charter begins by arguing that spam is not well-defined,
and therefore moves to generalize the problem with consent-
based communications.  Let me first observe that based
on the discussion here, the definition of consent and consent-
based communication isn't clear enough.

In engineering, when a problem seems intractable, it's certainly 
a legitimate strategy to consider a different problem, as is 
being done here.  But then, unless the original problems falls 
out (as is frequently but not always the case), we must compare 
the original problem to the problem being solved.

In this case, my initial reaction was that consent-based
communication was sufficient but not necessary.  That is,
such a system could significantly address the underlying
problem, but as defined, is more general than is necessary
(at least by any obvious necessity).  But then, it occurred to
me that the approach is really just obscuring the original 
problem.  

My first take on "Consent Expression Component" was that it
was merely the mechanism to communicate my policy to the
software.  We still need a way to identify policies - and
that means coming up with some sort of meaningful definitions
for spam.  The trick is doing so, without forcing a single
definition of spam down everyone's throat.

2.  A framework for classifying definitions of spam:

So let me propose a framework:  Spam, as indicated in the
charter, is loosely defined as unwanted email.  Within that
set, there are a number of very large categories.  The 
categories are not exclusive (they may overlap), nor do
they necessarily cover the entire space (some may slip through).

Some categories are defined intuitively, e.g. "unsolicited,
commercial, bulk".  Others are defined formally, e.g. mail
for which the From field specifies a non-existent domain 
(ignoring issues of DNS reliability and timing windows).
Sometimes there will be a relationship between an intuitive
definition and a formal one; the relationship may be perfect,
or it may have holes (false positives or negatives).  The
closeness of a formal definition to an intuitive definition
is one particular measure of quality for that formal
definition.

At this point in time, arguing about the appropriateness of
any particular category (whether intuitive or formal) is 
inappropriate.  Rather, the point is to establish the structure
in which those categories can be documented and analyzed.

3.  Legal issues

The statement about legal issues limits the investigation to
the extent that legal issues affect the technology.  This needs
to be "and vice versa", i.e. should also consider the extent
to which the technology affects the legal issues.  In particular,
it is a legitimate question to ask whether the technology can
and should play a role in aided the encorceability of legal
sanctions, e.g. can and should the technology make it easier to 
find someone who violates an anti-spam law.

4.  Social issues

The charter is silent on the effect on social (and political) issues.  
The discussion here suggests that these are extremely important to
some number of people.  I'm not convinced that adding such issues
to the charter would be a wise move, but in the interest of 
completeness and fairness, I feel the need to point it out.

5.  Premises or Constraints

The charter say very little about the premises or constraints
of what falls within its scope.  The current set of discussions 
indicates that many people are working under the premise that 
existing (low-level) functionality must not be changed, or other
assumptions about approaches that would be out of bounds.  

Since this is a research group, I believe it important to do
away with preconceived notions about limits.  I also believe
it important to be explicit about this - precisely to avoid
ratholes.  In particular, proposed solution should not be
rejected a priori solely on the basis of change of functionality, 
but should be evaluated according to the same criteria mentioned
in the charter (usefulness, cost, effectivness, accuracy, etc.)

Furthermore, individual subsolutions should be evaluated in the 
context of a complete solution strategy.  In particular, if
one part of a solution breaks existing functionality, but that
purposes served by that functionality can be served by other,
new functionality,  then rather than dismissing the subsolution,
the entire solution, including the replacement of existing
functionality should be evaluted.  (Implicit in this is that
we also don't jump to a priori conclusions concerning the cost
of replacing functionality, but rather evaluate such costs 
seriously.)

I'm sure some won't agree with the above specifics.  Regardless
of the actual specifics chosen, I believe that such high-level
constraints should be clearly identfied early on and documented,
either in the charter or elsewhere.

Gary

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

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 05 Mar 2003 17:00:33 -0500

> based communication isn't clear enough.

  Everyone talks about "consent" in relation to the end user who
receives email.  The other parties in the process are ignored.

  When someone installs a broken piece of software which can be abused
to send spam, did they consent to such abuse?

  When someone receives email with forged 'from' lines, did the other
domain consent to that forgery?

  When someone receives email from another site, do they consent to
accepting any kind of lies or deception embodied in that email?

  The answer to all of these questions, I believe, is "No."  Achieving
consent-based email for these parties will *not* involve content
filtering, and will get rid of probably 90% of the spam.

  The left over spam will come from people who publicly admit that
they consent to sending spam.  Everyone else can individually agree
that they do *not* consent to receiving email from such people.  (But
that's a political decision, not a technical one.)

  A goal of this group should be updating the technology to allow
people to have informed consent, and to make informed decisions as to
which email satisifes their political or ecomonical objectives.  The
current lies and deception which are permitted in SMTP do not allow
these sort of informed decisions to be made.

  Instead, we have ad-hoc filters, which try to insinuate someone
else's intent, or consent, by doing content-based filtering.  That
doesn't scale.

> We still need a way to identify policies - and

  Sure.  Multiple definitions would help.  A start could be:

  "Spam is AT LEAST any email which is not intended to be sent from a
network."

  e.g. Unknowing open relays in schools in Korea, abused by people in
the U.S.  If it was legitimate email from Korea, then the 'from' line
would be from the school.  If it was legitimate email from someone in
the U.S., then they could send the mail directly themselves.

> charter, is loosely defined as unwanted email.

  Unwanted by who?  Odds are often that the administrator of the IP
sending the spam doesn't want it, either.

> in which those categories can be documented and analyzed.

  I agree.  Proposed solutions to a vague and ill-defined problem
aren't helpful.

> In particular, it is a legitimate question to ask whether the
> technology can and should play a role in aided the encorceability of
> legal sanctions, e.g. can and should the technology make it easier
> to find someone who violates an anti-spam law.

  I would say that the technology should make it possible to make
informed legal decisions.  Tracking down a spammer is just one part of
that process.

> assumptions about approaches that would be out of bounds.  

  I know I would appreciate it if people made their assumptions
explicit.

> context of a complete solution strategy.

  ... within a well-defined problem space.  I'm not even sure we have
that.

  But I think you've made a good start on narrowing the discussion.

  Alan DeKok.

---

From: "Mark Delany" <[email-masked]>
Date: 6 Mar 2003 03:17:33 +0000

> based communication isn't clear enough.

True enough, Gary. As with others I have no idea about the original
intent and meaning of "Consent-Based Communication". A term I would
prefer is "Permission-Based Communication" but that's really a nit.

The key to me is this: with the current system, the sender has way too
much influence over whether an email shows up in my Inbox or not. To
my mind, "Consent-Based" means that the decision about whether an
email shows up in my Inbox needs to be slanted much more towards me
rather than the sender.

In short, we need to give Inbox control back to the recipient. In that
light I guess that "consent" means something like "I consent to your
mail showing up in my Inbox and if I choose otherwise, you cannot
override my lack of consent". Or crudely, "My Inbox, my rules".

That to me is the high level goal. Return control to the user.

Regards.

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 06 Mar 2003 09:34:56 +0000

> the original problem to the problem being solved.

I'm not sure that "consent-based communication" is a different problem.
I believe it will be a very powerful generalisation and should allow us
to discuss the key issues without getting bogged down in arguments
about content classification, free-speech, politics etc.

The charter directs us to consider "architecture" and "framework".
I don't believe that that we're seeking anti-spam systems per se, rather
that we're working towards a system that enables their development.

The generalisation should lead us to consider:
  The entities which grant and seek consent
  (are they recipients/senders or "autonomous systems"?  Both?
   The charter refers to "recipients" 
      - is a recipient an email address?
        a personal email address?
        the person behind a set of email addresses?
        a robot?
        an network / mail system ?
  )

  The nature of the communication
  (content? traffic characteristics? other stuff?)

I like the generalisation, let's work with it.

--
Regards,
Jon Kyme

--------------------------------------------------------------------
Get your free email address at http://www.merseymail.com/
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Pierre Fortin <[email-masked]>
Date: Thu, 6 Mar 2003 10:53:55 -0500

On Wed, 05 Mar 2003 17:00:33 -0500 "Alan DeKok" <[email-masked]>
wrote:

Alan, your msg helped me understand better that "path verifiability" may
be a big part to this problem...  just as postal services add origin
stamps, phone companies provided CallerID, the 'net has similar
verifiabilty already spec'ed...  the recipients could take a large amount
of control back very simply: enforce path verifiability.  Once the path is
verifiable, much spam will crawl back into its hole, IMO.

> to send spam, did they consent to such abuse?

Explicitly, no.  Implicitly, arguable. Knowingly continuing after
discovery/notification, yes.

> domain consent to that forgery?

Hmmm...  ignoring the legal realities, would "Wire Fraud" be applicable? 
However, this is a content/payload issue; just like someone using forged
letterhead -- it's not part of the "path".

> accepting any kind of lies or deception embodied in that email?

I block at connection/envelope stage, so if my path filters fail, implicit
yes IMO.  Successful delivery just means someone sent me "data" (aka
content)...  truth vs lies vs misinformation at this stage is a rocky
road... 

>   The answer to all of these questions, I believe, is "No."

Partially disagree for above reasons.

>  Achieving

[Not sure I fully grok this as written...]

While there are those that argue for anonymous communication, my attitude
in denying anonymous person-to-person (or *-to-person) mail is that an
anonymous sender simply wants to shove something down my throat without
allowing or informing me how to respond...  the only places I accept
anonymous senders are on mailing lists and news sites...  there, it's my
choice to participate...  if a sender doesn't allow me the option of a
2-way communication**, I don't see why I should extend any open-arms
courtesy to him/her/it.

** since everything can be forged, my rules are that everything I *can*
confirm (IP, DNS, rDNS, not open-relay, dest_userid_exists, etc) *will* be
a requirement.  Access to my mailbox is freely available (my courtesy);
though, as in a contract, in return for this priviledge, I only ask for
the ability to confirm that the communications path is somewhat
trustworthy -- if a sender insists on hiding or lying about the path, then
the message must by association be highly suspect.  Such sender will have
to convince me via a more trustworthy path to allow the untrustworthy
path...  good luck.

> that's a political decision, not a technical one.)

Do it how you like, I chose the technical one for now since it works for
me.

> these sort of informed decisions to be made.

If you've already received the spa^H^H^H^message, then as Dr. Race stated:
   No proposal will gather public acceptance which is based on 
   the "make the victims pay" model.   

   The burden is rightly on the owners of the open relays, not on 
   their victims.

I don't limit the burden to open-relays... everyone, to the best of my
ability, owns the burden of using properly identifiable communications
paths.    IMO, it eliminates the "90% of spam" I would have gotten, the
rest are using proper paths; but if they lie in the content, they are
added to my personal blacklist...  could it be easier to do this, sure...
but again, this is not part of the "path verifiability" which everyone has
access to...  I wish everyone just enforced that part of the problem
space...

> else's intent, or consent, by doing content-based filtering.  That

Agreed; and the reason I don't use/like content-filtering (other than the
most obvious headers).

>   I agree.  Proposed solutions to a vague and ill-defined problem

I get the impression it's ill-defined to those who are still getting tons
of spam...  those of us who are enforcing the simple rule: "you must use a
verifiable path before I accept your mail"** are still open to spam; but I
assure you, it's already >90% less than we would be getting otherwise...  

** I live in the US, so for me, the USPS is the only verifiable path to my
P.O.Box...  the spam that arrives there has a valid return path (at least
to the originating P.O.; even uncancelled mail *could* be traced) for the
simple reason it's "sender pay".

If you want to send to me directly and the path is not verifiable, *we*
can address this with our providers....  keep trying to get your mail
through to me, and I will send the bounces to the provider as best I
can.... over time, my experience shows the legit ones *do* relent and make
the path verifiable...  However, if you are a spammer, your provider will
feel my pain, no more...  this too has worked for me...

> informed legal decisions.  Tracking down a spammer is just one part of

Simply enforcing verifiablity of the communications path goes a long way
IMO.

>   I know I would appreciate it if people made their assumptions

My assumption is that the path verifiability is already spec'ed and
implemented, just not fully, reliably and enforcibly deployed... 
enforcing this verifiability will not prevent From: abuse; but that's a
*payload* issue; just as the USPS doesn't get involved in the content of
the mail they transport.

>   ... within a well-defined problem space.  I'm not even sure we have

IMO, we are trying to encompass solutions to parts of the problem space
that already have a solution: path verifiability is the big one, the way I
see it.

>   But I think you've made a good start on narrowing the discussion.

I'm new to this list, so I'm reserving judgement...  :^)

Pierre

---

From: Nate W <[email-masked]>
Date: Thu, 6 Mar 2003 11:50:23 -0800 (PST)

> That to me is the high level goal. Return control to the user.

The simplest way to do that is with a whitelist.  Of course, that by
itself really reduces the usefulness of an email account.

The ideal system (IMO) will also provide a way to delegate the granting of
consent.  The user should not have to manually grant or reject requests
for consent, or we're right back to square one, with spam in the form of
requests for permission.

Whether it's delegating to software (s/delegation/automation/) or
delegating to trusted friends (a la the PGP web of trust), I think there's
got to be a way to remove from the recipient the burden of personally
reviewing requests for consent.

-- 

Nate Waddoups
Redmond WA USA
http://www.natew.com

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 7 Mar 2003 12:13:49 -0500

>verifiable, much spam will crawl back into its hole, IMO.

I think it might be valuable to classify spam a bit here, so that we 
can identify what kinds of solutions address what types of spam.

In particular, there are a growing number of spammers who are using 
perfectly identifiable paths.  Some of those paths lead to public 
ISPs, such that blocking the spammer also results in blocking 
legitimate users.  The Chinese spam I get from 163.net certainly 
doesn't hide the fact that it comes from 163.net.  Nor do they care 
if I block it.  Because the people who can't block it are the people 
who regularly communicate with people in China and can't afford to 
block a Chinese ISP.  And those of course are also the people who can 
read the spam.  I'm just collateral damage.

The bcc spammers who are using temporary webmail accounts are also 
completely path verifiable.  They simply don't care that the account 
will be torn down in a number of hours.  Much of the Spanish Prisoner 
(aka Nigerian) seems to fall into that category.

So, how about a start on a taxonomy for spam.  Not based on content, 
but on the class of technique.

1. Open Relay
Uses an open relay to send spam.  The relay is typically a loosely 
configured, misconfigured, or buggy mail server.  The server may or 
may not normally send email.  The sender typically attempts to 
obscure the true source of the email via fake headers or other 
information.  But the original email account is probably throw-away. 
There's no particular reason the spammer couldn't use the domain of 
the relay in the sending email if an "authorized server only" system 
was set up.

2. Open Proxy
Like an open-relay, except that the email arrives via a different 
protocol, so there is usually no trace.  HTTP/Socks proxies fit this 
category.  As do formmail exploits. Rooted servers can also be used 
for this purpose.

3. BCC
Uses a throwaway email account sending multiple messages bcc'd to the 
sender.  Very difficult to tell from normal email use.

4. Viral
Uses a virus or trojan to send email using the machine owner's 
account and/or identity. These appear to be on the rise.  I've heard 
of viral ones, but never seen it documented.  Trojan ones are 
definitely in use.  In addition some of the trojan's (e.g. the latest 
e-card one) are reported to have been snarfing the address book back 
to the spammer--thus making hay of white-listing systems.

5. Spam Indifferent Host
Uses a paid account at a legitimate ISP for sending spam.  Very 
common in Chinese spam.  No attempt to forge anything.

6. Spam Friendly Host
Major spammer with the infrastructure and pipes for sending bulk 
email directly.  They may or may not hide the domain.  In one case 
we've dealt with the spammer regularly registers new domains every 
few weeks and uses those as the source of the email.  The IPs keep 
changing.  The domains keep changing.

Any others?

Looking at these.  You want to think on different spam solutions and 
see where they have an impact and where they don't.  For instance.

Blacklists help against open relays and open proxies.  But there open 
relay blacklists have false positives and considerable collateral 
damage.  Open proxy blacklists seem a bit safer, but still can have 
collateral damage.  Both systems might survive an "IP is authorized 
to send mail for this domain" system, depending on the details and 
how tightly they were applied.

BCC spam is very difficult to tell from legit email.  Only by content 
or "bulkness".  It passes any authentication system just fine. 
Volume limits and manual signup systems help limit this, but not 
enough so far.  And both rely on the goodness of the source site, 
which is not sufficient.

Viral spam has even worse characteristics than BCC spam, since it 
also can punch through whitelists, including auto-whitelisting 
challenge-response systems.

Spam indifferent hosts are a real pain.  You can't necessarily 
blacklist them.  You have very little power over them unless the 
entire community bands together, and if that happens things could 
spill over into diplomatic circles.

Spam friendly hosts are easier to block.  But of course finding a 
reliable RBL that doesn't generate false positives is tough.  And if 
it were that easy, you'd think they'd be gone by now, instead of 
growing in number.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

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