[Asrg] Re: RMX evaluation
Vernon Schryver <vjs@calcite.rhyolite.com> Thu, 08 May 2003 17:21 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 NAA00701 for <asrg-archive@odin.ietf.org>; Thu, 8 May 2003 13:21:20 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48HUrJ32663 for asrg-archive@odin.ietf.org; Thu, 8 May 2003 13:30:53 -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 h48HUr832660 for <asrg-web-archive@optimus.ietf.org>; Thu, 8 May 2003 13:30:53 -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 NAA00686; Thu, 8 May 2003 13:20:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dp6a-0004TI-00; Thu, 08 May 2003 13:22:52 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Dp6a-0004TF-00; Thu, 08 May 2003 13:22:52 -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 h48HSj832557; Thu, 8 May 2003 13:28:45 -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 h48HR3832507 for <asrg@optimus.ietf.org>; Thu, 8 May 2003 13:27:03 -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 NAA00580 for <asrg@ietf.org>; Thu, 8 May 2003 13:17:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dp2s-0004Ri-00 for asrg@ietf.org; Thu, 08 May 2003 13:19:02 -0400
Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx with esmtp (Exim 4.12) id 19Dp2r-0004Rf-00 for asrg@ietf.org; Thu, 08 May 2003 13:19:01 -0400
Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h48HJsVT029163 env-from <vjs>; Thu, 8 May 2003 11:19:54 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305081719.h48HJsVT029163@calcite.rhyolite.com>
To: asrg@ietf.org
Cc: vixie@vix.com
References: <B1F08F445F370846AB7BEE424365F00DCBF6EE@ctxchg.ciphertrust.com>
Subject: [Asrg] Re: RMX evaluation
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, 08 May 2003 11:19:54 -0600
> From: Paul Judge <paul.judge@ciphertrust.com> > ... > Vernon, can you post Vixie's suggestions that you referring to so that > everyone is aware of them. Can you also explain in more detail the > difference between those and RMX to show why you say that it is simpler. > ... Paul Vixie's suggestion is differs from the common and old mechanism of rejecting mail with Mail_From values of free providers when the SMTP client is not an MTA of the free provider. RMX and Paul's notion allow the owner of a sender domain to authorize not only SMTP clients with names related to the sender domain but also SMTP clients in a small number of additional domain names to also send mail nominally from the sender domain. (The number is small because of the limited size of DNS/UDP packets.) I searched for but failed to find Paul Vixie's short mail message describing the idea. My recollection and perhaps slight elaboration of it is: To determine if an STMP client is authorized to send mail for the sender domain name in the envelope Mail_From field 1. an SMTP server first compares the reverse DNS name of the SMTP client with the sender domain. If they match by the usual rules (e.g. user@example.com matches mailhost.example.com), then the STMP client is authorized. To prevent forgery, the usual reverse-forward DNS check is made. 2. Otherwise the SMTP server searches for MX RRs for the sender domain. The IP address of the SMTP client is then compared to the list of IP address eventually obtained for the names in the MX RRs. (As usual and described in RFC 2821, if no MX RRs are found, the IP address of A RRs, if any, are used.) If the SMTP client's IP address is a member of this list, then the SMTP client is authorized. 3. Otherwise the SMTP server checks the list of MX RRs for a record with the preference 65391. If such a record exists, the SMTP server knows that sender domain is participating in this standard, the list of MX RRs contains a complete list of the SMTP clients authorized to send mail for the sender domain, and that the SMTP server is unauthorized. The SMTP server therefore rejects the message. 4. Otherwise the sender domain is not particpating and the SMTP server does not know whether the SMTP client is authorized to send the message. The SMTP server procedes according to local policy and other standards. Note that: - An authorized SMTP client need not be an SMTP server. While its IP address will found by other SMTP clients looking for an SMTP server for the domain, its preference will be numerically higher than all working SMTP servers. Only when all other SMTP servers are also not working will SMTP clients try to send to it. They will immediately receive and ICMP Port Unreachable and give up. - Most mail will already pass this test, because it is sent from SMTP clients that are also SMTP servers for the sender domain. - Step #1 is currently used. Many SMTP servers, albeit a small fraction of all SMTP servers, reject mail that does not satisfy the test in step #1. - The preference 65391 is choosen to be probably not currently used in any MX RR in the Internet. - This scheme is better than the RMX proposal because it has achieves the same goal, does not require the standardization and implementation of a new DNS RR in DNS server software and MTAs. It requires only small changes in system administration conventions and modest changes in MTAs. - I do not like this scheme, because I do not agree with the goal of forcing people to use the same going as incoming ISPs. Vernon Schryver vjs@rhyolite.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg
- [Asrg] RMX evaluation (was RE: Is there anything … Paul Judge
- [Asrg] Re: RMX evaluation Vernon Schryver
- Re: [Asrg] Re: RMX evaluation Alan DeKok
- Re: [Asrg] Re: RMX evaluation Hadmut Danisch
- Re: [Asrg] Re: RMX evaluation J C Lawrence
- Re: [Asrg] RMX evaluation (was RE: Is there anyth… Hadmut Danisch
- Re: [Asrg] Re: RMX evaluation Vernon Schryver
- Re: [Asrg] RMX evaluation (was RE: Is there anyth… Alan DeKok
- Re: [Asrg] Re: RMX evaluation Vernon Schryver
- Re: [Asrg] RMX evaluation (Monkeys vs. RMX) Hadmut Danisch
- Re: [Asrg] Re: RMX evaluation Hadmut Danisch
- RE: [Asrg] RMX evaluation (was RE: Is there anyth… Paul Judge
- Re: [Asrg] RMX evaluation (was RE: Is there anyth… Hadmut Danisch
- Re: [Asrg] Re: RMX evaluation Mike Rubel
- Re: [Asrg] RMX evaluation (was RE: Is there anyth… Matt Sergeant
- Re: [Asrg] RMX evaluation (was RE: Is there anyth… Hadmut Danisch