Re: [Asrg] "Affiliation"

John Leslie <john@jlc.net> Mon, 22 June 2009 17:52 UTC

Return-Path: <john@jlc.net>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800D428C220 for <asrg@core3.amsl.com>; Mon, 22 Jun 2009 10:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.012
X-Spam-Level:
X-Spam-Status: No, score=-6.012 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oN8tipcs7Kl for <asrg@core3.amsl.com>; Mon, 22 Jun 2009 10:52:16 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 8E8C03A68BB for <asrg@irtf.org>; Mon, 22 Jun 2009 10:52:16 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 1BFCB33C7A; Mon, 22 Jun 2009 13:52:31 -0400 (EDT)
Date: Mon, 22 Jun 2009 13:52:31 -0400
From: John Leslie <john@jlc.net>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <20090622175230.GA57980@verdi>
References: <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <C8F0F10E-E1A4-4D25-AF20-31E3F0DB68DF@mail-abuse.org> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <FED77586-8800-4BA6-99EA-30A1D9C089B6@mail-abuse.org> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <B5252B96-F0AB-4D4A-A0DA-8314AA8E038F@mail-abuse.org> <4A3D366E.2020304@tana.it> <BD23C7D8-9E95-45CA-93F3-80F9726F889C@mail-abuse.org> <4A3F63BE.1030303@tana.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4A3F63BE.1030303@tana.it>
User-Agent: Mutt/1.4.1i
Subject: Re: [Asrg] "Affiliation"
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 22 Jun 2009 17:52:17 -0000

Alessandro Vesely <vesely@tana.it> wrote:
> Douglas Otis wrote:
> 
>> CSV was to offer a DNS record type that explicitly declared a host as 
>> being an outbound MTA.  This would not in itself prevent abuse, but would 
>> help to determine which compromised systems might be sending email and 
>> resolving which domain is administrating the MTA.
> 
> It didn't help retrieving the responsible domain, though.

   CSV intended to use the EHLO string _as_ the responsible domain, even
though it might be one of several subdomains under a single management.

> Furthermore, it didn't do ranges, thus making it laborious to deny
> sending to a bunch of hosts.

   I agree it didn't "do ranges", since it seemed appropriate to allow
separate reputations for separate EHLO names.

> In addition, CSA spec curiously had a "MAY" for an non-authorized host
> with a non-ignored target resulting in weight 0.

   That was an artifact of our being told that excessive queries for
the root "." would cause problems. The "MAY" covered how to program a
case which "should" never happen.

> However, _client._smtp.domain-name records authorizing various targets 
> would be almost equivalent to setting SPF, or MX heuristics. (I'll 
> possibly add that to the next vhlo draft.)

   I'm certainly game to do any needed updates to draft...csv...

> AFAIK, all discussions eventually reach the conclusion that the 
> receiving server does not know which domain administers the client 
> MTA.

   CSV was intended to address exactly that problem. We felt that the
vast majority of domains _could_ get by with half a dozen IP addresses
returned by a A)ddress record, and that for those that couldn't, the
ability to have separable reputations was an _advantage_. For a
reputation service, more than one reputation record per domain actively
sending (reasonable) email seemed simple enough.

> FWIW the old ietf-marid-csv-csa asserts that
> 
>   The SMTP [RFC2821] [RFC0821] protocol permits a client to declare
>   its affiliation, by asserting a domain name in the HELO or EHLO
>   announcement.
> 
> which is wrong. EHLO only allows it to declare its identity.

   It's a relief, actually, to _finally_ have a useful correction to
these drafts!

   I agree that "affiliation" was not the best choice of words in
draft-ietf-marid-csv-csa-02. "Affiliation" should be multi-valued,
with an individual sending MTA able to affiliate with multiple
entities.

   OTOH, "identity" isn't quite right either. Though it is the term
used in RFC 2821, that RFC in no sense requires that the "identity"
identify a single server.

   "Identity" would probably be better that "affiliation"; some other
term might be better than either...

> Declaring the affiliation is VHLO's raison d'?tre.

   Hmm... I still think "affiliation" deserves to be multi-valued...

--
John Leslie <john@jlc.net>