Re: Lots of Post Fix Issues
And finally I think I've stumbled on to something that may be the culprit. DNS. Again be gentle with me here because I'm in unchartered waters here. I own two domains hagensieker.com (GoDaddy) hagensieker.org (NameCheap) My computer hostname is set to mail.hagensieker.com (Is this a problem?) When I do an dig MX mail.hagensieker.com it fails. No servers could be reached. My main.cf file uses the relay host for GoDaddy. Do I need this relay host? Can I just make everything hagensieker.org without a relay host? Or can I somehow or another resolve this inability to receive mail with the way I have things set? Terribly confused at this point? -- View this message in context: http://postfix.1071664.n5.nabble.com/Lots-of-Post-Fix-Issues-tp69856p69863.html Sent from the Postfix Users mailing list archive at Nabble.com.
Re: Lots of Post Fix Issues
On 08/12/2014 08:08 AM, hagensieker wrote: Terribly confused at this point? Yes. I recommend that you get the excellent The Postfix book[1] by Ralf and Patrick before getting in the world of e-mail and Postfix. Once you read it cover to cover and understand the concepts, everything will become crystal clear to you. [1]http://www.postfix-book.com/ -- Victoriano Giralt Central ICT Services Systems Manager University of Malaga +34952131415 SPAIN == Note: signature.asc is the electronic signature of present message A: Yes. Q: Are you sure ? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email ? signature.asc Description: OpenPGP digital signature
Re: Lots of Post Fix Issues
Ok I am learning. Here is what i did. I changed my hostname and /etc/hosts file to reflect hagensieker.org Then I changed all the appropriate entries in main.cf. Then changed the host relayhost to the NameCheap relay host. Then restarted postfix Then went to Thunderbird on my Linux box and created an account. It finds an smtp of mail.hagensieker.org and an IMAP server on Port 143 also with mail.hagensieker.org I can send and receive in both directions. I think I got it and just didn't understand the DNS thing. I was trying to point to a DNS that wasn't there. I'm pretty happy about this. Now I have to figure out how to add some other accounts. -- View this message in context: http://postfix.1071664.n5.nabble.com/Lots-of-Post-Fix-Issues-tp69856p69865.html Sent from the Postfix Users mailing list archive at Nabble.com.
Re: Use postfix and spamassassin packages on CentOS 6 to reject SPAM
On Tue, Aug 12, 2014 at 1:44 AM, Bill Cole postfixlists-070...@billmail.scconsult.com wrote: On 11 Aug 2014, at 10:22, li...@rhsoft.net wrote: http://serverfault.com/questions/619537/use-postfix- and-spamassassin-packages-on-centos-6-to-reject-spam-without-custo Also worth noting: embedding the GTUBE pattern in a message is an excellent way to minimize visibility of a message among SpamAssassin users. The GTUBE mail (and the other mails I try) come through, because I haven't touched header_checks yet. The problem is - why don't subjects get rewritten by Spamassassin - despite having rewrite_header Subject [SPAM] in /etc/mail/spamassassin/local.cf? But maybe the Postfix side is okay and I should ask at the Spamassassin mailing list - even though Mr. rhsoft.net disapproves. Regards Alex
Re: Use postfix and spamassassin packages on CentOS 6 to reject SPAM
Hello again,
On Tue, Aug 12, 2014 at 9:34 AM, Alexander Farber
alexander.far...@gmail.com wrote:
On 11 Aug 2014, at 10:22, li...@rhsoft.net wrote:
http://serverfault.com/questions/619537/use-postfix-
and-spamassassin-packages-on-centos-6-to-reject-spam-without-custo
the point of my question (maybe I haven't stated it clearly enough) has
been: how to combine Postfix and Spamassassin on CentOS with minimal
efforts.
I didn't want to add custom shell scripts or users - as suggested in many
HOWTOs on the web.
I think I have the answer now:
1) Install the spamassassin package (the postfix package is installed by
default)
2) Add a user to your system with useradd spam (you can't omit this step
- this has been the culprit in my case - I was trying to use the user
nobody, but it didn't have a home dir and that has broken Spamassassin
despite me passing -x to spamd)
3) Add /^Subject: \[SPAM\]/ DISCARD to the /etc/postfix/header_checks
(check the /etc/mail/spamassassin/local.cf to see the exact string to match)
4) Add the following 2 lines to the /etc/postfix/master.cf:
smtp inet n - n - - smtpd -o content_filter=spamassassin
spamassassin unix - n n - - pipe user=spam argv=/usr/bin/spamc -f -e
/usr/sbin/sendmail -oi -f ${sender} ${recipient}
Regards
Alex
Re: Lots of Post Fix Issues
Am 12.08.2014 um 08:08 schrieb hagensieker: And finally I think I've stumbled on to something that may be the culprit. DNS. surely, the outside world needs to deliver to your machine your MX pints to secureserver.net Again be gentle with me here because I'm in unchartered waters here. I own two domains hagensieker.com (GoDaddy) hagensieker.org (NameCheap) My computer hostname is set to mail.hagensieker.com (Is this a problem?) When I do an dig MX mail.hagensieker.com it fails. No servers could be reached why would you do this for the hostname instead the domain? @hagensieker.com != @mail.hagensieker.com BTW: why 2 CNAMES wrapped around mail.hagensieker.com ;; ANSWER SECTION: hagensieker.com.3600IN MX 0 smtp.secureserver.net. hagensieker.com.3600IN MX 10 mailstore1.secureserver.net. ;; ANSWER SECTION: mail.hagensieker.com. 3549IN CNAME pop.secureserver.net. pop.secureserver.net. 3549IN CNAME pop.where.secureserver.net. pop.where.secureserver.net. 300 IN A 72.167.218.192
milter_header_checks not supporting pcre
i am trying to use this feature in postfix 2.11: http://www.postfix.org/postconf.5.html#milter_header_checks I have created a milter which adds a Header: X-Body: bla and i'd like to filter mails, unfortunately the cleanup process doesn't support pcre for milter_header_checks, if i use the same pcre file for header_checks instead of milter_header_checks the pcre check is working, here my debug cleanup -v log : Aug 12 12:30:55 mslnx postfix/cleanup[22263]: reply: SMFIR_ADDHEADER data 11 bytes Aug 12 12:30:55 mslnx postfix/cleanup[22263]: hbc_header_checks: 'X-Body: bla' Aug 12 12:30:55 mslnx postfix/cleanup[22263]: warning: pcre:/etc/postfix/milter_header_checks is unavailable. unsupported dictionary type: pcre Aug 12 12:30:55 mslnx postfix/cleanup[22263]: warning: pcre:/etc/postfix/milter_header_checks lookup error for X-Body: bla Aug 12 12:30:55 mslnx postfix/cleanup[22263]: maps_find: milter_header_checks: X-Body: bla: search aborted Aug 12 12:30:55 mslnx postfix/cleanup[22263]: warning: 268A6A80F9B: milter_header_checks map lookup problem -- message not accepted, try again later Aug 12 12:30:55 mslnx postfix/cleanup[22263]: reply: SMFIR_ACCEPT data 0 bytes Aug 12 12:30:55 mslnx postfix/cleanup[22263]: maps_free: pcre:/etc/postfix/milter_header_checks(0,lock) Aug 12 12:30:55 mslnx postfix/cleanup[22263]: leave cleanup_milter main.cf: smtpd_milters = unix:/pythonsock milter_header_checks = pcre:/etc/postfix/milter_header_checks #header_checks = pcre:/etc/postfix/milter_header_checks - this works fine when uncommented /etc/postfix/milter_header_checks: /^X-Body:\s+bla/ OK /^./@./$/ REJECT pcre is installed and configured in dynamicmaps.cf $postmap -v -q X-Body: bla pcre:/etc/postfix/milter_header_checks postmap: name_mask: all postmap: inet_addr_local: configured 3 IPv4 addresses postmap: inet_addr_local: configured 7 IPv6 addresses postmap: dict_open: pcre:/etc/postfix/milter_header_checks postmap: dict_pcre_lookup: /etc/postfix/milter_header_checks: X-Body: bla OK $postmap -v -q a@bc pcre:/etc/postfix/milter_header_checks postmap: name_mask: all postmap: inet_addr_local: configured 3 IPv4 addresses postmap: inet_addr_local: configured 7 IPv6 addresses postmap: dict_open: pcre:/etc/postfix/milter_header_checks postmap: dict_pcre_lookup: /etc/postfix/milter_header_checks: a@bc REJECT Best regards Matthias Schneider
Re: milter_header_checks not supporting pcre
Am 12.08.2014 um 13:59 schrieb Matthias Schneider: i am trying to use this feature in postfix 2.11: http://www.postfix.org/postconf.5.html#milter_header_checks I have created a milter which adds a Header: X-Body: bla and i'd like to filter mails, unfortunately the cleanup process doesn't support pcre for milter_header_checks, if i use the same pcre file for header_checks instead of milter_header_checks the pcre check is working, warning: pcre:/etc/postfix/milter_header_checks is unavailable. unsupported dictionary type: pcre what does postconf -m list - most likely not pcre if not complain at the distributor responsible for the postfix build [root@rh:~]$ postconf -m btree cidr environ fail hash internal memcache mysql pcre proxy regexp socketmap static tcp texthash unix
Re: milter_header_checks not supporting pcre
please note that pcre is working fine with normal header_checks, the problem is just with milter_header_checks : # postconf -m btree cidr environ fail hash internal memcache nis pcre proxy regexp sdbm socketmap sqlite static tcp texthash unix what does postconf -m list - most likely not pcre if not complain at the distributor responsible for the postfix build [root@rh:~]$ postconf -m btree cidr environ fail hash internal memcache mysql pcre proxy regexp socketmap static tcp texthash unix
Re: Use postfix and spamassassin packages on CentOS 6 to reject SPAM
BTW, the point of Bill Cole's post (I almost posted something similar) was that you put the GTUBE string right here in a public mailing list. Most people who use SpamAssassin thus would not get your post: it was flagged as spam, of course. That's the idea; the GTUBE string is to test filters. The very people you most needed to reach, SA users with working configurations, did not see your message. On Tue, Aug 12, 2014 at 10:38:30AM +0200, Alexander Farber wrote: On Tue, Aug 12, 2014 at 9:34 AM, Alexander Farber alexander.far...@gmail.com wrote: On 11 Aug 2014, at 10:22, li...@rhsoft.net wrote: http://serverfault.com/questions/619537/use-postfix- and-spamassassin-packages-on-centos-6-to-reject-spam-without-custo the point of my question (maybe I haven't stated it clearly enough) has been: how to combine Postfix and Spamassassin on CentOS with minimal efforts. Consider using amavisd-new. Yes, it's another piece of software to configure, but it manages and runs SA for you. I didn't want to add custom shell scripts or users - as suggested in many HOWTOs on the web. Stick with the Postfix and Amavisd-new documentation. Most random HOWTOs you can dig up are written by people who at best barely understand what they did. Postfix documentation for after-queue content filtering: http://www.postfix.org/FILTER_README.html and for before-queue filtering, which according to your Subject: seems to be what you wanted: http://www.postfix.org/SMTPD_PROXY_README.html In either case amavisd-new can help you, acting as either the content_filter or the smtpd_proxy_filter respectively. I think I have the answer now: snip 3) Add /^Subject: \[SPAM\]/ DISCARD to the /etc/postfix/header_checks (check the /etc/mail/spamassassin/local.cf to see the exact string to match) It's not particularly safe to discard mail flagged as spam, your own GTUBE adventure here being a good example why not. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Lots of Post Fix Issues
On 08/11/2014 10:17 PM, hagensieker wrote: And here is dovecot.conf How about /sbin/iptbles -vnL | egrep '((DROP)|(REJECT)) ? Or, if you are running a mostly-closed firewall configuration, the output of /sbin/iptables -vnL | egrep '((:25)|(:143)|(:587)) ?
Re: milter_header_checks not supporting pcre
i searched the code what returns the error, hope this will help.
if you have any suggestions or experimantal code changes i'll compile
and test them
with my addheader milter.
Best regards
Matthias Schneider
cleanup_milter.c:
381 static int cleanup_milter_header_checks(CLEANUP_STATE *state,
VSTRING *buf)
382 {
383 char *ret;
384
385 /*
386 * Milter application add/insert/replace header requests
happen at the
387 * end-of-message stage, therefore all the header operations are
relative
388 * to the primary message header.
389 */
390 ret = hbc_header_checks((void *) state, state-milter_hbc_checks,
391 MIME_HDR_PRIMARY, (HEADER_OPTS *) 0,
392 buf, (off_t) 0);
393 if (ret == 0) {
394 return (0);
395 } else if (ret == HBC_CHECKS_STAT_ERROR) {
396 msg_warn(%s: %s map lookup problem --
397 message not accepted, try again later,
398 state-queue_id, VAR_MILT_HEAD_CHECKS);
399 state-errs |= CLEANUP_STAT_WRITE;
400 return (0);
401 } else {
402 if (ret != STR(buf)) {
403 vstring_strcpy(buf, ret);
404 myfree(ret);
405 }
406 return (1);
407 }
408 }
Re: milter_header_checks not supporting pcre
I found a solution, turning off chroot for cleanup in master.cf cleanup unix n - n - 0 cleanup this should be added to the documention: http://www.postfix.org/postconf.5.html#milter_header_checks
Re: milter_header_checks not supporting pcre
On Tue, Aug 12, 2014 at 04:04:46PM +0200, Matthias Schneider wrote: I found a solution, turning off chroot for cleanup in master.cf cleanup unix n - n - 0 cleanup this should be added to the documention: http://www.postfix.org/postconf.5.html#milter_header_checks When using dynamicmaps.cf, the table drivers (shared objects) need to also be present in the chroot jail. Milter header check tables are currently registered on the fly, after the process is chrooted. -- Viktor.
Re: milter_header_checks not supporting pcre
Am 12.08.2014 um 16:04 schrieb Matthias Schneider: I found a solution, turning off chroot for cleanup in master.cf cleanup unix n - n - 0 cleanup this should be added to the documention: http://www.postfix.org/postconf.5.html#milter_header_checks no - chroot should not be enabled until someone knows exactly what he is doing and it is *not* enabled by default except by the Debian maintainers over years more then 50% of the here reported problems are caused by chroot enabled somewhere in master.cf
Re: Use postfix and spamassassin packages on CentOS 6 to reject SPAM
On 12 Aug 2014, at 8:38, /dev/rob0 wrote: BTW, the point of Bill Cole's post (I almost posted something similar) was that you put the GTUBE string right here in a public mailing list. Most people who use SpamAssassin thus would not get your post: it was flagged as spam, of course. That's the idea; the GTUBE string is to test filters. The very people you most needed to reach, SA users with working configurations, did not see your message. Precisely. I only know the message existed because the SA score was an order of magnitude higher than the worst normal spam and I was tinkering with my SA config due to recent FPs for this list. On Tue, Aug 12, 2014 at 10:38:30AM +0200, Alexander Farber wrote: On Tue, Aug 12, 2014 at 9:34 AM, Alexander Farber alexander.far...@gmail.com wrote: On 11 Aug 2014, at 10:22, li...@rhsoft.net wrote: http://serverfault.com/questions/619537/use-postfix- and-spamassassin-packages-on-centos-6-to-reject-spam-without-custo the point of my question (maybe I haven't stated it clearly enough) has been: how to combine Postfix and Spamassassin on CentOS with minimal efforts. Consider using amavisd-new. Yes, it's another piece of software to configure, but it manages and runs SA for you. Another option in a very similar vein: MIMEDefang. It's a milter that directly supports SA and anti-virus scanning as well as essentially anything you can make Perl do. MD is particularly good with MIME manipulation, so it is an ideal tool if you want to do things like strip attachments without maiming messages. A simpler alternative than Amavisd-new or MD would be spamass-milter. I didn't want to add custom shell scripts or users - as suggested in many HOWTOs on the web. Stick with the Postfix and Amavisd-new documentation. Most random HOWTOs you can dig up are written by people who at best barely understand what they did. Beyond that, it is common for shoddy random HOWTOs to migrate upwards in web searches as they age and become increasingly obsolete. If there is a solid simple recipe for a minimalistic Postfix 2.11 SpamAssassin 3.4 rig on some obscure site, it cannot have been in existence for long enough to be widely linked, so what you will find instead will be ancient orphaned pages that document obsolete software. Postfix documentation for after-queue content filtering: http://www.postfix.org/FILTER_README.html and for before-queue filtering, which according to your Subject: seems to be what you wanted: http://www.postfix.org/SMTPD_PROXY_README.html In either case amavisd-new can help you, acting as either the content_filter or the smtpd_proxy_filter respectively. I think I have the answer now: snip 3) Add /^Subject: \[SPAM\]/ DISCARD to the /etc/postfix/header_checks (check the /etc/mail/spamassassin/local.cf to see the exact string to match) It's not particularly safe to discard mail flagged as spam, your own GTUBE adventure here being a good example why not. In the modern world it's not particularly safe to do anything with mail that you've flagged as spam after accepting it, which is the main argument for before-queue filtering.
SASL authentication failure: cannot connect to saslauthd server
Hi there, I know this is a common error but I swear I checked everything, yet still get that error trying to setup Postfix with Cyrus SASL on Debian wheezy. Here’s my confgs: /etc/postfix/sasl/smtp.comf: pwcheck_method: saslauthd mech_list: PLAIN LOGIN saslauthd_path: /var/run/saslauthd/mux log_level: 7 main.cf: smtpd_sasl_path = smtpd smtpd_sasl_auth_enable = yes cyrus_sasl_config_path = /etc/postfix/sasl I also run testsaslauthd -u paul -p 12345678 -r 10.1.10.18 -f /var/run/saslauthd/mux -s smtp: 0: OK Success.” Please help.
Re: SASL authentication failure: cannot connect to saslauthd server
El 2014-08-12 22:29, pavel degtiarev escribió: Hi there, I know this is a common error but I swear I checked everything, yet still get that error trying to setup Postfix with Cyrus SASL on Debian wheezy. Here’s my confgs: /etc/postfix/sasl/smtp.comf: Be careful with the extension. cyrus_sasl_config_path will try to find $smtpd_sasl_path.conf, which by default is smtp.conf, instead of your smtp.comf. pwcheck_method: saslauthd mech_list: PLAIN LOGIN saslauthd_path: /var/run/saslauthd/mux log_level: 7 main.cf: smtpd_sasl_path = smtpd smtpd_sasl_auth_enable = yes cyrus_sasl_config_path = /etc/postfix/sasl I also run testsaslauthd -u paul -p 12345678 -r 10.1.10.18 -f /var/run/saslauthd/mux -s smtp: 0: OK Success.” Please help. Regards.
Re: SASL authentication failure: cannot connect to saslauthd server
Sorry, typo: /etc/postfix/sasl/smtpd.conf - that’s what I have. On Aug 12, 2014, at 6:13 PM, nico...@devels.es wrote: El 2014-08-12 22:29, pavel degtiarev escribió: Hi there, I know this is a common error but I swear I checked everything, yet still get that error trying to setup Postfix with Cyrus SASL on Debian wheezy. Here’s my confgs: /etc/postfix/sasl/smtp.comf: Be careful with the extension. cyrus_sasl_config_path will try to find $smtpd_sasl_path.conf, which by default is smtp.conf, instead of your smtp.comf. pwcheck_method: saslauthd mech_list: PLAIN LOGIN saslauthd_path: /var/run/saslauthd/mux log_level: 7 main.cf: smtpd_sasl_path = smtpd smtpd_sasl_auth_enable = yes cyrus_sasl_config_path = /etc/postfix/sasl I also run testsaslauthd -u paul -p 12345678 -r 10.1.10.18 -f /var/run/saslauthd/mux -s smtp: 0: OK Success.” Please help. Regards.
Re: SASL authentication failure: cannot connect to saslauthd server
* nico...@devels.es nico...@devels.es: El 2014-08-12 22:29, pavel degtiarev escribió: Hi there, I know this is a common error but I swear I checked everything, yet still get that error trying to setup Postfix with Cyrus SASL on Debian wheezy. Here’s my confgs: /etc/postfix/sasl/smtp.comf: Be careful with the extension. cyrus_sasl_config_path will try to find $smtpd_sasl_path.conf, which by default is smtp.conf, instead of your smtp.comf. pwcheck_method: saslauthd mech_list: PLAIN LOGIN saslauthd_path: /var/run/saslauthd/mux log_level: 7 #/etc/postfix/sasl/smtpd.comf pwcheck_method: saslauthd mech_list: PLAIN LOGIN main.cf: smtpd_sasl_path = smtpd smtpd_sasl_auth_enable = yes cyrus_sasl_config_path = /etc/postfix/sasl #/etc/postfix/main.cf smtpd_sasl_auth_enable = yes I also run testsaslauthd -u paul -p 12345678 -r 10.1.10.18 -f /var/run/saslauthd/mux -s smtp: This works only on Postfix servers that do not run chrooted. On Debian Postfix' SMTP server smtpd runs chrooted by default. Either run smtpd not chrooted or place saslauthd's socket in Postfix chroot. Modify OPTIONS at the end of /etc/default/saslauthd in order to do so. Use the new socket path also in testsaslauthd testing. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: SASL authentication failure: cannot connect to saslauthd server
I checked that as well: ls -ld /proc/1831/root lrwxrwxrwx 1 root root 0 Aug 12 17:14 /proc/1831/root - / It does not look like postfix is chrooted, 1831 is postfix pid. The entry in master.cf also points to non chrooted install: smtps inet n - - - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING On Aug 12, 2014, at 7:41 PM, Patrick Ben Koetter p...@sys4.de wrote: * nico...@devels.es nico...@devels.es: El 2014-08-12 22:29, pavel degtiarev escribió: Hi there, I know this is a common error but I swear I checked everything, yet still get that error trying to setup Postfix with Cyrus SASL on Debian wheezy. Here’s my confgs: /etc/postfix/sasl/smtp.comf: Be careful with the extension. cyrus_sasl_config_path will try to find $smtpd_sasl_path.conf, which by default is smtp.conf, instead of your smtp.comf. pwcheck_method: saslauthd mech_list: PLAIN LOGIN saslauthd_path: /var/run/saslauthd/mux log_level: 7 #/etc/postfix/sasl/smtpd.comf pwcheck_method: saslauthd mech_list: PLAIN LOGIN main.cf: smtpd_sasl_path = smtpd smtpd_sasl_auth_enable = yes cyrus_sasl_config_path = /etc/postfix/sasl #/etc/postfix/main.cf smtpd_sasl_auth_enable = yes I also run testsaslauthd -u paul -p 12345678 -r 10.1.10.18 -f /var/run/saslauthd/mux -s smtp: This works only on Postfix servers that do not run chrooted. On Debian Postfix' SMTP server smtpd runs chrooted by default. Either run smtpd not chrooted or place saslauthd's socket in Postfix chroot. Modify OPTIONS at the end of /etc/default/saslauthd in order to do so. Use the new socket path also in testsaslauthd testing. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: SASL authentication failure: cannot connect to saslauthd server
* pavel degtiarev paul.d...@gmail.com: I checked that as well: ls -ld /proc/1831/root lrwxrwxrwx 1 root root 0 Aug 12 17:14 /proc/1831/root - / It does not look like postfix is chrooted, 1831 is postfix pid. The entry in master.cf also points to non chrooted install: smtps inet n - - - - smtpd You are wrong. A '-' means 'use defaults'. Check the defaults in the column description. -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING On Aug 12, 2014, at 7:41 PM, Patrick Ben Koetter p...@sys4.de wrote: * nico...@devels.es nico...@devels.es: El 2014-08-12 22:29, pavel degtiarev escribió: Hi there, I know this is a common error but I swear I checked everything, yet still get that error trying to setup Postfix with Cyrus SASL on Debian wheezy. Here’s my confgs: /etc/postfix/sasl/smtp.comf: Be careful with the extension. cyrus_sasl_config_path will try to find $smtpd_sasl_path.conf, which by default is smtp.conf, instead of your smtp.comf. pwcheck_method: saslauthd mech_list: PLAIN LOGIN saslauthd_path: /var/run/saslauthd/mux log_level: 7 #/etc/postfix/sasl/smtpd.comf pwcheck_method: saslauthd mech_list: PLAIN LOGIN main.cf: smtpd_sasl_path = smtpd smtpd_sasl_auth_enable = yes cyrus_sasl_config_path = /etc/postfix/sasl #/etc/postfix/main.cf smtpd_sasl_auth_enable = yes I also run testsaslauthd -u paul -p 12345678 -r 10.1.10.18 -f /var/run/saslauthd/mux -s smtp: This works only on Postfix servers that do not run chrooted. On Debian Postfix' SMTP server smtpd runs chrooted by default. Either run smtpd not chrooted or place saslauthd's socket in Postfix chroot. Modify OPTIONS at the end of /etc/default/saslauthd in order to do so. Use the new socket path also in testsaslauthd testing. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: SASL authentication failure: cannot connect to saslauthd server
Am 13.08.2014 um 01:52 schrieb Patrick Ben Koetter: * pavel degtiarev paul.d...@gmail.com: I checked that as well: ls -ld /proc/1831/root lrwxrwxrwx 1 root root 0 Aug 12 17:14 /proc/1831/root - / It does not look like postfix is chrooted, 1831 is postfix pid. The entry in master.cf also points to non chrooted install: smtps inet n - - - - smtpd You are wrong. A '-' means 'use defaults'. Check the defaults in the column description honstly - chroot is in most cases a bad idea nd not recommended *why* ist the *default* chroot on? otherwise 30%-50% of the typical problem reports would not exist
Re: SASL authentication failure: cannot connect to saslauthd server
* li...@rhsoft.net li...@rhsoft.net: Am 13.08.2014 um 01:52 schrieb Patrick Ben Koetter: * pavel degtiarev paul.d...@gmail.com: I checked that as well: ls -ld /proc/1831/root lrwxrwxrwx 1 root root 0 Aug 12 17:14 /proc/1831/root - / It does not look like postfix is chrooted, 1831 is postfix pid. The entry in master.cf also points to non chrooted install: smtps inet n - - - - smtpd You are wrong. A '-' means 'use defaults'. Check the defaults in the column description honstly - chroot is in most cases a bad idea nd not recommended *why* ist the *default* chroot on? That's a discussion you need to take to the Debian folks. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: SASL authentication failure: cannot connect to saslauthd server
On Wed, Aug 13, 2014 at 01:56:41AM +0200, li...@rhsoft.net wrote: Am 13.08.2014 um 01:52 schrieb Patrick Ben Koetter: * pavel degtiarev paul.d...@gmail.com: I checked that as well: ls -ld /proc/1831/root lrwxrwxrwx 1 root root 0 Aug 12 17:14 /proc/1831/root - / It does not look like postfix is chrooted, 1831 is postfix pid. The entry in master.cf also points to non chrooted install: smtps inet n - - - - smtpd You are wrong. A '-' means 'use defaults'. Check the defaults in the column description honstly - chroot is in most cases a bad idea nd not recommended *why* ist the *default* chroot on? The master(5) default for chroot is y, but that means nothing. Postfix ships with a master.cf with n in the chroot column. Debian changes that default. We get the complaints here. otherwise 30%-50% of the typical problem reports would not exist Yes. Blame Debian. To be fair, if you follow Debian's instructions, their scripts populate and maintain the chroot. So blame Debian users for their failure to read Debian's documentation. But you are right; it's not a good idea. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: SASL authentication failure: cannot connect to saslauthd server
Am 13.08.2014 um 02:07 schrieb Patrick Ben Koetter: * li...@rhsoft.net li...@rhsoft.net: Am 13.08.2014 um 01:52 schrieb Patrick Ben Koetter: * pavel degtiarev paul.d...@gmail.com: I checked that as well: ls -ld /proc/1831/root lrwxrwxrwx 1 root root 0 Aug 12 17:14 /proc/1831/root - / It does not look like postfix is chrooted, 1831 is postfix pid. The entry in master.cf also points to non chrooted install: smtps inet n - - - - smtpd You are wrong. A '-' means 'use defaults'. Check the defaults in the column description honstly - chroot is in most cases a bad idea nd not recommended *why* ist the *default* chroot on? That's a discussion you need to take to the Debian folks how do you come to that conclusion? the chroot (yes) default is not debian specific debian specific is to set it not to -n what i meant is if it is not recommended why - means yes # === # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ===
Re: SASL authentication failure: cannot connect to saslauthd server
On Wed, Aug 13, 2014 at 02:42:47AM +0200, li...@rhsoft.net wrote: what i meant is if it is not recommended why - means yes The recommended *configuration* is an explicit chroot=no, the default behaviour of the software is to be more secure when no explicit setting is specified. This is not going to change, so asking why is pointless. -- Viktor.
Re: SASL authentication failure: cannot connect to saslauthd server
I changed Postfix to non chroot, plus some manipulation on saslauthd path permissions, and it worked. I must say that testsaslauthd thing is really confusing, it makes it look like it’s all postfix fault. :-) Thanks a lot guys! On Aug 12, 2014, at 9:17 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Aug 13, 2014 at 02:42:47AM +0200, li...@rhsoft.net wrote: what i meant is if it is not recommended why - means yes The recommended *configuration* is an explicit chroot=no, the default behaviour of the software is to be more secure when no explicit setting is specified. This is not going to change, so asking why is pointless. -- Viktor.
Re: Configuring postfix for outgoing SSL
Hi, I only see information on smtpd_tls_wrapper_mode in TLS_README. Am I missing it? That's the one. http://www.postfix.org/TLS_README.html#server_enable follow the instructions as written. Okay, I believe I have it working properly, but wanted to be sure, and also that my understanding of it all is correct. I have the following in master.cf, which was already there, just now uncommented: smtps inet n - n - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING I've enabled debug for my test host, and after restart postfix, I've tested it with the following openssl command: # openssl s_client -connect mail.example.com:465 It connects, displays the certificate, but it also says depth=0 OU = Domain Control Validated, CN = mail.example.com verify error:num=21:unable to verify the first certificate verify return:1 Is this something wrong with how I have the certificate set up? At the end, it says the following: SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 5C056C6F9E8528EBBCA...7D60A82EC9FF Session-ID-ctx: Master-Key: 688EDF0C592501E88D328...A11C2D05DE05318 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1407896713 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) I have a similar error when connecting to port 587 using openssl, however, it doesn't produce the complete certificate output, which I was expecting: # openssl s_client -quiet -starttls smtp -connect mail:587 depth=0 OU = Domain Control Validated, CN = mail.example.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 OU = Domain Control Validated, CN = mail.example.com verify error:num=27:certificate not trusted verify return:1 depth=0 OU = Domain Control Validated, CN = mail.example.com verify error:num=21:unable to verify the first certificate verify return:1 250 DSN On the server side, I have the following: Aug 12 22:37:50 email postfix/smtps/smtpd[10664]: Anonymous TLS connection established from sage[192.168.1.7]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) I have the complete log output here: http://pastebin.com/7wafUchT I think the problem I'm still having is that I thought I would also test with Thunderbird, and it doesn't work. When I test with port 587 it works okay, however, port 465 produces the following: Aug 12 22:52:13 mail01 postfix/smtps/smtpd[13529]: warning: TLS library problem: 13529:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:s3_pkt.c:1257:SSL alert number 42: submission on 587 works with the same key/cert pair, so I can't figure out what's wrong, and whether it's a Thunderbird problem or a postfix problem. I'm also having a problem with IMAP using STARTTLS on 143 working, but that's probably a dovecot problem. They do share the same cert, though. Any ideas greatly appreciated. Thanks, Alex
Re: Configuring postfix for outgoing SSL
On Tue, Aug 12, 2014 at 11:49:05PM -0400, Alex wrote: I've enabled debug for my test host, and after restart postfix, I've tested it with the following openssl command: # openssl s_client -connect mail.example.com:465 You've not specified a CAfile or CApath. See s_client(1). It connects, displays the certificate, but it also says depth=0 OU = Domain Control Validated, CN = mail.example.com verify error:num=21:unable to verify the first certificate verify return:1 Is this something wrong with how I have the certificate set up? Not necessarily, but a common error is to only configure the leaf certificate and not append the required intermediate certificates to the server's chain file. I think the problem I'm still having is that I thought I would also test with Thunderbird, and it doesn't work. When I test with port 587 it works okay, however, port 465 produces the following: Thunderbird generally employs STARTTLS not wrapper-mode. However, the certificate chain is the same, so it suffices to test port 587 with Thunderbird, and just test that 465 responds via s_client. submission on 587 works with the same key/cert pair, so I can't figure out what's wrong, and whether it's a Thunderbird problem or a postfix problem. Neither. Nothing is wrong. -- Viktor.
