Authenticated SMTP with Sun JES Messenger
When nomadic users would like to send emails via their organization’s smtp server, a problem arises around smtp. The pop and imap protocols are well suited for remote users and can be secured by using either ssl or ipsec connections.
With smtp however, a remote smtp session can be simply be used to send emails with. The reason being that the remote user is not identified as a local – domain user. If that same user would initiate an smtp session and would like to send an email to an email account outside the local mail domain, then the email server would perform an open relay function which should not be allowed by any properly configured server.
So how can the roaming user use a remote smtp connection to it’s own smtp server and still be seen as a local user? The answer to this comes in a few ways:
-either the user uses a vpn tunnel which makes the client email seem to originate from the local – email server’s network. This requires vpn administration however and optional client software. Besides that the client will not have ‘total’ access to the organization’s local network.
-the client uses an old email – client facility called “pop before smtp”. This will not work for imap however
-authenticated smtp: this feature enables the server to authenticate the remote client so that the server for this one connection will allow an open relay. Due to the security sensitivies involved, it’s good practice to encrypt this connection via ssl or so.
Let’s first check that Open Relaying is not allowed:
# telnet mailserver 25
220 zone-mail2.ulimit.nl — Server ESMTP (Sun Java(tm) System Messaging Server 6.3-0.15 (built Feb 9 2007))
mail from: test@mydomain.nl
250 2.5.0 Address Ok.
rcpt to: john@yahoo.com
530 5.7.1 Relaying not allowed: john@yahoo.com
The incomming tcp_local channel keywords for this are to be found in imta.cnf and are:
! tcp_local
tcp_local smtp mx single_sys remotehost inner switchchannel identnonenumeric subdirs 20 maxjobs 7 pool SMTP_POOL maytlsserver maysaslserver saslswitchchannel tcp_auth missingrecipientpolicy 0 loopcheck disableetrn
tcp-daemon
and:
! tcp_auth
tcp_auth smtp mx single_sys mustsaslserver missingrecipientpolicy 4
tcp_auth-daemon
Meanings: maysaslserver and maytlsserver allow clients to attempt to use sasl authentication.
saslswitchchannel mean that incomming sasl – authentication attempts will be switched to a different channel, in this case “tcp_auth”.
As you can see from the channel configuration above, smtp with tls authentication is enabled by default. The user can – once a TLS connection has been established, use the AUTH feature of (e)smtp.
To see the AUTH – SMTP feature without SSL:
# telnet mailserver 25
Connected to mailserver.
Escape character is ‘^]’.
220 server1.mycompany.com — Server ESMTP (Sun Java(tm) System Messaging Server 6.3-0.15 (built Feb 9 2007))
ehlo note that helo is for smtp and ehlo is for extended smtp = esmtp
[…]
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=LOGIN
Important Note: here the plain login and password MUST be in Base64 encoded text!
So let’s convert this:
$ printf ‘john�john0mysecret’ | mmencode
dXNlcm5hbWUAcGltLm5sAGJhc2hvMTIz
Or in Perl:
$ perl -MMIME::Base64 -e ‘print encode_base64(“john�john�mysecret”);’
dXNlcm5hbWUAcGltLm5sAGJhc2hvMTIz
Now let’s try to authenticate:
AUTH PLAIN dXNlcm5hbWUAcGltLm5sAGJhc2hvMTIz
235 2.7.0 PLAIN authentication successful.
Now relaying should work:
AUTH PLAIN cGltAHBpbQBiYXNobzEyMw==
235 2.7.0 PLAIN authentication successful.
mail from: test@mydomain.nl
250 2.5.0 Address Ok.
rcpt to: john@yahoo.com
250 2.1.5 john@yahoo.com OK.
Now once Authenticated SMTP works, let’s combine this with an SSL connection. In order to start an SSL connection manually to the smtp server, use:
$ openssl s_client -starttls smtp -crlf -connect server1@mycompany.com:25
CONNECTED(00000003)
depth=0 /OU=Domain Control Validated/OU=PositiveSSL/CN=mycompany.coml
[…]
250-STARTTLS
250-AUTH PLAIN LOGIN
And again we can use:
AUTH PLAIN dXNlcm5hbWUAcGltLm5sAGJhc2hvMTIz
235 2.7.0 PLAIN authentication successful.
This has proven that Authenticated SMTP over an SSL connection works!
Let’s see if we can now disable the use of authenticated SMTP WITHOUT SSL encryption, for security purposes. The channel involved is tcp_local. Here we will change ‘maytlsserver’ to ‘musttlsserver’.
Recompile the imsimta configuration:
/opt/SUNWmsgsr/sbin # ./imsimta cnbuild
AFTER a restart, a SMTP AUTH attempt will result in:
AUTH PLAIN cGltAHBpbQBiYXNobzEyMw==
530 5.7.0 No STARTTLS command has been given.
This implies however, ALL incomming email will need to use SSL at the moment and will get bounced!
“Connected to 83.160.130.4 but sender was rejected.
Remote host said: 530 5.7.0 No STARTTLS command has been given.”
The reason being: “musttlsserver” means that the MTA Smtp server will advertise support for the STARTTLS extention and will INSIST upon TLS when receiving incomming messages and will NOT accept messages from clients that do not successfully negotiate TLS use. [283 Administration Manual]
So for this document, we’ll use the following:
“musttlsclient” and “maytlsserver” in order to send un-authenticated mail to other (Internet) SMTP servers.
