Authentication by Prior Arrangement2005-05-17 03:13:36
At 11:00 PM 5/16/2005 -0400, John P Baker wrote:
I am intrigued by your proposal. However, I don't see that it will wholly address the underlying authentication problems.
The ID declaration is only the first step in an authentication process. The proposal addresses only that step, not the whole process. I'm not ready yet to submit the other pieces, but if you want to look ahead see purl.net/macquigg/email.
Sometime back, I had raised the issue of having some type of authentication method. However, I believe that we really have to look at two separate authentication points. First, let us consider a local mail server receiving mail from a directly connected remote client to whom is allocated a mailbox address on the server. In this scenario, I will argue that when the mail origination authentication extension is enabled, the local mail server should verify that the "From:" mail address specified in the message header for each message submitted from the remote client to the local mail server is a valid mail address allocated by the local mail server to that remote client (i.e., the remote client's mailbox address, or some other mail address which the local mail server recognizes as properly associated with that remote client). Second, let us consider a local mail server receiving mail from a connected remote mail server. In this scenario, I will argue that when the mail origination authentication extension is enabled, the local mail server should be required to maintain a resident list of "trusted" remote mail servers (i.e., remote mail servers who stipulate that they require that all mail message traffic must comply with the requirements of the mail origination authentication extension), and no SMTP session establishment to a "non-trusted" remote mail server should be permitted. The local mail server need only maintain a list of remote mail servers from which it receives mail message traffic directly. Mail message traffic originating in or routed through such remote mail servers should be permitted to flow freely. There may be some holes in this proposal. Let me know what you think.
I would need to see a lot more detail, something like what the other methods have written, but a quick response is that it looks like you are assuming a prior relationship between sender and receiver. The general problem is that we need to authenticate when there is no prior relationship.
I have thought a bit about how you could use a protocol separate from SMTP to establish such a relationship, but I concluded that there would be not enough advantage over doing it within the SMTP session. The idea for the separate protocol, call it RSMTP (Request for SMTP service), is to intercept all attempts to connect on port 25, and let them through only if the incoming IP is on a whitelist. To get on the whitelist, you first connect to RSMTP on a different port, then do an authentication via DNS, just like we do now with any of the proposed IP authentication methods. If the result is PASS, the IP goes on the whitelist for whatever time is allowed by the DNS record.
This assumes that a particular IP will be using one ID for all of its transmissions. It saves a few DNS queries, but it looks like the savings over one query per SMTP session is insignificant.
I'm holding RSMTP in reserve, in case there are unexpected problems adding an ID command to SMTP.
-----Original Message----- From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of David MacQuigg Sent: Sunday, May 15, 2005 21:24 To: ietf-smtp(_at_)imc(_dot_)org Subject: Sender's Declaration of Identity I've written a draft that I hope will help resolve some of the inter-operability problems for different email authentication methods. Before submitting it, I would like to make sure I haven't missed something important. The proposal is to add an ID command to the SMTP exchange, after EHLO, but before MAIL. My main concern is backward compatibility. Here are the relevant paragraphs: EHLO mailserver7.my-company.com ID mycompany.com MAIL FROM: bob(_at_)sales(_dot_)my-company(_dot_)com ... The proposed syntax will require extension of SMTP standard [RFC- 2821] and changes in current MTA software and practices. See section 7. IANA Considerations. MTA software will need to be enhanced and deployed at sites that provide email authentication. To minimize upgrade efforts these changes should be bundled with the upgrade to enable authentication. Receivers that don't recognize the ID command should return a Reply Code 500 COMMAND UNRECOGNIZED. Receivers that recognized the command, but chose to ignore it, should return 502 COMMAND UNIMPLEMENTED. [RFC-2821] section 4.2.4. Senders should ignore these errors, and proceed with the MAIL command. Backward compatibility may be an issue for receivers that do not wish to add authentication, but have been enforcing overly strict requirements on SMTP syntax, perhaps for the purpose of spam filtering. Mail with an unrecognized command should not be rejected. The complete draft is at: http://purl.net/net/macquigg/email draft-macquigg-authent-declare Comments will be appreciated. -- Dave ************************************************************ * * David MacQuigg, PhD email: david_macquigg at yahoo.com * * * IC Design Engineer phone: USA 520-721-4583 * * * * Analog Design Methodologies * * * * 9320 East Mikelyn Lane * * * * VRS Consulting, P.C. Tucson, Arizona 85710 * ************************************************************ *