Updated from Mail-Sender-0.8.21 to 0.8.22 back in April, and only just discovered that vacation has been broken ever since. Everything works as expected up to the sending of the message, which fails with: ERROR> /var/spool/vacation/vacation.pl:469 main::send_vacation_email - Failed to send vacation response: Connection not established Adding >dev-perl/Mail-Sender-0.8.21 to package.mask and downgrading to 0.8.21 fixed it straight away.
hm, 0.8.22 works fine by me.
Same problem with Mail-Sender-0.8.22 and vacation.pl from postfixadmin-2.3.5. Downgrade Mail-Sender to 0.8.21 solwed.
So, can someone please confirm this si maybe it can get fixed? Thanks
Ok, guys, this just happened to me AGAIN on the new server I'm rolling out. There is DEFINITELY a bug in 0.8.22 that causes a TLS/SSL failure when using the vacation.pl script with postfixadmin (and I imagine any other script that uses Mail::Sender in combination with TLS/SSL). If it matters, I do use self-signed certs. A quick downgrade to 0.8.21 fixed me right up.
Here is what happens in the postfix logs for a failed session using 0.8.22: 2013-12-28T11:04:58-05:00 newhost postfix/587/smtpd[10598]: connect from myclient.example.com[192.168.1.110] 2013-12-28T11:04:58-05:00 newhost postfix/587/smtpd[10598]: 5A76A80170248: client=myclient.example.com[192.168.1.110], sasl_method=PLAIN, sasl_username=validuser@example.com 2013-12-28T11:04:58-05:00 newhost postfix/cleanup[10613]: 5A76A80170248: message-id=<52BEF6A0.1050507@example.com> 2013-12-28T11:04:58-05:00 newhost postfix/qmgr[10594]: 5A76A80170248: from=<validsender@example.com>, size=623, nrcpt=2 (queue active) 2013-12-28T11:04:58-05:00 newhost dovecot: lda(validrecipient@example.com): msgid=<52BEF6A0.1050507@example.com>: saved mail to INBOX 2013-12-28T11:04:58-05:00 newhost postfix/pipe[10614]: 5A76A80170248: to=<validuser@example.com>, relay=dovecot, delay=0.05, delays=0.02/0.01/0/0.02, dsn=2.0.0, status=sent (delivered via dovecot service) 2013-12-28T11:04:58-05:00 newhost postfix/587/smtpd[10598]: disconnect from myclient.example.com[192.168.1.110] 2013-12-28T11:04:58-05:00 newhost postfix-25/smtpd[10620]: connect from newhost.example.com[127.0.0.1] 2013-12-28T11:04:58-05:00 newhost postfix-25/smtpd[10620]: SSL_accept error from newhost.example.com[127.0.0.1]: 0 2013-12-28T11:04:58-05:00 newhost postfix-25/smtpd[10620]: warning: TLS library problem: 10620:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1256:SSL alert number 48: 2013-12-28T11:04:58-05:00 newhost postfix-25/smtpd[10620]: lost connection after STARTTLS from newhost.example.com[127.0.0.1] 2013-12-28T11:04:58-05:00 newhost postfix-25/smtpd[10620]: disconnect from newhost.example.com[127.0.0.1]
Ok, I've confirmed that this problem is due to 0.8.22 changing the default setting for using TLS to TRUE. I asked about this on the postfix list, and after a bit of troubleshooting with cboltz with the postfixadmin project, we determined that this is apparently a bug in Mail::Sender's TLS implementation: https://rt.cpan.org/Public/Bug/Display.html?id=85438 It simply does not work. The reason it only reared its ugly head in 0.8.22 is because they changed the TLS DEFAULT to TRUE. To fix 0.8.22 to work with postfixadmin's vacation.pl, just edit: /var/spool/vacation/vacation.pl and add 'tls_allowed' => 0, somewhere in the %smtp_connection settings (starting at line 435). Confirmed that this works now with 0.8.22
> Confirmed that this works now with 0.8.22 Closed then, thanks :)
