> On 18 Apr 2016, at 14:08, Boudewijn Dijkstra > <[email protected]> wrote: > >>> 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 > > smtpd -v -Tall > doesn't seem to make it more verbose, but I understand that there are a > several open issues related to logging. With -d it works though. I'll report > findings to github issue #674. > >> Now, I noticed that the -T flag got lost from man page as well... I will >> investigate and bring it back. > > Great.
This is done. >>>> [...] >>> 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. >> >>> 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?). > > My filter doesn't really have expectations, it just keeps (naive) state of > information gathered and inserts a dataline when it has all the info it needs. > > Curious? Read code here: Ok, I see. Within your filter you want to make sure filter_api_writeln() is always called and all lines are written back (avoiding data loss). This is what you correctly do already in on_dataline(). > https://github.com/bdijkstra82/OpenSMTPD-extras/tree/master/extras/wip/filters/filter-spf A few comments from a very quick look: - mem-leak: you alloc struct envelope, but never free(), e.g. in on_disconnect() - you do not need to define/use callbacks if you do not do anything or just accept things, e.g. your on_rcpt() and on_commit() can be zapped, just use filter-trace if you want to see/debug what is going on - consider adding prefix, see other filters - you may want make your filter hard fail returning reject_code 4xx on in-consistencies, e.g. if you do not find the envelope() Other than that it looks good already and is the right direction. So keep up the good work. >> Even if next callback is on_dataline() you may be >> able to check and notice the broken pipe. > > How? filter_api_writeln() doesn't have a return value. Does it set errno? Yes, not possible. Sorry for confusion. >> 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. > > Sure, but I'm trying to develop a filter, so if a work-around is quicker, > I'll take it. After reading your code, I fear there is no quick workaround as this bug is beyond the scope of your filter and located in the underlying filter API. -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
