Re: [Asrg] misconception in SPF

Alessandro Vesely <vesely@tana.it> Mon, 10 December 2012 11:13 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 9BF5521F8E7E for <asrg@ietfa.amsl.com>; Mon, 10 Dec 2012 03:13:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level:
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flbjutv2sH1j for <asrg@ietfa.amsl.com>; Mon, 10 Dec 2012 03:13:52 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E33AA21F8D8E for <asrg@irtf.org>; Mon, 10 Dec 2012 03:13:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1355138030; bh=z0NUaZOqw4TfU3IDEpG+GI8276HaMVPi4ErDvE1RurY=; l=1796; h=Date:From:To:References:In-Reply-To; b=Az8L0cyhh/WGpur1VIoS1E3eTzcYhGk3v8olgIH/c/lxqiLtut9vLG6WNRB5wYclr Igvy9u/A7REhYMmwtMZIE/RQ8+P2E+xWxYP3Xe65QrNieyp4aKcRzvs0nuvs0sb/Om EmpSXDP45jxFaufc0XYrnrw7mG+xyhqYH40KaykI=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 10 Dec 2012 12:13:49 +0100 id 00000000005DC031.0000000050C5C3ED.00005C52
Message-ID: <50C5C3E4.3090901@tana.it>
Date: Mon, 10 Dec 2012 12:13:40 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: asrg@irtf.org
References: <20121207204554.18364.qmail@joyce.lan> <50C38A37.8050602@tana.it> <20121208233809.GA9196@mx1.yitter.info>
In-Reply-To: <20121208233809.GA9196@mx1.yitter.info>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] misconception in SPF
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, 10 Dec 2012 11:13:52 -0000

On Sun 09/Dec/2012 00:38:10 +0100 Andrew Sullivan wrote:
> On Sat, Dec 08, 2012 at 07:43:03PM +0100, Alessandro Vesely wrote:
> 
>> Aren't there generic (i.e. non spf-specific) DNS conventions for
>> publishing such relationships?
> 
> No, but comments on
> http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02
> would be most welcome.

Those SOPA records, at least in the "names-only" strategy, would be an
easy way to lightheartedly use wildcard records so as to cover all the
subdomains.  I'm surprised there are no established hacks, such as
capturing part of the SOA, as it might be part of a negative reply to
a TXT query, e.g. RNAME =~ /hostmaster\.([-.a-z0-9]{2,63})/i.

While RNAMEs may get filled in unwittingly of such use, SOPA is sound
because of the clearness of its semantics.  However, it is also true
that its precise meaning depends on the kind of policy.  One then has
to turn to "port-and-scheme" strategy, and complicate the subject
beyond ease of reach.  In comparison, the overloaded-redirect hack has
some nice properties:

*semantics*:  the same mail abuse team looks after both domains.

*hierarchy*:  a loop entails the setup is broken.

*conciseness*:  the vertex must be reachable withing 10 queries.

*awareness*:  SPF never suggested to use redirect for helo records, so
anyone using it must be aware of it.  For a more stringent check, it
could be conceived as, say, redirect=_spf_policy_hack.master.tld.

That doesn't address the OP concern about non-mailing subdomains,
albeit in some cases it can.  It just reduces the number of entries in
a receiver's senders database.  Since each of those entries is likely
to cost some fraction of human operator's time, reducing them seems to
be worth an extra lookup on each message.