Viktor Dukhovni via Postfix-users:
> On Tue, Feb 24, 2026 at 05:17:45PM +0100, lejeczek via Postfix-users wrote:
>
> > I've just upgraded whole OS and postfix along with it.
> > I've had in my _sender_dependent_default_transport_maps_ file:
> >
> > @one.xyz? local_1-out:
> > @two.xyz? local_2-out:
> >
> > which
> >
> > -> $ postmap -F hash:/etc/postfix/sender_transport
>
> Is this some sort of AI hallucination? Why on earth would you use "-F"
> in this context? The postmap(1) documentation notes:
>
> When the -F option is given, the value must specify one or more
> filenames separated by comma and/or whitespace; postmap(1) will
> concatenate the file content (with a newline character in? serted
> between files) and will store the base64-encoded result instead of
> the value.
>
> I can't think of any reason why a human and not a bot would decide that
> "postmap -F" is the right tool for indexing a transport table...
>
> When I ask Google's Gemini:
>
> When buildind index tables with the Postfix "postmap" command when
> is it appropriate use "postmap -F"?
>
> the answer is way off the mark. Tables built with "postmap -F" are only
> useful for storing SNI-based private key + certificate chains, and the
> Postfix code consumng such a table needs to be prepared to decode the
> base64-encoded payload before handing it off to the TLS library (which
> internally decodes more base64, but that's the TLS library's internal
> business).
It is way off, but the response to 'When is it appropriate use
"postmap -F"' gets closer to the mark and mentions SNI map updates.
I suppose that a query can contain too much information?
Wietse
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
