Beiträge von tbc233

Zu meinem Punkt 2)

Habe es inzwischen getestet. Mails mit einer DKIM-aktivierten Domain als Absenderadresse werden auch dann DKIM signiert, wenn sie via simplen php mail() (somit via /usr/sbin/sendmail) generiert werden. Find ich klasse!

Mir ist aufgefallen, dass auf einem Server beim Aktivieren von DKIM in der pd-admin Oberfläche oben dann anschließend

Bad file descriptor/flock failed: Resource temporarily unavailable

angezeigt wird. Die DKIM Signatur scheint aber anschließend zu funktionieren.

Weiters bleibt DKIM anscheinend aktiviert, wenn man den Schalter wieder umlegt (also wieder deaktivieren möchte). Der Schalter bleibt jedenfalls auf "On".

Vorab möchte ich Daniel Bradler sagen dass ich für die DKIM Implementierung wirklich sehr dankbar bin. Das ist in meiner Wahrnehmung ein riesiger Schritt, der Potential hat den Alltag von uns und unseren Anwendern massiv besser zu machen. Tolle Arbeit!

Was mir bis jetzt aufgefallen ist:

1) Rein interne Mails (also alice@domain.com mailt direkt an bob@domain.com) werden anscheinend nicht DKIM signiert. Soweit ich beobachten kann auch dann nicht, wenn es verschiedene Domains sind die sich auf dem selben Host befinden (Server hostet domain1.com und domain2.com und die beiden mailen untereinander -> keine DKIM Signatur). Ich denke mal dass dieser Punkt zu vernachlässigen ist, fallen jemand Szenarien ein in denen das von Nachteil sein könnte? Wobei: Nett wär es irgendwie schon.

2) Ich konnte noch nicht Testen, ob scriptgenerierte Mails signiert werden. Also wenn eine Webpräsenz zum Beispiel via PHP ein Mail absetzt (sendmail Kommando oder PHP mail() Funktion). Hat das schon jemand beobachtet? Das wär nämlich der Oberhammer, meine Hoffnung wäre dass sich die Zustellungsrate von Webshop-Bestätigungen, Registrierungsmails etc. damit massiv verbessert.

3) Einige meiner Anwender verwenden Scripte bzw. Suites, die bereits ihrerseits eine DKIM Signatur an generierten Mails anbringen. "Superwebmailer" zum Beispiel kann das. Hier wird bei entsprechender Konfiguration vor dem Absetzen des Mails bereits softwareseitig eine DKIM Signatur angebracht. Ich frage mich nun, ob es hier nun zu einer "Doppelsignierung" kommen könnte. Und falls ja, ob das ein problem wäre. Weil dann müsste ich die Leute informieren, dass sie das DKIM signieren auf deren Seite wieder raus nehmen.

4) Ich verwende das Thunderbird Plugin "DKIM Verifier". Hier finde ich interessant, dass dieses die DKIM Signaturen von pd-admin Systemen NICHT erkennt. Also es beurteilt sie auch nicht als invalid, es verhält sich einfach so als wäre das Mail nicht DKIM signiert. Würde ich mich interessieren warum. Das aber nur am Rande, hier werde ich vielleicht den Entwickler des Plugins mal befragen.

