I am intrigued by your proposal.
However, I don't see that it will wholly address the underlying
authentication problems.
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.
John P Baker
Software Engineer
-----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 *
************************************************************ *