It has not been possible to provide a local message submission service (an SMTP server for email) for members of the University who are accessing the local network from some other Internet Service Provider (ISP). Current recommendations (prior to the release of this new service) for such people is that they configure their email software to use the SMTP servers of their ISPs.
The reason for the difficulty is that given message submission does not require any user authentication, it is all too easy for "open" servers to be misused as "junk mail relays".
Recent developments mean that we are now able to offer such a service without the risk of opening ourselves to abuse.
RFC 2554, SMTP Service Extension for Authentication, defines an SMTP service extension (ESMTP) whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions.
In the local context, the authentication supplied will be the UOB username and password.
RFC 2487, SMTP Service Extension for Secure SMTP over TLS, describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications.
(Transport-layer security is defined in RFC 2246, The TLS Protocol)
Given that the authentication information we are using is the UOB username and password, it is critical that these are protected from prying eyes.
Do note, however, that this service will not, of itself, provide end to end privacy, nor authentication (in the sense that you can be certain that messages sent using the service are really from whom they say they are from). What it will do, in a nutshell, is restrict message submission to authenticated users only and protect usernames and passwords in transit.
To use the service, your mail program must have support for both authenticated message submission and SSL/TLS. Unfortunately not many mail programs can meet these requirements at present, although increasing numbers can be expected to introduce support in the near future.
Recent versions of Netscape can. I'm not exactly sure which versions but at least 4.61 and beyond.
Outlook 2000 and Outlook Express 6.0 also can, but not previous versions of Outlook (nor Outlook Express).
Mulberry version 2.0.5 introduced SSL/TLS support (not available for the 68K Macintosh at the time of writing).
Assuming you already have Netscape configured for mail, do the following to reconfigure it to use the service:
Netscape is now reconfigured to use the service (no need to restart it).
Mulberry is now reconfigured to use the service (no need to restart it).
Outlook 2000 (and above) and Outlook Express 6.0 (and above) can both be configured to use the SAMS service. In either case:
Outlook 2000 is now reconfigured to use the service (no need to restart it).
No, you can use it from anywhere. This means that you won't need to reconfigure your mail client depending on where you are.
If you're having problems when working from off-site, it may well be because your ISP is blocking outgoing connections to "smtp" ports. You should be able to get around this by reconfiguring Mulberry to use the standard "message submission" port instead of the "smtp" port. To do this, reconfigure your SMTP server changing it from smtp-auth.bris.ac.uk to smtp-auth.bris.ac.uk:587
Alternatively, anti-virus and/ or firewalling software installed on your computer may cause you problems.
If Norton Anti-Virus is configured to scan outgoing mail, for example, you might get the failure message "SMTP server 'STARTTLS' command ref: 500 unsupported command" or "SMTP Server 'STARTTLS' command reply 454 TLS not available due to temporary reason" when you try to send your mail through the service. The workaround in this case is to disable the scanning of outgoing mail.