Beiträge von statnc

netcup

"Wir werden mit den Upgrades frühestens am 10.08.2021 beginnen. Wir kündigen diese für jedes System in der vorigen Woche per E-Mail an"

könnt ihr eine Angabe machen, ob der ganze Prozess vielleicht 2-3 Wochen dauert oder wird es sehr viel mehr sein?

Für die eigene Planung wäre gut zu wissen, ob das alles zB noch im August durch sein wird oder ob man möglicherweise erst im September oder so eine Mail bekommt, dass man in der nächsten Woche "dran" ist.

Wäre super, danke!

(ich hoffe das hier ist im richtigen Forum)

ich lass das mal. Das ist mir zu viel Trouble mit den verschiedenen Acounts und Hosting und Server. Wer weiß wie lange das stabil so läuft. Ich werde einen virtuellen MTA aufsetzen der auf Port 25 antwortet so wie ich das haben will. Danke an alle für die Hilfeversuche!

ulf8000 keine Ahnung wie du darauf kommst, das hab ich nicht geschrieben. Die uralt-Software auf einem uralt-Mac eines Kunden verschickt Statusmails nur auf Port 25. Ist eben so.

ja, bestimmt ist das so. Aber ich nutze einen Reseller Server (welcher kein Root-Server ist). Trotzdem danke.

über meinen Reseller Server gings nicht mit Port 25, egal ob und welche Verschlüsselung.

Ich habe da wenig auch Hoffnung. Bei H-e-t-z-n-e-r geht's auch nicht, hab da auch nen Web-Hosting Account getestet.

Ok, da muss dann wohl ne andere Lösung her.

Danke jedenfalls an euch beide!

Haha, Netcup zensiert andere Providernamen, deswegen oben mit den Strichen, das ist ja der Hammer.

in einer uralten Software ist der Port 25 hardcoded drin. Keine Verschlüsselung. Der bisher genutzte Server wird demnächst abgeschalten.

Wie schon im Betreff geschrieben und ich hab's natürlich versucht aber vielleicht übersehe ich ja was:

Kann ich bei irgendeinem Netcup-Produkt (Server, Hosting) über Port 25 unverschlüsselt Mails senden?
Weiß das jemand?

Danke.

Zitat von nipfuh

Moin zusammen

da FPM bei neueren PHP Versionen nicht mehr verfügbar ist, wollte ich fragen, ob vielleicht jemand von euch eine Lösung gefunden hat, die ohne FPM auskommt

hatte dasselbe Problem und habe es letzlich hinbekommen mit den Einstellungen

php5.6.40, FastCGI, 1024M Memory Limit, 360 Execution Time.

Download von Dateien bis 3GB und Laufzeit ca. 8 Minuten (also deutlich mehr als 360 Sekunden!) hat funktioniert.

Das folgende Script hat mit 90 Sekunden Execution time immer bei ca. 1024MB Download abgebrochen bei ca, 5.5 MB/s

Das hatte mich irritiert wegen 1024MB Memory Limit wobei der Download in Chunks ja unabhängig vom Memory Limit sein sollte.

Ich habe keine Ahnung wieso es bei 360 Sekunden nun völlig problemlos geht - obwohl der Download deutlich länger dauert. Vermutlich sind die Skript-Laufzeiten nicht in "echten" Sekunden zu sehen. Andere Laufzeiten hab ich nicht getestet.

Eventuell würde bei größeren Dateien die 6-Minuten-Laufzeit dann den Download auch wieder killen.

Ich bin froh, dass es jetzt funktioniert mit meinen Dateien (max. 3 GB wie gesagt). Das hat mich Stunden gekostet.

$size = intval(sprintf("%u", filesize($datei_userdownload)));
$chunksize = 1024 * 1024;
header('Pragma: public');
header('Expires: 0');
header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
header('Cache-Control: private', false);
header('Content-Transfer-Encoding: binary');
header("Content-Disposition: attachment; filename=" . $datei);
header("Content-Type: " . $MimeTypes[$DateiExt]);
header('Content-Length: ' . $size);

if ($size > $chunksize) {
 $handle = fopen($datei_userdownload, 'rb');
 while (!feof($handle)) {
   $buffer = fread($handle, $chunksize);
   echo $buffer;
   ob_flush();
   flush();
 }
 fclose($handle);
 exit;
} else {
 readfile($datei_userdownload);
 exit;
}

Wie erwartet kamen dann nun von gmail und protonmali die Non delivery reports:

"Zustellung nicht abgeschlossen Bei der Zustellung Ihrer Nachricht an quotatest@meinedomain.de ist ein vorübergehendes Problem aufgetreten. Gmail versucht noch weitere 45 Stunden, die Nachricht zuzustellen. Sie werden benachrichtigt, falls die Zustellung dauerhaft fehlschlägt. Die Antwort vom Remoteserver ist: 452 4.2.2 Mailbox full"

Ich hake das jetzt ab und danke euch für die Tipps!

Bei mir läuft eh postfix und bzgl. der Bounce-Konfig ist alles auf default. Der Netcup Server jedenfalls meldet völlig korrekt "Mailbox full" (was ja anfangs mein Irrtum war). Was dann die MTA des Mailsenders aus dieser Response machen, ist ja wieder was anderes.

Es macht irgendwie keinen Sinn, dass der Mail-Absender nicht zeitnah die Bouncemail von seinem MTA bekommt und die Mail erstmal tagelang resended wird und der Absender damit tagelang völlig im unklaren ist - und das eben per default. Nicht nur bei meinem postfix, sondern auch bei gmail, web.de und protonmail. Dort habe ich (nach weniger als 24h) auch noch keine Info über die Verweigerung meiner Testmail.

