Subject: [Asrg] Technical Considerations for Spam Control Mechanisms

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Apr 2003 22:46:18 -0400

Folks,

I've just send an internet-draft titled:

     Technical Considerations for Spam Control Mechanisms

     Summary:

     Internet mail has operated as an open and unfettered channel between
     originator and recipient. This invites some abuses, called spam, such 
     as burdening recipients with unwanted commercial email. Spam has 
     become an extremely serious problem, is getting much worse, and is 
     proving difficult (or impossible) to eliminate. The most practical 
     goal is to bring spam under reasonable control; it will require an 
     on-going, adaptive effort, with stochastic rather than complete 
     results. This note discusses available points of control in the 
     Internet mail architecture, considerations in using any of those 
     points, and opportunities for creating Internet standards to aid 
     in spam control efforts.  It offers guidance about likely 
     trade-offs (benefits and limitations.)

A copy is now available at:
<http://brandenburg.com/specifications/draft-crocker-spam-techconsider-00.txt>

This is very much a first draft.  Comments and suggestions are eagerly sought.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

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

---

From: "Jon Kyme" <[email-masked]>
Date: Mon, 28 Apr 2003 11:14:19 +0100

>      Technical Considerations for Spam Control Mechanisms

I like it (for what that's worth).  I can see scope for possible changes
/ clarifications in a couple of places:

Near the bottom of section 2.

"Unfortunately there is no opportunity for software control of spam in the
UA.o..."

This isn't the case for webmail systems (for example) where the mail client
software is NOT under the control of the originator.

It might be useful to add 
"except in particular cases such as 'webmail' systems"

(which might include 'e-greetings' etc...)

Also in 4.1. you mention "expanding the scope" of Whitelist/Blacklist,
to cover "More complex analysis"
I wonder if it might be useful to generalise this as something like:

message classification : response

a blacklist / whitelist is then expressed as a set of something like:

listed(identifier) : acceptable|unacceptable 

and more complex policies will fit in something like:

classified(classifier,message-data) : acceptable|unacceptable

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Apr 2003 09:27:07 -0400

Folks

DC> I've just send an internet-draft titled:
DC>      Technical Considerations for Spam Control Mechanisms
DC> A copy is now available at:
DC> <http://brandenburg.com/specifications/draft-crocker-spam-techconsider-00.txt>

Thanks to those who sent me feedback so quickly.  I have posted a new
version at the above URL.  (There is also an html version with the
obvious name.)  The version number is -00 for this draft because the
first version did not get issued as an internet-draft.

Changes include quite a bit of what I hope is cleanup to the language
and clarification to some of the content.

The discussion of whitelist/blacklist has been made to match common
usage.

There are many other small changes such as changing MTA.i to be ISP.i.

Comments are still eagerly sought.

As a reminder, here is the abstract:

     SUMMARY
     
     Internet mail has operated as an open and unfettered
     channel between originator and recipient. This invites
     some abuses, called spam, such as burdening recipients
     with unwanted commercial email. Spam has become an
     extremely serious problem, is getting much worse, and
     is proving difficult (or impossible) to eliminate. The
     most practical goal is to bring spam under reasonable
     control; it will require an on-going, adaptive effort,
     with stochastic rather than complete results. This note
     discusses available points of control in the Internet
     mail architecture, considerations in using any of those
     points, and opportunities for creating Internet
     standards to aid in spam control efforts.  It offers
     guidance about likely trade-offs (benefits and
     limitations.)

d/

---

From: Liudvikas Bukys <[email-masked]>
Date: Tue, 29 Apr 2003 11:43:00 -0400

Dave,

Typo as of Tue Apr 29 10:59:46 EDT 2003:

- Hanging indent label for false negative is "FP", should be "FN".

Best practice for recipient/filter interface should include some mention
that per-recipient tuning is a desirable feature.

A standards opportunity:

- SMTP error replies after the end of the DATA transfer
  offer no opportunity to "5xx" reply for individual recipients.
  Either an SMTP rejection applies to all recipients, or
  the MTA assumes responsibility for generating DSNs for
  individual rejects instead.  SMTP rejects are to be
  preferred over DSN generation (because they are one step
  closer to the originator, and because many originators
  create bogus sender information that makes any DSN bogus
  as well.  However, inability to selectively reject is in
  conflict with a best practice of per-recipient filtering.

Consent negotiation and presentation of credentials

- I think negotiation is a much larger and important topic that CR.
- Standards opportunities:
	- protocols for establishing consent,
	  formats for annotating messages to refer to that consent,
	  with potential hooks for UAs to insert themselves as helpers
	  in both establishment and revocation.
- I think that CR becomes non-workable as a general solution,
  so in any revision it should be no more than a special case
  of the general topic.

Credibility measures

- Many of the proposals can be generalized as credibility evaluation
  mechanisms.

  - Blacklists and whitelists allow for sender/recipient-indexed
    credibility ratings.
  - Signature and service-mark schemes are sender-indexed but
    increase credibility by the involvement of known third parties.
  - Collaborative mechanisms (content-indexed) hinge on the credibility
    of pools of users or detectors at identifying spam features.
  - Consent-documenting schemes allow individual messages to
    bear their own self-documenting credentials.

Liudvikas Bukys
University of Rochester
<[email-masked]>

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 30 Apr 2003 16:10:29 -0400

In Section 2:
> Hence Internet-wide designs of spam control must assume
> that UA.o and MTA.o may cooperate to generate and 
> transmit spam.  Efforts to control either of these 
> components may be sought as an adjunct, where they are 
> operated by an independent service, but it must not be relied on.
	While the text above is certainly true, I think that it may be
obscuring an important point. That is: Given any particular point in the
path from UA.o to UA.r, "spam" is something that can be seen as being
"done" by the component on the left to the component on the right.
	The point here is that MTA.o may be very motivated, for a
variety of reasons, to reduce the amount of spam that it receives from
UA.o. This would often be the case where the MTA.o is run as a shared
service such as by an ISP. However, the tone of the draft seems to
bundle MTA.o in as a co-conspirator of UA.o and thus potentially
distracts readers from carefully considering how MTA.o can protect
itself from UA.o orginated spam.
	Spam costs MTA.o's in terms of bandwidth, risk of blacklisting,
public reputation, etc. it should be recognized that some operators of
MTA.o's are just as victimized by spam as are others further downstream.

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 30 Apr 2003 17:00:04 -0400

In draft-crocker-spam-techconsider-00.txt
>4.2. Explicit Lists
	I think this might be better expressed as "explicit
authorization". White lists are lists of authorized senders, black lists
are lists of senders who are explicitly not-authorized to send. 
	Maintaining "lists" is only one way for a recipient to express
authorization or lack of it. 
	An alternative to whitelists, as a mechanism for recording
consent to receive mail or authorization to send it, is for a recipient
to issue to an originator a certificate that explicitly authorizes that
originator to send messages. You can think of this as a "license to
send." As has been proposed at various times on this list, such a
certificate would either be carried in the mail headers or a token
abstracting it could be embedded into the recipient's address (i.e.
single-user email addresses). Any *.r (recipient) could issue a license
to any upstream *.o (originator) which would be returned, like a cookie,
by the *.o when sending messages. The recipient would use the presence
of a "license to send" as an indicator that other anti-spam mechanisms
should be short-circuited for the specific message. Or, a recipient
could refuse all unlicensed mail.
	Elaborations are, of course, possible. For instance, if the
recipient had access to the public key of the originator, then the
originator could add a signature to the license which signed the
combination of the license and the message. The result would be both
clear authentication and authorization of the message being sent.
	As pointed out, this mechanism of "license to send" could be
used between any pair of *.r's and *.o's. Thus, two MTA's could, for
instance, establish a trust relationship via such licenses which would
be enforceable even if there were intervening MTA's.
	Such licenses to send have the advantage of not requiring a
central "whitelist" in order to be maintained. Not having a central list
creates a more robust system as well as tends to protect the privacy of
correspondents (i.e. you can't get my full list of authorized
correspondents by capturing my whitelist.)
	Licenses could also be constructed that would authorize not just
sending, but be specific about what could be sent. While going somewhat
beyond "spam," this could allow MTA.o's to help ensure that originated
messages are only those that conform to what the recipient desires to
receive. For instance, the "license to send" could carry constraints
that might limit the size of authorized messages, the frequency of
messages, or whether or not messages contained HTML. If such expressive
licenses were used, in theory, a cooperating MTA.o could evaluate a
message, compare it against the policy expressed in the license and warn
the sender that the message might not be authorized... Various
additional elaborations are possible -- it is all about consent...
	The opportunities for standardization include:
	* Definition of a format for the license to send
	* Definition of Best Practices for issuing and maintaining the
licenses

		bob wyman