Apple Event: May 7th at 7 am PT
I have followed the advice in http://support.apple.com/kb/TS3023 to solve this but the main.cf file keeps reverting back to the original meaning I am having to re-apply this patch this every few hours at the moment.
Not sure whether this is happening when I stop and restart mail, reboot or edit some of the other postfix settings as I install roundcube - but it is extremely annoying. Any ideas?
Solution is to edit the right postfix configuration file - there seem to be two postfix directories - one left over from the SLS restore from a Time Machine backup
Go to /Library/Server/Mail/Config/postfix/main.cf and add the kocal network ip address range to the mynetworks declation at the end of the file. It should read:
mynetworks = 127.0.0.0/8, [::1]/128
change to
mynetworks = 127.0.0.0/8, [::1]/128, 192.168.0.1/24
replacing 192.168.0.1/24 with your local subnet range.
All clients on the LAN can then send email - Outlook and as a bonus clients that cannot authenticate (e.g. HP printers and (as an added bonus for me) other devices which send notification emails).
This is an inelegant solution and you risk having to reapply the patch as Serveradmin periodically overwrites main.cf
When you have edited the file run:
cp main.cf main.cf.backup1
You can then easily reverse the command to restore the updated file after Serveradmn has re-written it. Hopefully Apple will come up with a more elegant solution to this problem - and not revert to the bad old days of excluding all non-apple devices and software from working with their products.
To make your settings permanent , you have three options.
The least preferred is to make the change to the config file. As you've found, these changes get nuked ever time you make a change via server.app .
Option 2 is to find the default config file , make a copy and then make the change to the default file as well. So in your case, copy main.cf.default to main.cf.default.10.8.2 and then edit main.cf.default as well as main.cf . This way, when server.app makes the changes , it uses a file that already has the edit. However, this doesn't protect you from OS X server updates in the future.
The most preferred is to use the tools provided by Apple.
So the easiest and most ( but not guaranteed) future-proof method is to use serveradmin from the command line for those change that can not be made in the server.app GUI.
Any setting you see in serveradmin can be changed by serveradmin command and will be permanent unless you make a change to the same setting via the server.app GUI.
I.e
$ sudo serveradmin settings mail:postfix:mynetworks:_array_index:0 = 192.168.0.0/16
I'm pretty sure that the way to specify the range is as follows - 192.168.10.0/8 or 192.168.0.0/16 or 192.0.0.0/24
Should do the trick!
Cheers
Gerry
Gerry,
Thank you very much for the syntax to get serveradmin to write the changes.
I need 192.168.1.0/24 - to address range 192.168.0.1 - 192.168.1.254.
I will get back to you on the ManageSieve errors - this forum was down all day yesterday - some progress but no solution.
Nick
Sorry my bad re the tcp mask :)
I helped someone setup Roundcube and managesieve from scratch yesterday and it took around 90 minutes including downloads. I'm going to take a guess and say that the tcp port that the sieve listens on in 10.8 is different to 10.6 but I guess we'll see!
Gerry
Is it possible to also get serveradmin to manage the other edits needed to main.cf:
namely remove:
"reject_non_fqdn_helo_hostname" from the
smtpd_helo_restrictions = declaration and;add:"permit_sasl_authenticated"
Outlook clients should then be able to authenticate with the SMTP server from inside and outside the LAN.
This removes the problem to second guessing when OSX has decided to ovewrite the config files
Nick, sorry - don't know - you could try!
Otherwise , make a backup of main.cf.default and make the change to main.cf and main.cf.default and then copy the altered main.cf.default to another backup file - say main.cf.default.myfixes . That way, at worst when you do an operating system upgrade , you may have to copy your altered main.cf.default.myfixes file back to main.cf.default.
Cheers
Gerry
Actually, you can keep the rejection for non-FQDN so long as the "permit_sasl_authenticated" comes first in the helo restrictions.
The article available here presents a good discussion of how to deal with this robustly and securely. It is related to several of the other suggestions in this thread.
These changes leave the HELO restriction in place unless he user is authenticated or is on the local network.
Note that you also need to set mynetworks appropriately. If, for example, you are on the ubiquitous class C home network 192.168.1.*, then you need to do the following as well:
1) QUIT (not close) Server Admin and open Terminal
2) Check your current config with this command:
sudo postconf -c /Library/Server/Mail/Config/postfix mynetworks
3) In most cases, you will get back just the following. If you get something more like what is shown in (5), then someone already did this and you can stop.
mynetworks = 127.0.0.0/8,[::1]/128
4) If your "mynetworks" looks like the one above, then execute these two commands:
sudo postconf -c /Library/Server/Mail/Config/postfix -e "mynetworks=127.0.0.0/8,192.168.1.0/24,[::1]/128
sudo postfix reload
5) Repeat step 2 and you should get this:
mynetworks = 127.0.0.0/8,192.168.1.0/24,[::1]/128
Ok - so to be complete, here is the solution from the link above as added steps...
6) Enter these commands to set postfix to let the FQDN restriction "slide" for local network and authenticated users:
postconf -e "smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated reject_non_fqdn_helo_hostname reject_invalid_helo_hostname"
sudo postfix reload
I have been running this way for a couple of months (OS X Mountain Lion Server 2.2.1 and now 2.2.2) with no problems having these changes overwritten. This includes surviving a couple of config changes from Server Admin and several reboots.
(I do make the changes using the postconf command in the terminal, and not by hand editing the config files as others are suggesting, although I can't say whether this really makes any difference as far as protection from overwriting.)
Outlook: Helo command rejected: need fqdn