On Sun, Dec 23, 2018 at 01:30:09PM +0100, Aham Brahmasmi wrote:
> 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.
>
I think there is a misunderstanding, builtin and external filters handle
the exact same filtering phases. No matter if the filter is written as a
builtin or an external filter, you would register for the same phases.
There is _nothing_ you can do with builtins that you can't do with proc,
and what you do with one would be done the same with the other.
> > > > > 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.
>
yup, feel free to ask any question, until we have a stable interface and
documentation for it, I'm the only point of information ;-)
I want to make it clear though that OpenSMTPD will not cover for filters
misbehaving, in most cases it will abort because filters are not allowed
to violate the protocol, plain and simple.
Most of the missing work is to actually ensure that filters can't end in
a situation where they violate the protocol because of the API not being
good enough or not notifying the filters that they should not answer, or
that a session has timed-out, etc...
For instance, smtpd will not abort because a filter timed out reponsing,
it will throw a temporary error at smtp session because it is not really
a protocol violation. If the filter responds incorrectly to a phase, the
daemon will abort because it essentially means the filter has gone nuts.
--
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
