On Mon, 06 Jul 2015 16:53:27 +0200, Walter Alejandro Iglesias wrote: > Till you mentioned about it I've ignored the existence of > /usr/libexec/mail.local. :-) I'm a new to OpenBSD. Is it some kind of > procmail's alike functionality?
It's what delivers messages to /var/mail/username when invoked by the MTA. > I tried modifying the comsat line in inetd.conf, using just udp4, > removing the ip limit prefix, etc. I've tried installing procmail > (telling smtpd to use it). I did some tests stopping /etc/rc.d/inetd > and running inetd -d form the command line. It turns out mail.local only supported udp4 anyway (though I've just committed a fix for that). > With the default inetd.conf, after sending a mail to myself: > > # inetd -d > ADD: 127.0.0.1:comsat proto=udp, wait.max=1.256 user:group=root:wheel builtin > =0 server=/usr/libexec/comsat > ADD: ::1:comsat proto=udp6, wait.max=1.256 user:group=root:wheel builtin=0 se > rver=/usr/libexec/comsat > ADD: daytime proto=tcp, wait.max=0.256 user:group=root:wheel builtin=1959e0e0 > 8630 server=internal > ADD: daytime proto=tcp6, wait.max=0.256 user:group=root:wheel builtin=1959e0e > 08630 server=internal > someone wants comsat > 14937 execv /usr/libexec/comsat > > The last two lines appeared right after sending the email. I understand > (in my ignorance) that means inetd *receives* the notification (from > mail.local?). And the following is what netstat shows: Correct, mail.local sends a message to the comsat port which inetd listens on. Then inetd will exec comsat with the socket hooked up to standard input and output. > I know biff isn't a big concern but I insisted because I thought it > could be a symptom of some other more important issue. The root cause was that mail.local sends a newline character after the spool file offset which comsat was not expecting. This used to work but got broken by the conversion to strtonum(). I've committed a fix for comsat similar to the diff I send earlier. - todd
