> On Oct 7, 2022, at 15:08, Wietse Venema <wie...@porcupine.org> wrote:
> 
> Dan Mahoney:
>> Hey there all,
>> 
>> We have a couple of recipient canonical maps that do things like
>> transform firstname_lastname into username (i.e. dan_mahoney -->
>> dmahoney), also handle things like mapping people's former names
>> into current names.
> 
> Envelope or header?

Header, I think.  If you mean the bit in the <dmaho...@foo.org> part of the To: 
line.  DKIM and DMARC are looking at typically from, to, cc, (other headers 
too, but less likely to be rewritten).

>> 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?

> Things would get complicated otherwise.
> 
> 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?

> - 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.

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?


Reply via email to