[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mail Server Registries and Foreign Sender Authentication: A Proposal
On Mar 28, 2007, at 7:52 PM, Jeff Macdonald wrote:
On Wed, Mar 28, 2007 at 07:42:51AM -0600, Randy Smith wrote:
Since OpenID is built to allow authentication, among other things,
against 3rd party systems, it seems like an excellent way to allow
and recipient server to authenticate all users who wish to send or
deliver mail with their server.
Randy, could you use OpenID terms in describing your SMTP extension?
I don't think an SMTP extension is required. Explaining follows:
I'm having trouble understanding how this would work from your
description in your blog. Adding PGP seems to add additional
overhead for what OpenID provides (unless I'm totally mis-
understanding OpenID). Here are what I think are some of the
relevant terms:
MTA terms:
C: Sending MTA - sending message
S: Receiving MTA - receiving message
There are OpenID extensions proposed to allow the exchange of public
keys related to an Identity.
http://openid.net/specs/openid-service-key-discovery-1_0-01.html
There are OpenID extensions proposed for email-addresses such as:
http://www.sappenin.com/openid/ext/oet/openid-email-transform-
extension-1_0.html
http://blog.phpbb.cc/2007/02/04/smtp-service-extension-for-yadis-
discovery/
Now imagine an extension to DKIM, OpenPGP, or S/MIME where a query
method is defined for OpenID.
This would allow senders to sign messages and allow recipients to
verify using extensions proposed for identifying email-addresses
using OpenID.
This would not require any change to SMTP, but would require a minor
change to DKIM, OpenPGP, or S/MIME. But it gets better...
OpenID terms:
Consumer - wants proof
End User - wants to prove their identity to Consumer
User Agent - End user web browser
Add:
Sender - wants proof of recipient and secure receipt for web
exchanged information.
It would also be possible to forgo any public-key cryptography
related to the message by using standardized conventions for where
the web exchanged information is placed with regard to a specific
identity.
Perhaps a subdomain of OMail.<email-domain> could work where the
local-part is normalized within the first path. Sub-path components
could function as the message-ID, for example.
When a message is exchanged using something like BURL, the identity
of the sender can be deduced from the embedded URI. Nothing else is
needed as it would be expected this location would be identified
using SSL certs when related to commerce. It would be rather
difficult to forge such messages when the entire message body is
found via the link. The web server could then use OpenID to ensure
only the intended recipient receives the message. When done using
HTTPS, email becomes secure without use of encrypted messages.
OpenID is already establishing whitelists to protect blogs. This
effort could extend to whitelisting email that is sent using such
conventions.
I is the Identity server
Say there is a new ESMTP keyword, OPENID. Here's a breakdown loosely
following your example:
C->S: connects
S->C: banner
C->S: ehlo
S->C: OPENID is returned along with whatever else
There could be extensions made in the HTTP header structures found in
OMail subdomain that lists the root names of all "authorized" SMTP
clients, for example. I doubt this would be needed once only BURL
style messages are adopted as an exclusive mode of exchange. This
will take awhile.
C->S: OPENID <url identifier>
S: <becomes a Consumer>
S->I: <fetches url identifier: Section 3.3 of OpenID spec>
S->C: 250 <identity provider URL: Section 3.5 of OpenID spec>
Possible, but this would require a lengthy adoption process. There
could be a convention used for the SMTP client host-name that also
signals use of an authorization field found within the OMail
subdomain. This convention might look something like:
EHLO:
OMAIL-<host-name>.<email-domain>.
S->I: associate with identity provider? Section 4.1.x
C->I: go to identity provider? Section 4.2.x
C->S: OPENID CRED <stuff from 4.2.2.3?>
S->C: 250 Ok Credentials are OK
<continue with normal SMTP>
I may of abused SMTP extensions in this example (re: OPENID CRED).
An extension could also be used. Which ever shows the least
resistance will likely be the best choice.
-Doug