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