Bonjour Monsieur Gilles,
> To reject a session based only on reporting events, you should subscribe
> to the relevant events in order to gather the info you want, then to one
> filter event to actually perform the action of rejecting.
>
> For example, I could subscribe to tx-connect, tx-helo and tx-ehlo to get
> source address, rdns, fcrdns and helo name from reporting events, but to
> reject the session based on this information I must decide when I want a
> rejection (do i want to reject at MAIL FROM ? RCPT TO ? DATA ? COMMIT ?)
> and register for appropriate filter event to actually reject a session.
>
> Builtin filters are a bit special because we are going to be VERY, VERY,
> VERY selective about them. Anything that can be done with a builtin, can
> be done with a proc filter and proc filters don't run in the same memory
> space so ... a good approach is to write a proc filter and if we find it
> makes sense to convert to a builtin, it can be discussed.
Understood. To be transparent on my side as well, I am primarily
interested in the Postfix filters listed in Craig Skinner's mail on
openbsd-misc [1].
An example is reject_unknown_helo_hostname, "Reject the request when
the HELO or EHLO hostname has no DNS A or MX record" - one might want
to add "DNS AAAA" to it.
This filter could reject the connection at helo/ehlo with "I had you at
helo", but as an external filter, will have to wait till one of the
filter phases.
> > > > 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.
> >
>
> yes, definitely.
>
> in filter chains, all filters always receive all _reporting_ events.
>
> this is a reason why report and filters are separate, if you look at the
> connect phase, all filters will receive the tx-connect report event THEN
> the connect filter event is triggered and all filters may not receive it
> because first filter may reject. if it rejects, then the reporting event
> tx-disconnected is sent to all filters.
>
> the action of a filter will never prevent all filters from receiving the
> report events.
Thanks. That is great to know.
> > > > 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);
> >
>
> yes, I had to start with something.
>
> to be very transparent my goal was to get behaving filters to fully work
> before the end of the year, then jan/feb/mar will be to ensure smtpd can
> cope with misbheaving filters.
>
> the areas we know need to be improved:
>
> - all kinds of timeouts: smtp session timeout, filters timeout, ...
> - all kinds of DATA issues: filter responding with end of message, while
> client hasn't responded with end of message yet, ...
> - all kinds of exhaustions: failure to allocate filter sessions, failure
> to send data to filters because the pipe is exhausted, ...
> - all kinds of filters fuckup: filters responding with bad phases or bad
> sessions or bad action, etc... some are bugs, some are legit, ...
>
> now that we know filters work, including in chains, we can focus on what
> is needed to make them rock solid for April :-)
Completely understand. My queries were from the perspective of getting
to understand the interfaces, and also as a defensive measure against
misbehaving filters. And since volks will write misbehaving filters, we
would need to guard against them.
Dhanyavaad.
Regards,
ab
[1] - https://marc.info/?l=openbsd-misc&m=153804263417563&w=2
---------|---------|---------|---------|---------|---------|---------|--
--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]