Klar, die delays und Anzahl der Zustellversuche lassen sich bei postfix leicht ändern, aber das ändert ja grundsätzlich nichts am Problem (die Versuche über meinen eigenen postfix dienten nur als Test).

Wie gesagt, was mich stutzig machte waren die Bounce-Mails die ich selbst hin und wieder (sehr selten) mal bekommen habe an T-Online Adressen, deren Mailbox voll war. Dort kamen die dann immer sofort und daher hatte ich dann in meinem Fall einen Fehler vermutet.

Ich warte also also erstmal auf mehrere Bounce-Mails. Werde es dann hier posten.

Zitat von vmk

4xx = Versuche es später noch mal lieber einliefernder Mailserver

Der einliefernde Mailserver versucht es dann bis zu ca 2 Tage. Ob er den Absender benachrichtigt, das ist alleine seine Sache.

Danke, das war ein guter Hinweis. In der Mailqueue des Sender-MTA hab ich die Mails von heute tatsächlich gefunden! Hab dooferweise nicht reingeschaut.
Ok, mal schau'n was passiert.

Bei T-Online Empfängern bin ich selbst schon oft über das "Postfach voll" gestolpert und habe bisher immer sofort und direkt die Mail zurück bekommen. Das ist jetzt hier nicht so, was mich vielleicht fehlgeleitet hat.

Werde weiter berichten, ganz glücklich bin ich noch nicht damit.

also jetzt war ich etwas irritiert. Habe nochmal beim Sender-MTA das Logging mitgelesen und der Netcup-MTA refused tatsächlich die Mails mit Hinweis "Mailbox full". Soweit so gut! Allerdings erfolgte trotzdem keine Benachrichtigung (keine Ahnung warum mir das bei den anderen Tests nicht aufgefallen ist)

Hier das Postfix-Log des sendenden Servers mit einer Mail an das Postfach im Netcup Reseller-Paket:

Sep 21 15:27:28 s13 postfix/smtp[6882]: 273F77D85C6A: to=<quotatest@meinedomain.de>, relay=127.0.0.1[127.0.0.1]:10026, delay=0.34, delays=0.13/0/0/0.21, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10027): 250 2.0.0 Ok: queued as 5D6247D85C6B)

Sep 21 15:27:28 s13 postfix/smtp[7914]: 5D6247D85C6B: to=<quotatest@meinedomain.de>, relay=webmail.meinedomain.de[185.243.11.XX]:25, delay=0.38, delays=0.06/0.01/0.1/0.21, dsn=4.2.2, status=deferred (host webmail.meinedomain.de[185.243.11.XX] said: 452 4.2.2 Mailbox full (in reply to end of DATA command))

Ich war mir nun gerade unsicher, ob der Sender-MTA (dieses Log) oder der Empfänger-MTA (Netcup) die Refuse-Mail an den Mail-Absender schicken muss und habe Mails von meinem Gmail- und web.de-Account an das Postfach quotatest@ geschickt. Auch hier kommt keine Benachrichtigung. Das bedeutet dann, dass der Netcup-MTA die Refuse-Meldung "Mailbox full" an den Mail-Sender nicht rausschickt. Also da stimmt dann was nicht.

Ich schreibe das nun wie empfohlen an den Support. Bin neu bei Netcup und weiß noch nicht so genau wie das hier läuft, danke für den Tipp!

Nachtrag: das Problem ist reproduzierbar. Aktuell hab ich mir ein Test-Postfach angelegt dessen Quota voll ist. Dasselbe Problem.

In meinem Reseller Paket 4000 hatte das Postfach eines Abos das Quota-Limit erreicht (2GB). Die Folge war, dass Mails natürlich nicht mehr zugestellt wurden - allerdings haben die Absender auch keine Benachrichtigung erhalten und Mails wurden auch nicht gebounced/rejected.

Konkret war das nun über 3 Tage bei einem Postfach. Nachdem der Kunde mir davon berichtete dass keine Mails mehr ankommen, habe ich einige Testmails das Postfach geschrieben (Quota-Limit war mir nicht sofort aufgefallen). Später dann nach Erhöhung des Quotas auf 5GB (3 Tage später!) kamen meine eigenen Testmails jedoch auch nicht mehr zurück (wieso auch plötzlich).

Das ist natürlich eine ziemlich schwerwiegende Sache, da die Mails de facto weg sind.

Im Service-Paket gewählt war die Option "Überbeanspruchung von Speicherplatz und Traffic ist zulässig. Erlauben Sie die Überbeanspruchung von Speicherplatz und Traffic. Lassen Sie die Überbeanspruchung anderer Ressourcen nicht zu." - "andere Resourcen" ist natürlich Mails, ist klar.

Insofern ist die Nicht-Annahme neuer Mails natürlich völlig korrekt!

Aber dass dem Absender keine Info/Bounce zugestellt wird, kann nur ein Fehler im MTA sein. Liest der Support hier mit? Ich frage erstmal hier ... Danke!

stimme zu, eine Verlinkung oder eine etwas klarere Benennung der Angebot wäre schon im Sinne aller Beteiligten

Jedenfalls vielen dank!

Welche Unterschiede haben denn die verschiedenen Web-Hosting Pakete, auf die ich im CCP upgraden kann?

Ich benötige mehr php_max_upload und Execution time und wollte auf Webhosting 2000 upgraden. Aber welches nur?

Weiß jemand was der tragende Unterschied ist und ob überhaupt?

(de und int ist eigentlich klar - aber was ist SE und was ist a1)