Hi, i installed opensmtpd-5.4.1p1-1.el6.x86_64 from the EPEL repo 2 days ago in order to try it out and possibly switch from postfix to it. I configured to work with dovecot 2 and everything to the knowledge that was available on the net (which is not very much and inconsistent on top because of the time lines the blogposts/news/configs were written), the only thing that i never got to work was actually sending a mail because the authentication failed every single time, even without tls.
More useful information below. ---------------------------- smtp.conf: ---------------------------- if_ext="eth0" if_loc="lo" pki mydomain.com certificate "/etc/opensmtpd/mydomain.com.crt" pki mydomain.com key "/etc/opensmtpd/mydomain.com.key" table aliases file:/etc/aliases table passwords file:/etc/shadow table secrets file:/etc/opensmtpd/secrets table domains file:/etc/opensmtpd/domains listen on $if_loc listen on $if_ext port 25 tls pki mydomain.com auth-optional <secrets> listen on $if_ext smtps pki mydomain.com auth-optional <secrets> tag authenticated hostname mydomain.com mask-source accept from any for domain <domains> alias <aliases> deliver to maildir accept from any relay ------------------------------- maillog: ------------------------------- ebug: smtp: listen on xxx.xxx.xxx.xxx port 25 flags 0x9 pki "mydomain.org " debug: smtp: listen on IPv6:::1 port 25 flags 0x0 pki "" debug: smtp: listen on 127.0.0.1 port 25 flags 0x0 pki "" debug: smtp: will accept at most 2022 clients debug: smtpd: scanning offline queue... debug: smtpd: offline scanning done debug: smtp: new client on listener: 0x793b60 smtp: 0x7f7970: STATE_NEW -> STATE_CONNECTED smtp-in: New session ca6b6d46008a0867 from host client.domain.net[xxx.xxx.xxx.xxx] debug: lka: looking up pki "mydomain.org" debug: session_start_ssl: switching to SSL smtp-in: Started TLS on session ca6b6d46008a0867: version=TLSv1/SSLv3, cipher=ECDHE-RSA-AES128-SHA, bits=128 smtp: 0x7f7970: >>> 220 mydomain.org ESMTP OpenSMTPD smtp: 0x7f7970: <<< EHLO [10.0.0.66] smtp: 0x7f7970: STATE_CONNECTED -> STATE_HELO smtp: 0x7f7970: >>> 250-mydomain.org Hello [10.0.0.66] [xxx.xxx.xxx.xxx], pleased to meet you smtp: 0x7f7970: >>> 250-8BITMIME smtp: 0x7f7970: >>> 250-ENHANCEDSTATUSCODES smtp: 0x7f7970: >>> 250-SIZE 36700160 smtp: 0x7f7970: >>> 250-AUTH PLAIN LOGIN smtp: 0x7f7970: >>> 250 HELP smtp: 0x7f7970: <<< AUTH PLAIN plain_password= smtp: 0x7f7970: STATE_HELO -> STATE_AUTH_INIT debug: lka: authenticating for secrets:testuser smtp-in: Authentication failed for user testuser on session ca6b6d46008a0867 smtp: timing-attack protection triggered, will defer answer for 613979 microseconds smtp: 0x7f7970: >>> 535 Authentication failed smtp-in: Failed command on session ca6b6d46008a0867: "AUTH [...]" => 535 Authentication failed smtp: 0x7f7970: STATE_AUTH_INIT -> STATE_HELO smtp: 0x7f7970: <<< AUTH LOGIN smtp: 0x7f7970: STATE_HELO -> STATE_AUTH_USERNAME smtp: 0x7f7970: >>> 334 VXNlcm5hbWU6 smtp: 0x7f7970: <<< Y2l0cw== smtp: 0x7f7970: STATE_AUTH_USERNAME -> STATE_AUTH_PASSWORD smtp: 0x7f7970: >>> 334 UGFzc3dvcmQ6 smtp: 0x7f7970: <<< password= debug: lka: authenticating for secrets:testuser smtp-in: Authentication failed for user testuser on session ca6b6d46008a0867 smtp: timing-attack protection triggered, will defer answer for 476478 microseconds smtp: 0x7f7970: >>> 535 Authentication failed smtp-in: Failed command on session ca6b6d46008a0867: "password=" => 535 Authentication failed smtp: 0x7f7970: STATE_AUTH_PASSWORD -> STATE_HELO -------------------------- I am not really sure where the problem is, since the secrets table is loaded and so is the domain file. I can only assume that it's a linux-port related issue in relation with pam or a layer 8 problem which seems very unlikely at this point. On another note, while testing and trying to understand this behavior, the sendmail from this package seems to be using the fqdn (hostname.domain.tld) in order to send mails via mail command. This results in "Sender address rejected: Domain not found" because the MX can not be resolved because the fqdn is not the MX record. I already talked to __gilles on irc, where he suggested that i should try contacting the maintainer dfateyev, which is why i am here.
