RE: [Asrg] RMX and aliases

"Eric D. Williams" <eric@infobro.com> Tue, 06 May 2003 23:49 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14449 for <asrg-archive@odin.ietf.org>; Tue, 6 May 2003 19:49:38 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46NwLF09331 for asrg-archive@odin.ietf.org; Tue, 6 May 2003 19:58:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46NwL809328 for <asrg-web-archive@optimus.ietf.org>; Tue, 6 May 2003 19:58:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14422; Tue, 6 May 2003 19:49:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DCDJ-0003Xw-00; Tue, 06 May 2003 19:51:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DCDJ-0003Xt-00; Tue, 06 May 2003 19:51:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Nv1809265; Tue, 6 May 2003 19:57:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Nuf809240 for <asrg@optimus.ietf.org>; Tue, 6 May 2003 19:56:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14389 for <asrg@ietf.org>; Tue, 6 May 2003 19:47:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DCBh-0003XP-00 for asrg@ietf.org; Tue, 06 May 2003 19:49:33 -0400
Received: from black.infobro.com ([63.71.25.39] helo=infobro.com) by ietf-mx with smtp (Exim 4.12) id 19DCBh-0003XC-00 for asrg@ietf.org; Tue, 06 May 2003 19:49:33 -0400
Received: from red (unverified [207.199.136.153]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id <B0002399664@infobro.com>; Tue, 06 May 2003 19:49:23 -0400
Received: by localhost with Microsoft MAPI; Tue, 6 May 2003 19:49:30 -0400
Message-ID: <01C31408.9C0B8380.eric@infobro.com>
From: "Eric D. Williams" <eric@infobro.com>
To: 'Alan DeKok' <aland@freeradius.org>, "asrg@ietf.org" <asrg@ietf.org>
Subject: RE: [Asrg] RMX and aliases
Organization: Information Brokers, Inc.
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Tue, 06 May 2003 19:47:35 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

This to me represent an evolution of a framework for dealing with 'spam'. Why? 
because the now the addition of consent as an element in the 'anti-spam' 
architecture is (to me) more workable.  The universe of systems needing consent 
may be reduced by RMX and that may allow consent proposals to be more precise.

-e

On Tuesday, May 06, 2003 5:27 PM, Alan DeKok [SMTP:aland@freeradius.org] wrote:
>   In keeping with the charter of this group, I will now discuss
> consent.  Within the context of SMTP, RMX allows the originating
> domain and MTA do explicitely publish their consentual relationship.
> In this case, if envelope sender re-writing is done, we can use RMX to
> establish that the domain 'example.com' consented to have that
> particular MTA send an email with a body "from" of 'example-2.com'.
>
>   In this case, the answers to questions 1 and 2 stay the same.  The
> answer to question 3 now becomes an explicit "yes, consent exists."
> The answer to question 4 becomes "the originating MTA is not an open
> relay or 'owned' machine, unless the attacker has additionally taken
> over the DNS records."
>
>
>   So the solution to .forward files, is to have the forwarding MTA
> explicitely declare it's consent to forwarding messages for another
> domain.
>
>   In contrast, the simple act of forwarding messages tells you
> nothing about consent, other than that forwarding is occuring.

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg