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

Chris Lewis <clewis+ietf@mustelids.ca> Sun, 13 May 2012 15:29 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 23E4E21F852A for <asrg@ietfa.amsl.com>; Sun, 13 May 2012 08:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.252
X-Spam-Level:
X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[AWL=1.300, 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 KS3hdJiighIG for <asrg@ietfa.amsl.com>; Sun, 13 May 2012 08:29:29 -0700 (PDT)
Received: from mail.mustelids.ca (unknown [174.35.130.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B02821F8526 for <asrg@irtf.org>; Sun, 13 May 2012 08:29:29 -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 q4DFTJYe008300 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <asrg@irtf.org>; Sun, 13 May 2012 11:29:21 -0400
X-DKIM: Sendmail DKIM Filter v2.8.3 mail.mustelids.ca q4DFTJYe008300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mustelids.ca; s=default.private; t=1336922961; bh=kDDTXF5xnijdr87MhCLrVLdlmxqklXXaX8tl8Vsv1+M=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dnMIu78KFB2UF2yWW+t4V/yWd7wygw+CZB09r8hkhiGaj9nY1KFHROae5sdkWpm9Z 4ysXTMLCFB28Sm8zFPLX4xA0P0owWe4vAz+XzPLRm0HYb+aMxrdSbRI3N3P/0Jg0Sv XU369tGJG+0qB2gT/cwOx+lL6ykwfuIYeKLfWTpQ=
Message-ID: <4FAFD34F.6010301@mustelids.ca>
Date: Sun, 13 May 2012 11:29:19 -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>
In-Reply-To: <4FAF85D0.8050305@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 15:29:30 -0000

On 12-05-13 05:58 AM, Alessandro Vesely wrote:
> On Sun 13/May/2012 11:07:45 +0200 Chris Lewis wrote:
>> On 12-05-12 03:59 AM, Alessandro Vesely wrote:
>>> This probably belongs to ASRG, not only because MARF has finished, but
>>> also because a *Taxonomy of reporting targets* should be hosted
>>> somewhere, and I'm unable to think of a better place than this list's
>>> wiki.
>>>
>>> Opinions?
>>
>> It would be nice if it could be made usable.
>>
>> This would tend to make a large organization having all of their servers
>> helo exactly the same way, which flies in the face of industry BCP (eg:
>> MAAWG), and even if it wasn't specifically RFC5321-illegal, clearly
>> violates its intent.
> 
> I see nothing wrong if an organization uses the same helo name for all
> its mailouts.  A helo name does not have to be a label of any DNS
> record. 

Uh what?

RFC5321:

Section 4.1.1.1:

   These commands are used to identify the SMTP client to the SMTP
   server.  The argument clause contains the fully-qualified domain name
   of the SMTP client, if one is available.  In situations in which the
   SMTP client system does not have a meaningful domain name (e.g., when
   its address is dynamically allocated and no reverse mapping record is
   available), the client SHOULD send an address literal (see
   Section 4.1.3).

   ...

   The SMTP server identifies itself to the SMTP client in the
   connection greeting reply and in the response to this command.

Yeah, I suppose you could make all your outbounds have the same name (up
to whatever limit DNS imposes), but clearly this violates the intent.

And it's also very explicitly counter to industry practises/BCP.