[Top] [All Lists]

Authentication by Prior Arrangement

2005-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

Sometime back, I had raised the issue of having some type of authentication

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

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

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:

    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: draft-macquigg-authent-declare

Comments will be appreciated.


************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *