ietf-asrg
[Top] [All Lists]

[Asrg] Propposed additions and changes for draft-irtf-asrg-requirements

2003-11-14 09:37:50
--- draft-irtf-asrg-requirements-00.txt 2003/11/14 14:57:05     1.1
+++ draft-irtf-asrg-requirements-00.txt 2003/11/14 16:36:28
@@ -278,18 +278,73 @@
 
 1.3.1     Anti-spam (Requires consensus definition - RCD)
 
+An anti-spam technique is any method which assists in the suppression
+or rejection of unsolicited bulk email.  Such techniques include, but
+are not limited to: methods for mail-sender identification and
+authentication; content-based spam recognition; graylisting;
+challenge-response systems; hash-cash and other methods for imposing
+transmission costs on senders.
+
 1.3.2     Bulk E-mail (RCD)
 
+Bulk email is email sent in volume, as duplicates or near-duplicates
+distinguished only by tumblers.  Fewer than a dozen recipients is not
+generally considered bulk volume; more than fifty generally is.  In
+between is a gray area, which however is seldom relevant to anti-spam
+efforts as they are generally concerned with stopping unsolicited bulk
+mailings of much higher volume (e.g. in the thousands or millions).
+Bulk mail may be solicited (as when people join a mailing list and
+thereby consent to receive it) or unsolicited.
+
 1.3.3     Caller (RCD)
 
 1.3.4     Callback (RCD)
 
 1.3.5     Challenge/Response System (RCD)
 
+A challenge-response system is a technique that requires a mail sender
+to authenticate itself by computing and returning an acceptable
+response from a piece of data presented by the receiver.
+Challenge-response authentication may be used to demonstrate that 
+the sender knows a shared secret qualifying it as one that has the
+receiver's consent, or that the sender has paid a toll in
+computational or other resources for the privilege of sending to
+the receiver, or possibly in other ways not anticipated here.
+
 1.3.6     Consent (RCD)
 
+An email user explicitly consents to receive mail when he or she records with
+a potential sender or sender's agent a willingness to receive mail from 
+that sender meeting a specified range of topic or content criteria.
+Consent is a credential given to the sender but owned by the
+consenting party, and may be withdrawn.  
+
+An email user may also implicitly consent to receive mail by allowing
+certain categories of mail from senders with which no explicit consent
+has been registered.  The key point about both kinds of consent is
+that they may be withdrawn.
+
+Most users implicitly consent to receive non-commercial communications
+from individuals, and implicitly withhold consent to receive
+unsolicited bulk email.  Explicit consent to recieve solicited bulk
+email (e.g. mailing lists) is also common.
+
 1.3.7     Consent Based Communications (RCD)
 
+A consent-based communications system is one in which receivers may
+set and enforce a policy on what communications they wish to have
+sent to them in order not to be overwhelmed by unsolicited and unwelcome
+commmunications.  The premise of consent-based systems is that the
+user may withdraw consent, at which point senders have an affirmative
+duty to respect the user's wishes and the system may enforce upon
+them an inability to send to that user.
+
+An individual consent-bassed communication is one for which the sender
+has a justified expectation of consent by the receiver.  Most users
+implicitly consent to receive non-commercial communications from
+individuals, and implicitly withhold consent to receive bulk
+commercial email; the justified expectation should be formed in light
+of this standard policy.
 
 Williams              Expires:   April 2, 2003            [Page 5] 
 Internet-Draft            Requirements          October  2, 2003
@@ -297,6 +352,10 @@
 
 1.3.8     Commercial E-mail (RCD)
 
+Commercial email is any electronic mail sent for the purpose of
+promoting a product, service or profit-making enterprise; or of
+soliciting a business relationship.
+
 1.3.9     Domain Name System (DNS)
 
  A system for associating character based names with 
@@ -334,6 +393,9 @@
 
 1.3.13    Legitimate Messaging (RCD)
 
+Legitimate messaging is that for which the sender has the explicit or
+implicit consent of the sender.  
+
 1.3.14    Message Content
 
  That part of a messaging transaction that contains data as
@@ -342,6 +404,14 @@
 
 1.3.15    Message Envelope Forgery (RCD)
 
+Message envelope forgery occurs when a sending program misidentifies
+the sender during the email protocol transaction from the receiver.
+It may be, and often is, combined with message header forgery; both
+are common traits of spam.  The usual purpose of such forgery is to
+fool the receiver into thinking the message comes from a sender with
+good reputation (e.g.  not a criminal or habitual spammer) so that it
+will not be rejected before it is read.
+
 1.3.16    Message Envelope Protocol
 
  The protocol used during message transfer to insert message
