Re: Any Comments on the Draft?

[Dave Cridland <dwd@xxxxxxxxxxxxxxx>]

// 1)  I'd prefer to see the whole solution provided on the SMTP port than =
// on some other port.  Admittedly if someone is _only_ going to provide =
// on-demand email service a separate port for a specialized service might =
// make sense, but in reality anyone who's providing on-demand service is =
// also going to be providing regular SMTP service.  Just making this part =
// of SMTP seems to make more sense to me.

I think I'd prefer to see SMTP unchanged, and add in a seperate host 
authentication protocol, and then called by the provider SMTP server on the 
customer host.

In other words, I'd prefer to see a seperate protocol, which can be reused in 
other areas as a building block. So typically, just as many mailservers use 
the Ident protocol to discover user information about the connection, they 
would use the HostIdent (or whatever) protocol to detirmine in a secure manner 
which host it is talking to.

The only major differences between some method of authentication in-built to 
SMTP and my suggestions are that:

1) The protocol is distinct from SMTP.
2) The protocol requires a seperate server running on the customer's host.
3) The protocol can be used for tasks other than SMTP easily.

This could then in theory be used for numerous other things. Though quite 
what, I'll admit to not being able to guess right now, other than the vanity 
of a hostname that follows you around, somewhat like the dyn.ml.org domain.

It's also the one requiring minimum changes. The customer's SMTP server 
requires no changes at all, in fact, and the provider's server only requires 
minimum additional changes - an extra library and a call into it, effectively.

Consider the following scenario:

Provider runs a typical setup - UNIX, sendmail.

Customer runs another typical setup - NT, Exchange.

To change from static IP to dynamic IP using the seperate host authentication 
protocol, the only changes are:

1) Provider's sendmail needs to be patched. Addition of client side host id 
protocol library, and call into it.

2) Customer requires addition of one NT service - the host id server.

If the authentication etc is integrated into SMTP, then the following changes 
are required:

1) Provider's sendmail need to be patched, with much the same work as before.

2) Customer needs to buy a brand new version of Exchange.

I think that my method seems a lot simpler.

Even considering it from a purely marketing point of view, it makes sense to 
minimise the change required on the customer side. I don't particularly mind, 
as an ISP, changing the mailserver again, but a customer is likely to be a lot 
more nervous about it.

With the host authentication as a seperate system from the customer's 
viewpoint, it doesn't matter if they use Exchange, Worldserver, or any other 
SMTP server which supports static IP dialup usage.

Even the dreaded finger scripting would be left unchanged, so SMTP servers 
which don't support ETRN can be used.

// 2)  I don't see the need for specifying the domains to be turned on the =
// TURN command.  Since some out-of-band mechanism is required to link =
// authenticated user IDs and the domains they're allowed to TURN, simply =
// having the server keep a list of domains to TURN for each ID would be =
// simpler.  With no arguments on the TURN command, adding a domain to the =
// list for a given ID only requires updating the ISP's configuration; with =
// domain arguments, both the ISP and the customer would need to update =
// their configuration in synch.

Agreed. Once the host is identified to be the correct one by some method, which may or may not be part of SMTP, then TURN may as well act as advertised, which means, without any arguments, whether the customer has need for configuration or not. Though as Randall Gellens says, it's invariably unsupported, and often difficult to implement with many systems.

ETRN, by the same argument, would need a domain specified.

Dave.
-- 
Dave Cridland -- Network Systems Manager -- Cerbernet Ltd