Am Do, den 15.07.2004 schrieb James Kosin um 22:45: > | Maybe a little misunderstanding: the default entry in Sendmail.conf is > | "pwcheck_method:saslauthd". Then the saslauthd must be running (service > | saslauthd status). The saslauthd is by default configured to auth > | against the shadow file. If you want to change that you will have to > | create a file /etc/sysconfig/saslauthd with content i.e. "MECH=pam", > | this will override the setting in the init script. > > There is a file /etc/sysconfig/saslauthd that I did not create. It > contains the following: > # To read about how postfix uses saslauthd read this: > # /usr/share/doc/postfix-*/README-Postfix-SASL-RedHat.txt > # > # To see a list of authentication mechanisms supported by saslauthd > execute this command > # /usr/sbin/saslauthd -v > # > # Default to pam > MECH=pam > > Maybe this is another postfix change.... When I installed FC1, I > usually install everything. It saves having to find something when I > need it. Ok, I did not know that the Postfix package comes with that file and that it has a different default setup for AUTH than Sendmail. > Should I set the entry in Sendmail.conf to pwcheck_method:saslauthd. > Then change the /etc/sysconfig/saslauthd to use shadow? Maybe, I'm a > little confused how this is suppose to work properly..... You can leave your setup as it is now. But I think the SASL developers have a reason why the version 2 of SASL has the saslauthd daemon service running for authentification and not letting the application directly communicate with the AUTH MECHs. Decide yourself what you like. The default would be to set /usr/lib/sasl2/Sendmail.conf to pwcheck_method:saslauthd and the saslauthd either use MECH=pam or MECH=shadow (first seems Postfix package setup, second is Sendmail package setup). Be sure the saslauthd is enabled by running "chkconfig saslauthd on". > | I don't know what you did, but it sounds not proper. The cacert is > | something very different then the client certificates as ipop3d.pem. > | Maybe should post you a brief description of the necessary steps. > | > > The ipop3d.pem is needed for the server to authenticate with the client > when connecting. The client then imports this certificate into its > database of accepted certs. The ipop3d.pem is a server cert that > identifies (in my case the server: beta.support.intcomgrp.com on IP > 192.168.10.20). Of course that is right. I just wondered about the steps you did as that sounded to me like something wrong. See the reply by Mike to your mail. His first posted link describes creating self-signed certificates not using the CA.sh|CA.pl scripts but directly calling the OpenSSH functions, but that is not so important. Important is the fact, that it very clearly shows you what which part of the files created is! Handling the serial is in that description necessary because it does not create a demo_CA hierarchy. The serial is important of you would work with revocations. > | One last note: The default setting in sendmail.mc is not to force > | STARTTLS being active for PLAIN and LOGIN AUTH. If you did not already > | change that, then change that to allow LOGIN and PLAIN only after > | STARTTLS has been done: > | > | define(`confAUTH_OPTIONS', `A p')dnl > | > | Else it matters how the user configured his client, if he did activate > | SSL/TLS in his mail client. And you know, never trust the user. > > Already done... although I've even seen one setup on the web that > suggests `A p y'. Yes, the "y" parameter means not allowing anonymous logins. I too use define(`confAUTH_OPTIONS', `A p y')dnl > James Hope I did not confuse you more :) Alexander -- Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13 Fedora GNU/Linux Core 2 (Tettnang) Athlon CPU kernel 2.6.6-1.435.2.3.uml Serendipity 01:20:21 up 2 days, 23:02, load average: 0.78, 0.33, 0.15
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
