Smarthost Test ?

[ThomasSWCS]

Hallo, ich würde gerne die Berichte im Alerting Center als Mail versenden. Aus den Anleitungen habe ich entnommen, dass dazu der Punkt "Smarthost" konfiguriert werden muss. Das habe ich auch getan. Leider kommen keine Berichte an. Ich finde auch keine Einträge im Log, die auf einen Fehler hindeuten. Schön wäre eine Funktion "Testmail senden" -). Wie kann ich den Smarthost testen ?

Aktuell werden sonst keine E-Mails versendet, die Funktion wird aktuell nur für das Versenden der Berichte verwendet

Danke

Thomas
P.S. Guten Rutsch und viel Erfolg in 2020

[Mario]

Schauen Sie bitte im Log bei den Applikations und Kernal-Meldungen nach. Zustaendig fuer den Versand ist Postfix bei der aktuellsten Softwareversion. Dort sollten entsprechende Rueckmeldungen angezeigt werden. Das Alerting-Center sendet mit "spalert@firewallname"

[ThomasSWCS]

Danke -). Da gibt es aktuell nur zwei Einträge

postfix/master[27400]: reload -- version 3.3.1, configuration /etc/postfix
postfix_bq_dkimdmarc[]: 32049|INF|destination set to inet:127.0.0.1:10026

[niklas]

Hallo, ich hab auch ein Problem mit dem Mail Versand im Alerting Center.
2 UTMs bei 2 verschiedenen Kunden, gleiche Konfig, bei einem bekomme ich Mails vom Alerting Center, bei der anderen keine.
Der Status für den Mailversand im AC ist bei beiden grün.
Die Funktion Testmail wäre schon super.

Grüße

[ThomasSWCS]

Ich habe nochmal nachgesehen. In den letzten 24 Stunden ist kein einziger Eintrag im Log bezüglich postfix zu sehen. Es passiert einfach nichts, der Status ist aber grün.

[Mario]

Bitte senden Sie ueber das Log eine Alerting-Center E-Mail. 

>> Log >> Alerting Center

Seit: > Alle

Dann unten auf "Bericht versenden" druecken.

Dann sollte im Log auf jeden Fall etwas auftauchen. (Umschalten auf Applikations- und Kernelmeldungen: postfix)

[ThomasSWCS]

Ja, jetzt taucht etwas auf -). Bin aber etwas verwundert

2020-01-02T19:12:03.039+01:00 postfix/relay/smtp[5932]: 840C08003A: to=<spalertd@firewall.oxxxxxxng.local>, relay=ds5xxxxx.goserver.host[37.17.xxx.xx]:25, delay=0.5, delays=0.01/0/0.33/0.16, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as DC1744C82E6)
2020-01-02T19:12:03.066+01:00 postfix/qmgr[5690]: 840C08003A: removed

spalertd@firewall als to-adressat ?. Ich habe eine andere Adresse konfiguriert..

[Mario]

Hallo, welche Adresse haben Sie denn konfiguriert?

Im Normalfall wird an die unter den Servereinstellungen definierte Mail-Adresse versendet. Und dann von der spalert@xxx.

[ThomasSWCS]

Hallo, habe mal ein paar screenshots als PM gesendet..-))

[Mario]

Hallo,

war das die gesamte Logmeldung? Fuer mich sieht es aktuell so aus, als ob es sich hier um eine Bounce-Mail handelt, die wieder zur Firewall kommt um dann wiederum an den Smarthost weitergeleitet zu werden. 

[ThomasSWCS]

2020-01-03T13:21:41.619+01:00 postfix/pickup[27666]: 970C880039: uid=205 from=<spalertd@firewall.xxxxx.local>
2020-01-03T13:21:41.629+01:00 postfix/cleanup[4330]: 970C880039: message-id=<20200103122141.970C880039@firewall.xxxxx.local>
2020-01-03T13:21:41.637+01:00 postfix/qmgr[5690]: 970C880039: from=<spalertd@firewall.xxxxx.local>, size=43177, nrcpt=1 (queue active)
2020-01-03T13:21:43.117+01:00 postfix/relay/smtp[4332]: 970C880039: to=<bu-notify@xxxxx>, relay=dsxxxxxxx.host[37.17.xxx.xxx]:25, delay=1.5, delays=0.03/0.01/1.4/0.04, dsn=5.7.1, status=bounced (host dsxxxx.xxxxx[37.17.xxx.xxx] said: 553 5.7.1 <spalertd@firewall.xxxx.local>: Sender address rejected: not owned by user backup@xxxxx (in reply to RCPT TO command))
2020-01-03T13:21:43.172+01:00 postfix/cleanup[4330]: 29D328003A: message-id=<20200103122143.29D328003A@firewall.xxxxx.local>
2020-01-03T13:21:43.179+01:00 postfix/bounce[4344]: 970C880039: sender non-delivery notification: 29D328003A
2020-01-03T13:21:43.179+01:00 postfix/qmgr[5690]: 29D328003A: from=<>, size=45468, nrcpt=1 (queue active)
2020-01-03T13:21:43.180+01:00 postfix/qmgr[5690]: 970C880039: removed
2020-01-03T13:21:43.665+01:00 postfix/relay/smtp[4332]: 29D328003A: to=<spalertd@firewall.xxxxxxx.local>, relay=xxxx..host[37.17.xxx.xxx]:25, delay=0.49, delays=0.01/0/0.33/0.15, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 80B464C82B5)
2020-01-03T13:21:43.692+01:00 postfix/qmgr[5690]: 29D328003A: removed
2

