Re: [Asrg] EPOSTAGE Too Big to Block?

John Leslie <> Fri, 10 July 2009 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70A9F3A6858 for <>; Fri, 10 Jul 2009 10:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.357
X-Spam-Status: No, score=-6.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bE8VBASE85eI for <>; Fri, 10 Jul 2009 10:26:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F04293A67AD for <>; Fri, 10 Jul 2009 10:26:25 -0700 (PDT)
Received: by (Postfix, from userid 104) id AE2CF33C7C; Fri, 10 Jul 2009 13:26:49 -0400 (EDT)
Date: Fri, 10 Jul 2009 13:26:49 -0400
From: John Leslie <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <20090710172649.GU15652@verdi>
References: <20090709173627.GP15652@verdi> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
Subject: Re: [Asrg] EPOSTAGE Too Big to Block?
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jul 2009 17:26:31 -0000

John Levine <> wrote:
>>> The point is not the zombies attacking the crypto.  The point is
>>> zombies (ab)using their machines' legitimate owners' epostage.
>>   This is a problem why?
> It destroys epostage's credibility to potential users.

   Remember, the "users" are sending and receiving MTAs. I see little
benefit in defining a class of "potential users" that goes beyond the
class of current MTA operators.

   While I grant that FUD can always "destroy credibility", I don't see
it as hard to convince current MTA operators that if they give malware
access to a "bank" account they shouldn't be surprised when a particular
malware empties that account. "Credibility" of a cash-transfer system
running on compromised machines isn't a concept I wish to promote...

> Please see my white paper.

   Presumably John means

which makes a number of excellent points, most of which I quite agree
with. For example:
] Since a sender can send the same valid stamp to many recipients, a
] recipient who gets a stamp from an unknown sender needs to check to
] see if it has already been used, by asking the issuing bank.
] Most likely the majority of banks will be competently run, but some
] won't, deliberately or inadvertently issuing stamps that they can't
] later cash.
] Usable international e-postage will need a system that lets recipients
] rapidly decide whether they're willing to accept stamps from unknown
] far-away banks.
] If a stamp costs a penny... and 10% of the total stamps presented are
] real (the other 90% being spam), and that the bank's cut on each stamp
] is 10%, the bank has only 1/10 cent to spend to cancel each real stamp
] and 1/100 cent to reject a fake stamp.

   I believe draft-irtf-asrg-postage sets out to live within those

   John continues and elaborates some threats
] To send mail without paying postage, one might send spam with fake 
] stamps hoping recipients won't check them, send mail with forged
] return addresses that are on recipients' whitelists, send a little
] innocent mail to get recipients to whitelist them followed by a lot
] of spam, set up a fake bank that deliberately issues uncashable
] stamps, or trick a legitimate bank into issuing postage without
] paying for it.
] To charge e-postage to third parties. one might sneak spam into other 
] people's mailing lists, or use a virus or Trojan horse software that 
] sends spam from the third party's computer.

   These are valid threats, but not in scope of draft-irtf-asrg-postage,
IMHO. They seem most appropriate for documents issued by "banks" to
their customers. I could go over any of them on request, but I see no
reason to try to address all of them in a single email.

   I expect to reissue draft-irtf-asrg-postage, and I am open to
suggestions for improvement, but issues such as those, IMHO, are better
treated in a draft on a possible implementaton of an ePostage bank (in
progress) or a draft on "best practices" for using an ePostage system
(which I'm willing to act as Editor for).

John Leslie <>