Subject: [Asrg] Revised proposal

From: "Ken Hirsch" <[email-masked]>
Date: Fri, 2 May 2003 10:31:52 -0400

Antispam-certified mail servers.

Ken Hirsch
2002-05-03

Voluntary certification.  Other SMTP traffic is allowed.  Certified
servers may accept mail from non-certified servers as specified below.

In order to be considered a compliant server,

I. INCOMING - Each incoming connection to the server must be checked

    (SMTP "clients" may of course be other SMTP servers.)
    A. Connections from outside SMTP clients must either be checked by
    IP address or by (client) certificate in the TLS handshake (IP
    addresses should be checked with reverse DNS, etc.)

    B. A connecting client must be recognized in a positive (whitelist)
    manner.  While more than one kind of whitelist is possible (e.g.
    Bonded Sender, antispam-certified, etc.), the whitelist must be
    revokable.  Compliant servers may cache the checking of the
    connecting clients, but there must be a time-limit on the caching.
    [Servers may use more more than one way to validate an incoming
    connection, but it must treat unknown servers as in paragraph D.]

    C. Clients that are not on a recognized whitelist must be checked
    against a blacklist of open relays and other unforgivable behavior
    (e.g. not responding to either postmaster or abuse@server).

    D. If a client is neither on a whitelist or a blacklist, then each
    message from the client is treated as unauthenticated and subject to
    either (1) certificate checking or (2) challenge/response
    authorization.  The certificates of signed messages are subject to
    the same verification and policies as the certificates of clients
    connecting to the SMTP server.  When per-message certificates are
    used for authentication purposes, each message signature must be
    checked to make sure it is valid and each RCPT TO address must be
    listed as a recipient within the signed portion of the message.

    E.  Messages from whitelisted clients are generally not subject to
    per-message authorization, except that this may be specified in an
    anti-spam profile.

    [There should be an SMTP extension which requests that each email
    should or should not be signed by the outgoing server.]

    Servers may sign messages whether or not they are requested to.

    Again, when per-message authentication is used, each message
    signature must be checked to make sure it is valid and each RCPT TO
    address must be listed as a recipient within the signed portion of
    the message.

    F. Each server must have an address where its compliance to incoming
    messages can be checked (but not postmaster).

    G. Each server must respond appropriately to messages to postmaster.
    For each server, there should be a responsible person that can be
    contacted by the whitelist administrator at a separate mail address.
    This address need not be published.

II. OUTGOING

    A. The party responsible for the SMTP server must agree to an
    explicit anti-spam policy set by a whitelist administrator.  The
    administrator of the SMTP server is responsible for enforcing this
    policy on the users of the server.  The administrator of the
    whitelist is responsible for verifying that the SMTP server is
    enforcing the policy and to handle complaints against the SMTP
    server.  The whitelist administrator has the authority and technical
    means to revoke the authorization of the SMTP server.

    B. Clients connecting to an SMTP server to send outgoing mail must
    be authenticated.

    C. The originating SMTP server may add headers that give
    information about the sender.  E.g. Hotmail & Yahoo may (should)
    distinguish between paying customers and free customers.  Further
    classification of customers is possible.  The originating SMTP
    server must not allow its users to forge these headers.

    D. The original sender may add message headers for classifying the
    mail. The originating SMTP server may also add/require/verify these.

    E. The originating SMTP server must be able to sign each message
    with the certificate issued by the whitelist administrator.
    Transparent signing should be used [RFC1847/RFC2633] so that users
    without S/MIME-compliant MUAs can read the message.

    F. Each server must respond appropriately to messages to postmaster.
    For each server, there should be a responsible person that can be
    contacted by the whitelist administrator at a separate mail address.
    This address need not be published.

