Re: [Asrg] misconception in SPF

Paul Smith <paul@pscs.co.uk> Fri, 07 December 2012 17:12 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 A5E2221F8AE3 for <asrg@ietfa.amsl.com>; Fri, 7 Dec 2012 09:12:53 -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 5hTf985w9-I7 for <asrg@ietfa.amsl.com>; Fri, 7 Dec 2012 09:12:52 -0800 (PST)
Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2895C21F8A94 for <asrg@irtf.org>; Fri, 7 Dec 2012 09:12:51 -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 17:21:30 -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 16:53:16 -0000
Message-ID: <50C21EFC.4060508@pscs.co.uk>
Date: Fri, 07 Dec 2012 16:53:16 +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> <50C1A95A.5000001@pscs.co.uk> <CAFdugan=tzj+oMMSLH0ukWHK5jF7tSjbp5jx1uBauaq_YF6pxw@mail.gmail.com>
In-Reply-To: <CAFdugan=tzj+oMMSLH0ukWHK5jF7tSjbp5jx1uBauaq_YF6pxw@mail.gmail.com>
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: Fri, 07 Dec 2012 17:12:53 -0000

On 07/12/2012 16:23, Christian Grunfeld wrote:
> 2012/12/7 Paul Smith <paul@pscs.co.uk>:
>
>> 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.
> I think you are confused about the MX on the receiver side and the A
> record of the sender !
> Mails are sent to MX for a domain but the sender has not to have a MX
> record to send !
Oh, I know that. But a reasonable test is that if a message comes from 
an email address which you cannot reply to, then the sender email 
address is probably forged. (This is how call-back verification (CBV) works)

So, if you could ONLY send to MX addresses, the OP's issue wouldn't be a 
significant problem.

Currently, I could send a message from 'bill@www.microsoft.com', and 
even though there are no MX records for 'www.microsoft.com', there is an 
'A' record, so a quick check cannot tell that the sender address is 
invalid. I can look for SPF records, but there is no SPF record for 
'www.microsoft.com', so I assume they don't use SPF, and let the message 
through.

(I could use CBV, but since that would also help with the OP's problem, 
I'll assume we aren't doing that)

If (in the past) it had been mandated that you can only send mail to an 
MX record server, then if a message comes from 'bill@www.microsoft.com', 
I can quickly tell that it is probably a bad email address, since there 
is no MX record for www.microsoft.com. This would make it easier at the 
cost of 5 seconds more configuration time per domain. Unfortunately, 
it's too late to change that now.

>> 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.
> same as above. MX for bibble.twitter.com is only to receive emails.
> Nothing prevents someone@bibble.twitter.com to send unless you put a
> TXT "v=spf1 -all" for it !
>
But it would help tremendously, without needing to add SPF records for 
each host in a domain.

This is because there would be no MX record for 'bibble.twitter.com', so 
you could assume (because of this 'new rule') that that sender email 
address is invalid, because there is no way of replying to it.

Yes, the MX is for receiving mail only, according to the SMTP standard, 
BUT if you work on the assumption that you have to be able to reply to 
the sender (which is a common enough assumption), then it ALSO has to be 
valid for sending mail.



-

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