Re: [fw-wiz] Spam (or, how to buy Cheap Korean Cellphones :-)

From: Rod Gilchrist (
Date: 02/06/04

  • Next message: Mike Meredith: "Re: [fw-wiz] Uploading config files to Pix 515"
    To: Chris Blask <>
    Date: Thu, 5 Feb 2004 22:54:37 -0500

    On Thursday, February 5, 2004, at 07:28 PM, Chris Blask wrote:

    >> > Last year I worked (again) at BorderWare* and ended up chairing
    >> JamSpam
    >> > (from which nothing but the AMY triangle has come out of afaik, to
    >> my
    >> > chagrin). BW's VP of Eng (Rod Gilchrist, infinitely bright guy)
    >> and I gave
    >> > it serious thought and wrote a whitepaper for a structure dubbed
    >> "cmail"
    >> > (certified mail) which as far as I can tell was entirely too
    >> straight
    >> > forward to gain any traction <the reader will please manually
    >> subtract any
    >> > battle-borne irony - I'm too tired to try>.

    Cmail was a good shot and a year later it still seems to address all
    the issues.
    (If you want to read the white paper, I can email it to you.)

    Its primary problem I think is that the audience needs to get up to
    speed a bit
    at a time and it is quite a big first bite. No point in solving secure
    opt-out in step

    (BTW, JamSpam was stunningly good at illuminating the spam problem
    from all of email's participant's points of view. I think a lot of the
    happening between the big guys today started at those meetings.)

    If you are going to start at the beginning and do things in tiny bites
    you need to
    start with identity. People kind of 'get' that.

    Then you need to add two tweaks....

            1) Relax identity far enough to make it practical
            2) Fix revocation

    >> > If I recall, revocation lists were the best reason given for not
    >> trying,
    >> > but at the end of the day SPAM has gotta be an identity fix, so may
    >> as well
    >> > meet it head on. I read this as yet another data supporting my
    >> belief that
    >> > cert folks have trouble recognizing Users when they see them.
    >> Without revocation, the first Exchange overflow would break the entire
    >> process.
    > o Revocation is necessary, but throwing up the collective PKS hands
    > isn't the way to address it. Fix identity, fix spam. A problem with
    > efforts to fix identity, imho, is that folks try to boil the damn
    > ocean when the task is to make a nice cup of tea,,,
    > Cert folks: Revocation is a problem? Fix it!! Don't make me come
    > down there and do it myself, I'll be so cross! ;-)

    There are a couple of straight forward fixes for revocation.

    You only get into deep trouble if you adopt the whole set of
    assumptions behind PKI. PKI is a
    general solution that is intended to work over long (i.e. infinite)
    periods of time. Relax that set
    of assumptions and revocation is solvable.

    For email identity all you need is a key pair that's valid long enough
    for email to arrive at its
    destination. A much easier problem than what PKI's revocation attempts
    to solve.

    >> > Anyone else see - if in fact this is the right forum - any solution
    >> to spam that doesn't involve fixing the identity problem?
    > There's the actual question for the list: If it ain't ID, what *is*
    > the shape of the solution?

    Yes identity is the first and most basic issue. But almost everyone
    gets hung up on perfect
    identity as per PKI (i.e. individual identity right down to name,
    address and social insurance number).

    You don't really need that at all to fix spam.

    For spam its enough to be labeled as 'an AOL user whose mail mail is
    subject to AOL's terms of use that
    require that the user never send more that 100 emails in an hour and
    that AOL has taken effective
    action to enforce that behavior'.

     From an email MTA's point of view that translates to 'a message that is
    signed by the mail source that
    has public key 'X' and whose past behavior I see from reputation store
    'Y' rarely includes spamming
    should be passed on without passing though my aggressive spam filter'.

    So what's going to do spam in? I think a solution is coming. There are
    at least three separate solutions
    out there that have relaxed identity into the practical realm; SMPTi,
    'Sender Permitted From' and 'Domain
    Keys' (Google can fill in the details of all of these). The first two
    use IP addresses as identity,
    which has serious limitations when messages are relayed (which is kind
    of basic in SMTP). Domain Keys
    (from Yahoo) on the other hand is a home run.

    With Domain Keys, the owner of a DNS domain generates a public/private
    key pair, signs all email
    messages originating (via SMTP extension headers) in that domain with
    the private key and publishes
    the public key via DNS. Since the publishing mechanism is out of band
    with respect to SMPT, no
    changes are required to the SMPT protocol.

    Details haven't been published yet, but revocation could be handled by
    publishing two public keys
    via DNS (old and new) and a few days after the last email signed with
    the old key was sent, trashing
    the old key.

    So basically, Chris's grandmother doesn't need to get a certificate;
    her ISP worries about the key pair
    and bounces all the email she sends that's addressed to all 115 of her
    grandchildren at the
    same time. People publishing news letters need to be savvy enough to
    generate a public/private key
    pair for their own mailer. And nobody pays Verisign...

    If your private key gets stolen, your reputation (as measured by a
    DCC-like reputation server)
    gets trashed and you need to make a new key pair and start building a
    reputation again.

    So, we're winning I think. Much further ahead than last year.

    - Rod

    BTW, I'm not on this list. Hopefully Chris will relay as required.

    firewall-wizards mailing list

  • Next message: Mike Meredith: "Re: [fw-wiz] Uploading config files to Pix 515"