[Spectrum]

I sort of expected this answer and honestly, I’m glad to know it isn’t me but something that was changed for the better. It just behaved differently than my other existing servers and I wanted to make certain that something wasn’t hosed before continuing to add data to it.

Thanks, guys.

[Spectrum]

1.) Does not appear in the list of accounts in WGM if looking at the LDAP directory.
2.) Can not auth in WGM against the LDAP directory to manage it.

Only the diradmin account is capable of doing either now.

I’ve updated other existing servers with local admin accounts and never had this issue. Either account could admin the OD through WGM. It is only on this built from scratch new server.

[Spectrum]

Well, after a bit more digging around with net groupmap list, I found that the Win2k3 legacy group Administrators is mapped to the unix admin group.

Since Administrators contains Domain Admins and Enterprise Admins as members by default, this is a fairly easy work around for the problem. Adding Administrators to ACLs works as expected.

edit: gah – typo. I need coffee.

[Spectrum]

I got that as well after an attempted inplace upgrade. The funny thing is that the Print Server wasn’t active before the upgrade nor after it, yet I got the cups generated errors exactly as you did.

[Spectrum]

I tried on a test server. Fortunately, I made a clone beforehand.

After the upgrade install, no services would run. There was a notation in Server Admin that the services had been updated, needed to be kerberized and to go to Open Directory in SA to do so.

That’s all the instruction there is about it as well. I found a button under the general settings area (which disappeared on execution) labeled, Kerberize.

Foolishly, I believed it would accomplish the required task. I ended up with what was essentially a dead server and had to restore the clone.

[Spectrum]

My apologies for not getting this done sooner. Life has gotten a bit crazy here as we just completed a migration from Novell to some XServes. 🙂

Anyway, I’ve barely proofread this, but I believe it to be correct and complete:

Basically, it requires that you nuke postfix-watch, create custom transport tables and relay tables in /etc/postfix/main.cf and add a custom pipe filter in /etc/postfix/master.cf. You’ll also need to invoke a shell script to do the pass off to spamc/spamd and retransmit the e-mail with postfix-sendmail to the final recipient. If your server is acting as a relay (like mine), you need to make sure that it can resolve the FQDN of the internal server, that you have local DNS MX records that point at your internal server and that the relay server relies on that information.

If you plan to use the tarball to compile SpamAssassin, you’ll need Xcode installed on your machine.

SpamAssassin requires an ton of perl modules to be installed prior to compilation/installation. Get them from CPAN.

SpamAssassin requires /etc/mail/spamassassin to exist. It doesn’t in OS X, so create it.

Now either make, or install SpamAssassin per the included READMEs.

Check SpamAssassin’s functionality before you go any further (spamassassin -t command). If SA isn’t working properly, you’ll be wasting your time.

After SpamAssassin is installed and successfully tested, you need to modify the postfix configuration files. They are located in /etc/postfix.

Lets start off with main.cf. As I’m accustomed to working in *nix, I use vi as my editor, use whatever you like. You’re basically recreating the entire file, but you will include some existing lines.
Here’s mine (edited with <yourstuffgoesinhere> tags):
============================================
# declarations
queue_directory = /private/var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
sendmail_path = /usr/sbin/sendmail
newalias_path = /usr/bin/newalias
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix/examples
readme_directory = /usr/share/doc/postfix
#
mail_owner = postfix

# hostname entry
myhostname = <FQDN of this server> # Enter the FQDN of this server here. It MUST resolve.
# domain entry
mydomain = <your domain name> #Enter your domain name here.

