I was getting some strange errors in my maillog when an ldap user would try to call spamassassin on incoming mail. This was fixed by adding the “–ldap-config” option to the spamassassin startup script. The line in the file that I changed, no looks like this:
SPAMDOPTIONS="-d -c -m5 -H --ldap-config"
I had a problem where I couldn’t send mail with squirrelmail. Whenever I hit the send button, I got an error that said:
Server replied: 71 Can't execute command '/usr/sbin/sendmail -i -t -fmailaddress@someone.com'.
So, I then tried to run the command as a regular user at the command line and I got this error:
NOQUEUE: SYSERR(): can not write to queue directory > /var/spool/clientmqueue/ (RunAsGid=0, required=25): Permission denied
It turns out that my smmsp user had uid=51 and gid=51, but in /etc/group, the smmsp group was gid=25. To fix this, I simply changed the gid of the smmsp user to 25 and restarted sendmail. That fixed things.
I finally got ldap working for accounts both in ldap and /etc/passwd. Here is my /etc/dovecot.conf file, with all comments removed.
protocols = imaps pop3s
log_path = /var/log/dovecot.log
ssl_cert_file = /usr/share/ssl/certs/imapd.pem
ssl_key_file = /usr/share/ssl/certs/imapd.pem
login_dir = /var/run/dovecot/login
mmap_disable = yes
first_valid_uid = 200
protocol imap {
}
protocol pop3 {
}
protocol lda {
postmaster_address = postmaster@example.com
}
auth default {
mechanisms = plain
passdb pam {
}
passdb shadow {
}
passdb ldap {
args = /etc/dovecot-ldap.conf
}
userdb passwd {
}
userdb ldap {
args = /etc/dovecot-ldap.conf
}
user = root
}
dict {
}
plugin {
}
In preparing for our mail server upgrade, I’m setting up a new test server, just to make sure that everything will be working together as I hope it will. I had a problem with sendmail in that I was able to receive mail ok, but was unable to send it. In the mail logs, I got messages like this:
Sep 17 08:47:03 server sendmail[2884]: l8HDkmas002884: yo.robot.com [192.168.52.8]: possible SMTP attack: command=AUTH, count=3
Since yo.robot.com is my computer, I knew we weren’t getting hacked. The problem was that I didn’t have saslauthd running on the mail server. As soon as I turned it on, things were working fine.
Must use the same certificate (.pem file) in both sendmail.mc and the dovecot config files. Otherwise, you’ll get an error when trying to send mail about having a certificate with a duplicate value. (Or something like that.)
The ldap learning curve continues…
I have just gotten sendmail working with ldap. Had a bunch of problems, but mail is coming in.
I have two machines, ldapserver and mailserver. The mailserver machine has to look up accounts on the ldapserver machine. I had to add a couple of things to ldapserver.
# mail, people, ldapserver.uchicago.edu
dn: uid=mail,ou=people,dc=ldapserver,dc=uchicago,dc=edu
uid: mail
cn: mail
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: {crypt}*
loginShell: /sbin/nologin
uidNumber: 8
gidNumber: 12
homeDirectory: /var/spool/mail
gecos: mail
# smmsp, people, ldapserver.uchicago.edu
dn: uid=smmsp,ou=people,dc=ldapserver,dc=uchicago,dc=edu
uid: smmsp
cn: smmsp user for sendmail
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: {crypt}*
uidNumber: 51
gidNumber: 51
homeDirectory: /dev/null
gecos: smmsp user for sendmail
# sendmail, people, ldapserver.uchicago.edu
dn: uid=sendmail,ou=people,dc=ldapserver,dc=uchicago,dc=edu
uid: sendmail
cn: Mail Transfer Agent
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: {crypt}*
loginShell: /bin/tcsh
uidNumber: 101
gidNumber: 2
homeDirectory: /var/adm
gecos: Mail Transfer Agent
I got this information from our current /etc/passwd file. I’m not sure if I needed all of these accounts, but to be sure, I put them all in.
I also had to create an ou called sendmail. I put it in the ou called dsa that was created for secure accounts.
# sendmail, dsa, ldapserver.uchicago.edu dn: ou=sendmail,ou=dsa,dc=ldapserver,dc=uchicago,dc=edu objectClass: organizationalUnit ou: sendmail
I also had to add some more info to the user account.
dn: uid=testuser1,ou=people,dc=ldapserver,dc=uchicago,dc=edu changetype: modify add: objectClass objectClass: inetLocalMailRecipient - add: mailLocalAddress mailLocalAddress: testuser1@mailserver.uchicago.edu - add: mailRoutingAddress mailRoutingAddress: testuser1@mailserver.uchicago.edu
Finally, I had to uncomment this line in /etc/openldap/slapd.conf.
allow bind_v2
This is because sendmail does use version 2 binds.
Those are all the changes I made on ldapserver.
On the mailserver, most of the changes were in /etc/mail/sendmail.mc. Here are the lines I added:
dnl # LDAP Settings dnl # basic definition of access_db using LDAP FEATURE(`access_db',`LDAP')dnl dnl # To use sendmail's default LDAP search parameters for aliases define(`ALIAS_FILE',`ldap:')dnl LDAPROUTE_DOMAIN(`mailserver.uchicago.edu')dnl FEATURE(`ldap_routing')dnl define(`confLDAP_DEFAULT_SPEC',`-h ldapserver.uchicago.edu')dnl
After I created the new sendmail.cf from this and restarted sendmail, I could receive mail to my user testuser1.
Now, I have to figure out how to configure dovecot to be able to authenticate to read mail.
One big problem with my idea of switching over to ldap for all users is that dovecot 0.99 does not seem to work with ldap. My ldap user is not allowed to login with imap. However, ldap accounts can forward their mail to another account. So, I could set up accounts for people and immediately put a .forward file in their home to forward mail somewhere else.
The dovecot website doesn’t have all that much info on using ldap. One file mentioned is /etc/dovecot-ldap.conf. I have no trace of this file any of my RHEL systems. So, I also think that RedHat has not compiled openldap and dovecot to do this. I put a service request into RedHat asking this.
Our imap server has been acting a little funny and despite my attempts to ignore it until it got better, it just kept acting funny. It would undelete messages and not let them be moved to other folders at times. At other times, it would work fine. So, I decided to go with the RedHat provided dovecot package.
The config file is /etc/dovecot.conf. It had a few lines that needed to be edited.
protocols = imaps (we only allow secure connections)
ssl_cert_file
ssl_key_file
first_valid_uid = 200 (the default is 500)
auth_passdb = shadow
Once these were changed, I just had to turn off imaps with chkconfig and restart xinetd. Then start dovecot.
I got a call from Network Security saying that our mail server was reporting to an ehlo command that its name was localhost.localdomain. This isn’t really a problem, except that some spam-reporting companies have a bug where this would be enough to automatically blacklist our machine. I edited /etc/hosts and added our machine there, restarted sendmail and everything looks ok.
Also, you have to go to the spamhaus website and request that the address be removed from their system. What a pain!
We used to use horde to provide our webmail service, but redhat now provides squirrelmail for this purpose. So, installed the package with up2date:
up2date squirrelmail
This also installed package: php-mbstring
Instructions are to restart httpd and go to http://
/usr/share/squirrelmail/config and run:
./conf.php
Then go through and change the settings to match our site. After changing everything, I was allowed to log in.