Dan Mahoney:
> >> This is useful where a user wants to have one canonical spamassassin
> >> settings folder, which spamass-milter gets by looking at the left
> >> hand side of the address. So we clearly want spamass-milter to
> >> run after this rewriting happens.
> >>
> >> On the other side...we want our DKIM checks to run BEFORE this
> >> thing, since otherwise, the DKIM signatures on the to: line will
> >> not match.
> >>
> >> Is there a way to tell specific milters where in this chain to
> >> fire?
> >
> > Postfix rewrites headers while mail is written to the queue file,
> > AFTER that, the first Milter gets an opportunity to see message content
> > and optionally make changes, then the second milter, and so on.
>
> Okay, but everything in the docs
> (https://www.postfix.org/MILTER_README.html) refer to them as
> before-queue milters. Is that a misnomor?
No. There are two queue files.
The current flow is:
network -> smtpd(8)+milters ->cleanup(8)+milters -> queue file -> some delivery
agent.
The proposed flow is:
network -> smtpd(8)+milters#1 ->cleanup(8)+milters#1 -> queue file#1 -> smtp(8)
->
smtpd(8)+milters#2 ->cleanup(8)+milters#2 -> queue file#2 -> some delivery
agent.
Where milters#1 are before queue file#1, and milters#2 are after
queue file#1 (but before queue file#2).
> > Things would get complicated otherwise.
More complicated in Postfix internal implementation, that is.
> > What you could do is
> >
> > - Implement the header rewrite with a Milter that follws the DKIM
> > militer. Not much fun there.
>
> Honestly, a rewriting milter would be the best option here, so its
> position in the chain can be controlled and made optional. I don't
> suppose there's a way to call a copy of cleanup or trivial-rewrite
> AS a milter, is there, so it can fire up its various rewrite rules?
No. Those are internal interfaces that do change, as they did after
Postfix 3.5. Programs that use internal interfaces cannot be
supported. They would make it much harder to improve Postfix.
Also, cleanup writes queue files. It can currently not be piped
through another cleanup instance. Making that sanely usable would
be a major project.
> > - Run multiple Postfix instances, or implement CONTENT_FILTER_README
> > with Postfix talking over SMTP to itself without going through an
> > actual content filter. Do the DKIM check in Postfix before the
> > fake content filter, and do the header rewriting in Postfix after
> > the fake content filter.
>
> In reading the FILTER_README, it looks like that doc refers to
> triggers after messages have already queued, and thus are already
> rewritten.
It's just mail going through Postfix twice, no mystery triggers
at all.
> The problem here feels like all these extra copies of postfix would
> be after I've accepted the message, and thus lose my opportunity
> to reject messages at SMTP time. Am I misunderstanding this?
Yes. All rejects would have to happen when a message enters Postfix,
before the first queue file. The second pass through Postfix would
just rewrite headers, no reason to reject mail.
Wietse