# configuration lines
myorigin = <your domain name> # Enter your domain name here.
mydestination = $myhostname,localhost.$mydomain,
mynetworks = <enter your public/private networks here> # Enter ALL your public/private nets in a comma separated list. You can use CIDR masks (i.e., x.x.x.x/24)
relay_domains = <your domain name> #Enter your domain name here
parent_domain_matches_subdomains =
debug_peer_list smtpd_access_maps
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination,permit
relay_recipient_maps = hash:/etc/postfix/relay_recipients
transport_maps = hash:/etc/postfix/transport
local_recipient_maps =
local_transport = error:local mail delivery is disabled
virtual_alias_maps = hash:/etc/postfix/virtual
smtpd_banner = $myhostname ESMTP #I’ve truncated this because I don’t like people knowing just what is running. 😉
setgid_group = postdrop
unknown_local_recipient_reject_code = 450
fast_flush_domains = $relay_domains
mydomain_fallback = <enter a secondary server address here> # Warning! This entry is mandatory. Postfix will not run without it. You can enter an IP or FQDN. It doesn’t need to ever be used, but it must exist.
###########################################
# Rest of this junk is from server admin tool and unmodified from original form.
#
luser_relay =
maps_rbl_domains =
message_size_limit = 0
smtpd_use_tls = no
smtpd_enforce_tls = no
smtpd_tls_loglevel = 0
smtpd_sasl_auth_enable = no
smtpd_use_pw_server = no
smtpd_pw_server_security_options = none
server_enabled = 1
mailbox_transport = cyrus
enable_server_options = yes
inet_interfaces = all
relayhost =
smtpd_client_restrictions =
always_bcc =
~
============================================

The above file configures your server as a DMZ relay with no local transport. We’ll be adding alias for root, postmaster, etc that send all e-mail to internal addresses.

Next, we need to edit master.cf to add a content filter inclusion on the smtp service line.
Here’s mine:
============================================
smtp inet n – n – – smtpd # this line is already there and uncommented if running smtp
-o content_filter=spamfilter # this is the line you add directly under the smtp line. Lead with whitespace as shown.
============================================

Next you need to set up the content filter itself in master.cf In the interfaces section, you need to add the following:
============================================
spamfilter
unix – n n – pipe
flags=Rq user=spam argv=/usr/bin/spamfilter.sh -f ${sender} — ${recipient}
============================================

The above uses a shell script named spamfilter.sh to invoke the pipe. The SpamAssassin, spamd and spamc executeables install in /usr/bin by default, so I also installed my shell script there as well.

Since I didn’t want this running as root, I chowned spamd and spamc as spam:wheel with perms = 755.

Now, we need to create the shell script.
Here’s mine:
============================================
#!/bin/bash
/usr/bin/spamc | /usr/sbin/sendmail -i "$@"
exit $?
============================================

So, essentially what we’re doing is creating a complex pipe from postfix to spamc/spamd to sendmail.

Next, we need to create some tables in /etc/postfix to manage the connection.

First we need to create a transport table. It should already exist as transport. I’m a bit overly cautious when doing these, so I cp the originals to .bak files just in case there’s a problem down the road.

This is a very simple table mapping the smtp server to the domain.
============================================
<yourdomainname> [smtp:<ipaddressofyourinternalmailserver>]
nowhere.net [smtp:192.168.0.1] ; Here’s a quick example.
============================================

Earlier I mentioned that since we are disabling local mail service, we needed to create alias for the well known receivers to redirect them to internal addresses.
This is done with the virtual table and the file should also pre-exist here.

============================================
postmaster postmaster@<yourdomain>
abuse sysadmin@<yourdomain>
sysadmin sysadmin@<yourdomain>
root postmaster@<yourdomain>
============================================

The above will redirect the local e-mail accounts in the left column to the internal addresses in the right column. Obviously, the internal addresses must exist.

The next table is the most complex of the ones we’ll deal with. This is the relay_recipients table. Here you can make a choice. You can enter some wildcard info and forward all e-mail inbound OR you can really tighten this up to relay only mail to existing internal addresses. (The former is quite simple, the latter requires either manual update by the sysadmin (a real chore if you’ve got a lot of people) or an automation script that can handle it for you.)

relay_recipients may or may not pre-exist in the /etc/postfix directory. If it doesn’t, just create it and make sure to chown/chmod it to be the same as the other existing tables (root:wheel / 644)
Here’s the easy way using the wildcard:
============================================
@<yourdomain> x

