Re: Setting up secure submission for remote users
Le 12/04/2013 02:11, LuKreme a écrit : Reindl Harald opined on Thursday 11-Apr-2013@16:58:28 mynetworks should be genrally used with care and only for specific address instead whole networks with sooner or later potentially infected clients which can be banned if using auth even if the malware leaks auth data and abuse it from outside Mynetworks currently contains the mail server, the webmail server, and my home fixed IP since I do not have secure submission working as of now. I’m reading up on dovecot-1.2.17 and dovecot-2.1.16 and trying to decide if I can switch to either of those without breaking everything. One item of concern was reading a comment that “postfix hands the mail off to dovecot for local delivery” which makes me think I will lose procmail as my LDA. That would be bad. I’m also wondering if I can set dovecot up to only work with port 587 and keep cyrus-sasl for port 993, at least for now. I know it seems redundant, and it would be a stepping stone to ensure that current users are able to connect as they do now. (IMAP-SSL with “Password” for either local users or mysql users). yes, you can install dovecot and disable pop+imap in its configuration (otherwise, it will conflict with your courier setup) and configure postfix to use dovecot-auth (that's actually the default). do not configure postfix to deliver mail to dovecot. it should also be possible to use your current user-password database with dovecot. later, you may be able to replace courier with dovecot (to avoid having to manage two solutions. I have nothing against courier!). and over time, you may move more and more procmail rules to postfix, sieve, ... or /dev/null (if they're no more useful).
Re: Setting up secure submission for remote users
In our previous episode (Thursday, 11-Apr-2013), b...@bitrate.net said: you can certainly upgrade without breaking everything. as with anything else, it just takes some care and consideration. as far as procmail goes, i'd consider losing procmail to be a benefit. why do you think you need it? Because I use it extensively. I’m also wondering if I can set dovecot up to only work with port 587 and keep cyrus-sasl for port 993, at least for now. I know it seems redundant, and it would be a stepping stone to ensure that current users are able to connect as they do now. (IMAP-SSL with “Password” for either local users or mysql users). does this mean that you want to use dovecot sasl with postfix, for submission, and cyrus sasl with your imap software? it's certainly possible, but i question the actual benefit. The only benefit is that it would not change the current login procedures for Courier-IMAP. -- Eureka, he said. Going to have a bath then?
Re: Setting up secure submission for remote users
On 2013.04.12 07.01, LuKreme wrote: In our previous episode (Thursday, 11-Apr-2013), b...@bitrate.net said: you can certainly upgrade without breaking everything. as with anything else, it just takes some care and consideration. as far as procmail goes, i'd consider losing procmail to be a benefit. why do you think you need it? Because I use it extensively. that's a foregone conclusion. the question is for what do you use it. in the vast majority of cases, sieve can do everything procmail can do. if you were to switch from courier to dovecot for imap, delivery via lmtp from postfix to dovecot offers a number of benefits, only one of which is easy integration of sieve. -ben
Re: Setting up secure submission for remote users
On Apr 12, 2013, at 7:10, btb b...@bitrate.net wrote: On 2013.04.12 07.01, LuKreme wrote: In our previous episode (Thursday, 11-Apr-2013), b...@bitrate.net said: you can certainly upgrade without breaking everything. as with anything else, it just takes some care and consideration. as far as procmail goes, i'd consider losing procmail to be a benefit. why do you think you need it? Because I use it extensively. that's a foregone conclusion. the question is for what do you use it. in the vast majority of cases, sieve can do everything procmail can do. if you were to switch from courier to dovecot for imap, delivery via lmtp from postfix to dovecot offers a number of benefits, only one of which is easy integration of sieve. I've never used sieve, but have been using procmail for 15 years or so. I use it to sort mail, of course, but also for adding headers, sending copies of certain mails, altering subject lines, and probably a couple of other things I'm not think of. My procmail recipes tend to span 4 or 5 rc files and several hundred lines. It's not something I think I want to try to redo in sieve.
Re: Setting up secure submission for remote users
On Apr 8, 2013, at 13:26, Jeroen Geilman jer...@adaptr.nl wrote: I would personally recommend using dovecot for SASL, especially if you don't need client SASL (from postfix to remote servers); dovecot is way, way easier to set up, and evolves quite nicely My hesitation is that I already have an auth system setup and I hate to end up in a position where either it's no longer working or I have to have everyone reset their passwords. OTOH, I can't get PBS to work at all with 2.8 (they disagree over the db file format), but that is not necessarily a bad thing. I added my fixed IP for my home server to mynetworks, and anyone else can use webmail if they can't send via their ISP/gmail I guess.
Re: Setting up secure submission for remote users
On Apr 8, 2013, at 13:26, Jeroen Geilman jer...@adaptr.nl wrote: The clue is that there should be no permit_ rules before /or/ after permit_sasl_authenticated, and the last rule should be an explicit reject. Quick question on this, not ever a permit mynetworks? (I mean, I can't think of a reason mynetworks would need to use submission, but is there any reason not to allow it?)
Re: Setting up secure submission for remote users
Am 12.04.2013 00:04, schrieb LuKreme: On Apr 8, 2013, at 13:26, Jeroen Geilman jer...@adaptr.nl wrote: The clue is that there should be no permit_ rules before /or/ after permit_sasl_authenticated, and the last rule should be an explicit reject. Quick question on this, not ever a permit mynetworks? (I mean, I can't think of a reason mynetworks would need to use submission, but is there any reason not to allow it?) mynetworks may be OK in most cases but * without authentication use port 25 and mynetworks * if a client is using submission it is good practice to have a user in the logs mynetworks should be genrally used with care and only for specific address instead whole networks with sooner or later potentially infected clients which can be banned if using auth even if the malware leaks auth data and abuse it from outside signature.asc Description: OpenPGP digital signature
Re: Setting up secure submission for remote users
Reindl Harald opined on Thursday 11-Apr-2013@16:58:28 mynetworks should be genrally used with care and only for specific address instead whole networks with sooner or later potentially infected clients which can be banned if using auth even if the malware leaks auth data and abuse it from outside Mynetworks currently contains the mail server, the webmail server, and my home fixed IP since I do not have secure submission working as of now. I’m reading up on dovecot-1.2.17 and dovecot-2.1.16 and trying to decide if I can switch to either of those without breaking everything. One item of concern was reading a comment that “postfix hands the mail off to dovecot for local delivery” which makes me think I will lose procmail as my LDA. That would be bad. I’m also wondering if I can set dovecot up to only work with port 587 and keep cyrus-sasl for port 993, at least for now. I know it seems redundant, and it would be a stepping stone to ensure that current users are able to connect as they do now. (IMAP-SSL with “Password” for either local users or mysql users). -- Man is born free, but is everywhere in chains.
Re: Setting up secure submission for remote users
On Apr 11, 2013, at 20.11, LuKreme krem...@kreme.com wrote: Reindl Harald opined on Thursday 11-Apr-2013@16:58:28 mynetworks should be genrally used with care and only for specific address instead whole networks with sooner or later potentially infected clients which can be banned if using auth even if the malware leaks auth data and abuse it from outside Mynetworks currently contains the mail server, the webmail server, and my home fixed IP since I do not have secure submission working as of now. i would very strongly encourage you to get a properly configured submission service up and running. it's really not terribly difficult, and there's just no reason for a webmail server nor whatever email programs you use at home to not be authenticating. in all honesty, i'm a proponent of doing away with mynetworks entirely, and if truly necessary, using check_client_access instead. I’m reading up on dovecot-1.2.17 and dovecot-2.1.16 and trying to decide if I can switch to either of those without breaking everything. One item of concern was reading a comment that “postfix hands the mail off to dovecot for local delivery” which makes me think I will lose procmail as my LDA. That would be bad. you can certainly upgrade without breaking everything. as with anything else, it just takes some care and consideration. as far as procmail goes, i'd consider losing procmail to be a benefit. why do you think you need it? I’m also wondering if I can set dovecot up to only work with port 587 and keep cyrus-sasl for port 993, at least for now. I know it seems redundant, and it would be a stepping stone to ensure that current users are able to connect as they do now. (IMAP-SSL with “Password” for either local users or mysql users). does this mean that you want to use dovecot sasl with postfix, for submission, and cyrus sasl with your imap software? it's certainly possible, but i question the actual benefit. -ben
Re: Setting up secure submission for remote users
On 04/08/2013 01:32 AM, LuKreme wrote: I've long used pop-before-smtp to allow authenticated users a short window in which to send mail, but now that I've setup postfix 2.8.14 I want to also setup secure submission on port 587 with ssl and something like Kerberos 5 or MD5 challenge/response (or, frankly, even password) over SSL. I built postfix with: make -f Makefile.init makefiles 'CCARGS=-DHAS_MYSQL -DUSE_TLS -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -I/usr/local/include/mysql -I/usr/local/include/sasl' 'AUXLIBS=-L/usr/local/lib/mysql -lmysqlclient -lz -lm -lssl -lcrypto -L/usr/local/lib -lsasl2' Seems to work: # postconf -a cyrus dovecot # postconf -A cyrus Also, the SASL Readme says: Cyrus SASL version 2.x searches for the configuration file in /usr/lib/sasl2/. Cyrus SASL version 2.1.22 and newer additionally search in /etc/sasl2/. (I am running 2.1.22_2) I would personally recommend using dovecot for SASL, especially if you don't need client SASL (from postfix to remote servers); dovecot is way, way easier to set up, and evolves quite nicely. It's also ridiculously easy to set up from scratch: http://www.postfix.org/SASL_README.html#server_dovecot postconf -n smtpd_data_restrictions = reject_unauth_pipelining, reject_multi_recipient_bounce,check_sender_access hash:$config_directory/backscatterpermit smtpd_helo_restrictions = permit_mynetworks,reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, permit smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_invalid_hostname, permit_mynetworks, check_client_access hash:$config_directory/pbs, permit_sasl_authenticated, reject_unauth_destination, reject_unlisted_recipient, reject_unlisted_sender, reject_unknown_reverse_client_hostname, warn_if_reject reject_unknown_client_hostname, check_client_access cidr:/var/db/dnswl/postfix-dnswl-permit check_sender_access pcre:$config_directory/sender_access.pcre, check_client_access pcre:$config_directory/check_client_fqdn.pcre, check_recipient_access pcre:$config_directory/recipient_checks.pcre, check_client_access hash:$config_directory/access, reject_rbl_client zen.spamhaus.org, permit smtpd_sender_restrictions = check_client_access hash:$config_directory/pbs, permit_sasl_authenticated, permit_mynetworks Submission should disable all of the above (in master.cf) except smtpd_recipient_restrictions=permit_sasl_authenticated,reject. You can prefix that with any reject_ restrictions you wish to impose on your users, such as a proper sender- and/or recipient domain. The clue is that there should be no permit_ rules before /or/ after permit_sasl_authenticated, and the last rule should be an explicit reject. -- J.
Re: Setting up secure submission for remote users
In our previous episode (Sunday, 07-Apr-2013), LuKreme said: /usr/local/sbin/saslauthd -a pam -m /var/run/authdaemond one other thing I might have mentioned: # cat /usr/local/etc/authlib/authdaemonrc |egrep -v ^$|^# authmodulelist=authmysql authpam version=authdaemond.mysql authmodulelistorig=authuserdb authvchkpw authpam authldap authmysql authpgsql daemons=5 authdaemonvar=/var/run/authdaemond subsystem=mail DEBUG_LOGIN=0 DEFAULTOPTIONS=wbnodsn=1 LOGGEROPTS= This was setup years ago because some users are local (/usr/locale/etc/pam.d/) and some are mysql users. -- No one ever thinks of themselves as one of Them. We're always one of Us. It's Them that do the bad things.
