Bonjour Monsieur Gilles,
Merci beaucoup for your exhaustive explanations.
> > 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.
So in case one wants to reject a session based only on reporting events,
one still has to wait till the filter events start coming in. Or one
could write a built-in like fcrdns. Is this correct?
> > 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.
So if in a chain {f1,f2,f3}, if f2 takes too much time to respond, both
f1 and f3 will be notified of the session timeout.
> > 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.
I may be wrong here, but I was unable to find a filter_builtins_ehlo in
the code. From lka_filter.c
..
static int filter_builtins_notimpl(struct filter_session *, struct filter
*, uint64_t, const char *);
static int filter_builtins_connect(struct filter_session *, struct filter
*, uint64_t, const char *);
static int filter_builtins_helo(struct filter_session *, struct filter *,
uint64_t, const char *);
static int filter_builtins_mail_from(struct filter_session *, struct
filter *, uint64_t, const char *);
static int filter_builtins_rcpt_to(struct filter_session *, struct filter
*, uint64_t, const char *);
..
{ FILTER_CONNECT, "connect", filter_builtins_connect },
{ FILTER_HELO, "helo", filter_builtins_helo },
{ FILTER_EHLO, "ehlo", filter_builtins_helo },
{ FILTER_STARTTLS, "starttls", filter_builtins_notimpl },
..
> > 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.
Understood. I based the LINE_MAX on the following within lka_filter.c:
int
lka_filter_process_response(const char *name, const char *line)
{
...
char buffer[LINE_MAX];
...
(void)strlcpy(buffer, line, sizeof buffer);
Dhanyavaad.
Regards,
ab
---------|---------|---------|---------|---------|---------|---------|--
--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]