III. WHITELIST PRACTICES

    Some parts of this section are applicable only to whitelists that
    use cryptographic certificates as part of the authentication and
    authorization process.  Other parts are applicable to any feasible
    whitelist.  For cryptographic authentication, the whitelist
    administrator may be the CA or must work with the CA to sign and
    revoke certificates.

    A. Procedures that are used to identify, authenticate, and authorize
    whitelist members must be published.

       It must not be possible for a spammer to obtain many certificates
       without significant penalties.

       If strong identity can be established, a whitelist administrator
       would (1) check the identity against a database of known spammers
       (2) get the person to sign a contract to abide by a set of
       antispam policies.
       [While it is not mandatory for whitelist administrators to
       exclude persons who have been declared "known spammers" by other
       whitelist administrators, their reputation is at stake.  Among
       the possibilities are (1) requiring a large deposit against any
       claims made against them, (2) assigning them to a lower user-class so
       recipients can filter them...]
       When whitelist adminstrators revoke a certificate because of
       spamming activity, they must publish enough details of the
       identity of the spammer that other CAs can identify the person if
       they apply to them.  Since this may contain somewhat sensitive
       information (such as social security numbers), this information
       should be available to other CAs, but not for casual inspection,
       much as a credit-reporting agency does.  In fact,
       credit-reporting agencies may find this within their scope.

       Not specified: up-front costs/renewals/bonds/credit checks ...

       There may be more than one procedure used to verify members but
       the certificate must specify exactly which class the user falls
       into.

    B. The antispam policy that is going to be enforced on the
    certificate holder needs to be posted.  There may be more than one
    policy, but the certificate must specify exactly which one will be
    enforced on that user.  This needs to be available (via HTTP, HTTPS,
    and SMTP) from the whitelist administrator.  The policy needs to be
    available in human-readable form and, hopefully,
    program-understandable form.  It may be possible to embed a summary
    of the policy in the certificate.

    C. There must be a simple, automated way to check whether a
    whitelist member's authorization has been revoked.

    D. There must be clear procedures for filing complaints against servers
    on the whitelist.  These complaints must be acted upon in a timely
    manner.  It must be easy to determine where/how to complain from the
    certificate.

    E. Whitelist administrators must actively check compliance of the
    members.  They must post email addresses on the web and USENET (in a
    way not obviously linked to them) that they will monitor for spam
    from their members.  They must periodically check that member's
    incoming SMTP servers correctly handle at least the following cases:

      1) A client with a valid certificate
      2) A client without a certificate
      3) A client with a recently revoked certificate
      4) A signed email with a valid certificate
      5) A signed email with a recently revoked certificate
      6) An email with an invalid signature

IV. CHALLENGE-RESPONSE

Email users who do not have direct access to a certified antispam server
need to be able to send to one.  They could contract with a third-party
mail provider who is antispam-certified.  They can also acquire a
personal antispam email certificate and use it with an S/MIME-capable
MUA.  These will be accepted by a compliant server.

For other users, antispam-compliant servers must provide a
challenge-response system.
    a) Properly handle mailing list mail
    b) Never challenge a reply to an E-mail you sent, even if you sent
       it from elsewhere and a different account which aliases over to
       the real mailbox.
    [This must include opt-out replies to a mailing]
    c) Include protections against loops, obviously and challenging other
       challenges, autoresponses etc.
    d) Provide a means to allow the user to review all their blocked mail
       (sorted by spam score) to catch the people who did not respond
       to the challenge.  Yes, these happen regularly even with simple
       challenges, and not because the other person is lazy.

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

Opportunities for standardization:
- requirements of antispam certificate
- mechanism for CRL retrieval
- machine-understandable description of spam-policy
- message headers for challenge-response
- message headers for user-classification
- message headers for message-classification
- SMTP extension to negotiate message-signing
----------------------------------------------------------------
My thinking about "SMTP extension to negotiate message-signing" is that
in many/most cases, you want to avoid the overhead of the signature
(which is about 1K without embedded certificate and 4K with embedded
certificate), but that it is very valuable for proving abuse.

You may want to have messages signed depending on the CA/whitelist or on
the particular client connecting.  The CA may not have an established
reputation and you may want to keep a chain of evidence in case they
turn out to be unreliable.  The client connecting may have a user-class
indicated in their certificate that is less than stellar.

