A Trial Balloon to Ban Email?

Anne & Lynn Wheeler lynn at garlic.com
Fri May 9 09:11:52 PDT 2003


the proposal in the past has been that ISPs filter spam at ingress from 
their customers. the counter-argument has been that there are lots of ISPs 
that can't be trusted to do it.

So it is much easier for ISPs to have lists of other trusted &/or untrusted 
ISPs that they will accept email from.

It is orders of magnitude easier (and more efficient) for ISPs to do 
ingress filtering for SPAM and effectively ISP blacklists than it is to 
populate the whole consumer infrastructure.

There are still some ways to slip thru the cracks with small amounts .... 
but it isn't the 40-80% volume of all email that is seen today.

It does have an analogous downside to the individual privacy issues ... 
which are that the big ISPs could use blacklisting for other purposes than 
addressing SPAM issues.

Some of the ingress filtering pushback may be similar to the early 
counter-arguments for packet ingress filtering related to ip-address 
spoofing. however, that seemed to be more a case of disparity among the 
router vendors in which could & could not implement ingress filtering. as 
majority of the router vendors achieved such capability ... the push-back 
significantly reduced.
http://www.garlic.com/~lynn/rfcidx7.htm#2267
2267 -
Network Ingress Filtering: Defeating Denial of Service Attacks which employ 
IP Source Address Spoofing, Ferguson P., Senie D., 1998/01/23 (10pp) 
(.txt=21032) (Obsoleted by 2827)

there already are logs relating ingress email to originating ISP customer 
id. that could be made available via some sort of legal action. the only 
issue then is the strength of authentication that is performed on customer 
connection to the ISP ... rather than some sort of origin authentication 
for every email.

At 03:40 AM 5/9/2003 +0100, Adam Back wrote:
>Yes, there is some discussion of it on slashdot, including several
>other people who have commented similarly to anonymous that it is a
>pretty big privacy invasion and centralised control point problem.
>
>The claim that you can optionally be anonymous and not use a cert, or
>get an anonymous cert is plainly practically bogus.  You'd stand about
>as much chance of having your mail read as if you shared mail hub with
>spamford wallace -- ie 90+% of internet mail infrastructure would drop
>your mail on the floor on the presumption it was spam.
>
>Plus a point I made in that thread is that it is often not in the
>internet user's interests to non-repudiably sign every message they
>send just to be able to send mail because that lends amunition to
>hostile recipients who from time-to-time target internet users for
>bullshit libel and unauthorised investment advice etc.
>
>Companies also are I would expect somewhat sensitive to not signing
>everything for similar reasons as those behind their retention
>policies where they have policies of deleteing emails, files and
>shredding paper files after some period.
>
>In addition PKIs because of the infrastructure requirements have
>probem complex to setup and administer.  So now we've taken one hard
>problem (stopping spam) and added another hard problem (hierarchical
>PKI deployment) and somehow this is supposed to be effective at
>stopping spam.
>
>In addition unless there is significant financial cost for
>certificates and/or signifcant and enforceable financial penalty and
>good identification and registration procedures enforced by the CAs it
>wouldn't even slow spammers who would just get a cert, spam, get
>revoked, get another cert and repeat.
>
>Certificate revocation is already a weak point of PKI technology, and
>to reasonably stop spam before the spammer manages to send too many
>millions of spams with a cert, you have to revoke the cert PDQ!
>
>And finally it all ends up being no more than an expensive
>implementation of blacklists (or I suppose more properly whitelists),
>because the CAs are maintaining lists of people who have not yet been
>revoked as spammers.  Some click through agreement isn't going to stop
>spammers.  Legislation or legal or financial threat is going to stop
>spammers either because any level of registration time identity
>verification that is plausibly going to be accepted by users, and this
>is also limited by the cost -- higher assurance is more cost which
>users also won't be willing to accept -- will be too easy for the
>spammers to fake.  And email is international and laws are not.
>
>It is pretty much an "internet drivers license" for email.
>
>I also think that fully distributed systems such as hashcash are more
>suitable for a global internet service.  My preferred method for
>deploying hashcash is as a token exempting it's sender from bayesian
>filtering, and any other content based or sender based filtering.
>
>That way as an email user you have an incentive to install a hashcash
>plugin http://www.cypherspace.org/hashcash/ because it will ensure
>your mail does not get deleted by ever-more aggressive filtering and
>scattergun blackhole systems.  The camram system
>http://www.camram.org/ is a variant of this.
>
>It also more directly addresses the problem: it makes it more
>expensive for spammers to send the volumes of mail they need to to
>break even.
>
>Adam
>
>On Fri, May 09, 2003 at 03:50:02AM +0200, Nomen Nescio wrote:
> > Lauren Weinstein, founder of People for Internet Responsibility, has
> > come out with a new spam solution at http://www.pfir.org/tripoli-overview.
> >
> > According to this proposal, the Internet email architecture would be
> > revamped.  Each piece of mail would include a PIT, a Payload Identity
> > Token, emphasis on Identity.  This would be a token certifying that you
> > were an Authorized Email User as judged by the authorities.  Based on
> > your PIT, the receiving email software could decide to reject your
> > email.
> >
> >    It is anticipated that all Pits considered acceptable by the vast
> >    majority of all Tripoli-compliant software user would be digitally
> >    signed by one or more designated, trustworthy, third-pary authorities
> >    who would be delegated the power to certify the validity of identity
> >    and other relevant information within Pits.
> >
> > In other words, here comes Verisign again.
> >
> >    It is anticipated that in most cases, in order for the sender of an
> >    e-mail message to become initially certified by a Pit Certification
> >    Authority (PCA), the sender would need to first formally accept
> >    Terms of Service (ToS) that may well prohibit the sending of spam,
> >    and equally importantly, would authorize the certification authority
> >    to "downgrade" the sender's authentication certification in the case
> >    of spam or other ToS violations.
> >
> > Thus you have to be politically acceptable to the Powers That Be in
> > order to receive your license to email, aka your PIT.  And be careful
> > what you say or your PIT will be downgraded.
> >
> > Unfortunately he doesn't discuss various crypto protocol issues:
> >
> > If the PIT is just a datum, what keeps someone from stealing your PIT
> > and spams with it?
> >
> > If the PIT is a cert on a key, what do you sign?  The message?  What if
> > it gets munged in transit, as messages do?  You've just lost most of
> > your email reliability.
> >
> > Or maybe you sign the current date/time?  Then delayed mail is dead mail.
> >
> > Or maybe you respond to a challenge and sign that?  That won't work if
> > relays are involved, because they can't sign for you.
> >
> > Spam is a problem, but it's no excuse to add more centralized
> > administrative control to the Internet.  Far better to go with a
> > decentralized solution like camram.sourceforge.net, basically a matter
> > of looking for hashcash in the mail headers.  This raises the cost to
> > spammers without significantly impacting normal users.
> >
>
>---------------------------------------------------------------------
>The Cryptography Mailing List
>Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm





More information about the cypherpunks-legacy mailing list