|
|
Fixing Sendmail after March 2003 Security Update
Are you trying to run sendmail 8.12.x (the march security update was to 8.12.8; MacOSX 10.2.4 came with 8.12.6) using old sendmail.cf files from 8.11? (My best guess is that you are not running Jaguar, or have not been keeping up with the updates, as Apple's been using Sendmail 8.12 (and hence submit.cf) for a while now.) That's a really bad idea, as is subverting the MSP process by tricking it into using sendmail.cf instead of submit.cf. You should sit down and create new 8.12 configuration files. Sendmail will work better and will be more secure if you do. Oh, and make sure that /System/Library/StartupItems/Sendmail/Sendmail says: /usr/sbin/sendmail -L sm-mta -bd -q1h & /usr/sbin/sendmail -L sm-msp-queue -Ac -q 20m & as the lines to startup sendmail (one as an MTA, one as an MSP, using, respectively sendmail.cf and submit.cf). Apple spooged this on their first go-around.
Fixing Sendmail after March 2003 Security Update
Thanks for the tip. I am running all the latest updates, but my original Sendmail config files were back from 10.2 or 10.2.1. I had recreated them after the March security update, but things still didn't work. I'll be making the appropriate changes to my Sendmail config this morning.
Confusion
Maybe somebody could straighten out us poor slobs who learned everything we know about sendmail from James Duncan Davidson's article Configuring sendmail on Jaguar.
For those sendmail experts who don't have the time to read that article, my summary of what it does is: o Copy the file /usr/share/sendmail/conf/cf/generic-darwin.mc to /etc/mail/config.mc and modify it o Run the new file through m4 with
> m4 /usr/share/sendmail/conf/m4/cf.m4 /etc/mail/config.mc > /tmp/sendmail.cf
o Replace /etc/mail/sendmail.cf with the new /tmp/sendmail.cf o Tell sendmail to use /etc/mail/sendmail.cf via netinfo with
> sudo niutil -create . /locations/sendmail
Security Update 2003-03-03 fixed and updated sendmail but seems to have broken sendmail's former ability to read /etc/mail/sendmail.cf when told to by netinfo. I've seen several "cures": o Replace the /etc/mail/submit.cf file with my /etc/mail/sendmail.cf file. This got sendmail going again but sounded dangerous because sendmail is called twice for two different functions, and, I thought, once with sendmail.cf and once with submit.cf. o Modify /System/Library/StartupItems/Sendmail/Sendmail so that the first call to sendmail gets the "-Am" switch, which forces it to use /etc/mail/sendmail.cf. This sounded safer because the second invocation still gets to use its original submit.cf. o The posting above indicates we should make brand new .cf files, but I don't know how to make a new one that isn't exactly the same as the one I already made and want to use. And I don't know how a submit.cf file should differ from a sendmail.cf file. Is there anything clean and relatively simple that we can do that doesn't involve turning off sendmail, or understanding all of sendmail, or suffering until James Duncan Davidson writes a new article? Thanks for listening, jzsimon p.s. Speaking for myself, all I want to do is to read email sent locally by cron jobs--I don't even want sendmail to know about the rest of the internet if I can help it.
Confusion
This is generic advice for producing a new (customized) sendmail.cf. In the end, /etc/mail/ should have a sendmail.cf and a submit.cf file.
Utterly unnecessary. The default location for sendmail to find its configuration files is in /etc/mail. Unless you've overridden this in NETINFO, sendmail will work fine without this. (Which is why Apple didn't do it.)
Both of these are wrong. The first invocation, with the "-bd" flag will cause sendmail to use sendmail.cf. The second invocation, with the "-Ac" flag will cause it to use submit.cf.
Running the same sendmail.mc file through m4 with the cf/ from a new version of sendmail will produce a different sendmail.cf file as output (which is why it is good practice to rebuild your .cf files when updating sendmail). Of course, if your /usr/share/sendmail/conf/ contains the config files from an old version of sendmail, you'll get the old version of sendmail.cf out. If that's the case, you may need to download the sendmail sourcecode from sendmail.org and use the cf/ directory found there instead of /usr/share/sendmail/conf/ to build your new *.cf files.
I didn't think very highly of the article in the first place, and I can see that it has caused more confusion than enlightenment. The instruction for building the *.cf files from the sendmail 8.12.8 source directory is % cd cf/cf % cp [your customized .mc file] sendmail.mc % ./Build sendmail.cf % sudo make install-cf % sudo /System/Library/StartupItems/Sendmail/Sendmail restart Mr. Davidson makes it all sound much more complicated than it is.
hostnameProblems
No updates 'broke' sendmail for me precisely because that is the procedure that I was following. i.e. regenerate the .cf files. One problem has been created though. When I set up sendmail in the first place I used the line
define(`confDOMAIN_NAME', `myDomain.com')
to make outgoing mail come from user@myDomain.com. This broke with the updates, so now mail comes from user@machine-name.local.
Any suggestions on how to fix this?
Thanks,
DC.
Confusion
Thanks for the thoughtful reply. Unfortunately I'm still confused because some of the things you said do not seem to be valid on my system:
Confusion
From the sendmail manpage: Parameters -Ac Use submit.cf even if the operation mode does not indicate an initial mail submission. -Am Use sendmail.cf even if the operation mode indi- cates an initial mail submission. -bd Run as a daemon. Sendmail will fork and run in background listening on socket 25 for incoming SMTP connections. -Cfile Use alternate configuration file. Sendmail refuses to run as root if an alternate configuration file is specified. So I'm pretty sure "-bd" ought to imply "sendmail.cf". There is a subtle difference between "-Csubmit.cf" and "-Ac". When in doubt, I'd use the latter.
Again, which .cf file to use should be determined by how sendmail is envoked. If the envocation is as I wrote in my first post, you should not need NETINFO to tell it. It can only trip you up down the road (my experience).
Easily remedied, eh?
I think there are a lot better tutorials on sendmail available on the 'net. They may not be MacOSX specific, but the only truly MacOSX-specific aspects of Davidson's article were
Confusion
Well, guess what. I'm still confused. Is anyone out there willing to post step-by-step instructions for those of us who used the O'Reilly method (dontblamesendmail) to get sendmail running ought to do after applying the latest security update?
Confusion
I too would like to see what changes (step by step) are needed inside
a little less confused now
Thanks for the info and instructions professor, this helped me a lot.
A few days ago my ISP had sent me email after their' scan determined I was using the old sendmail so I am eager to make sure I really am using the latest Sendmail. I downloaded the latest source from sendmail.org. Then I copied /usr/share/sendmail/conf/cf/generic-darwin.mc to sendmail.mc and the rest of your instructions worked fine. (I am not using any custom mc, and this generic file with my 10.2.4 is the same as the latest one in the Darwin CVS, except for some reason mine has RBL configuration entries. http://www.opensource.apple.com/cgi-bin/registered/cvs/sendmail/sendmail/cf/cf/generic-darwin.mc) Now when I telnet localhost 25, I see "Sendmail 8.12.7/8.12.8" which is looking better, previously it showed "Sendmail 8.12.7/8.12.2". I'm still a little troubled that part of the Sendmail version string appears to be the old version, and not 8.12.8. Also:
tells me:
Any suggestions?
Confusion
I installed security update over 10.2.4 and sendmail sends my cron jobs exactly as written in the articles. Don't know what changed on your system. |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysNo new commentsLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.06 seconds |
|