Downloads

SMTP Authentication

Introduction

This describes how to do the dirty deed of setting up sendmail to allow password authentication on SuSE 7.0 and 7.1. It may well work on other distributions and packages. The short of it is that you need to compile sendmail with different options and set it up, but happily, there is a package which includes these settings for us.

Packages

Uninstall sendmail, and install sendmail-tls which is linked to the Cyrus-SASL library. Alternatively, recompile sendmail with SASL support linked in (or rpm --rebuild the SuSE 7.1 sendmail-tls.src.rpm and whatever else you need). Also install Cyrus-SASL (requires tcl, gdb and pam, usually). 
	rpm -e sendmail
	rpm -i /suse/CD2/suse/sec2/sendmail-tls.rpm \
	       /suse/CD1/suse/tcl1/tcl.rpm \
	       /suse/CD1/suse/sec1/cyrus-sasl.rpm

It's probably a good idea to backup /etc/mail before you do this, since uninstalling sendmail and installing over it may or may not do amazing things here. Probably it will nerf your system. (If you are doing this on Redhat 6.0, you will also need to upgrade libc. You were warned. Rather rebuild from the source distribution ... I think.)

Configuration

Add to linux.mc the lines (and I assume that you have done the requisite perl -p -i -e 's/^SENDMAIL_TYPE.*/SENDMAIL_TYPE=no/' /etc/rc.config.d/sendmail.rc.config ... see /etc/mail/README) 
	TRUST_AUTH_MECH(`GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5 LOGIN DPA NTLM')
	define(`confAUTH_MECHANISMS',`GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5 LOGIN DPA NTLM')
	define(`confDEF_AUTH_INFO', `/etc/mail/auth')dnl
	define(`confLOG_LEVEL',`10')dnl
If you are wondering where or what linux.mc is, you are reading the wrong documentation.

You can be facist and add this too--allow only AUTHENTICATED mail -- this would mean that nobody will send you mail: 

	FEATURE(`no_default_msa')dnl turn off default entry for MSA
	DAEMON_OPTIONS(`Port=587, Name=MSA, M=E')dnl

/etc/mail/auth is the login parameters that sendmail tries to use if some remote server asks it for authentication. If you put something like this in there, it kinda works: 

	admin
	admin
	afo2q2u3h4jtiuhirhgiuhsnckajns
	realm
These are the credentials used by sendmail when it sends mail. Not sure if this is necessary. sendmail 8.10 has a bug, so don't use it. The first two are the user id and the auth id. The third is a password. The fourth is the `realm' (This all means something)

Creating users

Create user accounts like this: 
	echo password | saslpasswd -p -c user -p -u realm
`password' is the password, `user' is the user name, and `realm' is the realm. The first time you do it you will get a message `generic failure', as it creates /etc/sasldb. Don't worry, but do run the command again. Check that it worked with 
	sasldblistusers
Don't feel that you have to use user names and passwords which match anything else on your system -- these passwords are sent in the clear over the network.

Client side

You also need to configure the mail client to send the authentication information: 
	[x] My server requires authentication
	User name: user@realm
	Password: password
	Use SSL: No
That should do it. The `@' in the user name only works because the Cyrus SASL library has a hack for people who don't support a non-default `realm' (like outlook, it seems). If your mail client has a `realm', you can either use it, or leave it blank and use the hack above.

Final refinement

Outlook does not send a realm, but it seems that the default realm is the server name -- hostname -f. If you set `realm' to the exact server name, then you can convince sendmail to send your outlook express mails without saying user@realm (the server name is case sensitive here): 
	echo password | saslpasswd -p -c user -p -u smtp.acme.widgets.com
	echo password | saslpasswd -p -c user -p -u `hostname -f`
And in outlook: 
	SMTP server: smtp.acme.widgets.com
	[x] My server requires authentication
	User name: user
	Password: password
	Use SSL: No

Debugging

If you need to test the whole lot yourself, you need to mime encode the user name and password, and then you can do something like this: 
	# echo -n 'smtpusername' | mimencode
	c210cHVzZXJuYW1l
	# echo -n 'smtppassword@realm' | mimencode
	c210cHBhc3N3b3JkQHJlYWxt
That tells us what the mimencoded version of the user name and password is. Let's try it: 
	# telnet localhost 25
	Trying 127.0.0.1...
	Connected to localhost.
	Escape character is '^]'.
	220 localhost.localdomain
	EHLO THERE
	250-localhost.localdomain Hello localhost [127.0.0.1], pleased to meet you
	250-ENHANCEDSTATUSCODES
	250-8BITMIME
	250-SIZE 2000000
	250-DSN
	250-ONEX
	250-XUSR
	250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN
	250 HELP
	AUTH LOGIN
	334 VXNlcm5hbWU6
	c210cHVzZXJuYW1l
	334 UGFzc3dvcmQ6
	c210cHBhc3N3b3JkQHJlYWxt
	500 5.7.0 authentication failed
Why didn't it work for me? Well, it's just an example. Now what do those lines prefixed with `334' mean? It's actually just plain text, but mime encoded: 
	# echo -n 'VXNlcm5hbWU6' | mimencode -u ; echo
	# echo -n 'UGFzc3dvcmQ6' | mimencode -u ; echo
Real world example of why `AUTH LOGIN' is not secure: I set this up for a client, and they said it rejected their user name and password. I sniffed the user name and password they were using with ngrep, and discovered that they don't spell things the same way as I do (using mimencode -u as above).

Acknowledgements