SendMail authentication question

14 posts / 0 new
Last post
#1 Thu, 09/06/2007 - 07:19
DanLong

SendMail authentication question

Howdy,

Has anyone figured out a clean SMTP authentication for sendmail? I can't keep opening up relays for every ISP or bandwidth carrier (duh!)

I looked at the current sendmail.cf configuration and commented "smart_host" and turned on "saslauthd" to try to initiate SMTP login to send mail but got a digital signature error so I tried a pop login before sending and it crashed out. So I went back to pristine and now I get relay denied (possibly forged) error. I took an unmodified sendmail.cf and uploaded it and get the same error now. I can send to local addresses but can't send off network. Something seems to have erroneously remembered the IP as denied and won't relay.

Two things, how do I setup the SMTP auth and more importantly how do I get my IP back in good graces?

Thanks,

Fri, 09/07/2007 - 06:35
DanLong

I guess for now I just need to find out where Sendmail is retaining a block on the :offending" domain.

Even when I put the carrier's domain into the allowed relays it still comes up with a 550 error and denies relaying.

relay=ppp0024.centurytel.net [xxx.xxx.xxx.xxx] (may be forged), reject=550 5.7.1<br><br>Post edited by: DanLong, at: 2007/09/07 07:58

Fri, 09/07/2007 - 13:55
DanLong

Well. we did form a kluge for the problem by inserting the IP of the firewall protecting our workstations. But that doesn't explain the sudden dislike for the carrier domain name ;-(

and still, how do we get SMTP authentication working....

