Index | Thread | Search

From:
"Omar Polo" <op@omarpolo.com>
Subject:
Re: smtpd: Give filters their own syslog tag
To:
"Kirill A. Korinsky" <kirill@korins.ky>
Cc:
Martijn van Duren <openbsd+tech@list.imperialat.at>, tech@openbsd.org
Date:
Tue, 10 Mar 2026 09:28:09 +0100

Download raw body.

Thread
Kirill A. Korinsky <kirill@korins.ky> wrote:
> On Fri, 20 Feb 2026 12:44:16 +0100,
> Martijn van Duren <openbsd+tech@list.imperialat.at> wrote:
> > 
> > On 2/20/26 10:18, Martijn van Duren wrote:
> > > EHLO,
> > > 
> > > A few months ago Leo Unglaub send me an e-mail asking about the position
> > > of the mail ID inside the syslog line, more specifically that we
> > > currently prepend the filter-name before it; Making it hard to find the
> > > ID with automated tools.
> > > 
> > > While I'm not a fan of automated parsing of log-files, there is
> > > something to say for having consistency in the placement, and not
> > > forcing in the filtername.
> > > 
> > > I would like to propose the following diff, making use of syslog_r to
> > > give every filter their own tag. Since tags can only have alpha-
> > > and up to 32 characters (RFC3164 section 4.1.3) I made it the default
> > > to use the first 32 alpha-characters from the filter-name, and if that
> > > result is too ugly an admin can use the new tag keyword to create their
> > > own one.
> > > 
> > > syslog_r isn't a portable function, but I've already discussed a couple
> > > of potential solutions with op@, so there shouldn't be any problems in
> > > that area.
> > > 
> > > OK?
> > > 
> > > martijn@
> > As a followup I would like to add the option to let filters specify the
> > loglevel per message. There's no value in specifying the global loglevel
> > on a per-filter basis via cli flags, and to let smtpd log them all as
> > LOG_WARNING.
> > It might be worthwhile to also send a config update when smtpctl
> > changes the loglevel to reduce the logmsg overhead for filters that
> > would support this, but that wouldn't make a functional difference and
> > outside the scope of this diff.
> > 
> > martijn@
> >
> 
> It reads well, and, frankly, I had missed that feature when developed and
> debuged filter a few times.

ok op@ as well =)