Benutzerdefinierte SMTP Reply Codes für before_queue_filtering

[linushstge]

Vielen Dank für die Implementierung der before_queue_filtering Funktion!

Aktuell werden alle blockierten Nachrichten bei aktiviertem Feature mit

5.7.1 Rejected for policy reasons

abgelehnt.

Ist hier geplant, benutzerdefinierte Reply Codes anzugeben, damit der Sender weitere Informationen über den Grund der Ablehnung erfahren kann?

Genial wäre, wenn "Block" Action Objekte angelegt werden könnten, die sowohl Reply Code als auch eine Nachricht enthalten.

 

[Stoiko Ivanov]

hmm - global den code und die Nachricht zu ändern ließe sich relativ gut bewerkstelligen - es beim Block Object hinzuzufügen, wäre wohl einiges mehr an Aufwand - was wäre der use-case für individuelle responses je regel?
(Ich gehe davon aus, dass möglichst wenig Informationen an potentielle Spammer zurückgemeldet werden sollten)

Bitte einen enhancement request in unserem bugzilla erstellen: https://bugzilla.proxmox.com, dann haben wir es an der richtigen stelle gesammelt und andere User, die die Funktionalität auch gerne hätten könnten sich dort melden.

Danke!

 

[linushstge]

Generell müsste es nicht zwangsläufig beim Block Object sein. Stattdessen wäre eine Config Datei auch völlig ausreichend.

Natürlich möchte man nicht zu viele Informationen für den Block Grund weitergeben, aber ggf. macht es Sinn hier FAQ Perma Links zurückzugeben, sodass ein entsprechender False Positive "Spammer" weitere Informationen darüber enthält, weshalb seine E-Mail abgelehnt wurde. Z.B. aufgrund von einem SPF Hard Fail o.ä.

Enhancement ist angelegt:
https://bugzilla.proxmox.com/show_bug.cgi?id=2505

Danke für die schnellen Rückmeldungen.

 

[agrisvv]

it think this would be nice for ldap user rejects - without need to create smtp layer ldap rejects.

 

[linushstge]

Wie stehen die Chancen für eine Implementierung in den nächsten 6 Monaten?
(Genrell wäre eine Lösung via Config Datei auch völlig ausreichend)

 

[Stoiko Ivanov]

Wie stehen die Chancen für eine Implementierung in den nächsten 6 Monaten?

Wir sind derzeit am vorbereiten eines point releases (PMG 6.2) - da hat das enhancement keinen platz gefunden.

Auch wäre es eher realistisch eine Antwort konfigurierbar zu machen (und nicht unterschiedliche antworten je rule)