It takes a bit of work, but I’ve got a working sample of the alias map in LDAP for sendmail.
Trying to debug this is difficult. It appears that within the ALIAS_FILE LDAP definition one cannot have anything besides the -k and -v options (I was hoping to restrict it to a subtree using -b, but adding a -b caused M4 to make a CF file that seemed to indicate an alias file with the value of -b). It also interacts strangely with LDAP routing.
In any case, I’ve found the following LDIF will produce a proper object:
dn: cn=ALIAS, ou=Aliases, dc=example, dc=edu objectClass: top objectClass: groupOfUniqueNames objectClass: mailrecipient objectClass: mailGroup cn: ALIAS mail: ALIAS mail: ALIAS@example.edu mailRoutingAddress: ALIAS mgrpRFC822MailMember: recipient1 mgrpRFC822MailMember: recipient2
Both of the mail attributes are required for both the local and esmtp mailers to work right (i.e., this is the part where LDAP routing can bit you). The recipients in the mgrpRFC822MailMember attributes can be local recipients (without the @domain) or full addresses for aliases that forward off-site.
With this in place, the following in the MC file can be used:
The default LDAP spec needs to have the base DN for searches added to it, and in our case it can be restricted to the aliases subtree since the LDAP routing feature will have a different base DN specified (in this case the whole subtree because wee need to be able to hit both the People and Aliases subtrees, and we can be pretty certain that no other subtrees will have any objects that match).
Cutting out the e-mail server overnight is about as painful as cutting it out over lunch.
So last week we made a small glitch at about 6 pm Monday night, which resulted in KE tempfailing e-mail all night. Starting at 7:30 the next morning, I pumped queued messages through it from BARIS and kept the system running at a sustained load average of over 25 until lunch, when things pretty much started to calm down. The afternoon was slightly squirrely, but not bad.
Today, “preventative maintenance” on the UPS took out PAX and MIR (and thus all DNS service) for about half an hour starting just before noon. The recovery time for that was about the same as it was for last week’s snafu, and I managed to keep the load average greater than 35 for most of that time. Last week I had sendmail’s queue/refuse load averages set to 30 and 60; today I upped them to 50 and 100. Kind of painful on the IMAP and POP processes, but not at all unusable.
What this tells me (and something I already knew) is that e-mail usage peaks around lunchtime around here. I can look at the Cricket graphs of normal load average, number of messages processed, etc., but this is something visceral that a sysadmin can sink his teeth into (though he’d rather not). It also tells me that the virus scanning we’re using is just a touch suboptimal, but again, I already knew that. Lump spam scanning in there as well. But that’s why we’re looking to offload that onto another system.
Sendmail LDAP routing is working on Karelia with the standard LDAP server.
On the LDAP side, we need the following added to the user object:
objectClass: mailrecipient mail: user@example.edu mailHost: mailserver.example.edu mailRoutingAddress: user@example.edu
All our users already have the mail attribute, but this has to be set specifically for the test domain, as Sendmail will try to do a lookup with, among other things, the mail attribute set to the full domain name. You can have multiple mail attributes if you also have a mailRoutingAddress attribute to specify the canonical address — this way we can have one mail attribute of user@example.edu and another of User.Lastname@example.edu.
On the Sendmail side, I have the following defined in the MC file:
I have not yet gotten to putting maps (aliases, access, etc.) into LDAP. That’s the next step. This just gets us the routing portions.
Looking at possible spam/virus gateway appliances.
The idea being that maybe we’ve outlived the usefulness of our in-house scanning system and might be better served with a packaged box. I’ve identified four so far which might work; time to start seeing about evaluation units.
In that vein, I’ve also set up Karelia to host e-mail services, currently just like Ke. We can copy all mail over there before it gets run through SpamAssassin, and get a feel for how well any appliance works.
Worked up a FormMail hack for student development to use as a semi-anonymous web mailer for their “encourager” system.
They need something that only a few people can access to send notes to people. The FormMail hacks were to only allow sending from specific addresses (so that people couldn’t put together a different form and abuse it that way), change the email output format, include form elements of message, disclaimer, and signature, and to put in an extra email header that includes an obfuscation of the HTTP REMOTE_USER variable if it’s set (since this will be put in a password protected area). This gives us logging via standard Apache logs, plus something within the message itself that we can use to track back to the account responsible if something goes awry.
According to this post on the Netatalk list, apparently some of our AppleTalk problems may be due to having home directories mounted over NFS to the AppleTalk server.
Fortunately, there’s a fix — I created /usr/local/atalkdb/$user for all users on PAX and then changed AppleVolumes.default to include dbpath:/usr/local/atalkdb/$u for the ~ (home) share. This path is getting used, but I’ve yet to verify with anyone who had problems before whether they’re continuing to have problems or not.
I got the SpamAssassin SNMP reporter completed and got Cricket hooked up to show SpamAssassin stats.
The trickiest part was remembering that rrd_min has to be set to a negative number in order for the negative spam scores to be stored in the RRD database.
Working up a program that can be called from NET-SNMP to monitor SpamAssassin stats for Cricket.
I’ve got the base program done — it can count number of messages, average score, average time, and average size for both spam and ham that is sent to spamd. Also have it using a state file so that it doesn’t have to grep the maillog each time it’s called — very useful if we’re going to walk a MIB tree.
Next up is to get it to respond to NET-SNMP command line arguments rather than my own cryptic ones. For tomorrow…