Sat, 09/08/2007 - 14:02 (Reply to #3)
Joe
Joe's picture

Hey Dan,

It looks like you've got everybody stumped. Not a whole lot of sendmail users around. ;-)

Some things that I know:

saslauthd needs to be running

smtpd.conf (which could be anywhere and named something else, depending on the OS and version) probably needs to know about the relevant settings for authentication--specifically it'll contain:

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

Note I say probably here, as it looks like Sendmail also includes these details in the configuration. So this file might just be for Postfix.

If you're using user@domain.tld usernames, you'll also need to add the -r to the FLAGS or OPTIONS field in /etc/sysconfig/saslauthd (Red Hat based systems) or /etc/defaults/saslauthd (Debian/Ubuntu).

So, that probably covers the saslauthd side. As for the Sendmail side...I'm not sure. The last time I used sendmail was before SMTP authentication existed, and we used POP-before-SMTP (which has always been a nasty hack).

Looks like the sendmail configuration looks something like this:

define(`confAUTH_OPTIONS', `A p y')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl

From there, we'll want to get more detail from the logs. Maybe crank up debugging in Sendmail with:

define(`confLOG_LEVEL', `14')dnl

You can also get some very useful information by connecting with telnet, like this:

# <b>telnet localhost 25</b>
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 virtualmin.com ESMTP Postfix
<b>EHLO localhost</b>
250-virtualmin.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250 8BITMIME

Where the bold bits are the ones I typed. Everything else is from the server. We're looking for the AUTH PLAIN LOGIN entry to let us know that at least the mail server is saying that it will allow SMTP auth.

--

Check out the forum guidelines!

Fri, 12/28/2007 - 06:50 (Reply to #4)
DanLong

Hi Joe,
After banging around and many many calls, I found out our new static IPs were actually hoisted from a dynamic block and set as non-expired. Have the appropriate DNS now (well, maybe) and have broken some ground on this, though every source I found was out dated or OS specific.

I'm this far:
*****************************************************************
telnet local

[root@a102 ~]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 a102.solvdns.net ESMTP Sendmail 8.13.1/8.13.1; Fri, 28 Dec 2007 08:13:57 -0600
ehlo localhost
250-my sub.networkdomain Hello my sub.networkdomain [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP
quit
221 2.0.0 my networkdomain closing connection
Connection closed by foreign host.

***************************************************************
and as a public domain

[root@a102 ~]# telnet testyetagain.com 25
Trying xxx.xxx.xxx.xxx...
Connected to testyetagain.com (xxx.xxx.xxx.xxx).
Escape character is '^]'.
220 my sub.networkdomain ESMTP Sendmail 8.13.1/8.13.1; Fri, 28 Dec 2007 08:24:06 -0600
ehlo testyetagain.com
250-my sub.networkdomain Hello my sub.networkdomain [xxx.xxx.xxx.xxx] (may be forged), pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
250-STARTTLS
250-DELIVERBY
250 HELP
Connection closed by foreign host.
*************************************************************

So locally it appears to be working. But when I try to send with Pegasus mail ( which uses CRAM MD5) I get the following trace:

***************************************************************
&gt;&gt; 0037 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
&gt;&gt; 0014 250-STARTTLS
&gt;&gt; 0015 250-DELIVERBY
&gt;&gt; 0010 250 HELP
&lt;&lt; 0010 STARTTLS
&gt;&gt; 0030 220 2.0.0 Ready to start TLS
&lt;&lt; 0020 EHLO [192.168.1.2]
&gt;&gt; 0095 250-my sub.networkdomain Hello my networkdomain [xxx.xxx.xxx.xxx] (may be forged), pleased to meet you
&gt;&gt; 0025 250-ENHANCEDSTATUSCODES
&gt;&gt; 0016 250-PIPELINING
&gt;&gt; 0014 250-8BITMIME
&gt;&gt; 0010 250-SIZE
&gt;&gt; 0009 250-DSN
&gt;&gt; 0010 250-ETRN
&gt;&gt; 0037 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
&gt;&gt; 0015 250-DELIVERBY
&gt;&gt; 0010 250 HELP
&lt;&lt; 0015 AUTH CRAM-MD5
&gt;&gt; 0054 334 PDI1OTMyMDg1Ljc2NzM4NzZAYTEwMi5zb2x2ZG5zLm5ldD4=
&lt;&lt; 0074 YmlsbEB0ZXN0eWV0YWdhaW4uY29tIDkwMjIzNzYxZTM4MDhkZDMxYjZjODYwNjNhODMxYzEx
&gt;&gt; 0033 535 5.7.0 authentication failed
*******************************************************************

I can't tell if it's lost on the encrypted response or lack of a username and password. I note that on the remote attempt the hello greets networkdomain instead of the host sub.networkdomain.

In the M4 config file there is an entry for &quot;&quot; Define define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl &quot;&quot; userdb.db is not in the /etc/mail location and I can't tell if it's a generic insert your DB name here reference. SASLAuthd is set with the -r flag and shadow for the MECH. But inerting the shadow file into this entry didn't do it.

I tested saslauth:
[root@a102 ~]# testsaslauthd -u bill@testyetagain.com -p ********
0: OK &quot;Success.&quot;

I'm pretty sure that all that's stopping us right now is the question of where is the username and password.

THe CentOS folks have as their solution a simple X,Y Z and Whalla it's done. SO the OS must have all the elements.

any insights?

Dan Long

Sat, 12/29/2007 - 03:40 (Reply to #5)
DanLong

I created two empty files in the /etc/mail/

userdb and userdb.db

and this is the log entry:

Dec 28 10:43:23 a102 sendmail[6718]: lBSGhNZq006718: db_open(/etc/mail/userdb.db): Bad file descriptor
Dec 28 10:43:43 a102 sendmail[6719]: STARTTLS=server, relay=solvdns.net [209.206.145.221] (may be forged), version=TLSv1/SSLv3, verify=NO, cipher=DES-CBC3-SHA, bits=168/168
Dec 28 10:44:06 a102 sendmail[6719]: lBSGhhdH006719: solvdns.net [xxx.xxx.xxx.xxx] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

So I still don't know what this file is or how it gets populated

Sat, 12/29/2007 - 12:33 (Reply to #6)
Joe
Joe's picture

Sorry for the slow reply, Dan. Still trying to get caught up from the holidays.

You don't want a userdb/userdb.db, populated or otherwise. You want to configure saslauthd to use PAM or shadow for authentication. This userdb stuff is for a standalone mail login database, and that makes it not really convenient to use alongside all of your other services (since FTP, Dovecot, and everybody else are looking to PAM or shadow for auth information).

--

Check out the forum guidelines!

Mon, 12/31/2007 - 05:04 (Reply to #7)
DanLong

Thanks Joe,

Actually I found some info on the userdb and Yes, not anything I want. What I did discover, overlooked, right under my nose in the messages log was that sendmail is trying to access the wrong DB:

Dec 31 08:42:04 a102 sendmail[9073]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Dec 31 08:42:04 a102 sendmail[9073]: unable to open Berkeley db /etc/sasldb2: No such file or directory
Dec 31 08:42:04 a102 sendmail[9073]: no secret in database

I've commented out the userdb line and commented out the following lines (from well intended instructions off the web)

dnl # APPENDDEF(`confENVDEF', `-DSASL=2') dnl
dnl # APPENDDEF(`conf_sendmail_LIBS', `-lsasl2') dnl
dnl # APPENDDEF(`confMAPDEF', `-DNEWDB')

I can't for the life of me find where the instruction for the above errors is coming from. Nor can I find where the IP name possibly forged error keeps coming from. I've had our bandwidth provider actually assign our network realm to the IP adresses and on my testing I've connected directly to the network ahead of the firewall.

Dec 31 08:42:04 a102 sendmail[9073]: STARTTLS=server, relay=solvdns.net [xxx.xxx.xxx.xxx] (may be forged), version=TLSv1/SSLv3, verify=NO, cipher=DES-CBC3-SHA, bits=168/168
Dec 31 08:42:17 a102 sendmail[9073]: lBVEg4HE009073: solvdns.net [xxx.xxx.xxx.xxx] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

I feel like I'm so close, but something is keeping the verification process stymied. God knows, I don't want to initiate the POP first hack.

THanks for any help here,
Dan

Wed, 01/02/2008 - 12:38 (Reply to #8)
Joe
Joe's picture

You probably still need those Sendmail configuration lines--I can't think of how else you'd tell it to check with salauthd. But you probably need something a little different in the MAPDEF line. Maybe. I've never setup sendmail with saslauthd (the last Sendmail server I managed went out of service before SMTPD authentication was standardized or saslauthd existed, if that gives any indication of how long it's been since I've worked seriously with sendmail).

ENVDEF might also be something to change. I dunno what any of those lines mean, actually.

--

Check out the forum guidelines!

Mon, 01/07/2008 - 15:21 (Reply to #9)
DanLong

Hey Joe,
After uncommenting those lines an attempt to send resulted in a peer connection failure. I think it has most to do with Sendmail wanting a root only accessible DB file setup and the lack of desire to share with other programs within the environment. The confusing thing has been that the CentOS forum has saslauthd using shadow, so the stright forward uncomment 3 lines just didn't work. Something is keeping sendmail from using PLAIN/LOGIN as evidenced in the telnet logins and remote attempts.

So I've pretty much given up the notion and retreated to the older, though less desireable login method that you know and that works fine. So I can start getting things ready to go.

Dan

Joe, did you get my emails about liscensing?

Fri, 03/21/2008 - 05:45 (Reply to #10)
DanLong

Hi Joe,

I'm dicking around with SMTP auth again as I realize that outlook won't do a pop first.

I'm still at a loss why doing a local telnet won't do a PLAIN LOGIN

telnet solvnet.net 25
Trying xxx.xxx.xxx.xxx...
Connected to solvnet.net (xxx.xxx.xxx.xxx).
Escape character is '^]'.
220 ns1.solvdns.net ESMTP Sendmail 8.13.1/8.13.1; Fri, 21 Mar 2008 09:35:36 -0500
ehlo solvnet.net
250-ns1.solvdns.net Hello ns1.solvdns.net [xxx.xxx.xxx.xxx] (may be forged), pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
250-DELIVERBY
250 HELP

It insists on using the encrypted mechs even though they are removed from the .cf file compilation. Is there anything else that might want to call them up?

Fri, 03/21/2008 - 12:03 (Reply to #11)
Joe
Joe's picture

Hey Dan,

On a Postfix system, the mechs are listed in a standalone saslauthd configuration file (named smtpd.conf on a Red Hat-based system, and located in the saslauthd lib directory...on Debian-based systems it's in /etc/postfix/saslauthd, I think...). Like this on my Fedora desktop machine:

$ cat /usr/lib64/sasl2/smtpd.conf
pwcheck_method: saslauthd
mech_list: plain login

I note there's also a Sendmail.conf file in that same directory, which seems to be the same format, and is provided by the sendmail RPM...so I think we probably have a winner.

--

Check out the forum guidelines!

Sat, 03/22/2008 - 06:38 (Reply to #12)
DanLong

Hey Joe,

Good news for the non-Postfix users as we finally broke through with Sendmail SMTP authentication.

Geez, it was basically a couple of subtle and not so subtle problems. First of which was, uncommenting a sendmail M4 line is more than getting rid of the '#' getting rid of the 'dnl' (whatever it means) is required.

Then all the trickies.

The real kicker was assuming that using the bootup module to add the '-r' to the flags setting would do it. Apparently not, I had to actually add it to the /etc/sysconfig/saslauthd file.

After that I could actually get the TLS going and did do a PLAIN LOGIN. To accomplish this I had to remove the MD5 encryption stuff out of the trusted and mechs because I use Pegasus mail and it wants to go to an MD5 first. Otherwise then I was successful (I'll try to figure out the MD5 stuff later).

I still had an Outlook express problem that had me royally baffled ( could you expect anything less out of microsoft?). I'd had the ports opened and assigned correctly. In the MS account I went from not requiring SSL to requiring SSL and still kept failing. First off, when I think of requiring SSL I think of an SSL virtual server, thank you. But I'm assuming now they mean OpenSSL. None the less, I discovered you have to go to the &quot;advanced&quot; settings on the account and there is a check box to require SSL on the selected port (go figure). In a &quot;what the hey&quot; move I checked it and gave it a whirl, and ya know, it worked. Count on MS to complicate a simple process.

I'll get my notes together and try to put together a comprehensive mini tutorial to put in the wiki. THough, it will be for CentOS.

Thanks for puttin up with me ;-)
Dan

Oh, I did note, the the network ports module has a bug. Right now the ports are listed as defined ports (smtp, smtps, submission), and if you try to make a change in port options it fails because the updater is looking for a numeric port number.

Sat, 03/22/2008 - 06:44 (Reply to #13)
DanLong

Forgot one other important item.

Going to the /usr/share/ssl/certs directoru and running
make sendmail.pem , being sure to put your hostname into the certificate. By all likelyhood you'll using a local cerificate not in the bundle.

Topic locked