On Fri, Apr 15, 2016 at 11:35:27AM +0200, Boudewijn Dijkstra wrote: > > >5. Can you turn on tracing the filters and smtp session to see, where it > > stuck exactly? > > # smtpctl trace filter > smtpctl: invalid trace keyword: filter > # smtpctl trace filters > command succeeded > > Not sure if this discrepancy should be fixed in smtpctl.c or smtpctl.8.
Looks like a typo in smtpctl(8). I fixed it. Thanks for noticing. > Anyway, I did this: > # smtpctl log verbose > # smtpctl trace smtp > # smtpctl trace filters This trace is not (yet) passed to the filters. This is an open todo, see https://github.com/OpenSMTPD/OpenSMTPD/issues/630 step 3. > But the amount of information written per session to /var/log/syslog didn't > change. How should I turn on said tracing? Add the flags to the smtpd startup, either manually or via rc.conf(8), e.g. smtpd -dv -Tall Now, I noticed that the -T flag got lost from man page as well... I will investigate and bring it back. > >>However, with my filter-spf in the chain this results in > >>messages being accepted with an empty data portion, which is highly > >>undesirable. > >> > >>On an error, socketpair() sets errno, so as a work-around I think I > >>should reject with 451 if errno is found to be nonzero inside afilter > >>callback. Should this work? > > > >Yes, you should check every library or syscall for it's return value > >(and maybe errno) and handle the error, e.g. temporarily reject with 4xx > >error code. See the existing filters for examples. > > Can you confirm that an errno raised by the socketpair() call in > filter_dispatch() will be propagated to a filter callback before the message > is definitely accepted? Nope, probably it will not be propagated, because libc errno is highly temporarily. Next libc call will overwrite it. I miss-understood you in the first and thought your own filter called socketpair(), but this comes directly from the filter API. > Otherwise I will have to prevent data loss by > monitoring the open file count. If the socketpair() error happens the pipe will be closed and your next filter callback should be on_rollback or on_disconnect, so you will notice something went wrong (because you expected different state in your filter, right?). Even if next callback is on_dataline() you may be able to check and notice the broken pipe. So you can just clean up the required things in this case to avoid data loss. However, all this is duck tape around the original problem, which needs to be fixed. -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
