Authentication protects the server from unauthorized use and protects the user's mailboxes from unauthorized access. At it's most basic, authentication can be simply sending the username and password in clear text. Clearly there is nothing even remotely secure about this but much depends on how likely you think it is that someone will intercept your data as it passes over the Internet. It's worth remembering that sending clear text data over the Internet has been likened to writing it on a postcard and putting it in the public post. Anyone able to see the data pass by can read it. But on the Internet we're not just talking about postal workers, it's a staggeringly big world out there with all manner of devious and malicious people. And the route taken by your mail as it crosses the Internet is often quite surprising. This applies equally to the password and the message data. Passwords often give access to much more than a mail server. And even if the password is specific to the mail system, it can be used to gain access to more than the current message.
Therefore there are two issues : protecting passwords and protecting data.
Data is protected by encrypting the message data. Ideally the data encryption will use one of the public key schemes that allow the message to be signed by the sender and only read by the intended recipient, who can in turn verify the sender's identity. Note however that encrypting the message data does not protect the user's password.
Unfortunately public key message encyption can be inconvenient.
It require the sender and recipient to agree on a
message exchange format and exchange their public keys.
In a perfect world, everyone would be doing this routinely.
But at the moment the inconvenience outweighs the value and most people
simply don't bother.
Which is why the eitha.net mail server incorporates server-to-server
If two eitha.net servers are comunicating, they negotiate an encryption process that protects both the data and the addressing information contained in the message. Many organisations will not expose their mail servers to the Internet precisely because they are concerned about message snooping. If the central site installs an eitha.net server then only this need be exposed to the Internet. The eitha.net server will handle all mail from external sources and pass it through to the internal server which can remain fully hidden from the Internet. Then, with an eitha.net server installed on the remote user's computer, all mail data between the user's computer and the central site is fully secured.
In their infinite wisdom, Microsoft don't support the public standards for authentication in the various versions of the Outlook mail client. Instead they implement their own, proprietary, authentication mechanism - Secure Password Authentication (SPA) with NTLM. The eitha.net mail server supports NTLM 1 which is reasonably secure. Outlook also supports LOGIN authentication but, since this merely disguises the password with base-64 encoding, it's far from secure.
Microsoft Exchange Server supports NTLM/SPA and so Outlook and Exchange can happily coexist. For those who don't use Exchange Server but still want to support Outlook clients the options become rather more limited. NTLM is proprietary and undocumented. Non-MS implementations can be very variables and, given the anti-MS sentiment often expressed, many servers simply avoid the issue and don't even try. We don't have an axe to grind and like to think our implementation is a good one.
Runs on Windows NT 4.0, Windows 2000, Windows XP (with some service pack requirements). And, that's any version, e.g. Windows NT 4.0 Workstation, Windows 2000 Professional, not just the Server editions. The server would normally be run as a service but can also be run as a console application for testing purposes.
For performance, the servers do asynchronous I/O using I/O completion ports and therefore will not run on Windows 95 and Windows 98.
Like it or not, Windows is ubiquitous and it's a major upheaval for a small company or home user to setup a Linux system to run Sendmail (or any 'free' server). It's also a major expense to have a dedicated server running a Server edition of Windows plus Exchange Server.
So which server do you think Microsoft uses to handle their Internet mail? telnet to mail.microsoft.co.uk port 25 and all will be revealed.
In a perfect world, we'd all be connected to the Internet full-time; ADSL, cable, whatever. But for now, many still rely on a dial-up link. And, to cut costs, they only connect intermittently. The eitha.net server provides explicit support for dial-up users:
Look for the presence of an Internet link and send any outgoing mail that may be waiting. Configurable option.
Automatically establish dial-up connection to send outgoing mail immediately. Configurable option.
All available mail for all users at a location will be automatically downloaded whenever the Internet connection is available (this is SMTP at work). So mail will be stored locally and be ready and waiting for individual users on the internal network without them having to connect to the Internet individually.
When idle, the servers are genuinely idle. They block waiting for a connection request from a client or another server. In this condition all internal processing is stopped and they use no CPU. They can be paged out by the system leaving only a very small working set in memory. For example, on a Windows 2000 system with a rather limited 32 Mbyte of RAM, both servers are paged out while idle and, after about 20 minutes, they are down to just 40K.
The server executables are small, about 250 kbytes each. Admittedly, they do use some Microsoft DLLs but you probably have these on your system already.
Ready to try it? Download.