[ThomasSWCS]

Jetzt kamen mehr Meldungen. Scheinbar ist die Nachricht nicht angenommen worden

Sender address rejected: not owned by user backup@xxxxx (in reply to RCPT TO command))

[ThomasSWCS]

Das hier scheint das Problem zu sein: Sender address rejected: not owned by user backup@xxxxx

The mail server is rejecting your email because you're trying to send from a username which differs from the username you're logging in as, e.g. you've set the From: to be no-reply@mydomain.com, which is obviously not the same as admin@mydomain.com

Die Lösung wäre: Statt spalertd@ "einfach" eine einstellbare Adresse, ähnlich wie die globale E-Mail-Adresse, ermöglichen. Oder zumindest den Benutzernamen vom Smarthost als ALIAS eintragen.

Kann ich das irgendwie selbst erreichen oder ist das was für die Wunschbox ?

[Mario]

Leider in der Form nicht. Man kann zwar die Maildomain ueber Templates aendern, das spalert@ ist leider fest.

Gerne in die Wunschbox

[ThomasSWCS]

Die Sache mit der Maildomain wäre schon mal ein Anfang. Ich könnte ja eine E-Mail-Adresse spalertd@... generieren. Wie kann ich z.B. eine Maildomain "testxxxx.de", also den Absender als spalertd@testxxxx.de hinkriegen ?

[Mario]

Auf eigene Gefahr!

Im Webinterface: STRG + ALT + A

> Extras > Template

Suchen Sie nach "spalert"

/etc/spalertd/spalertd.conf >> Bearbeiten

Suchen Sie nach der Zeile "GLOBAL:HOSTNAME={{ print @GLOB_HOSTNAME}}"

Entsprechend aendern: "GLOBAL:HOSTNAME=huberthans.de"


Dienst des Alertingcenter neu starten!

Danach eine Testmail versenden >> Log pruefen

[ThomasSWCS]

Das funktioniert !!. Allerdings nur beim Test über das Alerting Center. Der regelmässige Bericht wird überhaupt nicht versendet.

[Mario]

Ist denn das Alerting Center entsprechend konfiguriert? Wenn der Test klappt, sind ja erst einmal nur die Vorraussetzungen erfuellt.

[ThomasSWCS]

Ja, es hat auch einen grünen Status -)). Wäre ja schön, wenn es einen Fehler gäbe, es passiert einfach..nichts...-)).

[it@ff-don.de]

Bei mir exakt das selbe Problem... es passiert einfach überhaupt nix

[Mario]

Versuchen Sie doch von Außen auf die Firewall zu verbinden und sich dann absichtlich mehrmals falsch zu authentifizieren. (Bitte daran denken, sich dabei nicht komplett von der FW auszusperren) Dann sollte entsprechend per IDS gesperrt + gemeldet werden. Im Log kann man auch pruefen, ob ueberhaupt Meldungen da sind: Statt "Heute" "Alle" waehlen.

Wenn keine Nachrichten im aktuellem Log sind >> No Mail

[it@ff-don.de]

Versuchen Sie doch von Außen auf die Firewall zu verbinden und sich dann absichtlich mehrmals falsch zu authentifizieren. (Bitte daran denken, sich dabei nicht komplett von der FW auszusperren) Dann sollte entsprechend per IDS gesperrt + gemeldet werden. Im Log kann man auch pruefen, ob ueberhaupt Meldungen da sind: Statt "Heute" "Alle" waehlen.

Wenn keine Nachrichten im aktuellem Log sind >> No Mail

Hi,
werde ich nachher mal probieren, sollte nicht Trotzdem der Planmäßige Bericht geschickt werden? auch ohne neue Meldungen?

[Mario]

Wenn keine aktuellen Meldungen vorliegen, kommt auch nichts.

Mit der IDS-Sperrung des Login bekommt man zumindest eine Meldung durch den regelmaeßigen Bericht.

[ThomasSWCS]

Wofür ist dann die Funktion "Regelmäßiger Bericht" gedacht ?. Da kann man wunderbar Tage und Uhrzeit einstellen. Ist das ein "Potemkinsches Dorf" ? . Nach all der Mühe, die ich aufgewendet habe um die Voraussetzungen für einen Bericht zu schaffen, stelle ich jetzt fest, das es keinen Bericht geben soll -((.  

[Mario]

Das ist identisch wie beim Spam-Bericht. Wenn es nichts zu vermelden gibt gibt es nichts zu vermelden. Frueher oder Spaeter werden Mails fuer das Alerting-Center eintreffen. Man sollte den Bericht dafuer nicht manuell ausloesen. Denn dann gibt es nichts mehr fuer den regelmaeßigen Bericht. Wie man es provozieren kann habe ich ja beschrieben.