Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

On 3/25/07, Hector Santos <[email protected]> wrote:
> Randy Smith wrote:
> >
> > Greetings,
> >
> > I was recently discussing various issues surrounding email with a
> > coworker and had a couple of ideas for authentication systems that I
> > would like to get some feedback on. You can read my ideas at
> > http://perlstalker.blogspot.com/2007/03/mail-server-registries-and-foreign.html.
> >
> >
> > As I said, I'm looking for feedback. Are these ideas worth pursuing or
> > am I barking up the wrong tree?
> >
> > Thank you for your time.
>
>
> In my opinion, you are not barking up the wrong tree, but the
> "inevitable tree."   Its not a new concept, but a concept we have moved
> away from in the name of having an open anonymous system. But we seem to
> be reinventing ourselves to go back to this direction.

The biggest problem, IMO, is not the open system but the anonymous
one. One reason spam works so well is that its so very easy to lie
about who the sender is. I don't think there's any reason why a mail
admin couldn't setup their own registration server but as the
recipient, I need to have some way of knowing that I can trust the
registry, hence the web of trust built around server keys.

>
> In short, you are simply talking about a client/server negotiation
> handshake stage.  In my opinion, maybe not in our "engineering" life
> time, this is will be the ultimate method of client/server operations.
> The anonymous sender will be "thing" of the past.
>
[snip: fidonet history]
>
> In any case, conceptually, we are talking about the same type of direction.
>
>    - Registration of servers and clients within some "controlled
>      and centralized" nodelist/DNS system.
>
>    - It will confronted with the same Legacy issues of supporting
>      legitimate clients that might not part of the "controlled network."
>
>      As with Fidonet, this is where you will have the major
>      uphill battle. The IETF is dead set against breaking the
>      the current open network integrity of the system.  Legacy
>      software must be supported.
>
> I happen to agree. Legacy software must be supported, however, I am also
> open to introducing a ZMH like idea where systems are allowed to
> designate "open" and "closed" times for legacy systems.

What I'm thinking of would be an extension to SMTP rather than an
entirely new system. As the main admin for an ISP, the last thing I
want to do is build a second system to handle a new protocol that
hardly anyone uses (at least, until the rest of the Net migrated). I
think the hand shake could be complete wrapped within the SMTP
conversation.

>
> Based on these experiences, I had started a IETF draft awhile back that
> basically defined "SERVER ATTRIBUTES" records that clients will use to
> obtain server attributes that will cover these client/server negotiation
> parameters.   I happen to believe the idea will be eventually be a major
> part of the system, in some form or another and we are beginning to
> touch based with it with DKIM and its SSP ideas.  Also look at the
> growth of SIP communications.  It is all going (back) in this direction.

It may be necessary to add a capabilities keyword similar to IMAP or
specify that the EHLO response include a list of supported keywords.

Thank you for taking the time to respond to my ramblings. :-)

>
> --
> Hector Santos/CTO
> Santronics Software, Inc.
>
>
>
>


-- 
Randy Smith
http://vuser.org/
http://perlstalker.vuser.org/