ietf-smtp
[Top] [All Lists]

Re: Chain of Trusted Forwarders

2005-05-29 03:14:52

At 12:46 AM 5/29/2005 -0400, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
On Sat, 28 May 2005 16:45:40 PDT, David MacQuigg said:

> Spammer -->  Forwarder1 --> Forwarder2 -->  Receiver
>
> A Trusted Forwarder will authenticate the ID presented by the Spammer. The
> Receiver will look at that ID, and rate it just as if the Spammer had
> connected directly to the Receiver.  If one of the Trusted Forwarders
> messes up an authentication, then that forwarder loses reputation.

Exactly.  So every time Forwarder*2* accepts a bogus one, *it* loses...

Forwarders are not responsible for content. The only way Forwarder2 loses, is if it fails to authenticate Forwarder1.

> The game could get a little more complicated if Forwarder1 is the spammer's

The whole point is that Forwarder1 can be *assumed* to be the spammer's...

> friend, but not much.  About the fifth time a rating service has to deal
> with a he-said-she-said situation involving Forwarder1, it will be pretty
> clear who is faking authentication headers.

And after a long run of Forwarder1A..Forwarder1Q.., Forwarder2 is starting to
look pretty shaky in the reputation market as well. Remember that we're talking
here about a class of opponents that have *literally* hundreds of thousands of
drones to enlist, and throwing tens of millions of bogus authentications.
"About the 5th time" gets you through the first 35 seconds of a concerted attack
against the reputation mechanism, if *that* long.

And don't bother suggesting "slow-start" mechanisms for setting up reputations - the spammers are *already* sometimes lining up domains and zombies well in advance
of the run they are to be used for.  There's no reason to believe they *won't*
engage in a ramp-up of bouncing totally pointless mail back and forth just to
drive up their reputation score before they make their spam run...

Now we are getting to some good stuff, and I will admit I haven't thought through all the details.

Let's assume authentication works perfectly, so we are looking just at the cost/benefit to spammers of acquiring/burning reputable IDs. Let's also ignore the occasional hijacking of a reputable ID. As you say, this must be a production process involving large numbers of names. Let's look at the benefit first, as that seems easiest. The system I imagine would give a spammer about an hour of operation with a B-rated ID before the downgrade notification propagates to all that care about a quick response.

The real question is, how easy will it be for spammers to move their plentiful supply of C-rated (unknown) IDs up to B (trusted, but not yet proven). If I were a reputation service, considering an applicant for a B rating, I would take a corporate registration as sufficient. This is easily checked, and will cover almost all wannabe operators of Public Mail Servers. For individuals, I would insist on a face-to-face with someone I trust, maybe one of my subscriber ISPs in the same town. My representative could copy the individuals driver's license and credit cards, and snap his picture. I would also run a check of credit and police records.

The fee for this service might include a bond, to be returned after the first six months of operation. I really don't care if individual applicants find this burdensome. My customers are email receivers, and I don't think I will lose much business if a few individuals decide that using a reputable ISP to forward their mail is easier than getting a "license" to operate their own Public Mail Server.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *



<Prev in Thread] Current Thread [Next in Thread>