Postfix: pcre: oder hash:

[Peter Blancke]

Guten Tag,

in meiner Postfix-Konfiguration befindet sich auch eine Datei namens
"transport", die in der main.cf durch

transport_maps = pcre:/etc/postfix/transport-maps

aufgerufen wird.

Ich koennte die "transport_maps" natuerlich auch mit postmap in eine
"transport_maps.db" konvertieren und dann als Aufruf

transport_maps = hash:/etc/postfix/transport-maps

verwenden.

Was mag bei den beiden Varianten unterschiedlich sein?
CPU-Auslastung? Zeitverhalten?

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!

[Peter Blancke]

Am 2017-04-26, Peter Blancke <bla...@gmx.de> schrieb:

Gerade selber gefunden:

> transport_maps = pcre:/etc/postfix/transport-maps
>
> transport_maps = hash:/etc/postfix/transport-maps

> Was mag bei den beiden Varianten unterschiedlich sein?

- hash = Notation, die einen Suchbegriff formuliert, der exakt paßt
oder garnicht
- pcre, regexp = Notation, die ein Suchmuster formuliert, das auf
mehrere Begriffe passen kann

Und "hash" soll auch schneller sein.

Ist das korrekt so?

[Juergen P. Meier]

Peter Blancke <bla...@gmx.de>:

> Am 2017-04-26, Peter Blancke <bla...@gmx.de> schrieb:
>
> Gerade selber gefunden:
>
>> transport_maps = pcre:/etc/postfix/transport-maps
>>
>> transport_maps = hash:/etc/postfix/transport-maps
>
>> Was mag bei den beiden Varianten unterschiedlich sein?
>
>
> - hash = Notation, die einen Suchbegriff formuliert, der exakt paßt
> oder garnicht
> - pcre, regexp = Notation, die ein Suchmuster formuliert, das auf
> mehrere Begriffe passen kann
>
> Und "hash" soll auch schneller sein.
>
> Ist das korrekt so?

Ja.

Hash nimmst du wenn du weniger Performance-impact haben willst und
exakte Matches hast (also keine Wildcards oder Substrings).

Regular Expression maps nimmst du wenn du die flexibilitaet brauchst

[Juergen P. Meier]

Peter Blancke <bla...@gmx.de>:

> Ich koennte die "transport_maps" natuerlich auch mit postmap in eine
> "transport_maps.db" konvertieren und dann als Aufruf
>
> transport_maps = hash:/etc/postfix/transport-maps
>
> verwenden.
>
> Was mag bei den beiden Varianten unterschiedlich sein?

Du musst letzteres mit postmap nach jeder aenderung updaten, denn hash:
greift eigentlich auf die Datei /etc/postix/transport-maps.db zu, die
mit dem Kommando "postmap /etc/postfix/transport-maps" erzeugt wird.

[Peter Blancke]

Am 2017-04-26, Juergen P. Meier <nospa...@jors.net> schrieb:

> Hash nimmst du wenn du weniger Performance-impact haben willst und
> exakte Matches hast (also keine Wildcards oder Substrings).
>
> Regular Expression maps nimmst du wenn du die flexibilitaet
> brauchst

Danke fuer die Erhellung, ja, jetzt ist's klar.

Mich verfolgt naemlich folgendes Problem:

Fuer einen "Autoresponder" habe ich in einer "hash-autoreply" in
etwa folgendes stehen:

,----[ /etc/postfix/hash-autoreply ]
| us...@example1.com us...@example1.com, us...@example1.com@autoreply.meinedomain.de
| us...@example2.com us...@example2.com, us...@example2.com@autoreply.meinedomain.de
| us...@example3.com us...@example3.com, us...@example3.com@autoreply.meinedomain.de
`----

Also eine normale Verteilung der Mails an den Originalempfaenger und
zusaetzlich an eine fiktive lokale Domain.

Die "fiktive" lokale Domain "autoreply.meinedomain.de" loest ein
Skript aus, welches Absender- und Empfaengeradressen herausfischt
und die entsprechende Autoreply-Aktion ausloest. Funktioniert alles
gut.

ABER:

Die /etc/postfix/hash-autoreply wird mir langsam ein wenig grosz und
unuebersichtlich. Es waere dienlich, wenn grundsaetzlich _alle_
eingehenden Mails behandelt wuerden, so dasz nur noch das
nachgeschaltete Autoreply-Skript die Arbeit hat festzustellen, ob
ein Autoreply erfolgt oder nicht.

Ich braeuchte also eine Art einzeilige RegEx fuer die Datei, gedacht
in etwa so:

,----[ /etc/postfix/hash-autoreply ]
| \(.*\@.*\/ \1, \1...@autoreply.meine.domain.de
`----

"recipient_bcc_maps" scheint mir da irgendwie nicht geeignet, weil
ich dann die Originalempfaengeradresse so schlecht bzw gar nicht
herausfiltern kann.

Wie kann ich so etwas angehen? Es soll kein SIEVE in Einsatz kommen,
weil ich die gesamte Weboberflaeche fuer den Endanwender bereits
fertig habe und die Weiterverarbeitung durch ein PHP-Script erfolgt,
welches die von der "master.conf" an das Skript weiter gegebenen
Variablen $sender, $recipient und $client_address auswertet.