Here's the output of a grep of "dnl"
The netstat -talpen |grep :25 returned nothing.
divert(-1)dnl dnl # dnl # This is the sendmail macro config file for m4. If you make changes to dnl # /etc/mail/sendmail.mc, you will need to regenerate the dnl # /etc/mail/sendmail.cf file by confirming that the sendmail-cf package is dnl # installed and then performing a dnl # dnl # make -C /etc/mail dnl # include(`/usr/share/sendmail-cf/m4/cf.m4')dnl VERSIONID(`setup for Red Hat Linux')dnl OSTYPE(`linux')dnl dnl # dnl # default logging level is 9, you might want to set it higher to dnl # debug the configuration dnl # dnl define(`confLOG_LEVEL', `9')dnl dnl # dnl # Uncomment and edit the following line if your outgoing mail needs to dnl # be sent out through an external mail server: dnl # dnl define(`SMART_HOST',`smtp.your.provider') dnl # define(`confDEF_USER_ID',``8:12'')dnl dnl define(`confAUTO_REBUILD')dnl define(`confTO_CONNECT', `1m')dnl define(`confTRY_NULL_MX_LIST',true)dnl define(`confDONT_PROBE_INTERFACES',true)dnl define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl define(`ALIAS_FILE', `/etc/aliases')dnl define(`STATUS_FILE', `/var/log/mail/statistics')dnl define(`UUCP_MAILER_MAX', `2000000')dnl define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl define(`confAUTH_OPTIONS', `A')dnl dnl # dnl # The following allows relaying if the user authenticates, and disallows dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links dnl # dnl define(`confAUTH_OPTIONS', `A p')dnl dnl # dnl # PLAIN is the preferred plaintext authentication method and used by dnl # Mozilla Mail and Evolution, though Outlook Express and other MUAs do dnl # use LOGIN. Other mechanisms should be used if the connection is not dnl # guaranteed secure. dnl # Please remember that saslauthd needs to be running for AUTH. dnl # dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl dnl # dnl # Rudimentary information on creating certificates for sendmail TLS: dnl # cd /usr/share/ssl/certs; make sendmail.pem dnl # Complete usage: dnl # make -C /usr/share/ssl/certs usage dnl # dnl define(`confCACERT_PATH',`/usr/share/ssl/certs') dnl define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt') dnl define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem') dnl define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem') dnl # dnl # This allows sendmail to use a keyfile that is shared with OpenLDAP's dnl # slapd, which requires the file to be readble by group ldap dnl # dnl define(`confDONT_BLAME_SENDMAIL',`groupreadablekeyfile')dnl dnl # dnl define(`confTO_QUEUEWARN', `4h')dnl dnl define(`confTO_QUEUERETURN', `5d')dnl dnl define(`confQUEUE_LA', `12')dnl dnl define(`confREFUSE_LA', `18')dnl define(`confTO_IDENT', `0')dnl dnl FEATURE(delay_checks)dnl FEATURE(`no_default_msa',`dnl')dnl FEATURE(`smrsh',`/usr/sbin/smrsh')dnl FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl FEATURE(redirect)dnl FEATURE(always_add_domain)dnl FEATURE(use_cw_file)dnl FEATURE(use_ct_file)dnl dnl # dnl # The following limits the number of processes sendmail can fork to accept dnl # incoming messages or process its message queues to 12.) sendmail refuses dnl # to accept connections once it has reached its quota of child processes. dnl # dnl define(`confMAX_DAEMON_CHILDREN', 12)dnl dnl # dnl # Limits the number of new connections per second. This caps the overhead dnl # incurred due to forking new sendmail processes. May be useful against dnl # DoS attacks or barrages of spam. (As mentioned below, a per-IP address dnl # limit would be useful but is not available as an option at this writing.) dnl # dnl define(`confCONNECTION_RATE_THROTTLE', 3)dnl dnl # dnl # The -t option will retry delivery if e.g. the user runs over his quota. dnl # FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl FEATURE(`blacklist_recipients')dnl EXPOSED_USER(`root')dnl dnl # dnl # The following causes sendmail to only listen on the IPv4 loopback address dnl # 127.0.0.1 and not on any other network devices. Remove the loopback dnl # address restriction to accept email from the internet or intranet. dnl # dnl # DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl dnl # dnl # The following causes sendmail to additionally listen to port 587 for dnl # mail from MUAs that authenticate. Roaming users who can't reach their dnl # preferred sendmail daemon due to port 25 being blocked or redirected find dnl # this useful. dnl # DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl dnl # dnl # The following causes sendmail to additionally listen to port 465, but dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1. dnl # dnl # For this to work your OpenSSL certificates must be configured. dnl # DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl dnl # dnl # The following causes sendmail to additionally listen on the IPv6 loopback dnl # device. Remove the loopback address restriction listen to the network. dnl # dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl dnl # dnl # enable both ipv6 and ipv4 in sendmail: dnl # dnl DAEMON_OPTIONS(`Name=MTA-v4, Family=inet, Name=MTA-v6, Family=inet6') dnl # dnl # We strongly recommend not accepting unresolvable domains if you want to dnl # protect yourself from spam. However, the laptop and users on computers dnl # that do not have 24x7 DNS do need this. dnl # FEATURE(`accept_unresolvable_domains')dnl dnl # dnl FEATURE(`relay_based_on_MX')dnl dnl # dnl # Also accept email sent to "localhost.localdomain" as local email. dnl # dnl LOCAL_DOMAIN(`localhost.localdomain')dnl dnl # dnl # The following example makes mail from this host and any additional dnl # specified domains appear to be sent from mydomain.com dnl # dnl MASQUERADE_AS(`mydomain.com')dnl dnl # dnl # masquerade not just the headers, but the envelope as well dnl # dnl FEATURE(masquerade_envelope)dnl dnl # dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well dnl # dnl FEATURE(masquerade_entire_domain)dnl dnl # dnl MASQUERADE_DOMAIN(localhost)dnl dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl dnl MASQUERADE_DOMAIN(mydomain.lan)dnl MAILER(smtp)dnl MAILER(procmail)dnl
Am So, den 06.11.2005 schrieb Sam Drinkard um 0:06:
dnl # DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl dnl # dnl # The following causes sendmail to additionally listen to port 587 for dnl # mail from MUAs that authenticate. Roaming users who can't reach their dnl # preferred sendmail daemon due to port 25 being blocked or redirected find dnl # this useful. dnl # DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
As you did set this
dnl # dnl # The following causes sendmail to additionally listen to port 465, but dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1. dnl # dnl # For this to work your OpenSSL certificates must be configured. dnl # DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
... and that
dnl # dnl # The following causes sendmail to additionally listen on the IPv6 loopback dnl # device. Remove the loopback address restriction listen to the network. dnl # dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl dnl # dnl # enable both ipv6 and ipv4 in sendmail: dnl # dnl DAEMON_OPTIONS(`Name=MTA-v4, Family=inet, Name=MTA-v6, Family=inet6')
you must instruct the MTA part too by DAEMON_OPTIONS. Either
DAEMON_OPTIONS(`Port=smtp,Name=MTA')dnl
or
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl DAEMON_OPTIONS(`Port=smtp,Addr=<public IP>, Name=MTA')dnl
Alexander
Alexander Dalloz wrote:
Am So, den 06.11.2005 schrieb Sam Drinkard um 0:06:
dnl # DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl dnl # dnl # The following causes sendmail to additionally listen to port 587 for dnl # mail from MUAs that authenticate. Roaming users who can't reach their dnl # preferred sendmail daemon due to port 25 being blocked or redirected find dnl # this useful. dnl # DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
As you did set this
dnl # dnl # The following causes sendmail to additionally listen to port 465, but dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1. dnl # dnl # For this to work your OpenSSL certificates must be configured. dnl # DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
... and that
dnl # dnl # The following causes sendmail to additionally listen on the IPv6 loopback dnl # device. Remove the loopback address restriction listen to the network. dnl # dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl dnl # dnl # enable both ipv6 and ipv4 in sendmail: dnl # dnl DAEMON_OPTIONS(`Name=MTA-v4, Family=inet, Name=MTA-v6, Family=inet6')
you must instruct the MTA part too by DAEMON_OPTIONS. Either
DAEMON_OPTIONS(`Port=smtp,Name=MTA')dnl
or
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl DAEMON_OPTIONS(`Port=smtp,Addr=<public IP>, Name=MTA')dnl
Alexander
I just now tried that and it turned on port 25. I was looking at that, but did not want IPv6 support, so didn't enable it. That really should be documented somewhere in the docs.. AFIK, I sure didn't find it, and I spent a good bit of time reading thru anything dealing with sysadmin. It's rather misleading having the V6 option. Things change from one version of sendmail to the other.. never had this kind of problem with all my BSD systems, and prior Linux installs.. Guess I just need to get up to speed!
Thanks...
Sam
Am So, den 06.11.2005 schrieb Sam Drinkard um 0:24:
I just now tried that and it turned on port 25. I was looking at that, but did not want IPv6 support, so didn't enable it. That really should be documented somewhere in the docs.. AFIK, I sure didn't find it, and I spent a good bit of time reading thru anything dealing with sysadmin. It's rather misleading having the V6 option. Things change from one version of sendmail to the other.. never had this kind of problem with all my BSD systems, and prior Linux installs.. Guess I just need to get up to speed!
Sam
Maybe I wasn't clear enough: You explicitly enabled the MSA with authentication enforced and TLSMTA (SMTPS), so the MTA is disabled if not explicitly instructed to run by a dedicated DAEMON_OPTIONS line. No, that didn't change for a long time. To avoid a listener on an IPv6 enabled interface is a different matter. A the sendmail.mc in its commented way shows, you can selective say whether to have an IPv4 MTA listener or IPv6 one, or both. Btw. the default sendmail.mc shipping with FreeBSD has those commented IP version splitted DAEMON_OPTIONS definitions.
More is explained in cf/README.
Alexander
On Sun, 2005-11-06 at 00:37 +0100, Alexander Dalloz wrote:
Maybe I wasn't clear enough: You explicitly enabled the MSA with authentication enforced and TLSMTA (SMTPS), so the MTA is disabled if not explicitly instructed to run by a dedicated DAEMON_OPTIONS line. No, that didn't change for a long time. To avoid a listener on an IPv6 enabled interface is a different matter. A the sendmail.mc in its commented way shows, you can selective say whether to have an IPv4 MTA listener or IPv6 one, or both. Btw. the default sendmail.mc shipping with FreeBSD has those commented IP version splitted DAEMON_OPTIONS definitions.
More is explained in cf/README.
Not sure I completely follow you Alexander. Are you saying that by enabling the TSLMTA / SMTPS , that *disables* the normal mta daemon? I do however need the MSA, but in an unauthenticated mode, as my home ISP blocks port 25. I was under the impression after reading the sendmail.mc that the MSA would be a non-authenticated operation. Perhaps I need to go back and re-read the sendmail.mc. Yes, as I recall on 4.9 BSD, the choice between ipv4 and ipv6 were two separate options.. That is what is running on my mailserver now. One other question while on the subject of mail, I believe I did a yum search for qpopper, or some other pop agent, and nothing shows up. I did find the latest version of qpopper at the Qualcomm website, I believe. I assume there is no available pop agent in the base distribution of CentOS is there?
Sam
On Sat, 2005-11-05 at 19:22 -0500, Sam Drinkard wrote:
On Sun, 2005-11-06 at 00:37 +0100, Alexander Dalloz wrote:
Maybe I wasn't clear enough: You explicitly enabled the MSA with authentication enforced and TLSMTA (SMTPS), so the MTA is disabled if not explicitly instructed to run by a dedicated DAEMON_OPTIONS line. No, that didn't change for a long time. To avoid a listener on an IPv6 enabled interface is a different matter. A the sendmail.mc in its commented way shows, you can selective say whether to have an IPv4 MTA listener or IPv6 one, or both. Btw. the default sendmail.mc shipping with FreeBSD has those commented IP version splitted DAEMON_OPTIONS definitions.
More is explained in cf/README.
Not sure I completely follow you Alexander. Are you saying that by enabling the TSLMTA / SMTPS , that *disables* the normal mta daemon? I do however need the MSA, but in an unauthenticated mode, as my home ISP blocks port 25. I was under the impression after reading the sendmail.mc that the MSA would be a non-authenticated operation. Perhaps I need to go back and re-read the sendmail.mc. Yes, as I recall on 4.9 BSD, the choice between ipv4 and ipv6 were two separate options.. That is what is running on my mailserver now. One other question while on the subject of mail, I believe I did a yum search for qpopper, or some other pop agent, and nothing shows up. I did find the latest version of qpopper at the Qualcomm website, I believe. I assume there is no available pop agent in the base distribution of CentOS is there?
---- dovecot and cyrus-imapd are 2 imap/pop3 servers included in CentOS 4 distribution. Qpopper is neither distributed, maintained or updated as part of CentOS. I would heavily recommend that you use dovecot or cyrus- imapd (my preference is for cyrus-imapd but many believe dovecot is easier).
You can have TLS/MTA and normal MTA on the same system, they must both be specifically enabled as Alexander has suggested.
Craig
On Sat, 2005-11-05 at 17:44 -0700, Craig White wrote:
dovecot and cyrus-imapd are 2 imap/pop3 servers included in CentOS 4 distribution. Qpopper is neither distributed, maintained or updated as part of CentOS. I would heavily recommend that you use dovecot or cyrus- imapd (my preference is for cyrus-imapd but many believe dovecot is easier).
You can have TLS/MTA and normal MTA on the same system, they must both be specifically enabled as Alexander has suggested.
Craig
I suppose there is no real compelling reason to use qpopper other than I've been using it for years with no problems, either security-wise or operational wise. There were some threads back just recently about dovecot vs. cyrun-imapd but I was not paying much attention to them. Is there documentation on setup of either/both of them somewhere in the CentOS docs ?
Sam
On Sat, 2005-11-05 at 20:05 -0500, Sam Drinkard wrote:
On Sat, 2005-11-05 at 17:44 -0700, Craig White wrote:
dovecot and cyrus-imapd are 2 imap/pop3 servers included in CentOS 4 distribution. Qpopper is neither distributed, maintained or updated as part of CentOS. I would heavily recommend that you use dovecot or cyrus- imapd (my preference is for cyrus-imapd but many believe dovecot is easier).
You can have TLS/MTA and normal MTA on the same system, they must both be specifically enabled as Alexander has suggested.
Craig
I suppose there is no real compelling reason to use qpopper other than I've been using it for years with no problems, either security-wise or operational wise. There were some threads back just recently about dovecot vs. cyrun-imapd but I was not paying much attention to them. Is there documentation on setup of either/both of them somewhere in the CentOS docs ?
---- not really - there isn't that much to setting them up if you are working with standard user accounts.
Craig
Am So, den 06.11.2005 schrieb Sam Drinkard um 2:05:
I suppose there is no real compelling reason to use qpopper other than I've been using it for years with no problems, either security-wise or operational wise. There were some
[...]
Sam
qpopper has a continuing, very doubtful history regarding security/bug issues. Each new release comes with a major bug (often a new buffer overflow). You better avoid that application. Too because it is not provided by CentOS. Use dovecot - quick, easy to configure and shipping with CentOS base.
Comment on your question about the MTA and MSA services by Sendmail: if you explicitly set DAEMON_OPTIONS for the MSA or TLSMTA you too have to explicitly set them for the MTA - else the MTA is disabled. You can easily play around with it: selective activate and deactivate DAEMON_OPTIONS for the services in sendmail.mc, rebuild the sendmail.cf from it (make -C /etc/mail) and then look at the results by running "grep DaemonPortOptions /etc/mail/sendmail.cf".
Alexander
On Sun, 2005-11-06 at 02:46 +0100, Alexander Dalloz wrote:
qpopper has a continuing, very doubtful history regarding security/bug issues. Each new release comes with a major bug (often a new buffer overflow). You better avoid that application. Too because it is not provided by CentOS. Use dovecot - quick, easy to configure and shipping with CentOS base.
Comment on your question about the MTA and MSA services by Sendmail: if you explicitly set DAEMON_OPTIONS for the MSA or TLSMTA you too have to explicitly set them for the MTA - else the MTA is disabled. You can easily play around with it: selective activate and deactivate DAEMON_OPTIONS for the services in sendmail.mc, rebuild the sendmail.cf from it (make -C /etc/mail) and then look at the results by running "grep DaemonPortOptions /etc/mail/sendmail.cf".
Alexander
Advice taken.. I did some extensive searching of the archived discussions, and did not find any one thing that related to setup of dovecot, nor could I find any kind of document describing setup of sendmail/cyrus-imapd. Even google did not return what I'd consider fair game unless I were installing from sources, which I'm not. That said, is there a document that describes setup of dovecot? All I really need is pop, as there is only one or two mail accounts on the machine.
Sam
Sam Drinkard wrote:
On Sun, 2005-11-06 at 02:46 +0100, Alexander Dalloz wrote:
qpopper has a continuing, very doubtful history regarding security/bug issues. Each new release comes with a major bug (often a new buffer overflow). You better avoid that application. Too because it is not provided by CentOS. Use dovecot - quick, easy to configure and shipping with CentOS base.
Comment on your question about the MTA and MSA services by Sendmail: if you explicitly set DAEMON_OPTIONS for the MSA or TLSMTA you too have to explicitly set them for the MTA - else the MTA is disabled. You can easily play around with it: selective activate and deactivate DAEMON_OPTIONS for the services in sendmail.mc, rebuild the sendmail.cf from it (make -C /etc/mail) and then look at the results by running "grep DaemonPortOptions /etc/mail/sendmail.cf".
Alexander
Advice taken.. I did some extensive searching of the archived discussions, and did not find any one thing that related to setup of dovecot, nor could I find any kind of document describing setup of sendmail/cyrus-imapd. Even google did not return what I'd consider fair game unless I were installing from sources, which I'm not. That said, is there a document that describes setup of dovecot? All I really need is pop, as there is only one or two mail accounts on the machine.
Sam
I don't use dovecot but here's what I found:
[root@mavis ~]# locate dovecot | grep doc /usr/share/doc/dovecot-0.99.11 /usr/share/doc/dovecot-0.99.11/NEWS /usr/share/doc/dovecot-0.99.11/configuration.txt /usr/share/doc/dovecot-0.99.11/multiaccess.txt /usr/share/doc/dovecot-0.99.11/securecoding.txt /usr/share/doc/dovecot-0.99.11/mkcert.sh /usr/share/doc/dovecot-0.99.11/dovecot-openssl.cnf /usr/share/doc/dovecot-0.99.11/mail-storages.txt /usr/share/doc/dovecot-0.99.11/COPYING.LGPL /usr/share/doc/dovecot-0.99.11/AUTHORS /usr/share/doc/dovecot-0.99.11/auth.txt /usr/share/doc/dovecot-0.99.11/README /usr/share/doc/dovecot-0.99.11/index.txt /usr/share/doc/dovecot-0.99.11/TODO /usr/share/doc/dovecot-0.99.11/design.txt /usr/share/doc/dovecot-0.99.11/COPYING /usr/share/doc/dovecot-0.99.11/INSTALL /usr/share/doc/dovecot-0.99.11/nfs.txt /usr/share/doc/dovecot-0.99.11/ChangeLog [root@mavis ~]# less /usr/share/doc/dovecot-0.99.11/configuration.txt
(And NO, I don't usually frolic about as root. I've been doing some recovery from a recent disaster.)
Sam Drinkard wrote on Sat, 05 Nov 2005 21:34:49 -0500:
That said, is there a document that describes setup of dovecot?
what about dovecot.org? And when you install dovecot there's also your standard /etc/dovecot.conf ...
Kai
On Sun, 2005-11-06 at 17:31 +0100, Kai Schaetzl wrote:
Sam Drinkard wrote on Sat, 05 Nov 2005 21:34:49 -0500:
That said, is there a document that describes setup of dovecot?
what about dovecot.org? And when you install dovecot there's also your standard /etc/dovecot.conf ...
Kai
Actually, I discovered the cyrus-imapd /pop agent works without doing anything to it. I figured at least it would have to be told something, but connecting to port 110 seems to bring it alive. Whether or not it will actually work when thunderbird or evolution connects to it is yet to be seen!
Am So, den 06.11.2005 schrieb Sam Drinkard um 17:43:
Actually, I discovered the cyrus-imapd /pop agent works without doing anything to it. I figured at least it would have to be told something, but connecting to port 110 seems to bring it alive. Whether or not it will actually work when thunderbird or evolution connects to it is yet to be seen!
Frankly, I am a bit astonished about that statement (Cyrus-IMAPd working without any configuration steps). I explain that to me that you so far didn't try to receive email from outside. Be aware that Sendmail from default setup - what you pasted as your sendmail.mc - will not hand over any incoming mail to Cyrus-IMAPd. This is not because you would have made a setup mistake, but because you so far didn't configure both to interact. Though you can contact your IMAP/POP3 server with your mail client it is a dumb thing so far. Even your mail client should tell you that there is no mailbox for the user you are logging in with: because with Cyrus-IMAPd the administrator (user cyrus) has to create each top-level mailbox (given you didn't configure and enable the autocreate feature).
Alexander
dipity.dogma.lan> From: "Kai Schaetzl" maillists@conactive.com X-Rcpt-To: centos@centos.org
Alexander Dalloz wrote on Sun, 06 Nov 2005 18:29:31 +0100:
because with Cyrus-IMAPd the administrator (user cyrus) has to create each top-level mailbox (given you didn't configure and enable the autocreate feature).
I've never worked with Cyrus, so my assumption may be wrong. But if you don't create any folders and just retrieve mail from the inbox it may work out of the box since it won't copy the inbox to your home dir and so on. That is how uw-imap works out-of-the-box.
Kai
On Sun, 2005-11-06 at 14:31, maillists@conactive.com wrote:
because with Cyrus-IMAPd the administrator (user cyrus) has to create each top-level mailbox (given you didn't configure and enable the autocreate feature).
I've never worked with Cyrus, so my assumption may be wrong. But if you don't create any folders and just retrieve mail from the inbox it may work out of the box since it won't copy the inbox to your home dir and so on. That is how uw-imap works out-of-the-box.
Dovecot will work with the system inbox (or you can configure it to use maildir format instead), but Cyrus uses its own storage area and needs a special setup and delivery agent.
On Sun, 2005-11-06 at 15:21 -0600, Les Mikesell wrote:
On Sun, 2005-11-06 at 14:31, maillists@conactive.com wrote:
because with Cyrus-IMAPd the administrator (user cyrus) has to create each top-level mailbox (given you didn't configure and enable the autocreate feature).
I've never worked with Cyrus, so my assumption may be wrong. But if you don't create any folders and just retrieve mail from the inbox it may work out of the box since it won't copy the inbox to your home dir and so on. That is how uw-imap works out-of-the-box.
Dovecot will work with the system inbox (or you can configure it to use maildir format instead), but Cyrus uses its own storage area and needs a special setup and delivery agent.
Les, that doesn't apply to using the Cyrus as a pop server does it? Assume it just reads from the users mail spool ?
On Sun, 2005-11-06 at 16:27 -0500, Sam Drinkard wrote:
On Sun, 2005-11-06 at 15:21 -0600, Les Mikesell wrote:
On Sun, 2005-11-06 at 14:31, maillists@conactive.com wrote:
because with Cyrus-IMAPd the administrator (user cyrus) has to create each top-level mailbox (given you didn't configure and enable the autocreate feature).
I've never worked with Cyrus, so my assumption may be wrong. But if you don't create any folders and just retrieve mail from the inbox it may work out of the box since it won't copy the inbox to your home dir and so on. That is how uw-imap works out-of-the-box.
Dovecot will work with the system inbox (or you can configure it to use maildir format instead), but Cyrus uses its own storage area and needs a special setup and delivery agent.
Les, that doesn't apply to using the Cyrus as a pop server does it? Assume it just reads from the users mail spool ?
-----
man imapd.conf Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Craig
Am So, den 06.11.2005 schrieb Sam Drinkard um 22:27:
Dovecot will work with the system inbox (or you can configure it to use maildir format instead), but Cyrus uses its own storage area and needs a special setup and delivery agent.
Les, that doesn't apply to using the Cyrus as a pop server does it? Assume it just reads from the users mail spool ?
No, Cyrus-IMAPd uses its own mail storage, whether offered by POP3 or IMAP. It is very different to other mail access servers in this regard (and thus a point of critic by some people).
Please read its documentation or you get unhappy very quickly. Said that I see the nice and helpful mail by Aleksandar - but it does not exchange to read through the docs to have a complete understanding.
Alexander
On Sun, 2005-11-06 at 15:27, Sam Drinkard wrote:
Dovecot will work with the system inbox (or you can configure it to use maildir format instead), but Cyrus uses its own storage area and needs a special setup and delivery agent.
Les, that doesn't apply to using the Cyrus as a pop server does it? Assume it just reads from the users mail spool ?
Yes, Cyrus serves IMAP and POP from the same location - as it would have to because it doesn't know ahead of time which you will use. Cyrus isn't much like anything else so if you try to run it without understanding all of it's documentation you'll probably go wrong.
Sam Drinkard wrote:
Les, that doesn't apply to using the Cyrus as a pop server does it? Assume it just reads from the users mail spool ?
Cyrus always uses its own mail spool. If you use Cyrus, your mail spool is in /var/spool/imap, and you must configure sendmail to deliver mail overthere.
On Sun, 2005-11-06 at 18:33 -0600, Aleksandar Milivojevic wrote:
Cyrus always uses its own mail spool. If you use Cyrus, your mail spool is in /var/spool/imap, and you must configure sendmail to deliver mail overthere. _______________________________________________
I just looked briefly over some of the documents about cyrus-imap and that is WAY too much complication for a single, or at most 3 mailbox server. The dovecot config file was just about as bad. Unix is supposed to make things simple.. not complicated, or at least that was the original vision of Unix.. guess that has been lost.......
Thanks for all the help and comments folks..
Sam
Am Mo, den 07.11.2005 schrieb Sam Drinkard um 3:11:
I just looked briefly over some of the documents about cyrus-imap and that is WAY too much complication for a single, or at most 3 mailbox server. The dovecot config file was just about as bad. Unix is supposed to make things simple.. not complicated, or at least that was the original vision of Unix.. guess that has been lost.......
Sam
The internet isn't the same as it was in the 80's, IT technology didn't stay the same and its applications moved with demands on them. If you think you can survive with knowledge based on training from 15 years ago, then you must fail - at least if you aren't willing to learn new and changed things.
Keep your head up, read through documentation and decide for the applications which best fit your needs.
Alexander
Quoting Sam Drinkard sam@wa4phy.net:
I just looked briefly over some of the documents about cyrus-imap and that is WAY too much complication for a single, or at most 3 mailbox server. The dovecot config file was just about as bad. Unix is supposed to make things simple.. not complicated, or at least that was the original vision of Unix.. guess that has been lost.......
Well, Dovecot should work by just installing and starting it, without touching any config files. Think of it as drop-in replacement for old wu-imapd. Mainly there for folks that want to have IMAP server quickly and with no fuss.
Cyrus requires couple of very simple config changes. I've described all of them in my previous email.
Number of users to support is irrelevant when deciding between Dovecot and Cyrus. My email server has exactly three users on it (my wife, my 17 month old son, and me). I'm running Cyrus on it.
One important thing people often don't think about is the *size* of mailboxes. Cyrus scales well with both size of mailboxes and number of users. Dovecot would probably handle thousands of small mailboxes just fine. But let them start growing and it would start falling apart (like anything else that uses non-indexed Berkely style mailboxes would).
Cyrus is really just a message store. It doesn't use system accounts at all. You could remove those three users from the system, and Cyrus wouldn't care about it. It would still accept emails for them as long as the mailboxes for them exist, and users would still be able to connect to it and get their email. You would need to setup some other way to authenticate them then, of course. Even in defualt configuraion in CentOS, Cyrus has no idea that you are authenticating users against local accounts. Cyrus simply passes username/password pair to saslauthd, and saslauthd is configured (by default, see /etc/sysconfig/saslauthd file) to check them against local user accounts. If you ever decide to tighten security on your email server by removing (really not needed) users from the system, no problems with Cyrus. It was blisfully unaware they existed anyhow.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Mon, 2005-11-07 at 09:02, Aleksandar Milivojevic wrote:
One important thing people often don't think about is the *size* of mailboxes. Cyrus scales well with both size of mailboxes and number of users. Dovecot would probably handle thousands of small mailboxes just fine. But let them start growing and it would start falling apart (like anything else that uses non-indexed Berkely style mailboxes would).
Dovecot builds an index but rebuilds it any time it thinks something else has modified the mailbox. Since Cyrus uses it's own oddball format and delivery agent, it can get away with expecting the index to always be correct. Dovecot also has the option to use maildir format which is more efficient for imap operations that have to make changes. For pop only, none of this is going to make much difference.
Sam Drinkard wrote:
Advice taken.. I did some extensive searching of the archived discussions, and did not find any one thing that related to setup of dovecot, nor could I find any kind of document describing setup of sendmail/cyrus-imapd. Even google did not return what I'd consider fair game unless I were installing from sources, which I'm not. That said, is there a document that describes setup of dovecot? All I really need is pop, as there is only one or two mail accounts on the machine.
Actually, you'll need to take couple of steps, however they are trivial. While you can telnet to port 110, your user will not be able to login, and email will be delivered to the wrong place (where Cyrus can't access it).
First thing, enable and start saslauthd. Cyrus uses it for authentication:
# chkconfig saslauthd reset # chkconfig saslauthd on # /etc/init.d/saslauthd start
Then, instruct Sendmail to use Cyrus for delivery to local mailboxes (instead of default procmail). First find and comment (place "dnl " string in front of them) these lines in sendmail.mc:
FEATURE(local_procmail) MAILER(procmail)
Replace them with these lines:
define(`confLOCAL_MAILER', `cyrusv2') define(`CYRUSV2_MAILER_ARGS', `FILE /var/lib/imap/socket/lmtp') MAILER(cyrusv2)
Rebuild sendmail.cf from sendmail.mc, and restart sendmail.
You would place "define" lines somewhere around start of sendmail.mc (where other "define" lines are). Place "MAILER" line at the end of the file (where other "MAILER" lines are).
If you want user's mailbox to be automatically created when user logs in for the first time, add this line to /etc/imapd.conf:
autocreatequota: -1
If you don't set this option, you would need to manually create user's mailbox before they could login. Note that for email to be delivered to mailbox, it must exist (in Cyrus world, mailbox and account are two different things). So, even with that option, user would either need to login to account or you would need to create mailbox before email can be delivered to it.
Creating mailboxes manually is easy. Set password for cyrus account. Excute "cyradm -u cyrus localhost", and then use "cm" command to create mailbox. For example, to create mailbox for user root, you would do (the "user." part is important!):
# cyradm -u cyrus localhost
cm user.root exit
While in cyradm, you can type "help" to see other usefull commands.
If your users are using Outlook or Outlook Express to read email, your life will be a bit easier if you add this line to /etc/imapd.conf:
altnamespace: 1
If your users are not using buggy IMAP clients such as Outlook or Outlook Express, don't set that option.
You might want to browse through man page for imapd.conf ("man imapd.conf") to see other usefull option. You probably will not want to change anything else. One thing to warn you, "createonpost" option will probably look tempting, but you really do not want to use it. It has some ill side effects.
BTW, since you'll have fully working IMAP server, my advice is to let users use it. Switching to new PC, or accessing email from webmail, or from multiple PCs is so much easier if users are using IMAP. Even if they need access only from single PC, there are still advantages of using IMAP, and having email stored on IMAP server.
On Sun, 2005-11-06 at 02:46 +0100, Alexander Dalloz wrote:
Sam
qpopper has a continuing, very doubtful history regarding security/bug issues. Each new release comes with a major bug (often a new buffer overflow). You better avoid that application. Too because it is not provided by CentOS. Use dovecot - quick, easy to configure and shipping with CentOS base.
Comment on your question about the MTA and MSA services by Sendmail: if you explicitly set DAEMON_OPTIONS for the MSA or TLSMTA you too have to explicitly set them for the MTA - else the MTA is disabled. You can easily play around with it: selective activate and deactivate DAEMON_OPTIONS for the services in sendmail.mc, rebuild the sendmail.cf from it (make -C /etc/mail) and then look at the results by running "grep DaemonPortOptions /etc/mail/sendmail.cf".
Alexander
I discovered with cyrus running, there is nothing to do. It works out of the box.. very nice! One less hurdle to overcome before this machine goes online monday.
Thanks for all the help
Sam
Anyone out there install FreeNX or Nomachines NX server on CentOS 4.2 yet? .. We have and it appears to work very well .. Just looking for any tips for Samba file shares or any other got ya's?
BRW
On Sat, 2005-11-05 at 19:21 -0800, Brian Watters wrote:
Anyone out there install FreeNX or Nomachines NX server on CentOS 4.2 yet? .. We have and it appears to work very well .. Just looking for any tips for Samba file shares or any other got ya's?
I use nx/freenx all the time. Some things that I have found make it not nearly as good as something like Citrix is it's lack of easy file copying or printing at the remote site. (On latest version there is CUPS print support and SMB file share support, but it didn't work well for me)
Since I am on a linux machine and connected to a linux machine using NX via ssh connection, I just use scp or sftp to copy files to the remote machine when I need to move a file or print a document. Connecting from a windows machine to a linux machine makes this harder (need something else installed on windows that does scp/sftp). This just may be an issue with me, as other people seem to print OK from NX.
Also, more often than not with the current version of NX, if I lose my connection and reconnect then a new session is opened instead of reconnecting to the old session on the same computer.
This is still a quick, secure and excellent method for a thin client connection that you can do via ssh.
nx / freenx are in the i386 extras repo of centos4 (does not work on x86_64).
Here is a great article on installing it with fedora: http://fedoranews.org/contributors/rick_stout/freenx/
(for centos i386 do:
yum install nx freenx
then follow the NoMachine client intructions in the above article)
Here is a Linux Journal series on NX:
http://www.linuxjournal.com/article/8477
http://www.linuxjournal.com/article/8480
http://www.linuxjournal.com/article/8483
http://www.linuxjournal.com/article/8489
http://www.linuxjournal.com/article/8538
Thanks, Johnny Hughes
Sam Drinkard wrote on Sat, 05 Nov 2005 19:22:02 -0500:
Not sure I completely follow you Alexander. Are you saying that by enabling the TSLMTA / SMTPS , that *disables* the normal mta daemon? I do however need the MSA, but in an unauthenticated mode, as my home ISP blocks port 25. I was under the impression after reading the sendmail.mc that the MSA would be a non-authenticated operation. Perhaps I need to go back and re-read the sendmail.mc.
AFAIK, looking at my mc and m4 files the only thing you need to do is comment out FEATURE(`no_default_msa') if it is uncommented. You don't need any DaemonOptions at all if you want sendmail listen on standard ports 25 and submission agent on 587. However, if you use at least *one* DeamonOptions line your override that all and have to explicitly set one-by-one.
Kai
On Sun, 2005-11-06 at 16:31 +0100, Kai Schaetzl wrote:
Sam Drinkard wrote on Sat, 05 Nov 2005 19:22:02 -0500:
AFAIK, looking at my mc and m4 files the only thing you need to do is comment out FEATURE(`no_default_msa') if it is uncommented. You don't need any DaemonOptions at all if you want sendmail listen on standard ports 25 and submission agent on 587. However, if you use at least *one* DeamonOptions line your override that all and have to explicitly set one-by-one.
Kai
Hello Kai,
I completely missed that line in the .mc file. Sure enough, commenting out the submission port and commenting out the no default MTA worked. I still think there should be something somewhere in the installation guide to reflect the fact that sendmail as packaged does not listen on any port except the loopback. Really, it's rather dumb to me, that having a MTA that does not listen on port 25 out of the box. Why even bother starting the sendmail daemon at all if it's not going to be useable for inbound mail? Perhaps someone up the road has different thoughts than I, or perhaps it's because there are lots of people who don't like sendmail due to the complexity of the sendmail.cf. Either way, it's now working as it should..
Many Thanks
Sam
On Sun, 2005-11-06 at 11:41 -0500, Sam Drinkard wrote:
On Sun, 2005-11-06 at 16:31 +0100, Kai Schaetzl wrote:
Sam Drinkard wrote on Sat, 05 Nov 2005 19:22:02 -0500:
AFAIK, looking at my mc and m4 files the only thing you need to do is comment out FEATURE(`no_default_msa') if it is uncommented. You don't need any DaemonOptions at all if you want sendmail listen on standard ports 25 and submission agent on 587. However, if you use at least *one* DeamonOptions line your override that all and have to explicitly set one-by-one.
I completely missed that line in the .mc file. Sure enough,commenting out the submission port and commenting out the no default MTA worked. I still think there should be something somewhere in the installation guide to reflect the fact that sendmail as packaged does not listen on any port except the loopback.
You mean like this: http://mirror.centos.org/centos/4/docs/html/rhel-rg-en-4/s1-email-mta.html
(Look for the "important note" box that starts out:
The default sendmail.cf file does not allow Sendmail to accept network connections from any host other than the local computer.
)
That would be because for the vast majority of installs, they need an MTA that works on the local machine to send out mail, but it is not a real mail server ... but something that will send php or other mail to a real mailserver.
Also, if it accepted mail from everywhere without configuration, it would be as insecure as the Windows XP defaults :)
Really, it's rather dumb to me, that having a MTA that does not listen on port 25 out of the box. Why even bother starting the sendmail daemon at all if it's not going to be useable for inbound mail?
Because for most machines that are not mail servers, they need out and not inbound mail.
Perhaps someone up the road has different thoughts than I, or perhaps it's because there are lots of people who don't like sendmail due to the complexity of the sendmail.cf. Either way, it's now working as it should..
On Sun, 2005-11-06 at 11:12 -0600, Johnny Hughes wrote:
You mean like this: http://mirror.centos.org/centos/4/docs/html/rhel-rg-en-4/s1-email-mta.html
(Look for the "important note" box that starts out:
The default sendmail.cf file does not allow Sendmail to accept network connections from any host other than the local computer.
Yes, I saw that while I was doing some reading about what was what, but even tho it says it does not allow network connections, that still does not tell one how to enable network connections, and that is the part I completely missed when looking over the sendmail.cf.
)
That would be because for the vast majority of installs, they need an MTA that works on the local machine to send out mail, but it is not a real mail server ... but something that will send php or other mail to a real mailserver.
I would assume if an individual is sending mail out, one would also need to be receiving mail as well. Granted many folks use their ISP's mail box for out/inbound, but then again, folks like me who use the machine as our primary mail gateway should not expect different configurations out of sendmail in the pureist extent. Sendmail, for me, has always been something that "just works" with little or no tweaking as it has in so many distributions of BSD years past. I was not expecting a "broken" configuration (broken as in no network connect) even tho the change is trivial.
Also, if it accepted mail from everywhere without configuration, it would be as insecure as the Windows XP defaults :)
I can't comment on windows xp, as I've never used the MTA altho it's there...
Because for most machines that are not mail servers, they need out and not inbound mail.
Perhaps someone up the road has different thoughts than I, or perhaps it's because there are lots of people who don't like sendmail due to the complexity of the sendmail.cf. Either way, it's now working as it should..
I still stand by my thinking that there should be some mention of how to enable sendmail to accept network connections in the docs without swimming thru all the various pages of setup and sysadmin, but that is strictly *my* opinion. I know better now :-)
Sam
On 11/6/05, Sam Drinkard sam@wa4phy.net wrote:
I still stand by my thinking that there should be some mention of how to enable sendmail to accept network connections in the docs without swimming thru all the various pages of setup and sysadmin, but that is strictly *my* opinion. I know better now :-)
I have to agree with you. Merely stating that default Sendmail doesn't work outside localhost without indicating the simple steps to cure that is only half a solution.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Sun, 2005-11-06 at 11:42, Collins Richey wrote:
On 11/6/05, Sam Drinkard sam@wa4phy.net wrote:
I still stand by my thinking that there should be some mention of how to enable sendmail to accept network connections in the docs without swimming thru all the various pages of setup and sysadmin, but that is strictly *my* opinion. I know better now :-)
I have to agree with you. Merely stating that default Sendmail doesn't work outside localhost without indicating the simple steps to cure that is only half a solution.
You mean they should put it in the manul like this: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/s1-ema... so the mailing list doesn't get cluttered with chatter about normal administration procedures?
On Sun, 2005-11-06 at 12:14 -0600, Les Mikesell wrote:
.
You mean they should put it in the manul like this: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/s1-ema... so the mailing list doesn't get cluttered with chatter about normal administration procedures?
Ok, it IS in the manuals, but for someone like me switching from a platform that has sendmail enabled by default to one that doesn't, I don't expect to have to dig thru all the sysadmin manuals to configure it to work. It would be a very simple task to take that same paragraph, and put it in the release notes or in some *conspicuous* place.
Yes, we're getting off topic, and my problem is solved, but placement of such an important topic as a mail transfer agent should be, in my opinion, not buried 49 levels deep in sysadmin.
EOF
Sam
On Sun, 2005-11-06 at 10:42 -0700, Collins Richey wrote:
On 11/6/05, Sam Drinkard sam@wa4phy.net wrote:
I still stand by my thinking that there should be some mention of how to enable sendmail to accept network connections in the docs without swimming thru all the various pages of setup and sysadmin, but that is strictly *my* opinion. I know better now :-)
I have to agree with you. Merely stating that default Sendmail doesn't work outside localhost without indicating the simple steps to cure that is only half a solution.
It does say how to fix it...
"To configure Sendmail as a server for other clients, edit the /etc/mail/sendmail.mc file, and either change the address specified in the Addr= option of the DAEMON_OPTIONS directive from 127.0.0.1 to the IP address of an active network device or comment out the DAEMON_OPTIONS directive all together by placing dnl at the beginning of the line. When finished, regenerate /etc/mail/sendmail.cf by executing the following command:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf "
Collins Richey wrote on Sun, 6 Nov 2005 10:42:13 -0700:
I have to agree with you. Merely stating that default Sendmail doesn't work outside localhost without indicating the simple steps to cure that is only half a solution.
The page Johnny mentioned does exactly say what to do. And it's "Chapter 11. Email" of "Red Hat Enterprise Linux 4: Reference Guide". It's clear and precise. The only information it lacks is that commenting out the option is the preferable way.
Kai
On Sun, 2005-11-06 at 11:35, Sam Drinkard wrote:
I still stand by my thinking that there should be some mention of how to enable sendmail to accept network connections in the docs without swimming thru all the various pages of setup and sysadmin, but that is strictly *my* opinion. I know better now :-)
You really shouldn't enable sendmail on the internet until you understand the options well enough to keep it from being an open relay. And if you have windows boxes as mail clients you should hook up some kind of virus protection for them (mimedefang and clamav work nicely).
On Sun, 2005-11-06 at 12:23 -0600, Les Mikesell wrote:
On Sun, 2005-11-06 at 11:35, Sam Drinkard wrote:
I still stand by my thinking that there should be some mention of how to enable sendmail to accept network connections in the docs without swimming thru all the various pages of setup and sysadmin, but that is strictly *my* opinion. I know better now :-)
You really shouldn't enable sendmail on the internet until you understand the options well enough to keep it from being an open relay. And if you have windows boxes as mail clients you should hook up some kind of virus protection for them (mimedefang and clamav work nicely).
I've been administering sendmail and Unix boxen since about 1990, and since switching to Linux, I admit, I've learned a thing or 3, but sendmail is not *normally* (in configurations I've used) set to accept open relaying, and I for one hate that anyone would permit it.
Sam Drinkard wrote on Sun, 06 Nov 2005 11:41:10 -0500:
Really, it's rather dumb to me, that having a MTA that does not listen on port 25 out of the box.
It *does* listen there, just that it restricts itself to 127.0.0.1 ;-) That's a security measure that most distributions introduced years ago. F.i. I have been using Suse before CentOS and they do it the same. Suse controls the sendmail.cf in their /etc/SuSEconfig/sendmail file where you can specify to listen on external IP as well or to not touch the sendmail.cf at all, etc. I don't know if Red Hat-based systems have something similar, it's possible that you can put that configuration option in the /etc/sysconfig/sendmail file as well (once you know the syntax - is there documentation about all sysconfig options somewhere?).
Kai
-
Aleksandar Milivojevic -
Alexander Dalloz -
Brian Watters -
Collins Richey -
Craig White -
Johnny Hughes -
Kai Schaetzl -
Les Mikesell -
maillists＠conactive.com
-
Robert -
Sam Drinkard