@@ -363,6 +433,14 @@
 
 1.3.18    Message Header Forgery (RCD)
 
+Message header forgery occurs when a sending program misidentifies the
+sender in the RFC822 or RFC2822 mail headers.  It may be, and often
+is, combined with message envelope forgery; both are common traits of
+spam.  The usual purpose of header forgery is to fool the receiver into
+thinking the message comes from a sender with good reputation (e.g.
+not a criminal or habitual spammer) so that it will not be rejected
+before it is read.
+
 1.3.19    Message Origination
 
  The process of inserting an original or revised message into
@@ -424,6 +502,13 @@
 
 1.3.25    Non Consent Based Communication (spam) (RCD)
 
+A non-consent-based communicatoon (idiomatically, spam) is one for
+which the sender does not have a justified expectation that the target
+will consent to receive it. Most users implicitly consent to receive
+non-commercial communications from individuals, and implicitly
+withhold consent to receive unsolicited bulk email; the justified
+expectation should be formed in light of this standard policy.
+
 1.3.26    Open Relay MTA
 
  An MTA which is configured to relay mail for local domains and
@@ -434,8 +519,22 @@
  
 1.3.27    Opt-In (RCD)
 
+An opt-in mailing list is one which reqires an explicit consent or
+sign-up before the user will be sent mail.  All legitimate mailing
+lists are of this type.
+
 1.3.28    Opt-Out (RCD)
 
+An opt-out mailing list is one for which target addresses are
+collected by the sender or some third party, and from which recipient
+may in theory withdraw by explicit withdrawal of consent.  In
+practice, so many operators of so-called "opt-out" lists ignore 
+attempt to opt out -- and (worse) use the addresses opt-out requests as 
+targets in other spam lists -- that most mail users will no longer
+touch an opt-out button.  Because of this trap, opt-out lists have
+come to be considered a spam technique and their operators presumptive
+spammers.
+
 1.3.29    Recipient/Receiver
 
  A computer system, application or process that is the final,
@@ -456,6 +555,13 @@
 
 1.3.31    Spammer (RCD)
 
+A spammer is a person or organization that habitually sends spam, that
+is email for which the sender has no reasonable expectation that the
+targets will consent to recieve it. Most users implicitly consent to
+receive non-commercial communications from individuals, and implicitly
+withhold consent to receive unsolicited bulk email; the justified
+expectation should be formed in light of this standard policy.
+
 1.3.32    Relay MTA
 
  An MTA configured to participate in a store-and-forward 
@@ -498,7 +604,25 @@
 
 1.3.36    Unsolicited Bulk E-Mail (RCD)
 
-1.3.37    Unsolicited Commercial E-Mail (RCD)
+Unsolicited bulk email is bulk email for which the sender does not
+have a prior indication of consent from the targets.  This category 
+almost coincides with spam and is generally considered the most
+serious kind of spam.
+
+1.3.37 Unsolicited Commercial E-Mail (RCD)
+
+Unsolicited bulk email is commercial email (whether bulk or not) for
+which the sender does not have a prior indication of consent from the
+targets. 
+
+1.3.38    Tumbler
+
+A tumbler is a section of text inserted in instances of bulk email
+(often in the Subject header) which varies between instances in a 
+way irrelevant to the semantic content of the message.  Spammers use
+tumblers to defeat spam-recognition methods based on exact hashing and
+to dilute the effectiveness of Bayesian and other content-based spam
+recognition techniques.
 
 1.4  Anti Spam Technical Framework
  
@@ -607,11 +731,11 @@
 
 2.4.1     Rational:
  
- Any solution to the problems with ‘spam’ should be easily
+ Any solution to the problems with 'spam' should be easily
  deployed to facilitate either incremental or wide-spread
  adoption.  Existing systems will likely continue to be used,
- thus a solution that leverages existing technology or MTS ‘anti-
- spam’ implementations will also speed introduction.  A proposal
+ thus a solution that leverages existing technology or MTS 'anti-
+ spam' implementations will also speed introduction.  A proposal
  that relies on non-existent infrastructure or technology is not
  likely to be deployed.
 
@@ -789,7 +913,7 @@
  
  One of the most pernicious issues involving [spam] are related
  to accountability of the [spammers] who provide invalid or
- simulated information in order to “game the system” provided by
+ simulated information in order to "game the system" provided by
  the current MTS.  Designers MUST describe the issues of
  accountability addressed by their proposal.  Message
  origination and message formatting forgery must be considered
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

The possession of arms by the people is the ultimate warrant
that government governs only with the consent of the governed.
        -- Jeff Snyder

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg