Re: [Asrg] SPF's helo identity as a reporting target

Chris Lewis <clewis+ietf@mustelids.ca> Sun, 13 May 2012 19:55 UTC

Return-Path: <clewis+ietf@mustelids.ca>
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 ECA8D21F8504 for <asrg@ietfa.amsl.com>; Sun, 13 May 2012 12:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.398
X-Spam-Level:
X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
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 xZm4RoPAz7Wu for <asrg@ietfa.amsl.com>; Sun, 13 May 2012 12:55:10 -0700 (PDT)
Received: from mail.mustelids.ca (unknown [174.35.130.2]) by ietfa.amsl.com (Postfix) with ESMTP id 27B6B21F8503 for <asrg@irtf.org>; Sun, 13 May 2012 12:55:10 -0700 (PDT)
Received: from [192.168.0.8] (otter.mustelids.ca [192.168.0.8]) (authenticated bits=0) by mail.mustelids.ca (8.14.4/8.14.4/Debian-2ubuntu2) with ESMTP id q4DJt83f030413 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <asrg@irtf.org>; Sun, 13 May 2012 15:55:08 -0400
X-DKIM: Sendmail DKIM Filter v2.8.3 mail.mustelids.ca q4DJt83f030413
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mustelids.ca; s=default.private; t=1336938908; bh=o3iA72E85DYXEJ/q2yLZ6S3TCQg81x/eBYDqtwvS+nc=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JK5JqQZ+BqdexlXo4BCzqbwerfhXsFOU5BimeJeCG6Ty03C4rWS25hUMFepszNPu5 K1WxWcwDr3O//zm3KWvs0OVga2aIzpd2FDl+y3o729tzeBJztI3NWZ62NW1wGLK72P uSR9dbXbjuv/kT5XguNji86hdSzlcVb6IYny76GU=
Message-ID: <4FB0119C.9000901@mustelids.ca>
Date: Sun, 13 May 2012 15:55:08 -0400
From: Chris Lewis <clewis+ietf@mustelids.ca>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
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>
In-Reply-To: <4FB00020.6080105@tana.it>
X-Enigmail-Version: 1.5pre
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] SPF's helo identity as a reporting target
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: Sun, 13 May 2012 19:55:11 -0000

On 12-05-13 02:40 PM, Alessandro Vesely wrote:
> On Sun 13/May/2012 20:13:44 +0200 Chris Lewis wrote:
>> On 12-05-13 01:21 PM, Alessandro Vesely wrote:
>>> That seems to imply that it is necessary to use scripts to keep helo
>>> names, IP addresses, and SPF in sync.  Would that be worth?
>>
>> The reality is going to be is that since it relies on SPF to be valid,
>> few people would bother implementing it on the sending side, and there
>> will be more than enough people ignoring the requirement to SPF verify
>> before trusting it, that kabooms! will still happen.
> 
> So it would be an error-prone technique?  We are talking about
> /postmasters/ extracting target addresses for abuse reporting, not end
> users.  Shouldn't that imply some knowledge?

It should.  But it doesn't.

> SPF records are going to sport a new ra= modifier, specifying an
> address for reporting authentication failures, not abuse.  That may
> bring further confusion, in fact.

Right.

As one said "the best thing about standards is that there's so many to
choose from" ;-)

>> 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.

abuse.net's doesn't use whois for anything.  I don't think Cymru's or
Mynetwatchman's does.

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.