Noreplay Adressen

[RichBone]

Hallo

ich habe folgendes Problem, aktuell gibt es noreply@ Adressen welche in der Queue hängen aber nicht in der Warteschlange von Webinterface angezeigt werden.

Dadurch bekommt der Absender der E-Mail alle 5 Minuten ein Mail Delivery, weil die E-Mail nicht zustellbar sei.

Gibt es irgendwie eine möglichkeit E-Mail an noreply@ Adressen generell zu blocken, damit diese nicht in der Warteschlange landen?

Mit freundlichen Grüßen
Martin Krüger

 

[Stoiko Ivanov]

ich habe folgendes Problem, aktuell gibt es noreply@ Adressen welche in der Queue hängen aber nicht in der Warteschlange von Webinterface angezeigt werden.

welche Warteschlange und welche queue? (nur um sicher zu gehen, dass wir vom selben sprechen) - wenn möglich bitte command-outputs und screenshots anhängen - ebenso bitte logs zu diesen Mails

Dadurch bekommt der Absender der E-Mail alle 5 Minuten ein Mail Delivery, weil die E-Mail nicht zustellbar sei.

das sollte auch nicht passieren (wenn die mails deferred sind gibt es zwar (konfigurierbar) reminder - aber nicht im 5-minuten takt)

Gibt es irgendwie eine möglichkeit E-Mail an noreply@ Adressen generell zu blocken, damit diese nicht in der Warteschlange landen?

einige - potentiell über eine Regel (oder die bestehende Blacklist regel) - potentiell über eine postfix-config - aber auch hier wären die logs hilfreich.

 

[RichBone]

Hallo

mit Warteschlange meine ist die Warteschlange welche im GUI vom Proxmox Mail Gateway angezeigt wird.

Diese war leer, als ich dann per mailq mit die Queue direkt auf dem betroffen MX anzeigen lassen hatte, habe ich die E-Mail gesehen.

Als ich diese dort dann gelöscht hatte, wurden vom Mail Gateway keine Fehlermeldung siehe:

This is the mail system at host mx1.xxx.de.

####################################################################

# THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. #

####################################################################

Your message could not be delivered for more than 4 hour(s).

It will be retried until it is 5 day(s) old.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can

delete your own text from the attached returned message.

The mail system

<noreply@domain.de>: connect to

o2.ptr758.XXXXX.cloud[XXX.XX.XXX.XX]:25: Connection timed out

versendet.

Aus welchen Logs benötigen Sie Auszuüge?

Mit freundlichen Grüßen
Martin Krüger

 

[Stoiko Ivanov]

mit Warteschlange meine ist die Warteschlange welche im GUI vom Proxmox Mail Gateway angezeigt wird.

unter GUI->Queues->Deferred Mail?
- das ruft (relativ direkt) `postqueue -j` auf - falls das Problem immer noch ist (das in `mailq` am PMG angezeigt wird, aber nichts in der GUI aufscheint) bitte das output von postqueue -j posten

This is the mail system at host mx1.xxx.de.

nur sicherheitshalber ist mx1.xxx.de das PMG system?

Aus welchen Logs benötigen Sie Auszuüge?

/var/log/mail.log vom PMG - welches die Zustellversuche anzeigt

 

[RichBone]

Hallo

Aufbau ist wie folgt:

Cluster aus 2 Proxmox Server im Cluster

mx1.xxx.de
mx2.xxx.de

unter

Queue Administration -> verzögerte E-Mail wurde nichts angezeigt

Danach via GUI die Konsole auf das System zugegriffen, per Befehl: mailq wurde die besagte E-Mail angezeigt, welche dort dann per postsuper -d XXXXXXX gelöscht wurde.

Mit freundlichen Grüßen
Martin Krüger

 

[bytemine]

Moin,

einige - potentiell über eine Regel (oder die bestehende Blacklist regel) - potentiell über eine postfix-config - aber auch hier wären die logs hilfreich.

dergleichen haben wir bereits versucht - eine "Droplist" mit "noply@domain.tld" drauf, und eine Regel mit Prio 97, Mails an die Droplist zu blocken. Scheint aber ignoriert zu werden, stattdessen wird eine Recipient-Verification beim empfangenden Server durchgeführt (was sonst der Fall sein sollte) und dann gebounced.

 

[RichBone]

Hallo

haben vielleicht andere ein Beispiel was funktioniert?

Mit freundlichen Grüßen
Martin Krüger

 

[Stoiko Ivanov]

Scheint aber ignoriert zu werden, stattdessen wird eine Recipient-Verification beim empfangenden Server durchgeführt (was sonst der Fall sein sollte) und dann gebounced.

Das ist das erwartete Verhalten:
* Recipient Verification wird von postfix gemacht - zur Zeit des SMTP dialogs - (nach dem RCPT command) - die mail wird erst danach ans Regelsystem übergeben.

Normalerweise stört das aber nicht, da die ja keine Mails verschickt werden und die recipient verification gecached wird:
http://www.postfix.org/ADDRESS_VERIFICATION_README.html

 

[bytemine]

Das ist das erwartete Verhalten:
* Recipient Verification wird von postfix gemacht - zur Zeit des SMTP dialogs - (nach dem RCPT command) - die mail wird erst danach ans Regelsystem übergeben.

Normalerweise stört das aber nicht, da die ja keine Mails verschickt werden und die recipient verification gecached wird:
http://www.postfix.org/ADDRESS_VERIFICATION_README.html

Also müsste man dies bei Postfix anpassen, und zwar an einer Stelle, die nicht von PMG überschrieben wird?

 

[Stoiko Ivanov]

Also müsste man dies bei Postfix anpassen, und zwar an einer Stelle, die nicht von PMG überschrieben wird?

was genau anpassen - falls die recipient verification nicht verwendet werden soll (wovon ich eher abraten wuerde, da recipient verification doch recht gut funktioniert und die last am System reduziert) - kann diese in der GUI (Configuration->Mail Proxy->Options) deaktiviert werden.

Falls die postfix config dennoch manuell angepasst werden muss - einfach das templateing system verwenden:
https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_template_engine