Messages especially should be signed if the receiving SMTP server is not
the final destination.  This may mean that signatures could be
negotiated depending on RCPT TO, not just on a session basis. Or perhaps
based on the MAIL FROM address, too.

I include the requirement that the actual RCPT TO recipient is included
in the signed part of the message because determining whether a message
is spam must include that information.  It is also important that the
signing date is relatively recent since it needs to be determined
whether a message is sent before or after an opt-out.

This is the only change to SMTP that is required by this proposal.
--------------------------------------------------------------------
Proposed implementation:

   Phase 1:
     All participating servers validate other participating servers via IP
     address.  A challenge-response system is provided for
     non-participating servers.  This can be done with current software
     (most any mail server plus TMDA).  TMDA would just need to be
     configured to exempt whitelisted servers from the challenge-response
     system.
     [Annoyance of challenge-response will encourage other SMTP servers
     to become certified.]

   Phase 2:
     Signed messages would be checked and exempted from challenge-response
if they pass.  Messages may be signed at originating server or by MUA.
Software changes: Challenge-response systems would need to be modified to do
this checking.  SMTP servers aren't mandated to sign at this point, but may,
so they don't

   Phase 3:
     All participating servers sign outgoing messages.  The server that
     they connect to may request that they not sign messages (e.g. via
     an EHLO response), but that does not have to be honored. (Messages
     may be signed before being submitted to the mail server software.)
     [Annoyance of all those .p7s attachments will encourage other SMTP
     servers to become certified.]

   Phase 4:
     Servers should support TLS and SMTP extensions for negotiating
     message signatures that may depend on MAIL FROM and RCPT TO.

--------------------------------------------------------------------
Antispam policies should be as objective and verifiable as possible.
None of these will be universally mandated (except probably the first
four.)
  - no open relays
  - more generally, no sending of mail from unauthenticated parties
  - opt-out must work
  - no sending allowed to harvested emails

  - double opt-in required for mailing lists.
  - all senders identities and addresses have been authenticated.
    (e.g. road-runner, but not Hotmail)

In each email message, the class of sender and/or email should be
indicated.  These could be used to filter messages or require
challenge-response, even from a certified server.
   Some possiblities:
    - This is a free email account without identity verification
    - This user is limited to 100 messages/day
    - This user is limited to existing correspondents + 10 messages/day
    - This user has been active for more than 180 days and has no complaints
    - This a new user
    - This user is a paying customer resident in same country as ISP
    - This email is an advertisement to existing customer
    - This email is non-advertisement to existing customer
    - This is a challenge message for email list subscription
    - This is a challenge message for antispam purposed
    - This is a message for a subscribed and confirmed email list
    etc.
    The properties that are supported are related to the general
    anti-spam policies listed in the certificate.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Art Pollard <[email-masked]>
Date: Fri, 02 May 2003 11:02:05 -0600

I like this idea in general.  However, there is one big hole.

The big hole rests with the whitelist.

If someone spams (and is whitelisted) many ISP's do not and will not impose 
penalties on their customers.  Often times, they will send out letters by 
the standard U.S. postal service asking their customer to stop.  They do 
this even though the EULA specifically outlines per-message penalties that 
may be assessed if they violate the anti-spam policy.

The whitelist should be administered by someone other than the ISP to avoid 
this conflict of interest.  It should also be administered by someone who 
has an interest in enforcing the anti-spam policy -- not the ISP who 
doesn't want to anger their customer base.

As part of the certification process, the ISP should have the person sign 
an agreement that is kept on file on behalf of the whitelist manager that 
authorizes them to collect if terms are not satisfied.  Also, proof of ID 
would need to be provided.

Even with all this, I suspect that many would find ways around it with fake 
IDs etc.  But it would probably curtail much of what is out there and get 
things back to manageable levels.

-Art

-- 
Art Pollard
http://www.lextek.com/
Suppliers of High Performance Text Retrieval Engines.