Beiträge von tbc233

Ich konnte eben mehrere Dateien, die definitiv am Montag noch geblockt wurden, versenden. Gehe daher mal vorsichtig davon aus, dass das Thema vom Tisch ist und habe Clamav wieder aktiviert.

Cool! Wenngleich sich in meiner Gedankwelt die Hinweise schon verdichtet haben, dass es in Richtung des Zertis als Ursache geht, wär ich darauf nicht gekommen.

Wobei, jetzt wo Du es sagst, darauf muss man generell aufpassen. Manche Anbieter liefern die Zertifikatsdateien mit Windows Zeilenumbrüchen und wenn man diese dann auf Linux System spielt, kann genau so ein Quatsch rauskommen. Ich glaube zum Beispiel GoDaddy liefert bis heute eine der Dateien aus dem Zertifikatspaket mit Windows Zeilenumbrüchen aus, die zweite Datei nicht.

Oder vielleicht doch mal testweise ein Zerti besorgen das auf den eigentlichen Hostnamen aus dem SMTP Dialog (bfnet.bpaserver.net) lautet und das an dc-install verfüttern. Dann wieder testen ob von gmail was durchkommt. Dank letsencrypt kostet so ein Experiment ja nichts (ausser Zeit) und Du kannst dann das als Ursache zumindest ausschließen - bzw. sollte das Mail dann durchgehen, weißt Du dass das doch die Ursache ist.

Das scheint mir echt ne harte Nuss zu sein. Soweit fällt mir in der DNS/MX Konfiguration nichts auf. Über die Tatsache, dass das implementierte Zerti einen anderen Common Namen hat als sich der Server im SMTP Dialog meldet (und auf den der PTR Record lautet), kann man diskutieren. Ich würde es mitelfristig harmonisieren, vermute aber mal nicht dass es was mit Deinem Problem zu tun hat.

Das Zerti ist ja relativ jung, vielleicht kannst Du trotzdem mal überlegen, ob der Zeitpunkt ab dem es die Probleme gab (3-4 Tage auf oder ab, weil es ja immer etwas dauert bis es bemerkt wird) mit dem Zeitpunkt der Zerti Installation zusammenfallen könnte. Falls ja, wär es ein Hinweis. Vielleicht bricht Google den SMTP Dialog ja tatsächlich ab, wenn das Zerti nicht mit dem Hostnamen zusammenpasst. Wenn zu so einem frühen Zeitpunkt der SMTP Dialog von der Gegenstelle abgebrochen wird, wär es auch denkbar dass Du nichts schlüssiges im Log siehst.

Ansonsten haben wir das bald soweit durchanalysiert, dass bald nur mehr Routing/Firewall Probleme von Google zu Dir übrig bleiben. Das würde dann auch ebenfalls erklären warum Du so gar nichts im Log siehst.

Danke für die Hostnamen, aber mich würde mehr eine Domain interessieren, die definitiv nichts von gmail empfangen kann.

Zitat von nitram70

Macht es Sinn hier mal ein paar records zu posten oder andere Zusammenhänge darzustellen?

Ich kann zwar nichts versprechen, aber es kann vielleicht nicht schaden. Vielleicht fällt jemandem von uns was auf. Zumindest eine betroffene Domain wär nicht uninteressant, den MX Record dazu etc. können wir dann eh selbst abfragen.

Sumeragi , hast eine PN von mir

Zitat von Sumeragi

Ich konnte gerade ohne Probleme eine Mail mit PDF im Anhang zuschicken. Signaturen Version ist ebenfalls 25462:

War es auch sicher eine PDF Datei, die vorher geblockt wurde? Es sind (oder waren) nämlich definitiv nicht alle PDFs betroffen. Ich konnte leider nicht so recht eingrenzen woran es lag, aber der Großteil der PDFs ging durch. Ich weiß das so genau, weil gestern ein Kollege von mir im Rahmen einer Sonderschicht sehr viele PDFs (Druckabzüge) verschicken musste und von ca. 20 PDF Dateien wurden nur etwa vier geblockt.

Ich hab inzwischen aufgegeben und clamav deaktiviert. Mir wurde es zuviel, Telefon hörte nicht mehr zu läuten auf. Da es ja nicht das erste mal ist, hab ich da schon scripte vorbereitet:

clamav deaktieren:

clamav wieder aktivieren:

Mist, ich hatte gehofft dass das vielleicht bis heute früh in den Virensignaturen korrigiert ist. Das kann ja dann lustig werden heute.

Ich würde ausnahmsweise Sumeragi widersprechen, meiner Erfahrung nach haben die einliefernden gmail Mailserver durchaus einen PTR Record.

Ich würde im ersten Schritt auch nochmal alle Logs abklopfen. Manchmal ist das setup des systemloggers etwas ungeschickt, sodass vielleicht relevante Meldungen in einem anderen Log gelandet sind. Ich würde hier an Deiner Stelle Mails von einem gmail Konto schicken und nebenbei live am Server mit schauen.

Sollte sich tatsächlich rausstellen, dass gmail weiterhin sagt dass Dein Server die Mails ablehnt OHNE dass Du auch nur irgendwas im Log davon mitbekommst, würde ich als nächstes andere Ursachen prüfen. Als erstes würde mir ein ipv6 Problem einfallen. gmail stellt bevorzugt per ipv6 zu. Ein denkbares Szenario wäre zum Beispiel, dass Du einen Hostnamen im MX Record hast, der einen AAAA Record hat, eine Kontaktaufnahme an diese ipv6 Adresse aber aus irgendeinem Grund nicht funktioniert.