@nowhere.net x ; Quick Example
============================================

The above will forward all mail inbound (and through the spamassassin pipe) to the internal servers for them to decide on delivery.

You can also choose to lock this down. The basic format is:
============================================
<user>@<yourdomain> OK
[email protected] OK ; Quick Example
============================================

If you’re running Microsoft’s Active Directory internally (like me), there’s a good perl script that can automate this process for you (This will probably work for any LDAP/OpenDirectory server as well, though you might need to massage it a bit). Otherwise, you’ll need to build it by hand each time a user is added/deleted. I’ll post that in a separate thread for those that are interested in it.

You’ve probably noticed that there are also files of similar name in the directory. virtual.db for example. These are the hashed versions of the text files that postfix actually reads. Since we’ve altered the base text files, we now need to update these hash tables so that postfix can use our tables.

To do this, you will use the postmap command. The syntax is: postmap hash file.db < file

So for the virtual table, the command would be: postmap hash virtual.db < virtual

Create the has tables for each of the tables we’ve updated (transport, virtual and relay_recipients).

Now that we’re done with the configuration of Postfix, we need to deal with that nasty little daemon known as postfix-watch. postfix-watch is a daemon that checks in on postfix on a regular schedule (via periodic daily and a few other means) and checks to see if it is alive if the server is configured to be a mail server. The problem with this is that it also stomps on master.cf and main.cf each time and will remove your customized settings for the server. To prevent this from happening, we’re going to prevent postfix-watch from respawning the server. To do this, we need to edit /etc/watchdog.conf. Using your favorite editor, open watchdog.conf and locate the line with this entry:
============================================
postfix:respawn:/usr/libexec/postfix/master # Mail services – SMTP
============================================

All we will do is comment this line out by placing a # at the beginning. Do NOT delete the line. The reason for this is that periodic.daily parses this file as part of it’s routine. If the line is missing, it will recreate it. Since we are commenting it, periodic believes the line still exists and leaves it alone. So, your edited version should look like:
============================================
#postfix:respawn:/usr/libexec/postfix/master # Mail services – SMTP
============================================

You’d think that is all you need, but wait, there’s more. postfix-watch and periodic are sneaky.

We also need to edit /etc/hostconfig. Again, open the file with your editor of choice and locate this entry:
============================================
MAILSERVER=-AUTOMATIC-
============================================

edit it to read:
============================================
MAILSERVER=-YES-
============================================

This is the one that actually prevents postfixc-watch from starting. Now, that we’ve edited the file, kill postfix-watch (if it is running). For those of you unfamiliar with the unix kill command, you need to find it’s PID to kill it. To do so, issue the following command:
============================================
ps -aux |grep postfix-watch
============================================

That will return a result to the console window similar to:
============================================
root 724 0.0 0.0 27476 408 ?? Ss 18Oct04 3:09.32 postfix-watch
============================================

The number in the second column is what we want (724 in the example above).
To kill the process type: kill 724 (for above, substitute the correct number for your system).

Next, type: "postfix stop" to make sure that postfix is stopped.

Now we are going to start up spamd (the daemon portion of SpamAssassin) to start the pipe.

The basic command is:
============================================
/usr/bin/spamd -d -m4 -H -u spam
============================================

