[Asrg] Re: Reverse DNS

Selby Hatch <selby_hatch@azza.com> Thu, 19 June 2003 17:50 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 NAA04494 for <asrg-archive@odin.ietf.org>; Thu, 19 Jun 2003 13:50:32 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JHo4O05456 for asrg-archive@odin.ietf.org; Thu, 19 Jun 2003 13:50:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3Xw-0001Pv-Dv for asrg-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 13:50:04 -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 NAA04463; Thu, 19 Jun 2003 13:50:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Vd-0000Ea-00; Thu, 19 Jun 2003 13:47:41 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T3Vc-0000EX-00; Thu, 19 Jun 2003 13:47:40 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3Xs-0001O2-Rf; Thu, 19 Jun 2003 13:50:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3Xj-0001Nf-PJ for asrg@optimus.ietf.org; Thu, 19 Jun 2003 13:49:51 -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 NAA04439 for <Asrg@ietf.org>; Thu, 19 Jun 2003 13:49:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3VQ-0000Dz-00 for Asrg@ietf.org; Thu, 19 Jun 2003 13:47:28 -0400
Received: from cpe-24-221-253-78.ut.sprintbbd.net ([24.221.253.78] helo=mail.azza.com) by ietf-mx with esmtp (Exim 4.12) id 19T3VP-0000Ds-00 for Asrg@ietf.org; Thu, 19 Jun 2003 13:47:28 -0400
Received: from ([192.168.0.1] helo=azza.com) by mail.azza.com with esmtp (Exim 3.33 #5) id 19T3Xf-0004Rh-00 for Asrg@ietf.org; Thu, 19 Jun 2003 11:49:47 -0600
Message-ID: <3EF1F7DE.9070305@azza.com>
From: Selby Hatch <selby_hatch@azza.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Asrg@ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Asrg] Re: Reverse DNS
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: Thu, 19 Jun 2003 11:50:22 -0600
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

There are other ways to authenticate an email with a server. I have
suggested one such method. It requires no DNS and could be used for
static and dynamic IP addresses. If you have the IP address of the
originating email, it is possible to trace that back to some entity even
if it's dialup. The method is found at:

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg05393.html

and goes as follows:

Sender authentication should be applied. A header called Sender-Auth or
Sender-Verification will be inserted into the message by the sending
server. It would consist of a delimited string containing the IP
address, server identification, and a timestamp. The string would be
preceded by the result of a function that was applied to that string as
it was sent by the originating server. A delimiter would separate the
function result from the string. The function would be implemented by
the server administrator and would be unique for that server or set of
servers.

A protocol would be employed such that a receiving server could request
that the originating server verify that the Sender-Auth header is
consistent. The originating server would be required to apply it's
function to the string as sent by the requesting server and then return
the result. The receiving server would compare the returned function
result with the result in the Sender-Auth header and if they match, the
sending server is authentic.





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