[Asrg] Re: 6 - Yahoo Domain Keys

Philip Miller <millenix@zemos.net> Wed, 19 May 2004 23:43 UTC

Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29314 for <asrg-archive@odin.ietf.org>; Wed, 19 May 2004 19:43:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQaeB-0004AT-FY for asrg-archive@odin.ietf.org; Wed, 19 May 2004 19:38:51 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JNcpKh016019 for asrg-archive@odin.ietf.org; Wed, 19 May 2004 19:38:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQacU-0002qV-Ph for asrg-web-archive@optimus.ietf.org; Wed, 19 May 2004 19:37:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29035 for <asrg-web-archive@ietf.org>; Wed, 19 May 2004 19:37:05 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQacS-00040j-SU for asrg-web-archive@ietf.org; Wed, 19 May 2004 19:37:04 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQabU-0003uc-00 for asrg-web-archive@ietf.org; Wed, 19 May 2004 19:36:05 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQaae-0003p5-00 for asrg-web-archive@ietf.org; Wed, 19 May 2004 19:35:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQaN0-0008Ev-5x; Wed, 19 May 2004 19:21:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQaIC-0006mF-KN for asrg@optimus.ietf.org; Wed, 19 May 2004 19:16:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27992 for <asrg@ietf.org>; Wed, 19 May 2004 19:16:05 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQaIA-0001U6-US for asrg@ietf.org; Wed, 19 May 2004 19:16:07 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQaHI-0001KA-00 for asrg@ietf.org; Wed, 19 May 2004 19:15:14 -0400
Received: from main.gmane.org ([80.91.224.249]) by ietf-mx with esmtp (Exim 4.12) id 1BQaFt-00011O-00 for asrg@ietf.org; Wed, 19 May 2004 19:13:46 -0400
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BQaFu-0001uU-00 for <asrg@ietf.org>; Thu, 20 May 2004 01:13:46 +0200
Received: from pcp09394639pcs.union01.nj.comcast.net ([69.141.77.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <asrg@ietf.org>; Thu, 20 May 2004 01:13:46 +0200
Received: from millenix by pcp09394639pcs.union01.nj.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <asrg@ietf.org>; Thu, 20 May 2004 01:13:46 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: asrg@ietf.org
From: Philip Miller <millenix@zemos.net>
Lines: 92
Message-ID: <40ABEA25.5060901@zemos.net>
References: <40AAB82D.3090004@solidmatrix.com> <GPEMJLCHICHEGPOKJHHDCELEHPAA.asrg@rebel.com.au> <16555.56412.585254.961521@world.std.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pcp09394639pcs.union01.nj.comcast.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5
X-Accept-Language: en, en-us
In-Reply-To: <16555.56412.585254.961521@world.std.com>
Content-Transfer-Encoding: 7bit
Subject: [Asrg] Re: 6 - Yahoo Domain Keys
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/asrg/>
Date: Wed, 19 May 2004 19:13:41 -0400
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,DOMAIN_BODY autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Barry,
You wrote:
> FWIW, I still think these sort of approaches might have some utility
> with authentication but will have little to no effect on spam so I
> wonder why they get so much attention on this list.

It will have little immediate effect on the *volume* of spam sent. However, 
it will have an effect on certain characteristics of the spam that is 
received. I'll get into specifics as I go along.

> As far as I can tell spammers have now become domain registries and
> just generate random-appearing, generated domains like www.fxbrezd.com
> (or, more often, .info or .somecountryyoudon'twanttoknowmoreabout.)

These types of things could potentially be blacklisted. Has anyone created a 
functioning BL of domain registrars, rather than domains?

> For example, these whacko domains usually have functioning MX's.

Functioning MX's would mean no rejection by Hector Santos's Call Back 
Verification. However, having a functioning MX gives us something beyond a 
domain name: an assigned or hijacked IP address, which can be traced, 
(black/block)listed, and/or dealt with by an upstream provider. It's easier 
to hunt down a real person if you can find where IP packets are being 
routed, compared to having just falsified whois records.

> Which means they can just as easily set up SPF or Domain Key or
> similar services for those randomly generated domains.

SPF simply says that they control the domain they're using, which is an 
improvement over the present state. In this case, if they're using zombies, 
they need some way to ensure that all of those zombies end up authorized by 
the SPF records. Perhaps SPF lookup libraries should keep a count of the 
total hosts authorized by the domain in question, which could be 
cross-referenced to an external list or other reputation service. I.e. 
domains that list a lot of sending hosts would need a much better reputation 
for their mail to be accepted than domains that list a very restricted set.

> Also, much spam from hijacked PCs seems to use the hijacked
> PC's host, as in wasteofoxygen@dyn-83-155-31-99.ppp.tiscali.fr

And no ISP worth its salt would authorize any host to send as an internal 
host name, so spammers can't play the pin-it-on-the-ISP game.

> That sort of thing will get around these SPF/YDK approaches, right?

Wrong. See above.

> And of course there's the whole problem of the envelope vs the header
> since these generally check the envelope but the user generally sees
> the header so can be spoofed anyhow. I realize this generally prompts
> a response about how there's some effort, somewhere, to extend all
> this into the header which is passed off as an answer but it quickly
> starts to sound like "oh we'll invent that too!" back-patching on an
> apparently weak idea.

There's not that much 'invention' to go into it, once something more 
primitive than 2822.From is authenticated. Either messages claiming a given 
domain will only come from hosts that can send return-paths in the domain, 
or there will be others, or they could come from anywhere.
Since only certain hosts are authorized, the domain owner can enforce 
local-part policy, so we need only worry about the domain.

> Again, I don't know for a fact that this is completely useless
> technology (like proof-of-work which is useless technology), but I
                    ^^^^^^^^^^^^^       ^^^^^^^^^^^^^^^^^^^^^
I still haven't seen proof of that, from you or others...
> think it's only potentially useful against certain types of scams,
> domain forgeries with malicious intent, in a very weak way, and as
> such really has little to nothing to do with spam per se except
> inasmuch as we can rationalize that ``anything which comes via email
> and might harm or annoy me'' is hereby spam.

Since this group has largely agreed that a formal, consensus definition of 
spam is non-existent, any methods that can be used to hinder messages that 
any people might not want is in scope as 'anti-spam research'.

You are using useful here to mean 'volume of spam (by my as-yet-unstated 
definition) will decrease'. I and others look at a much broader range of 
things as useful:
1. Practically eliminate receipt of DSNs about messages that were never sent
2. Protect domain owners (both large providers and joe-job targets) from 
accusations of abuse by letting them point to their DNS records and say 'you 
can see from that record that we did not authorize the transmission of that 
message'
3. Provide domain-name level accountability for messages. Really, any 
domain, appearing anywhere in the message, will do, so long as you can point 
to them and say "that domain said that they have no problem with their name 
being attached to this message"

Sincerely,
Philip Miller


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg