I do not use any of the DONTBLAMESENDMAIL options, but I also have root access
to the majordomo boxes that I manage. Even though I might use a majordomo.alias
file in the majordomo directory, I create a root owned link to it in /etc/mail,
then in the sendmail.cf (or .mc) I point my second aliases file to that link. I
also create a link in /etc to my majordomo.cf file. My directories are 755, and
list membership files are all majordomo.majordomo 644 permissions. The .config
files are 660.
http://www.sonny.com/majordomo/docs/Install.How-To
Dan Liston
Adam H. Kerman wrote:
> As you know, I had a great time troubleshooting problems related to Sendmail
> 8.12.7 and Majordomo on a SuSE linux host. I thought perhaps that SuSE had
> configured Sendmail oddly but that turned out not to be the case. One atypical
> thing SuSE does that I noticed, turning on the HOST STATUS DIRECTORY option,
> wasn't the cause of error messages.
>
> Nah. It's all the security changes made in Sendmail starting in 8.9. I resorted
> to RTFM once I found it. That FM is FAQ.sendmail.bz2 Q3.32 in the Sendmail
> distribution included in SuSE. I followed its recommendations.
>
> The answer is updated from something someone wrote in 1999. Does anyone know
> who the author is to get permission to incorporate it into the Majordomo docs?
>
> I still don't understand why certain DONTBLAMESENDMAIL options are turned on,
> such as TrustStickyBit and IgnoreGroupWritable yet I couldn't put the
> majordomo.aliases file in the majordomo user's directory, owner.group
> majordomo.majordomo WITH THE STICKY BIT SET and why I had to change list file
> permissions to 644. Why were the DONTBLAMESENDMAIL options ignored?
>
> Does anyone know how to get the initial list.config file created as owner.group
> majordomo.majordomo rather than root.mail? I assume that's another sendmail
> issue.
>
> Aargh. MTAs are complicated.
Follow-Ups:
References:
|
|