The above starts spamd with -d (daemon), -m4 (create 4 child processes (total of 5 with the parent), -H (use standard home directory (/etc/mail/spamassassin), -u (chrooted as user spam).

Now type: "postfix start" to start up postfix with the new configuration files.

Your relay server should now be working. You can check in on it by using the unix tail command. It will read the last few lines of the mail.log file and display them onscreen for you. You can also use the -f flag of tail to have the file displayed in realtime in the foreground as it is being written.

The full command to have the mail.log file run in foreground mode is:
============================================
tail -f /var/log/mail.log
============================================

When you want to stop displaying the log, simply Ctrl-C to exit the command.

I’ve not yet written startup scripts for spamd (mostly because I’ve been quite busy with other things) but you can do that as well if you like. Be sure to set a plist such that postfix depends on spamd to be running first.

[Spectrum]

I’ve done it and made it work with Postfix as a relay server in my DMZ.

It’s a lot of brain damage and somewhat time consuming. I’ll try to write something up over the weekend and post a reply on how to do it.

[Spectrum]

Just wanted to say that after a bit of brain damage from reading many pages of articles/manuals/posts I did get this working and also was able to cleanly integrate SpamAssassin 3.0and an LDAP relay access puller into it.

Works quite well allthough I think I will need to put some more RAM in my G5 XServe.

[Spectrum]

Thanks for the reply Joel.

I guess I’m just venting some frustration over about 350 hours of lab work at about 60-70 hours a week.

My problem stems from the fact that I need to maintain Exchange 5.5 for a legacy voice mail product. (since it has no upgrade path and there’s nothing out there for the OSX platform)

Without either a method to export the existing users + their NT SIDS (required to access exchange mailboxes) or another solution that is OSXS native, I’m basically hosed.

I looked at both Firstclass and at Kerio. Neither can do what I need and there are some other wierdo things about them as well.

Firstclass license fees make M$ look inexpensive. $80k for 100 users. The interface looks like it was written for DOS 3.1, no vmail support and no support for Blackberry.

Weirdest thing: all email (both inbound and outgoing) threaded in a single mailbox. Makes it quite interesting to sort through your mailbox looking for a message.

Kerio is much more attractive from a price standpoint, but, no vmail support, no public folders and no Blackberry support.

Weirdest thing: Issuing a beta with no dev contact, no feedback from beta users, no beta forums and no support at all (even to install) for the beta.

[Spectrum]

I’d be VERY interested in knowing how you got that to work. Considering I spent 3 weeks attempting the same thing.

How did you export the users from the NT domain? Did you also export User SID? I got hung up a bit there since the pdf is blatently incorrect. There is no way to export NT users with User Manager for Domains.

I did find some NTRK tools to do that, but without the SID. However, the description of the import file structure in the pdf lacks sufficient information to properly set up the file for import and I subsequently was unable to perform any importations.

My problems really stem from the fact that I need the user SID as well because I need to maintain Exchange as the mail service. This is primarily due to the fact that there is no native unified messaging service provider for OSX.

[Spectrum]

That is the only way other than a registry hack to do this. By default, NT (win2k+ as well) expects to be a domain member ans use roaming profiles.

[Spectrum]

Yes, I ultimately came to that conclusion after a 6 week run-around with Apple. So much for that 80k that Apple was going to get from us.

I’m just a little bit more than annoyed that Apple strung me out that long apparently hoping that I wasn’t going to try a proof of concept lab test.

As to why they decided to break basic functionality of Samba for their custom build, only they know. Hard to fathom that they tout the ability to seamlessly integrate with NT style domains when they simply can’t (or, probably, more aptly, chose not to do so).

IMO, until they come clean and either:

a.) Create a “Unified Messaging” solution on the OSXS platform and change the current line of thought on seamless migration (which they broke most of in their Samba build as well)

or

b.) allow domain trusts to occur to allow existing NT domains the ability to import existing userbase info for authentication to utilize Microsoft (or others) Unified Messaging solutions

they will not be accepted widely in the mainstream corporate sector.

Quite honestly, I don’t think that my organization does anything extreme in the arena of technology. Too bad that Apple can’t support it.

My thoughts on Apple after about 3.5 months:

1. Great hardware, maybe the best there is.

2. Server platform fine for homogenous clients. Mediocre at best for heterogenous clients.

3. Community: Snobbish and aloof – generally unwilling to take a few minutes to help. (Sorry, but that’s how it has played out in my scenario)

Too bad, because I really wanted to make this work, but, alas, it never will until Apple changes their tune.

[Author]

Posts