Your login name should be a few letters, eg your initials.

login names are unique within a site, though they only _have_ to be unique within one machine!

Remember to reserve all hostnames as login names, otherwise you'll get confused.

It is quite legal to allow one login-user-identity, to have two names (and passwords) in /etc/passwd, but share the same ID (and probably /home/dir). This is a trick, but it works. It allows two different people to know two different passwords, but both get the same UID number, and maybe $HOME configuration.

I use this for network rcp logins, where the local user has a real password, and normal access. The remote user has rcp login (no password from the recognised remote address/user) but a very limited range of commands that can be run remotely.

Although logins are locally registered (eg to Manchester), there has to be a unique global name that is unique within your Intranet. Then any of the main email gateways can accept email for any user.

A multi-site list, of say 20,000 people from different countries (more variety on names), will have a 98% unique name hit-rate, when you use Initials and Surname. After that try A.B.Surname.Manchester@Company, or a scheme of your choice.

Users don't like being the second person to claim a name, and getting a '2' in their name, but they get used to it, as long as it doesn't change!

If you do have a multi-site network, outside callers will probably send email to the main gateway, which will resend it to the site gateway.

Your entire comapny, will have a single huge list of unique names. You have to create and collect this list of names. Get it right before you have to change it.

Remember, you can have aliases (provided you don't mind maintaining longer lists), so it's easier to migrate between schemes, and you can re-direct unknown addresses to a postmaster who will help you avoid lost emails.

All the users, on one machine, who are allowed to start (and stop) the dial-up PPP link to the ISP, are in the dial_ppp group (for more information see Raven-Internet-Working)

All the users, who are allowed to read the accounting projects todo lists, progress reports and actual figures, are in a group whose name you have to devise.

You don't have to think of your entire network as a single machine, but doing so will allow you to freely merge and split machines as required.

	raven
	pigeon
	magpie
	dodo

	pc_gps
	pc_107
	pc_108 	alias pc_gps_laptop
	

Host names are difficult, because each LAN re-uses names like "pc_107" which is the 7'th PC on the LAN, and has IP address 192.168.140.107

PC workstations can be named "pc_gps" after the login. As well as being unique on the LAN, it is unique to the network (since login names are).

PC workstations can be named "raven" or "herron" or "ghoti" or anything. It does help to have completely unique names across the network, especially for your main servers and gateways.

After the central unique list, let groups think up their own themes. Different themes produce unique names.

Laptops, and home-dial-in's are a security nightmare, and need a bit of thought to be made convenient to use. A user might have two machines, an office machine and a laptop. When calling from home that laptop should use a different name, to get different permissions, from one that is on-site (and hopefully trusted more) when the identity of the operator is known, as well as the (apparent) identity of the machine.

	lan67		lan67.priv	Wealdstone_67
	lan140		lan140.priv 	Newcastle_140

lan140 was allocated to Newcastle. All hosts on that LAN will share the sub-domain: host.lan140.priv That tells you nothing about it being in Newcastle, or in the admin offices, but it works.

gps@trix.lan67.priv is a unique internal email address, so that's probably what you use 'behind the scenes' on your email gateways, even if you appear to aways use gps@company.co.uk. The central gateway, probably just knows gps@lan67.priv, and the local gateway knows about the trix address.

People in daily contact know that lan160 is Manchester, and that lan163 is the third floor (plus annexe ...) This will help your technicians keep control of the email routing and IP routing. It does make your internal delivery address rather boring, but you get other aliases.

The group of Manchester LANS { 140, 141, 142, 143 ... } happen to be in the same building, and lan142 has the firewall gateway and SMTP gateway, which accepts several styles of aliases.

Don't worry if the gateway has to be moved from lan142 to lan143. You will probably have to reconfigure several network configuration files, on the routers (etc), but such is life. There will always be changes, but at least now, all the external routers and cache servers are on the 143 LAN.

A good name for that gateway is Manchester2 or gw_142. Regrettably "Manchester" is too many letters, but with a few aliases, you can use what you want, and it works.

This is either the same as your fully qualified LAN name (lan67.priv), or a more sweeping alias. eg If all your company has one email address, collected by your ISP, it all gets fed to one (incoming) gateway. That gateway/postroom, then redirects the email to individual workstations, or the nearest SMTP gateway.

All incoming SMTP is delivered to a central postroom, which then forwards email to the workstations. That way the remote only has to deal with one host (the gateway), not several. However no gateway is irreplaceably unique, other gateways may appear in parallel, that could also route traffic, as required. The one you use, is the one you called.

All gateways within a domain are configured with the same data files, more or less ... non-gateways and end_pc's that wanted to act as an incoming gateway, but not have those config files, would pass the email upwards to it's nearest SMTP gateway. Leaf node workstations shouldn't accept email that will be routed, as there is no need, and this is where mail spoofing begins.

All outgoing SMTP gets queued at a central postroom, probably the same one as the incoming postroom, but possibly not. IE you can control how many parallel outgoing requests you use, but you can't predict incoming SMTP connections.

	lan57.priv
	lan58.priv
	lan63.priv

Since you will be using different LAN addresses to describe sites, you don't allocate site names. However, some organisations name all their server hosts after the town they are situated in (abbreviated).

If each LAN is a workgroup, allow them to allocate their own names. Since lan67.priv is unique, you can allow non-unique names to be used locally, then fix them up on an annual or quarterly review basis. I.E. a local name won't immediately mess up your network.

Due to the US origins of computers, and a terrible inertia to change, you will often be limited to 7-bit names, and cannot use 8-bit characters. Upper case and lower case are often the same.

In particular X400 email addresses, internet hostnames, SMPT users-names and system user-logins should be 7-bit ascii. The name held in /etc/passwd can contain 8-bit characters, as it is usually outside the actual envelope address, just a nice annotation.

With modernisation, your software might already be able to cope with 8-bit addresses, but other machine might not be able to.

These can be expensive, and dial_up connections are probably what you want. Each exterior gateway calls up the Internet every 2 hours to collect and send emails. (Or phone calls within your private Intranet, between towns).

You have to plan, to decide how often to poll, and how much delay is acceptable. Those delays may require your people to think and plan their own work, which isn't a bad thing. If someone claims they need to have 5 minute delivery times, all the time, the question is why? Such people ususally have executive powers, so the spoken question should be "what+when?".