5) Absolute Kleinigkeit: Nett wäre, wenn man den Namen des Eintrages (derzeit stets "default" selbst wählen könnte. Ist aber aus meiner Sicht wirklich nur "nice-to-have".

im Nachhinein ärgert es mich dass ich, als alter pd-admin Hase, da nicht schon früher drauf gekommen bin

Jetzt steht noch die zweite längerjährig in Betrieb befindliche Gentoo Maschine an.

Habe nun das Softlimit des unverschlüsselten smtpd auf 125000000 erhöht. Es scheint als wären die Probleme damit vom Tisch, ich beobachte weiter. In Summe würde das alles Sinn ergeben, auch die Tatsache dass es während der problematischen Phases auf Port 465 funktioniert hat (weil dort lauscht ja stunnel ohne Softlimit in diesem Sinne).

Ich habe jetzt gesehen dass auf dem betroffenen System im qmail-smtpd/run ein Softlimit von nur 50000000 drin ist. Andere (neuere) pd-admin Server haben hier 125000000. Also mehr als das Doppelte.

Ich werde mal versuchen diesen Wert anzupassen und dann wieder das neue /usr/local/pd-admin2 Verzeichnis in Stellung zu bringen. Da warte ich aber noch etwas bis sich die betroffenen User wieder beruhigt haben.

Ich muss das Thema nochmal aufgreifen, langsam verzweifle ich etwas.

Ich habe auf den betroffenen Systemen nun nochmal einen Versuch gewagt mit Update auf SE 0.369 (4) und pd-admin 4.70. Danach wieder kein Mailversand möglich. Meldung im Syslog

smtpd: 1605751813.541401 install_driver(mysql) failed: Can't load '/usr/local/pd-admin2/lib/perl5/site_perl/5.10.1/x86_64-linux/auto/DBD/mysql/mysql.so' for module DBD::m$
smtpd: 1605751813.541428  at (eval 5) line 3
smtpd: 1605751813.541434 Compilation failed in require at (eval 5) line 3.
smtpd: 1605751813.541442 Perhaps a required shared library or dll isn't installed where expected
smtpd: 1605751813.541449  at /usr/local/pd-admin2/bin/checksmtppasswd line 16
smtpd: 1605751813.716765 install_driver(mysql) failed: Can't load '/usr/local/pd-admin2/lib/perl5/site_perl/5.10.1/x86_64-linux/auto/DBD/mysql/mysql.so' for module DBD::m$
smtpd: 1605751813.716799  at (eval 5) line 3
smtpd: 1605751813.716805 Compilation failed in require at (eval 5) line 3.
smtpd: 1605751813.716810 Perhaps a required shared library or dll isn't installed where expected
smtpd: 1605751813.716815  at /usr/local/pd-admin2/bin/checksmtppasswd line 16

Spannend ist hier, dass diese Probleme anscheinend nur beim Absetzen von Mails (mit SMTP-Auth) auf dem Port 25 auftreten. Testmails von mir auf Port 465 (mit SSL) haben jederzeit funktioniert. Ebenso hat die reguläre Mail Einlieferung auf Port 25 stets funktioniert.

Nach einem Rück-Umbenennen des pd-admin2 Verzeichnisses auf die Version vor dem Update funktionierte alles wieder. Allerdings natürlich sehr unsauber, da nun wieder die alte Serverumgebung mit dem nagelnauen pd-admin läuft. Ich befürchte hier Side-Effects im Betrieb mit dieser Kombination.

Die eingesetzte Distri ist Gentoo. Mir ist klar, dass dies eher exotisch ist, andererseits setze ich seit 18 Jahren immer wieder mal pd-admin mit Gentoo ein und hatte vorher noch nie Probleme. Auch diese beiden betroffenen Systeme liefen vorher 3-4 Jahre stabil mit pd-admin.

Ich wäre hier sehr froh eine Lösung zu finden. Mir bliebe sonst nichts anderes übrig als diese beiden Server auf eine andere Distri zu migrieren (weil auf meinen Centos Servern habe ich dieses Problem nicht), das wäre natürlich ein sehr hoher Aufwand.

Danke vorab für jeden Input.

Schön dass ich helfen konnte.

Warum die Zuordnung der MAC Adresse des Interfaces zum Namen sich verändert hat, ist in der Tat mysteriös. Eigentlich dürfte das nur passieren, wenn sich die MAC Adresse des Interfaces ändert (zum Beispiel weil eine Netzwerkkarte getauscht wird oder man das System in einer anderen Hardwarekonfiguration hochfahren lässt). Möglicherweise ist es ja passiert, als Du die Platten im Ersatzrechner hochfahren hast lassen. Erklärt aber dann nicht, warum es vorher nicht ging.

Der genaue Hergang wird sich wohl jetzt nicht mehr rekonstruieren lassen. In jedem Fall weißt Du da aber jetzt Bescheid, weil dieses Procedere wird dann wieder wichtig sein, wenn Du tatsächlich mal auf den Ersatzrechner angewiesen bist.

Darum war das ifconfig -a wichtig, weil es alle Netzwerkschnittstellen anzeigt, auch die nicht konfigurierten.

Warum auch immer, ich würde jetzt mal als Ferndiagnose sagen dass sich die Zuordnung der MAC Adresse zum Interfacenamen verändert hat. Das ist ein udev Thema.

Du hast aus meiner Sicht zwei Möglichkeiten, entweder Du konfigurierst Dein Netzwerk auf die eth2 um, oder Du schaust ob Du klären kannst warum das physische Netzwerkinterface nun eth2 hat. Für letzteren Weg bin ich jetzt leider nicht so gut in Debian, aber ich würde hier mal nach /etc/udev/rules.d schauen. Dort könnte ein File liegen das zum Beispiel "70-persistent-net.rules" heißt (Name kann varieren). Dort steht zum Beispiel drin

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:7a:d5:03", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

Das könntest du auf eth1 adaptieren und rebooten. Andere Zeilen mit eth1 entfernen. Oder Du löschst das ganze File (vielleicht eventuell irgendwohin weg sichern), dann sollte es beim nächsten Reboot wieder neu aufgebaut werden und die Netzwerkinterfaces werden wieder neu durchnummeriert.

sind mehr Schnittstellen sichtbar wenn Du

ifconfig -a

eingibst?

Zitat von Eisenherz

Doch die gab es auch damals schon, nur war es da noch die Beta.

hmmm... Schwierig jetzt nachzuvollziehen ob mir das passiert ist damals.

Vielleicht war es wirklich das und ich sollte mich hier nochmal über ein Update drüber trauen.

Ich würde hier gern kurz auf mein Problem RE: SMTP Versand bei 4-354 funktioniert nicht vom April referenzieren. Ich trau mich nämlich seitdem nicht mehr, diesen einen Server wo das passiert ist, upzudaten. Jetzt wo ich all dies hier gelesen und mitbekommen habe: Wär es denkbar dass ich hier damals versehentlich die 64bit Version erwischt habe? Oder gabs die damals noch gar nicht?

Der Gedanke kam mir, weil die Fehlermeldung in meinem Log damals sehr änlich war wie die hier genannte.

ich hab mir dafür eine "neutrale-domain.com" gekauft und lasse jeden server da drunter laufen (zb. server01.neutrale-domain.com und so weiter).

Ich rate ebenfalls dringend davon ab einen Hostnamen unter einer Domain zu verwenden, die Du später auf dem Server verwalten willst mit pd-admin. Glaub mir, da kommt nichts gutes dabei raus.

Du kannst dem Reseller User ganz normal mittels passwd auf der kommandozeile ein neues Kennwort geben. Dann öffnest Du Dir die /etc/shadow und kopierst den Kennwort-Hash raus (zwischen dem ersten und dem zweiten Doppelpunkt der Zeile) und fügst ihn in die Tabelle vadmin -> resellers ins Feld passwd ein.

Wäre es denkbar dass die ABSENDER Domain mal bei diesem Provider war? Ich hatte mal einen sehr ähnlich gelagerten Fall, da stellte sich dann raus dass die Domain früher mal bei diesem Empfänger-Provider war und die dann nie von deren Mailservern gelöscht wurde. Das heißt, deren Mailserver fühlten sich immer noch für die Absenderdomain zuständig und haben daher die Absendermailbox überprüft. Die existierte dann natürlich nicht (bei denen) und daher wurde rückgewiesen.

Das oder etwas in die Richtung würde es erklären.

Mir ist aufgefallen dass es nun einen Punkt "Dienste" im Endkundenmenü gibt. Ich konnte da jetzt mittels Forumssuche nichts dazu finden und es erschließt sich mir nicht was man hier machen kann. Sorry falls blöde Frage - aber weiß hier jemand bescheid?

Das ist nur eine Warning. Ich bild mir ein, die seh ich seit Jahren beim updaten/installieren. Korrigiert mich, aber ich habe hier noch nie Auswirkungen bzw. Fehler im Alltag festgestellt.

Meine Vermutung wäre, dass Einträge

.domain.de

(neben der regulären Zeile für domain.de)

existieren in /var/qmail/control/ rcpthosts und virtualdomains. Diese sorgen glaube ich dafür dass sich qmail für alle Subdomains zuständig fühlt. pdadmin hat diese Zeilen früher standardmäßig angelegt, seit einiger Zeit nicht mehr. Ich kann das auf einem langjährigen Server recht gut sehen, ältere Domains haben diese Zeile, neuere nicht.

Es wäre einen Versuch wert, diese Zeile mit dem punkt voran in beiden Files zu entfernen und qmail Dienste neu zu starten. Ich denke, dann wird qmail nicht mehr versuchen, Mails für die Subdomains lokal zuzustellen.

Könnten bei Dir vielleicht die Inodes knapp werden auf der Partition? check mal mit df -i

Prüf vielleicht auch mal Dein /opt/pdadmin/tmp/top/ Verzeichnis, das läuft bei langjährigen Installationen gern mal über (sofern kein Löschjob existiert) und war hier schon 1,2 mal für eine knappe Inode Situation verantwortlich.

Weiters den ipv6 Support verbessern. Ich weiß nicht ob sich hier was getan hat, aber momentan tut man sich nichts gutes, wenn man für den Hauptservernamen einen AAAA Record hinterlegt. Es führt dazu dass Leute die per ipv6 daher kommen, nicht auf die pdadmin Oberfläche kommen.

Ich hätte mal mit viel Hingabe alles in der apache Konfig (respektive template) adaptiert damit das funktioniert, nur um dann festzustellen dass die ipv6 Besucher einen Lizenzfehler bekommen beim pd-admin einloggen.