[Asrg] Reporting targets, was SPF's helo identity as a

Alessandro Vesely <vesely@tana.it> Mon, 14 May 2012 09:27 UTC

Return-Path: <vesely@tana.it>
X-Original-To: asrg@ietfa.amsl.com
Delivered-To: asrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7421B21F85D9 for <asrg@ietfa.amsl.com>; Mon, 14 May 2012 02:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.6
X-Spam-Level:
X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DjNOFm0IQ00 for <asrg@ietfa.amsl.com>; Mon, 14 May 2012 02:27:55 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 838EA21F85D8 for <asrg@irtf.org>; Mon, 14 May 2012 02:27:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1336987674; bh=aNh2ZoX9ECHETjICvryp1LWPG/YAECV2ZSrY7JoFXZQ=; l=1990; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=CGORabtldc2fK5oL3KWUM0yumIIepQBV3Habh293nF3usHg41im9TraNWuta7ovAI qds67i/oKOHgdAqM0LG6j1Qeey6T7PN6Wz+9k7F8eFz+dAP5lh+WmXw/fRK4sqFhs1 Hp5d7ssbhAdKdM3gyC5ltr0x1wDweKDkdlzxQc3s=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 14 May 2012 11:27:54 +0200 id 00000000005DC039.000000004FB0D01A.0000655C
Message-ID: <4FB0D01A.4000300@tana.it>
Date: Mon, 14 May 2012 11:27:54 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: asrg@irtf.org
References: <4FA8FBCA.3050904@tana.it> <4FAE187B.9030902@tana.it> <4FAEA20F.8090302@mustelids.ca> <4FAF85D0.8050305@tana.it> <4FAFD34F.6010301@mustelids.ca> <4FAFEDA8.4090009@tana.it> <4FAFF773.10207@mustelids.ca> <4FB00020.6080105@tana.it> <4FB0119C.9000901@mustelids.ca>
In-Reply-To: <4FB0119C.9000901@mustelids.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [Asrg] Reporting targets, was SPF's helo identity as a
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2012 09:27:56 -0000

On Mon 14/May/2012 10:48:08 +0200 Chris Lewis wrote:
> On 12-05-13 02:40 PM, Alessandro Vesely wrote:
>> On Sun 13/May/2012 20:13:44 +0200 Chris Lewis wrote:
> 
>>> There are other ways of doing this that doesn't require ancillary gunk
>>> like SPF. There's at least one IP-based DNSBL that yields the same data.
>> 
>> Which one do you mean?  DNS lists like abusix get their data from
>> RIRs' whois databases.
> 
> That's an implementation detail.  There's no reason that they'd _have_
> to.  Mine doesn't rely on whois for responsible domain or abuse contact.
> While it does the published RIR maps for allocations and countries, it
> does no whois queries.

And how does it discover abuse contacts?

> abuse.net's doesn't use whois for anything.

Yes, but it's not IP-based.  It falls back to RFC 2142 role addresses,
and relies on cooperative contributions (I think).

> I don't think Cymru's or Mynetwatchman's does.

Thanks for the pointers, I'll take a look at them.

> It's _very_ hard to get domains from whois in an even remotely "global
> sense", let alone abuse addresses.
> 
>> In that case, virtual MTA providers would have
>> to restrict their choice of network providers based on proper
>> management of whois records, besides cost, bandwidth, uptime, support, ...
> 
> "Proper management" of IP whois records is probably coming as unlikely
> as it seems, so another reason for it wouldn't hurt.

That would be a Good Thing.  However, it may appear a double-edged
sword, as it hides the network provider's abuse team.  One could
navigate whois records hierarchically, so if the virtual MTA operator
is a bad guy, the abuse contact at the upper level should be its
network provider.  This operation can be done recursively, but
homogeneity may obscure awareness.  That is, by climbing the tree all
the way up, one eventually gets at IANA's --which hopefully will never
be a bad guy-- but might not realize what role corresponds to each level.