The traditional way to enable Apple Remote Desktop is using the kickstart command
. But there’s a simpler way in OS X Mountain Lion Server. To do so, use the serveradmin command.
To enable ARD using the serveradmin command, use the settings option, with info:enableARD to set the payload to yes:
sudo serveradmin settings info:enableARD = yes
Once run, open System Preferences and click on Sharing. The Remote Management box is then checked and the local administrative user has access to ARD into the host.
The Server app will also have the “Enable screen sharing and remote management” option checked.
There are also a few other commands that can be used to control settings. To enable SSH for administrators:
sudo serveradmin settings info:enableSSH = yes
To enable SNMP:
sudo serveradmin settings info:enableSNMP = yes
To enable the dedication of resources to Server apps (aka Server Performance Mode):
sudo serveradmin settings info:enableServerPerformanceMode = yes
krypted August 14th, 2012
Posted In: Mac OS X Server, Mac Security, Mass Deployment
ARD, dedicate system resources, mountain lion, os x mountain lion server, performance mode, Remote Desktop, server.app, serveradmin settings, Sharing, snmp, ssh
File Services are perhaps the most important aspect of any server because file servers are often the first server an organization purchases. There are a number of protocols built into OS X Mountain Lion Server dedicated to serving files, including AFP, SMB and WebDAV. These services, combined comprise the File Sharing service in OS X Mountain Lion Server.
File servers have shares. In OS X Mountain Lion Server we refer to these as Share Points. By default:
- File Sharing has some built-in Share Points that not all environments will require.
- Each of these shares is also served by AFP and SMB, something else you might not want (many purely Mac environments might not even need SMB). Or if you have iOS devices, you may only require WebDAV sharing.
- Each share has permissions that Apple provides which will work for some but not all.
In short, the default configuration probably isn’t going to work for everyone. Therefore, before we do anything else, let’s edit the shares to make them secure. The first step is to create all of your users and groups (or at least the ones that will get permissions to the shares). This is done in Server app using the Users and Groups entries in the List Pane. Once users and groups are created, open the Server app and then click on the File Sharing service in the SERVICES list in the List Pane. Here, you will see a list of the shares on the server.
In our example configuration we’re going to disable the Groups share. To do so, click on Groups one time and then click on the minus button on the screen.
As mentioned, shares can be shared out using different protocols. Next, we’re going to disable SMB for Public. To do so, double-click on Public and then uncheck the SMB protocol checkbox for the share.
When you’ve disabled SMB, click on the Done button to save the changes to the server. Next, we’re going to create a new share for iPads to be able to put their work, above and beyond the WebDAV instance automatically used by the Wiki service. To create the share, first we’re going to create a directory for the share to live in on the computer, in this case in the /Shared Items/iPads directory. Then from the File Sharing pane in Server app, click on the plus sign (“+”).
At the browse dialog, browse to the location of your iPad directory and then click on the Choose button.
At the File Sharing pane, double-click on the new iPads share.
At the screen for the iPads share, feel free to edit the name of the share (how it appears to users) as it by default uses the name of the directory for the name of the share. Then, it’s time to configure who has access to what on the share. Here, use the plus sign (“+”) in the Access section of the pane to add groups that should be able to have permission to access the share. Also, change the groups in the list that should have access by double-clicking on the name of the group and providing a new group name or clicking on the plus sign to add a user or group.
The permissions available in this screen for users that are added are Read & Write, Read Only/Read and Write. POSIX permissions (the bottom three entries) also have the option for No Access, but ACLs (the top entries comprise an Access Control List) don’t need such an option as if there is no ACE (Access Control Entry) for the object then No Access is assumed.
If more granular permissions are required then click on the name of the server in the Server app (the top item in the List Pane) and click on the Storage tab. Here, browse to the directory and click on Edit Permissions.
As can be seen, there are a number of other options that more granularly allow you to control permissions to files and directories in this view.
Once you have provided all of the appropriate users access to the share, go back to the settings for the share and scroll to the bottom of the screen.
Here, you have the option to set which protocols the share is accessible through (AFP, SMB & WebDAV) as well as make the share accessible to guests (only do this if the share should be publicly accessible) and make the share an option for home folders. Click Done once you’ve configured the share appropriately.
Once a share has been made an option for home folders it appears in both Workgroup Manager and the Server app as an available Home Folder location for users in that directory service.
Once you have created all the appropriate shares, deleted all the shares you no longer need and configured the appropriate permissions for the share, click on the ON button to start the File Sharing service.
The File Sharing service can also be controlled from the command line. Mac OS X Server provides the sharing command. You can create, delete and augment information for share points using sharing.
To create a share point for AFP you can use the following command:
sharing -a -A
So let’s say you have a directory at /Shares/Public and you want to create a share point called PUBLIC. You can use the following command:
sharing -a /Shares/Public -A PUBLIC
Now, the -a here will create the share for AFP but what if you want to create a share for other protocols? Well, -F does FTP and -S does SMB. Once created you can disable the share using the following command:
sharing -r PUBLIC
To then get a listing of shares you can use the following command:
You can use the sharing command to enable FTP for various share points. To do so, enable FTP using the Server app and then use the instructions at this site to manage FTP on shares: http://krypted.com/mac-os-x/ftp-on-lion-server
You can also use the serveradmin command to manage file shares as well as the sharing service. To see settings for file shares, use the serveradmin command along with the settings option and then define the sharing service:
sudo serveradmin settings sharing
To see settings for the services use the serveradmin command with the settings option followed by the services: afp and smb:
sudo serveradmin settings afp
To see a run-down of some of the options for afp, see this article I did previously
. Additionally, for a run-down of smb options, see this one
krypted August 8th, 2012
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
Command line, enable WebDAV, file sharing, Mac OS X, Mac OS X Client, macs, mountain lion server, os x, os x mountain lion server, OS X Server, public, serveradmin, settings, settings sharing, Sharing
The software patching configuration built into most operating systems is configured to open a box at home, join your network and start using the computer right away. As environments grow from homes to offices and then offices grow into enterprises, at some point software updates and patches need to be managed centrally. Mountain Lion, as with its OS X Server predecessors has a Software Update service. The service in the Server app is known as Software Update and from the command line is known as swupdate.
The Software Update service, by default, stores each update in the /var/db/swupd directory. The Software Update servie is actually comprised of three components. The first is an Apache server, invoked by the /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.host.plist LaunchDaemon. This LaunchDaemon invokes a httpd process and clients access updates from the server based on a manifest of updates available in the sucatalog. These are synchronized with Apple Software Updates via /Applications/Server.app/Contents/ServerRoot/usr/sbin/swupd_syncd, the LaunchDaemon for swupdate at /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.sync.plist. The Apache version is now Apache/2.2.22.
Clients can be pointed at the server then via a Profile or using the defaults command to edit the /Library/Preferences/com.apple.SoftwareUpdate.plist file. The contents of this file can be read using the following command:
defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist
To point a client to a server via the command line, use a command such as the following:
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://updates.krypted.com:8088/index.sucatalog
But first, you’ll need to configure and start the Software Update service. Lucky you, it’s quick (although quick in a hurry up and wait kind of way). To get started, open the Server app and then click on the Software Update service.
By default, updates are set to simply mirror the Apple servers, by default, enabling each update that Apple publishes, effectively proxying updates. You can use the Manual button if you would like to configure updates to either manually be approved and manually synchronized or just manually approved but automatically copied from Apple. Otherwise click on the ON button and wait for the updates to cache to simply mirror the Apple servers.
If you would like to manually configure updates, click on the Manual option and then click on the Updates tab.
The first item in the Updates tab is the “Austomatically download new updates” checkbox. This option downloads all of the updates but does not enable them. The Updates tab also displays all available updates. click on one and then click on the cog-wheel icon towards the bottom of the screen to configure its behavior (Download, Enable, Disable, Remove and View Update).
Note: The only option for updates in an Automatic configuration environment is disable.
The service can be managed using serveradmin. To start Software Update, use the start option, followed by the swupdate service identifier:
sudo serveradmin start swupdate
To stop the service, replace start with stop:
sudo serveradmin stop swupdate
To see the status of the service, including the location of updates, the paths to log files, when the service was started and the number of updates running, use the fullstatus option:
sudo serveradmin fullstatus swupdate
The output of which appears as follows:
swupdate:state = "RUNNING"
swupdate:lastChecktime = 2012-08-04 17:04:45 +0000
swupdate:syncStatus = "DONE"
swupdate:syncServiceState = "RUNNING"
swupdate:setStateVersion = 1
swupdate:lastProductsUpdate = 2012-08-04 17:07:10 +0000
swupdate:logPaths:swupdateAccessLog = "/var/log/swupd/swupd_access_log"
swupdate:logPaths:swupdateErrorLog = "/var/log/swupd/swupd_error_log"
swupdate:logPaths:swupdateServiceLog = "/var/log/swupd/swupd_syncd_log"
swupdate:readWriteSettingsVersion = 1
swupdate:checkError = no
swupdate:pluginVers = "10.8.91 (91)"
swupdate:updatesDocRoot = "/var/db/swupd/"
swupdate:hostServiceState = "RUNNING"
swupdate:autoMirror = no
swupdate:numOfEnabledPkg = 0
swupdate:servicePortsAreRestricted = "NO"
swupdate:numOfMirroredPkg = 0
swupdate:autoMirrorOnlyNew = no
swupdate:startTime = 2012-08-04 17:04:45 +0000
swupdate:autoEnable = no
There are also a number of options available using the serveradmin settings that aren’t exposed to the Server app. These include a feature I used to use a lot in the beginning of deployments with poor bandwidth, only mirroring new updates, which is available to swupdate via the autoMirrorOnlyNew option. To configure:
sudo serveradmin settings swupdate:autoMirrorOnlyNew = yes
Also, the service can throttle bandwidth for clients. To use this option, run the following command:
sudo serveradmin settings swupdate:limitBandwidth = yes
And configure bandwidth using the syncBandwidth option, as follows:
sudo serveradmin settings swupdate:syncBandwidth = 10
To automatically sync updates but not enable them (as the checkboxes allow for in the Server app, use the following command:
sudo serveradmin settings swupdate:autoEnable = no
The port (by default 8088) can be managed using the portToUse option, here being used to set it to 80 (clients need this in their catalog URL from here on out):
sudo serveradmin settings swupdate:portToUse = 80
Finally, administrators can purge old packages that are no longer needed using the PurgeUnused option:
sudo serveradmin swupdate:PurgeUnused = yes
One of the biggest drawbacks of the Software Update service in OS X Mountain Lion Server in my opinion is the fact that it does not allow for serving 3rd party packages, from vendors such as Microsoft or Adobe. To provide those vendors with a manifest file and a quick little path option to add those manifest files, a nice middle ground could be found between the Mac App Store and the built in software update options in OS X. But then, we wouldn’t want to make it too easy.
Another issue many have had is that users need administrative passwords to run updates and don’t have them (technically this isn’t a problem with the OS X Server part of the stack, but it’s related). While many options have come up for this, one is to just run the softwareupdate
command for clients via ARD or a similar tool.
Many environments have used these issues to look at tools such as reposado
or third party patch management tools such as JAMF Software’s the Casper Suite (JAMF also makes a reposado-based VM that mimics the swupdate options), FileWave, Absolute Manage and others. Overall, the update service in Mountain Lion is easily configured, easily managed and easily deployed to clients. It is what it needs to be for a large percentage of OS X Mountain Lion (10.8) Server administrators. This makes it a very viable option and if you’ve already got a Mountain Lion computer sitting around with clients not yet using a centralized update server, well worth enabling.
Note: Managing multiple Software Update Servers has changed in OS X Mountain Lion Server, see my previous post for more information on these changes.
krypted August 5th, 2012
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
10.8, Apple Remote Desktop, centralized management, JAMF, Mac OS X, macs, mountain lion, os x mountain lion server, Patch Management, Reposado, server, Software Update Service, Software Updates
Mountain Lion has an application called Contacts. Mountain Lion Server has a service called Contacts. While the names might imply differently, surprisingly the two are designed to work with one another. The Contacts service was called Address Book in Lion and below and is based on CardDAV, a protocol for storing contact information on the web, retrievable and digestible by client computers. The Contacts service is also a conduit with which to read information from LDAP and display that information in the Contacts client, which is in a way similar to how the Global Address List (GAL) works in Microsoft Exchange.
I know I’ve said this about other services in Mountain Lion Server, but the Contacts service couldn’t be easier to configure. First, you should be running Open Directory and you should also have configured Apple Push Notifications. To setup Push Notifications, have an Apple ID handy and click on the name of the server in the Server app. Then click on Settings and check the box for “Enable Apple push notifications”.
Provide the username and password for the Apple ID and then click on Finish.
To enable the Contacts service, open the Server app and then click on Contacts in the SERVICES section of the List Pane. From here, use the “Include directory contacts in search” checkbox to publish LDAP contacts through the service, or leave this option unchecked and click on the ON button to enable the service.
The Contacts service then starts and once complete, a green light appears beside the Contacts entry in the List Pane. To configure a client open the Contacts application on a client computer and use the Preferences entry in the Contacts menu to bring up the Preferences screen. From here, click Accounts and then click on the plus icon (“+”).
At the Add Account screen, select CardDAV from the Account type field and then provide a valid username from the users configured in Server app as well as the password for that user and the name or IP address of the server. Then click on the Create button.
When the account is finished creating click on the Server Settings tab if a custom port is required. Otherwise, close the Preferences/Accounts screen and then view the list of Contacts. Click on the name of the server in the Contacts sidebar list. There won’t be any contacts yet, so click on the plus sign to verify you have write access to the server.
To create additional lists of contacts, hover over the name of the server and a plus sign appears, click on it to create a group on the Contacts service.
Next, let’s get access to the LDAP-based contacts. To do so, bring up the Add Account screen again and this time select LDAP from the Account Type field.
Provide the name or IP address of the server and then the port that LDAP contacts are available over (the defaults, 389 and 636 with SSL are more than likely the settings that you’ll use. Then click on the Continue button.
At the Account Settings screen, provide the name that will appear in the Contacts app for the account in the Description field and then enter the search base in the Search base field. To determine the search base, use the serveradmin command. The following command will output the search base:
sudo serveradmin settings dirserv:LDAPSettings:LDAPSearchBase
Then set Authentication to simple and provide the username and password to access the server for the account you are configuring. The list then appears.
The default port for the Contacts service is 8443, as seen earlier in the configuration of the client. To customize the port, use the serveradmin command to set addressbook settings for BindSSLPorts to edit the initial array entry, as follows:
sudo serveradmin settings addressbook:BindSSLPorts:_array_index:0 = 8443
The default location for the files used by the Contacts service is in the /Library/Server/Calendar and Contacts directory. To change that to a folder called /Volumes/Pegasys/CardDAV, use the following command:
sudo serveradmin settings addressbook:ServerRoot = "/Volumes/Pegasys/CardDAV"
The service is then stopped with the serveradmin command:
sudo serveradmin stop addressbook
And started with the serveradmin command:
sudo serveradmin start addressbook
And whether the service is running, along with the paths to the logs can be obtained using the fullstatus command with serveradmin:
sudo serveradmin fullstatus addressbook
The output of which should be as follows:
addressbook:setStateVersion = 1
addressbook:logPaths:LogFile = "/var/log/caldavd/access.log"
addressbook:logPaths:ErrorLog = "/var/log/caldavd/error.log"
addressbook:state = "RUNNING"
addressbook:servicePortsAreRestricted = "NO"
addressbook:servicePortsRestrictionInfo = _empty_array
addressbook:readWriteSettingsVersion = 1
If you’re easily amused, run the serveradmin settings for calendar and compare them to the serveradmin settings for addressbook:
sudo serveradmin settings calendar
By default, the addressbook:MaxAllowedInstances is 3000. Let’s change it for calendar:
sudo serveradmin serveradmin settings calendar:MaxAllowedInstances = 3001
And then let’s see what it is in addressbook:
serveradmin settings addressbook:MaxAllowedInstances
If two services share a port and share all the same settings and even a binary then are they in fact the same service?
You know, there’s a million fine looking women in the world, dude. But they don’t all bring you lasagna at work. Most of ’em just cheat on you.
krypted August 3rd, 2012
Posted In: Mac OS X, Mac OS X Server
8443, addressbook, caldavd, carddav, common apple ports, finding search base, Mac OS X, Mac OS X Server, mountain lion, mountain lion server, os x mountain lion server, people, ports, search base, server, serveradmin settings, serveradmin settings addressbook, using ldap contacts
Mail is one of the hardest services to manage. Actually, mail is pretty simple in and of itself: there’s protocols people use to access their mail (such as IMAP and POP), protocols used to communicate between mail servers and send mail (SMTP, SMTPS) and then there’s a database of mail and user information. In Mount Lion Server, all of these are represented by a single ON button, so it really couldn’t be easier. But then there’s the ecoysystem and the evil spammers.
As a systems administrator of a large number of mail servers, I firmly believe that there is a special kind of hell where only spam is served at every meal for spammers. Here, the evil spammers must also read every piece of spam ever sent for eternity. By the end (aka Ragnarok), they should be fairly well hung, have chemically induced stamina of a 16 year old with the latest Sports Illustrated Swimsuit issue, enough pills of other types to not be able to use that stamina, plenty of African princes looking to donate large sums of money if only they can be helped out of their country (which should cost about 100,000 compared to a 5,000,000 payout, not a bad ROI, right?!?!?), have their conflicting stamina situation at the top of the search engines and of course, have lost all of the money made from their African princes due to getting their credit card hijacked by about 9,000 phishing scams. All in all, a special kind of hell…
But back to the point of the article, setting up mail… The things that mail administrators need to focus on to keep that mail server flowing mail to and from everyone else in the world:
- Static IP address. The WAN (and LAN probably) address should be static.
- Port Forwards. Port forwards need to be configured on the gateway for the SMTP port at a minimum and more than likely other ports used to access mail on client devices (25, 143, etc)
- DNS records. An MX record and some kind of mail.domain.com type of record should definitely be configured for the DNS servers that are authoritative for the domain. There should also be reverse records for the address of the server, usually created by the Internet Services Provider, or ISP, that match that record.
- Check the RBLs. If you have a new IP address you’ll be putting a DNS server on, check all the major Realtime BlackLists to make sure that some evil spammer hasn’t squatted on the IP before you got to it. This is true whether you’re in a colo, hosted on an IP you own or moving into space formerly occupied by a very standup company. A lot of IP addresses are blocked, as are blocks of IPs, so before moving mail to an IP, check it.
- Mail filtration (message hygiene). OS X Server has a number of mail filters built in, including clam for viruses, the ability to leverage RBLs, block specific addresses and of course RBL checking. However, this is often not enough. Third party services such as MXLogic help to keep mail from coming into your network. You also end up with an external IP to send mail that can cache mail in the event the server is down and keep mail off your network in the event that it’s spam.
- Backup. I am firmly of the belief that I’d rather not have data than not have that data backed up…
Once all of that is taken care of (I’ll add more as I think about it) then it’s time to enable the mail service. Actually, first let’s setup our SSL certificates. To do so, open the Server app and click on the name of the server in the HARDWARE section of the sidebar. Then click on the Settings tab and then the Edit button beside the SSL Certificate entry. Here, use the Certificate drop-down list for each protocol to select the appropriate certificate to be used for the service.
Click OK when they’re all configure. Now let’s enable the mail service (or outsource mail). To do so, open the Server app and click on Mail in the SERVICES list in the sidebar.
At the configuration screen is a sparse number of settings:
- Provide mail for: Configures all of the domains the mail server will listen for mail for. Each account on the server has a short name and each domain name will be available for each short name. For example, an account with a shortname of charles will be available for email addresses of firstname.lastname@example.org and email@example.com per the Domain Name listing below.
- Authentication: Click Edit for a list of sources that accounts can authenticate against (e.g. Active Directory, Open Directory, Custom, Local, etc) and in some cases the specific password algorithms used for mail.
- Relay outgoing mail through ISP: Provide a server that all mail will get routed through from the server. For example, this might be an account with your Internet Services Provider (ISP), an account on an appliance that you own (such as a Barracuda) or with an external filtering service (such as MXLogic).
- Limit mail to: Configure the total amount of mail a user can have in the mail store, in Megabytes.
- Edit Filtering Settings: Configure antivirus, spam assassin and junk mail filters. The “Enable virus filtering” checkbox enables clam. The “Enable blacklist filtering” checks the RBL (or RBLs) of your choice to check whether a given server is a “known” spammer and the “Enable junk mail filtering” option enables spam assassin on the host, configuring it to block based on a score as selected using the slider.
Once you’ve configured the settings for the Mail service, click on the ON slider to enable the service. At this point, you should be able to telnet into port 25 of the host to verify that SMTP is listening, preferably from another mail server:
telnet mail.krypted.com 25
You can also check that the mail services are running using the serveradmin command along with the fullstatus option for the mail service:
sudo serveradmin fullstatus mail
Which returns with some pretty verbose information about the service, including state, connections, running protocols and the rest of the following:
mail:setStateVersion = 1
mail:readWriteSettingsVersion = 1
mail:connectionCount = 0
mail:servicePortsRestrictionInfo = _empty_array
mail:protocolsArray:_array_index:0:status = "ON"
mail:protocolsArray:_array_index:0:kind = "INCOMING"
mail:protocolsArray:_array_index:0:protocol = "IMAP"
mail:protocolsArray:_array_index:0:state = "RUNNING"
mail:protocolsArray:_array_index:0:error = ""
mail:protocolsArray:_array_index:1:status = "ON"
mail:protocolsArray:_array_index:1:kind = "INCOMING"
mail:protocolsArray:_array_index:1:protocol = "POP3"
mail:protocolsArray:_array_index:1:state = "RUNNING"
mail:protocolsArray:_array_index:1:error = ""
mail:protocolsArray:_array_index:2:status = "ON"
mail:protocolsArray:_array_index:2:kind = "INCOMING"
mail:protocolsArray:_array_index:2:protocol = "SMTP"
mail:protocolsArray:_array_index:2:state = "RUNNING"
mail:protocolsArray:_array_index:2:error = ""
mail:protocolsArray:_array_index:3:status = "ON"
mail:protocolsArray:_array_index:3:kind = "OUTGOING"
mail:protocolsArray:_array_index:3:protocol = "SMTP"
mail:protocolsArray:_array_index:3:state = "RUNNING"
mail:protocolsArray:_array_index:3:error = ""
mail:protocolsArray:_array_index:4:status = "ON"
mail:protocolsArray:_array_index:4:kind = "INCOMING"
mail:protocolsArray:_array_index:4:protocol = "Junk_mail_filter"
mail:protocolsArray:_array_index:4:state = "STOPPED"
mail:protocolsArray:_array_index:4:error = ""
mail:protocolsArray:_array_index:5:status = "ON"
mail:protocolsArray:_array_index:5:kind = "INCOMING"
mail:protocolsArray:_array_index:5:protocol = "Virus_scanner"
mail:protocolsArray:_array_index:5:state = "STOPPED"
mail:protocolsArray:_array_index:5:error = ""
mail:startedTime = "2012-07-30 18:14:26 +0000"
mail:logPaths:IMAP Log = "/Library/Logs/Mail/mailaccess.log"
mail:logPaths:Server Log = "/Library/Logs/Mail/mailaccess.log"
mail:logPaths:POP Log = "/Library/Logs/Mail/mailaccess.log"
mail:logPaths:SMTP Log = "/var/log/mail.log"
mail:logPaths:Migration Log = "/Library/Logs/MailMigration.log"
mail:logPaths:Virus Log = "/Library/Logs/Mail/clamav.log"
mail:logPaths:Amavisd Log = "/Library/Logs/Mail/amavis.log"
mail:logPaths:Virus DB Log = "/Library/Logs/Mail/freshclam.log"
mail:imapStartedTime = "2012-07-30 18:14:26 +0000"
mail:servicePortsAreRestricted = "NO"
mail:state = "RUNNING"
mail:postfixStartedTime = "2012-07-30 18:14:49 +0000"
To stop the service:
sudo serveradmin stop mail
And to start it back up:
sudo serveradmin start mail
To configure some of the settings no longer in the GUI from previous versions, let’s look at the full list of options:
sudo serveradmin settings mail
One that is commonly changed is the subject line added to messages that are marked as spam by spam assassin. This is stored in mail:postfix:spam_subject_tag, so changing would be:
sudo serveradmin settings mail:postfix:spam_subject_tag = "***DIEEVILSPAMMERSDIE*** "
A number of admins also choose to disable greylisting, done using the mail:postfix:greylist_disable option:
sudo serveradmin settings mail:postfix:greylist_disable = no
To configure an email address for quarantined mail to go, use mail:postfix:virus_quarantine:
sudo serveradmin settings mail:postfix:virus_quarantine = "firstname.lastname@example.org"
The administrator, by default, doesn’t get an email when an email containing a file infected with a virus is sent through the server. To enable this option:
sudo serveradmin settings mail:postfix:virus_notify_admin = yes
I also find a lot of Mac environments want to accept email of pretty much any size. By default, message size limits are enabled. To disable:
sudo serveradmin settings mail:postfix:message_size_limit_enabled = yes
Or even better, just set new limit:
sudo serveradmin settings mail:postfix:message_size_limit = 10485760
And to configure the percentage of someone’s quota that kicks an alert (soft quota):
sudo serveradmin settings mail:imap:quotawarn = 75
Additionally, the following arrays are pretty helpful, which used to have GUI options:
- mail:postfix:mynetworks:_array_index:0 = “127.0.0.0/8” – Add entries to this one to add “local” clients
- mail:postfix:host_whitelist = _empty_array – Add whitelisted hosts
- mail:postfix:blacklist_from = _empty_array – Add blacklisted hosts
- mail:postfix:black_hole_domains:_array_index:0 = “zen.spamhaus.org” – Add additional RBL Servers
The client side of the mail service is straight forward enough. If you are wondering where in this article we discuss using webmail, er, that’s not installed by default any longer. But the open source project previously used, roundcube, is still available for download and easily installed (the pre-reqs are all there, already). Check out the roundcube wiki installation page
here for more info on that. Also, mail groups. I hope to have a post about that soon enough. Unless, of course, I get sidetracked with having a life. Which is arguably not very likely…
krypted July 31st, 2012
Posted In: Mac OS X, Mac OS X Server, Mac Security
configure, Mac OS X Server, mail, mail groups, Mail Server, mountain lion, os x mountain lion server, postfix, roundcube, server.app, serveradmin, webmail, wiki