Vorsicht Kostenfalle Strato V-Server!

Viel Spaß. Mir ist mal etwas ähnliches mit Alturo (1&1 Tochter) passiert. 1&1 hat Alturo irgendwann eingestampft. Die Server liefen allerdings ne Zeit weiter und 1&1 wollte mir den (nach dem Stichtag) entstandenen Traffic in Rechnung stellen. Ich habe per Anwalt mich dann mit 1&1 geeinigt.

Ich habe mir mal http://www.strato.de/server/virtual/v-power/index.html angeschaut. Der Punkt TrafficControl sieht interessant aus. Hat dich Strato denn darüber Informiert, dass dein Traffic "abweicht"?

Dein E-Mail-Problem ist zimlich interessant. Wenn man Dateien also per SMTP überträgt wird nicht vorher überprüft ob die Dateien die zugelassene größe nicht überschreiten. Wäre ja eigentlich nicht das Problem. Dein Server sagt GMX "Achtung hier kommt ne 170MB Datei" und GMX antwortet "Nene. Die wollen wir nicht".

Weiß jemand darüber mehr?
 
bibabu said:
Dein E-Mail-Problem ist zimlich interessant. Wenn man Dateien also per SMTP überträgt wird nicht vorher überprüft ob die Dateien die zugelassene größe nicht überschreiten. Wäre ja eigentlich nicht das Problem. Dein Server sagt GMX "Achtung hier kommt ne 170MB Datei" und GMX antwortet "Nene. Die wollen wir nicht".
Click to expand...

Ich verwende qmail (Ubuntu 8.04) mit Plesk 9.3, alles Standard. Wikipedia meint zum Senden SMTP folgendes:

Modern clients may use the ESMTP extension keyword SIZE to query the server for the maximum message size that will be accepted. Older clients and servers may try to transfer excessively-sized messages that will be rejected after consuming network resources, including connect time to network links that is paid by the minute.

Das war mir in der Form auch nicht bewusst. Ausserdem haette ich eigentlich erwartet, das Plesk/qmail schlau genug ist und irgendwann mal mit dem versenden an den Admin aufhoert. Ich kann daher eigentlich nur allen raten, in Plesk nur eine LOKALE mail-Adresse als Admin anzugeben, sonst hat man im Fehlerfall schnell eine Endlos-Mailschleife inkl. Traffic-Supergau gebastelt.
 
Nur so die technischen Details:
Der SIZE ist ein recht junger Command im SMTP-Dialog.
Ich kenne nicht alle MTA so genau, weiß aber dass der aktuelle Postfix es unterstützt. Aber ein Postfix für Ubuntu 8.04 wahrscheinlich noch nicht.
Ein über 10 Jahre alter Qmail kennt es definitiv nicht.
Allerdings verwendet auch GMX ein selbst gepatchtes Qmail. Ob die SIZE implementiert haben? :confused:

Eine "Endlosschleife" ist es nicht. Qmail versucht die Zustellung einer Email 7 Tage lang. (Bzw. control/queuelifetime in Sekunden.)
Dann wird sie gebounced. Sollte der Bounce ggf. wiederum auf postmaster oder ähnliches gehen, so dauerte es nochmal 7 Tage.
Erst mit einem Trippel-Bounce beendet Qmail die Zustellung.
Ich empfehle queuelifetime auf 3 Tage (= 259200 Sekunden) zu setzten.

Um zu verhindern, dass überhaupt so große Emails in die Queue kommen, sollte control/databytes gesetzt werden.
Ich empfehle Werte zwischen 10 und 20 MB (10240000 bis 20480000 Bytes).
Bereits ab 10 MB wird es kritisch ob die Gegenseite diese Emails überhaupt annehmen wird.

Nun noch zu dem Ratschlag für die root-Emails:
Besser ist es eine externe Email anzugeben. Denn etwas mit dem Server nicht mehr stimmt, könnte es sein, dass eine lokale Email nicht mehr abgeholt werden kann und somit die Warnung an den Admin unter den Tisch fällt.

huschi.
 
serverandmore said:
Der Traffic scheint eine ziemlich einfache Erklaerung zu haben: ich hab im Server in Plesk als Admin eine GMX-Mail Adresse hinterlegt. Aus mir noch unklaren Gruenden hab ich eine Bounced-Mail mit 170MB in der Queue, die Plesk/Qmail immer wieder und wieder versucht hat an das Admin Account (also GMX) zu verschicken. Da GMX max 20MB erlaubt, bounced die Mail wieder, wird nochmals an den Admin geschickt...

Hab jetzt als Admin eine lokale e-mail Adress angegeben, dann die 170MB bounce message heruntergeladen (wollte ja sehen wo die herkommt, aber in Outlook hat die keinen Inhalt oder Attachment). Und siehe da: der Spuk ist vorbei. Ganz schoen bescheuert so was: 3000 Euro Traffic wegen einer Bouncing e-mail...
Click to expand...

Mir ließ das irgendwie keine Ruhe... und wenn ich mir deine Erklärung noch mal anschaue, wundert mich das ein wenig...

Kleine Rechnerei:

# du hast einmal 600,- € mehr Traffic berechnet bekommen

Laut Info-Seite Strato berechnen sie 28ct/GB Mehrverbrauch. Demnach wären das:

600,00 € / 0,28 € = 2142,85 GB = 2,143 TB

# zweite Rechnung mit 3.000 €

3.000 € / 0,28 € = 10.714 GB = 10,714 TB


Wenn ich jetzt mal deine obige Erklärung nehme... dann wäre die Mail mit 170MB Größe in Fall 1 ganze 2142 GB / 0,170 GB = 12.600 mal gebounced.

