Authentication by Prior Arrangement

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.
--
Dave

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