I think the problem is the argument to the smtp-auth-command
parameter. Because there is a space between vchkpw and /bin/true,
spamdyke doesn't know they should both be part of the
smtp-auth-command. When an incoming connection starts, spamdyke runs
the /bin/true executable instead of
The executable error is occurring because the script is marked setuid
instead of just executable. The message is incorrect -- I'll fix it in
the next version. However (IIRC), I don't believe the setuid bit has
any effect on scripts in Linux environments.
The encrypted authentication failure
Authentication failures are only logged to the syslog when the
log-level option is verbose or excessive. Logging them at lower
levels could allow one misconfigured mail client to quickly fill a
server's logs with failure messages.
Yes, my mention of full log files was in reference to the
The executable error is occurring because the script is marked setuid
instead of just executable. The message is incorrect -- I'll fix it in
the next version. However (IIRC), I don't believe the setuid bit has
any effect on scripts in Linux environments.
You are right but instead of a script
The group permissions on your TLS certificate aren't working because
your script explicitly sets the group to nobody when tcpserver
starts. Entries in /etc/groups only affects interactive logins, not
daemon processes like tcpserver. Try changing your script from this:
-g `id -g nobody`
To
* Sam Clippinger s...@silence.org [090928 22:13]:
I think the problem is the argument to the smtp-auth-command
parameter. Because there is a space between vchkpw and /bin/true,
spamdyke doesn't know they should both be part of the
smtp-auth-command. When an incoming connection starts,
The script you posted did not include any details about which user is
running tcpserver, but it looks like that user does not have permission
to run /home/vpopmail/bin/vchkpw. If that file's mode is 711, take a
look at the permissions on the folders /home/vpopmail/bin,
/home/vpopmail and
The group permissions on your TLS certificate aren't working because
your script explicitly sets the group to nobody when tcpserver
starts. Entries in /etc/groups only affects interactive logins, not
daemon processes like tcpserver. Try changing your script from this:
-g `id -g nobody`
