On Sat, Dec 22, 2018 at 07:23:50PM +0100, Aham Brahmasmi wrote:
> Bonjour Monsieur Gilles,
>
> To start with, Merci Beaucoup for all the effort and patience.
>
> I think there might an inadvertent interchanging of the comments
> in your blog post titled "more on OpenSMTPD filters" [1]:
> ..
> listen on all filter # not filtered
> listen on socket # filtered
> ..
> If I am not wrong, the first comment might be "filtered" and the second
> might be "not filtered".
>
indeed
> In terms of the filter API, I base my thoughts and queries on the python
> API, blog posts, rspamd filter and the committed code in CVS.
>
> 1) What is the difference between the "report" and "filter" prefixes?
> My current understanding is that "report" is oriented towards reporting
> and "filter" is oriented towards writing filters.
>
very simple:
- event reporting lets smtpd notify filters of any event that leads to
a change in the SMTP session, they are informative and do not accept
any answer.
- event filtering lets smtpd notify filters of any event that leads to
a decision in the SMTP session, they are decisive and require that a
filter provides a decision.
report lines are one way from smtpd to filters, filters must not reply
filter lines are two way between smtpd and filters, for any request an
answer is required.
both reporting and filtering are "subscribed" so filters will only get
the events they subscribed to.
> 2) How would one handle failures within external filters? Is there a
> mechanism to signal to the SMTP filter chain to remove oneself?
>
nope, this is not going to happen.
the contract is very clear:
a filter is an infinite loop which must never exit.
just like smtpd processes never exit, filter processes never exit,
otherwise it means they are buggy.
> 3) Are there time limits for a filter to return response?
>
time limits are not implemented yet, but yes there will be a time limit,
very likely related to the SMTP session timeouts.
it's not tricky to implement, it'll be a notification sent to the filter
that the last query timed-out and it shouldn't respond anymore.
this will result in a Temporary Failure in the SMTP session, filters are
not allowed to exceed that timeout.
> 4) Suppose there are three filters {f1,f2,f3} in a chain. If f3 rejects
> the connection, do f1 and f2 get notified?
>
yes, the report events are broadcasted to all filters.
if f3 rejects a connection, f1, f2 and f3 will get a 'link-disconnect'
event if they subscribed to it.
> 5) Could we have the filter builtin for helo be different from the
> ehlo? It might be instructional to understand that the client asked
> for ehlo.
> { FILTER_EHLO, "ehlo", filter_builtins_helo },
it is already the case, helo and ehlo are different filter hooks:
filter foo1 builtin helo [...]
filter foo1 builtin ehlo [...]
the same applies for proc filters, they can subscribe to helo and ehlo
as different filtering events.
> 6) Could we add the reason for rollback in tx-rollback? If I am not
> wrong, a client can rollback using RSET, QUIT or HELO/EHLO within a
> transaction.
nope, as explained in the blog, the idea is to retain the interface
as small as possible by only passing info which is not available in
any other previous hook.
if listening to previous events can bring the knowledge, then it is
up to the filter to listen to these events and build its state. For
your example, there are events to catch RSET / QUIT / HELO and EHLO
so tx-rollback will not duplicate that info.
> 7) In lka_filter.c, if a filter feeds back more than LINE_MAX, should
> we handle that?
>
> (void)strlcpy(buffer, line, sizeof buffer);
>
that's an interesting question.
LINE_MAX is not the correct value but we need to have a maximum value
for the line and filters will need to ensure they don't produce lines
bigger than these.
> 8) What if the SMTP input/output or the filter input/output contains "|"
> as a character - would the separator processing still work?
>
yes
the protocol header fields have a fixed size and do not contain '|',
only the last field may contain '|' so there's no ambiguity.
> I am not sure all my queries above are relevant or correct, so in case
> they do not make sense, I apologize.
>
don't apologize, there were interesting questions :-)
--
Gilles Chehade @poolpOrg
https://www.poolp.org tip me: https://paypal.me/poolpOrg
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
