Re: [Asrg] misconception in SPF

Paul Smith <paul@pscs.co.uk> Sun, 09 December 2012 00:00 UTC

Return-Path: <prvs=0690ADBB90=paul@pscs.co.uk>
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 193FF21F8AAC for <asrg@ietfa.amsl.com>; Sat, 8 Dec 2012 16:00:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 YrlafSNeYT1G for <asrg@ietfa.amsl.com>; Sat, 8 Dec 2012 16:00:26 -0800 (PST)
Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) by ietfa.amsl.com (Postfix) with ESMTP id D6DFF21F897A for <asrg@irtf.org>; Sat, 8 Dec 2012 16:00:25 -0800 (PST)
Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP for <asrg@irtf.org>; Sun, 9 Dec 2012 00:11:33 -0000
Received: from [192.168.57.155] ([217.155.61.157]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP for <asrg@irtf.org>; Sat, 8 Dec 2012 23:17:21 -0000
Message-ID: <50C3CA7A.6080304@pscs.co.uk>
Date: Sat, 08 Dec 2012 23:17:14 +0000
From: Paul Smith <paul@pscs.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20121207204554.18364.qmail@joyce.lan>
In-Reply-To: <20121207204554.18364.qmail@joyce.lan>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: paul
X-Server: VPOP3 Enterprise V6.0 - Registered
X-Organisation: Paul Smith Computer Services
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: Sun, 09 Dec 2012 00:00:27 -0000

On 07/12/2012 20:45, John Levine wrote:
>> I think this makes sense, but I think it would make more sense if there was
>> a way to just specify in the SPF record for, for example, twitter.com, that
>> all legit senders for all subdomains are included in the highest level SPF
>> record.
> This sort of thing has been proposed before.  It turns out that
> anything in the DNS that starts "all names below this node ..." is
> astonishingly hard to implement.
Could we have a "direct parent" check rather than going up lots of levels?

Eg, if you are having to fall back to an A record, look at the direct 
parent for a TXT record with appropriate data in

So, if you are checking a message from xyz@bibble.twitter.com, you are 
doing your check back that bibble.twitter.com exists, and see that it 
only has an A record (if it has an MX record, that satisfies your 
checks). Now, you do a TXT lookup on 'twitter.com' and if the result has 
a record saying 'mx only' (or some such) you know that 
'bibble.twitter.com' isn't valid as an email domain.

This would be quicker than going up the tree, but would catch the most 
common case of having lots of hosts defined in a domain, any of which 
could be used for 'spoofing'. It would only be needed in the (hopefully, 
rare) case of having to fall back to the 'A' record.

Checking for the TXT record would be slower than not doing so, but would 
be a lot more efficient than attempting to connect to a non-existent 
mail server at the A record.
> I do agree that it would have been really nice if the SMTP fallback
> from MX to A records had been deprecated and killed back in the 1980s.
> I tried to get RFC 5321 not to add fallback to AAAA but the powers
> that be insisted that it was already too late.
>
I wish it could be deprecated (but still required) now (ie, you MAY just 
have an A record to indicate where mail is to be delivered, but you 
SHOULD have an MX record instead). That way if we came across an A 
record only, we would have a stronger argument for persuading domain 
admins to add MX records. Currently some say 'well the standards say 
it's OK, so we're not changing anything'.

It could be worth logging how many times we have to fall back to an 
A/AAAA record, AND the delivery succeeds - I may have a go at that 
ourselves.



-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53