Und in Fall 2 wären das 10.714 GB / 0,170 GB = 63.023 mal...

Witzig wird die Rechnerei, wenn man den Traffic-Tarif 0,14ct/GB nimmt, der glaub ich kürzlich noch galt. dann wären das 4,286 TB bzw. 21,428 TB und entsprechend 25.200 bzw. 126.046 bounces....

Ähm, ja... DAS soll ich dir jetzt abnehmen?? Nee, oder?

Nun ja - ich fand's grad lustig.
 
Naja - rechne mal weiter:
31 * 24 * 3600sec = 2678400sec
2678400sec/63.023Versuche = ca. 42sec/Versuch
Also alle 42sec hat ein Zustellversuch stattgefunden
=> 170MB/42sec = ca. 4MB/s

Es wäre also technisch durchaus möglich. Mich wunderts eher, dass GMX das mitmacht :confused:

Grüße Johannes
 
Glaub ich eher nicht das GMX das mitmacht und schon gar nicht einen ganzen Monat lang. Die meckern ja schon wenn man mit POP3 zu oft die Mails abruft
 
mici81de said:
Ähm, ja... DAS soll ich dir jetzt abnehmen?? Nee, oder?

Nun ja - ich fand's grad lustig.
Click to expand...

Nun, ich bin zugegebenermassen kein Linux Experte, aber was Huschi zu den technischen Details geschrieben hat (max. 3 Zustellversuche, Wartezeit), war mir so auch bekannt (und war auch so in Qmail konfiguriert). Deshalb konnte ich das ja auch nicht glauben. Es muss also entweder ein Bug gewesen sein bzw. der Traffic muss (noch) andere Gruende haben, die ich mir aber nicht erklaeren kann. Ich kann nur nochmals schreiben was ich gemacht habe, vielleicht hat ja jemand noch eine andere Idee:

Als ich mich in PLESK angemeldet hatte, war in der Mail-Server Queue genau eine Message (eine Bounced Warnung an den Admin), Groesse ca. 170MB. Ich hab dann ein paar mal refresh geklickt, und es war dann immer noch dieselbe Message da, aber die Groesse hat sich bei jedem Click (Refresh) um ein paar Bytes erhoeht! Dann hab ich als einziges die Admin-Adresse auf ein lokales Account geandert, es wurde 1 Mail (mit 170MB) zugestellt, dann war Ruhe (= keine weitere Message in der Queue). Hab dann ueber Pop3 die Mail in Outlook runtergeladen (170MB, hat einige Minuten gedauert), aber beim Aufmachen war in der Mail nichts drin. Hab dieselbe Mail dann weitergeleitet um zu sehen, ob sie wirklich so gross ist, die war dann aber beim Empfaenger nur noch ein paar Byte gross...

Was die Zustellversuche angeht komme ich sogar auf 1 pro 5 Sekunden, da GMX nach 20MB maxgroesse den Versuch hoechstwahrscheinlich abbrechen duerfte:

10740GB / 0.02 GB = 537000
2678400sec /537000 = 4.99
 
Hab mir nochmals die Mail-Logfiles naeher angeschaut und dabei festgestellt, dass es einen Fehlereintrag vom Spam_Hook von PLESK gibt. Im PLESK Forum bin ich dann fuendig geworden: ab PLESK 9.3 gibt es wohl einen Bug, der im Zusammenhang mit dem Spam-Filter leere e-mails bzw. eine Mail-Endlosschleife an Admin erzeugen kann...:eek::eek: Ich hab Anfang Juli einen Upgrade auf die 9.3 gemacht :mad:

Mich wundert es eigentlich immer noch, warum die Performance nicht merkbar gelitten hat bzw. der entsprechende Traffic in PLESK nicht angezeigt wird (da stehen seit dem Update auf 9.3 immer 0 Byte). Weiss zufaellig jemand, wo die Hoster (speziell Strato) i.d.R. den Traffic fuer V-Server messen? Am Router oder ueber Virtuozzo?
 
serverandmore said:
Im PLESK Forum bin ich dann fuendig geworden: ab PLESK 9.3 gibt es wohl einen Bug, der im Zusammenhang mit dem Spam-Filter leere e-mails bzw. eine Mail-Endlosschleife an Admin erzeugen kann...:eek::eek: Ich hab Anfang Juli einen Upgrade auf die 9.3 gemacht :mad:
Click to expand...

Gibts dazu einen Link?
Und bist Du sicher, dass der Fehler ab Plesk 9.3 auftritt und nicht nur bei 9.3? Sonst würde sich ein Update von Plesk auf Version 9.5.2 anbieten, deren Key Strato ja auch (ohne zusätzliche Kosten) anbietet.
 
kurzes Update:

nachdem ich den genauen Fehlerfall (PLESK Upgrade) bzw. das geloeschte Traffic-Limit (was u.a. auch bei anderen Kunden so aufgetreten ist) Strato geschildert hatte, wurde mir mitgeteilt, dass sie den Fall pruefen wollen und sich dann wieder bei mir melden.

Nachdem ich auch nach 6 Wochen noch nichts gehoert hatte und mir in der Zwischenzeit ein von Strato beauftragtes Inkasso-Unternehmen rechtliche Schritte angedroht hat, hab ich mal nachgefragt und mir wurde mitgeteilt, dass ich die Rechnungen zu bezahlen habe. Werde diesen Fall daher wohl jetzt gerichtlich klaeren lassen muessen.
 
You must log in or register to reply here.
Back
Top