Vorsicht Kostenfalle beim eMail-Abrufen

Vorsicht - Kostenfalle GPRS / HSCSD

Mobile Datenübertragung ist in diesem Jahr "in".
Die Schlagworte sind Wireless LAN (WLAN / WiFi), GPRS (General Pocket Radio Service) und HSCSD (High Speed Circuit Switched Data). Datenübertragung ohne! Ohne Kabel immer und überall ist einfach und praktisch. Wie so oft, kann aber einfach und praktisch auch ein Loch in die Geldbörse reißen. Um das Loch klein zu halten sollte man den Unterschied zwischen GRPS und HSCSD verstehen.

Für GPRS bieten die Mobilfunk-Provider volumenabhängige Tarife an. Das heißt, man bezahlt die Datenmenge die man überträgt. Bei HSCSD wird dagegen nach Zeit abgerechnet - die übertragene Datenmenge wird hier nicht berücksichtigt.

Der gebotene Internetzugang ist bei beiden Verfahren vollwertig. Man kann also Email versenden, im Internet surfen oder auch mit einem Firmennetzwerk Kontakt aufnehmen.

Aber aufgepasst, es kann teuer werden. Als Beispiel dient das beliebte "Neue eMails-Nachschauen" über das Volumenbasierte GPRS:

Bei jeder neuen Verbindung überprüft das eMail-Programm welche Emails es schon heruntergeladen hat und welche neu sind. Sinnvollerweise lädt es nur die Neuen herunter. Aber Achtung: Hier lauert eine Kostenfalle!

Bei einem leeren Posteingang kommt man auf eine Gesamt-Datenmenge von 1,5 KB pro "Neue eMails-Nachschauen". Liegen dagegen 190 eMails (was durch Email-Müll vorkommen kann) im Posteingang, beträgt die Gesamt-Datenmenge ca. 15 KB! Diese Datenmenge wird bei jeder Verbindung übertragen. Unter diesen Umständen kann 10x pro Tag "Neue-eMails-Nachschauen" 5 Euro kosten, obwohl keine einzige neue eMail eingetroffen ist!

Bei HSCSD ist "Neue eMails-Nachschauen" dank der zeitabhängigen Bezahlung überschaubarer. Dort ist es egal, ob Sie in zwei Minuten 15 KB oder 150 KB übertragen. Die Minutenpreise sind aber auch nicht günstig, auch hier können über den Tag verteilt einige Kosten entstehen.

Den Artikel hab ich auf meiner Homepage stehen:
http://www.toonic.de/markus/story_kostenfallegrps.htm

Im Detail liegt das Problem beim pop3-Protokoll, welches mit 'list' eine Übersicht der auf dem Server vorhandenen eMails anfordert und dann lokal auf dem Client (PDA, Handy etc.) abgleicht. Mit 'list' werden dem Mail-Programm die wichtigsten Daten der eMail-Übersicht angezeigt:

LIST [msg]

Arguments:
a message-number (optional), which, if present, may NOT
refer to a message marked as deleted

Restrictions:
may only be given in the TRANSACTION state

Discussion:
If an argument was given and the POP3 server issues a
positive response with a line containing information for
that message. This line is called a "scan listing" for
that message.

If no argument was given and the POP3 server issues a
positive response, then the response given is multi-line.
After the initial +OK, for each message in the maildrop,
the POP3 server responds with a line containing
information for that message. This line is also called a
"scan listing" for that message. If there are no
messages in the maildrop, then the POP3 server responds
with no scan listings--it issues a positive response
followed by a line containing a termination octet and a
CRLF pair.

In order to simplify parsing, all POP3 servers are
required to use a certain format for scan listings. A
scan listing consists of the message-number of the
message, followed by a single space and the exact size of
the message in octets. Methods for calculating the exact
size of the message are described in the "Message Format"
section below. This memo makes no requirement on what
follows the message size in the scan listing. Minimal
implementations should just end that line of the response
with a CRLF pair. More advanced implementations may
include other information, as parsed from the message.

NOTE: This memo STRONGLY discourages implementations
from supplying additional information in the scan
listing. Other, optional, facilities are discussed
later on which permit the client to parse the messages
in the maildrop.

Note that messages marked as deleted are not listed.

Possible Responses:
+OK scan listing follows
-ERR no such message

Examples:
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120

S: 2 200
S: .
...
C: LIST 2
S: +OK 2 200
...
C: LIST 3
S: -ERR no such message, only 2 messages in maildrop

Je länger diese Liste ist, desto mehr Daten werden übertragen!!!
Und wer volumenbasiert über GRPS (wohlmöglich noch byCall) das macht kann eine böse Überraschung erleben...

Es gibt auch Leute, die haben keine GPRS-Inklusiv-Volumen-Verträge...

Genau so ist es, wie trial-freak schreibt! Und wie gerne läßt man beim PDA etc. die Mails noch auf dem Server, weil man sie später dann extra mit dem Desktop-PC herunterladen möchte... Sorry, wenn dass falsch rübergekommen ist.

Nunja, aber anscheinend habt ihr andere Sorgen. Ich hatte das vor einem Jahr herausgefunden, als ich über GMX die ganzen Mails im Posteingang ließ und bei der Bundeswehr immer nur über den Tungsten gemailt hab. Tja, und irgendwann kommt man dahinter, warum er über HSCSD immer länger braucht, bis er dass alles abgeglichen hat. Also waren es bei mir keine 150 Spam-Mails.