At 11:53 PM +0800 2004-09-08, David Cake wrote:
The only error I seem to be getting is dangerous permissions=42755 on queue directory /var/spool/mqueue-client/ which I can't seem how to turn off - I'm not even sure why its there are all, given that dir is not group or world writable - or how to turn off this warning with DontBlameSendmail
The problem could be with a parent directory above this one. Or, it could be with a parent directory of a symbolic link pointing to something in this path. This can be a difficult one to debug.
Oh, joy.
Its not in /var/ or /var/spool, can't find anything in any place sendmail might be using that would link to here.
sendmail -v -d44.4 -bv listname claims its deliverable, and reports only a warning (which DontBlameSendmail should have dealt with)
check_perms is happy.
I really am beginning to run out of ideas.
(DontBlameSendmail? I want to go round to Eric Allmans house and slap him)
Everyone was riding Eric's case because there were so many ways that people were finding to break into systems via weaknesses that were not directly the fault of sendmail, but through which sendmail gave them an attack vector. He nearly killed himself tightening down the security for version 8 sendmail so that this sort of thing was no longer possible.
Yes. I am well aware of what those settings means, and why they are called that. I have no urge to blame Eric for any security flaws that might result from using them. He must, at least, bear some responsibility for the extraordinary difficulty of diagnosing why sendmail won't do what it should, though.
Unfortunately, there are an infinite number of vendors who ship an infinite number of systems that are themselves broken in one way or another, and where the extremely strict security model insisted upon by sendmail will cause other things to break.
That's why Eric came up with this option, so as to allow you to shoot yourself in the foot (or blow it off with thermonuclear weapons), if you so chose -- but he made sure that you would have to explicitly configure sendmail to do that, and he made sure that when the worst did happen as a result, you couldn't blame sendmail for your security breach.
Yes, indeed, I do not. But I can blame sendmail for being an overcomplex, incomprehensible, hard to debug, sanity damaging nightmare. Which I understand the historical basis for. But nevertheless, the frustration is very real, and aspects of sendmails design significantly contribute to that ongoing issue, aspects that Eric Allman has been known to deride himself.
Don't get me wrong, I appreciate the pioneering efforts of those involved in the creation of sendmail (and .oz.au for that matter), but not having to live with certain dubious design decisions decades later.
Just a couple more weeks and my last sendmail server moved to postfix. Can't wait. But will I ever get mailman working in the meantime.
If you want to tangle with me, I'll be glad to meet you in a dark alley at an upcoming LISA or SANE conference. Just let me know when and where.
Surely the appropriate when and where for that sort of thing is behind the bike sheds after school during junior high.
Cheers
David
... I felt very ambiguous about
creating something which I looked at and said "This is a monstrosity
by almost any reasonable definition." - Eric Allman
How did this happen? I should have gotten wise and said, "Wait! Something's wrong." - Eric Allman (referring to sendmail config file format)
------------------------------------------------------ Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
