Re: [Asrg] misconception in SPF

Paul Smith <paul@pscs.co.uk> Fri, 07 December 2012 08:40 UTC

Return-Path: <prvs=0688AFDA83=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 7864121F876B for <asrg@ietfa.amsl.com>; Fri, 7 Dec 2012 00:40:47 -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 kP8+dpObct0T for <asrg@ietfa.amsl.com>; Fri, 7 Dec 2012 00:40:46 -0800 (PST)
Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) by ietfa.amsl.com (Postfix) with ESMTP id C544B21F87AC for <asrg@irtf.org>; Fri, 7 Dec 2012 00:40:44 -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; Fri, 7 Dec 2012 08:51:24 -0000
Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Fri, 7 Dec 2012 08:31:23 -0000
Message-ID: <50C1A95A.5000001@pscs.co.uk>
Date: Fri, 07 Dec 2012 08:31:22 +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: <20121206212116.10328.qmail@joyce.lan>
In-Reply-To: <20121206212116.10328.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
Cc: John Levine <johnl@taugh.com>
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: Fri, 07 Dec 2012 08:40:47 -0000

On 06/12/2012 21:21, John Levine wrote:
> In article <CAFduganiaDkf0jFsV7FYcAvi9JjA9G-iTj8XLVzcDNY=jo_m=w@mail.gmail.com> you write:
>> here is the proof of concept ! an email sent to John Levine claiming
>> to be from ygii-john@www.johnlevine.com !!!
> Life is too short to publish SPF -all records for every host name that
> doesn't send mail.
>
While I agree totally, I understand the OP's point about semi-tech-savvy 
people being more trusting of Twitter mail coming from 
'bibble.twitter.com' than if it came from 'random.ru'

This problem is really due to the (IMHO horrible) allowance for an A 
record to be sufficient for mail delivery. However, it would be quite 
hard to remove that allowance nowadays. I don't know the stats for how 
many email addresses use A records for delivery rather than MX, but I'd 
guess its a significant number.

As a random thought, would there be the possibility to add some sort of 
marker on a parent domain to say 'we understand MX records, so we don't 
use A records for mail within this domain'? So, if you receive mail from 
'bibble.twitter.com', you check the TXT records for 'twitter.com' which 
tell you that subdomains/hosts without an MX record won't have mail, and 
since there isn't an MX record for 'bibble.twitter.com', you can reject 
it/treat it as spoofed.

The main problem I see with this is the increased DNS lookups - if you 
got a message from aa.bb.cc.dd.ee.ff.twitter.com (an excessive case), 
you'd have to do 6 or 7 extra DNS lookups before doing anything else, 
because you can't automatically tell where the 'parent' domain is. For 
small hosts this probably wouldn't be that big a problem. For big ones 
it may be, but then again, would any benefit this gave in reduced 
traffic outweigh the extra load, and would the DNS caches on the big 
hosts alleviate the problem?

(There'd also be a risk that a parent domain owned elsewhere (eg .com) 
would block A record mail for all its legacy subdomains, but you'd hope 
that wouldn't happen...)

Personally, I think I'd rather any effort went into some sort of 
'stronger' authentication being developed for prime phishing attack 
targets like Twitter, Facebook, banks etc.  eg a verification scheme 
which can verify specific messages, or a message collection system 
(rather than delivery) which can be automated by the recipient software, 
or something.



-

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