Subject: RE: Patent Application 683624

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 17 Sep 2004 13:02:07 -0700

The computational puzzles approach is outside the scope of this
wg, so why are we having a prolonged discussion of it here as
opposed to ASRG?

> -----Original Message-----
> From: Douglas Otis [mailto:[email-masked]]
> Sent: Friday, September 17, 2004 1:38 PM
> To: william(at)elan.net
> Cc: IETF MARID List
> Subject: Re: Patent Application 683624
> 
> 
> 
> On Thu, 2004-09-16 at 23:41, william(at)elan.net wrote:
> > On Thu, 16 Sep 2004, Douglas Otis wrote:
> > 
> > > From their presentation, the concept was to impose about 
> a 16 second
> > > additional CPU message burden for the sender.  Their 
> statement was such
> > > additional overhead doubled the cost of equipment for the 
> sender.  This
> > > does not consider that many abusive senders control 
> millions of Window
> > > machines with hidden Trojan proxies and never pay for their use. 
> > 
> > And besides, the CPU  costs are rapidly going down with 
> twice as fast CPUs
> > being released every one or two years. You simply can't 
> rely on this 
> > technique - the hardware cost even for spammer that does 
> not use zombie
> > machines is likely to be low percentage for cost of his 
> operation - its 
> > the cost of hosting of such machine on "spam tolerant" 
> network that is high.
> 
> Increased overhead burdens legitimate mail disproportionately 
> more than
> it does for illegitimate senders.  Higher overhead moves 
> toward a system
> that does not achieve the needed scale and that becomes more 
> fragile or
> prone.
> 
> > > It does bring up the issue of cost for a maximal 200 
> second receiver
> > > burden for resolving Sender-ID or SPF records.  With a 
> common spammer
> > > technique of using random sub-domains, this will keep 
> filters guessing
> > > and the DNS resolvers scrambling for records. 
> > 
> > I note that the same problem exists with absolutely every 
> proposal before
> > MARID. And in reality its not really proper concern for 
> this group, we
> > need to worry how to properly identify GOOD senders and how 
> to make sure
> > THEIR domains are not forged.
> 
> The focus should be centered upon establishing a basis for
> accountability with low overhead (i.e. CSV).  The marid-mpr 
> draft was to
> show once a reasonably strong name or identity is established, to then
> include mailbox domain constraints only requires a name list. 
>  There is
> then no need for "includes", "redirects" or various other subsequent
> record lookups.  Your point is on point, however.
> 
> > That spammers can still buy new domains for almost nothing 
> ($6) or use 
> > subdomains which are technically free to them and then 
> publish MARID 
> > records there is outside the scope of this group - it is 
> something to be 
> > addressed by reputation.
> 
> You are right, obtaining a new domain becomes just another 
> cost of doing
> business for the spammer.  I see some sites, in efforts to bypass
> filters, pickup several domains a day.
> 
> > > It would seemi illegitimate senders win in any war of escalated 
> > > overheads.  If only these innovators would properly 
> handle a temp error, 
> > > we could slow unknown senders without punishing 
> legitimate senders. ; )
> > 
> > I did not understand how handling temp error would help. 
> Can you explain
> > or give example?
> 
> Although a good list may be relatively complete, there will always be
> new users and legitimate domains that will need to enter the system. 
> Rather than tar-pitting, a friendlier method may be to cap 
> these obscure
> domains until there is a history established.  Capping could 
> be done by
> issuing a temp error.  There will still need to be a clearing house to
> note the good domains that have "gone bad" and perhaps help 
> identity the
> new domains from the older well behaved.  
> 
> Microsoft innovations have overlooked some basic elements to grapple
> with the spam problem.  Forwarding the message should include all
> headers to make submitting a complaint something an average user would
> be able to do.  Handling of temp errors should cause a sizable delay
> before the delivery is retried.  Some sites require the use of DoS
> blocking techniques to handle poor behavior.
> 
> -Doug
>