Im Moment berichten mir sehr viele Anwender von Problemen beim Senden von E-Mails mit PDF Attachments. Anscheinend gibts hier grad ein Problem mit ClamAV Signaturen. Sehr viele Mails werden zurückgewesen weil angeblich erkannt als "Win.Exploit.CVE_2019_0903-6966169-0"

Hab dazu auch diesen recht aktuellen Thread gefunden: https://marc.info/?l=clamav-users&m=155878981528623&w=2

Ich bin zwar nicht sicher ob nachfolgende Info outdated ist, weil der symlink vielleicht inzwischen gar nicht mehr notwendig ist, aber es klingt ein bisschen verdächtig dass ein perl update da reingefunkt hat.

Kontrollier mal ob /usr/bin/perl ein symlink auf /usr/local/pd-admin2/bin/perl ist. Falls nicht, mach einen draus.

Danke Dir für die Erkenntnisse. Der Wert von 3600 ist btw ziemlich sicher übertrieben, er wurde nur im Zuge des Testens so massiv erhöht. Ich stand ja am Anfang ohne jede Idee einer Ursache vor dem Problem und da klotzt man schon mal bei solchen Werten

Da ich derzeit etwas Streß habe, bin ich noch nicht dazu gekommen Tomloaders Tipps auszuprobieren, zumal ich es durch apache2.2 ja mal entschärfen konnte. Ich werde wohl weitere Versionen mal abwarten.

Ich ärgere mich im Nachhinein dass ich damals meine ipv6 Tests auf einem Testsystem gemacht habe, bei dem aufgrund der Domainanzahl keine Lizenz nötig war. Daher hat alles funktioniert und für mich war das Thema abgehakt.

Ich denke derzeit, eine Lösung kann hier nur pd-admin seitig geschehen. pd-admin stellt Lizenzen für die ipv6 Adresse aus, daher sollte auch diese geprüft werden. Oder man beginnt, ipv6 Adressen ins Lizenzsystem aufzunehmen.

Ich habe mir eine eigene Lösung gebaut für letsencrypt, mittels dehydrated: https://github.com/lukas2511/dehydrated

Das initiale erstellen eines zertis muss ich derzeit noch händisch machen mittels "dehydrated -c -d hostname". AB DANN hab ich ein script das täglich läuft und die vadmin datenbank nach allen ssl hosts anzapft. Findet es eins, schaut es im dehydrated certs Verzeichnis nach, ob es auch wirklich ein selbst erstelltes ist (könnte ja auch irgendein anderes zerti sein, zb eines dass der Kunde selbst gekauft hat). Wenn dem so ist, wird der dehydrated Befehl angeworfen und dieser erneuert das zerti, SOFERN es in weniger als 14 Tagen abläuft. Wenn es erneuert wurde, kopiert das script die zertis mit der nötigen Benennung nach /opt/pdadmin/sslcerts und macht einen apache reload.

Damit fahr ich recht gut auf vielen Servern. Ich hatte das schon fertig, bevor pd-admin begonnen hatte letsencrypt selbst zu implementieren, daher habe ich es auch weiterhin so gelassen.

Generell alle Mails die via nicht-authentifizierter smtp Verbindung zu localhost oder via sendmail Befehl abgesetzt werden, fallen nicht ins Sendelimit. Somit im Prinzip alles was so von Scripts / Weboberflächen generiert wird.

Wurde hier schonmal diskutiert, dass das schade ist. Andererseits versteh ich es, ich wüsste selbst nicht wie man das implementieren könnte.

Bezogen auf ein mailgenerierendes Kunden-Script dass in einem bestimmten Account liegt, ginge es vielleicht noch. Man könnte den sendmail Befehl durch ein wrapper Script ersetzen, dass auf das Sendelimit Rücksicht nimmt.

Aber bei einer serverweit gemeinsam genutzten Sache wie roundcube wirds schwierig.

Sowas ist wirklich Mist, zumal roundcube ja nicht im Kontext des SMTP Accounts des Users versendet. Somit greift das ansonsten recht hilfreiche Sendelimit des Accounts nicht.

Der erste Ansatz der mir einfallen würde:

Man kann bei Roundcube im config File ein logging aufdrehen. Dann wird jede Action in ein File im roundcube Logs Verzeichnis geloggt. Da könnte man dann schauen, ob sich beim Absetzen eines Mails hier etwas tut, das man in eine fail2ban Regel pressen könnte. Wenn hier bei jedem Mailversand, hoffentlich inklusive IP, eine Zeile geloggt wird, könnte man mit fail2ban die Sendelimits (zb. maximal 20 Mails in 15 Minuten) beinahe adäquat nachbauen.

Vielen Dank, das erleichtert mich direkt etwas. Bin aber unsicher was Du meinst mit "in meinem vhost habe ich gesetzt...". Die vhost Definitionen werden ja stets automatisch generiert und rausgeschrieben.

Oder meintest Du global in der httpd.conf-template?

Mist, ich hatte mich echt gefreut dass wir hier auf der richtigen Spur waren. Schade zu hören dass es nun nichts hilft.