MIME Multipart boundary

in rfc1341 (mime) steht:

The encapsulation boundary MUST NOT appear inside any of the encapsulated parts.

aber must not ist nicht iwo definiert, oder hab ichs einfach überlesen? normal findet sich doch am anfang sowas wie:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

kann ich davon ausgehen, dass wie in rfc 2119 gilt:

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

gut, gehen wir jetzt einfach mal davon aus, dass es so ist, gibt es einen algorithmus, 'einfach' eine 'boundry' zu bestimmen, die nirgends vorkommt?

http://www.tutorials.de/content/452-emails-mit-php-erstellen.html

hier wirds z.b. so gemacht...

$boundary='----'.md5(uniqid());

aber das ist doch brutal falsch

Scheppertreiber

Es ist halt PHP ...

Die Boundary darf halt nicht im Text vorkommen. Da Du den Text ja kennst
(Du könntest den sonst nicht versenden) kannst Du das überprüfen.

http://docs.python.org/library/mimetools.html

mimetools.choose_boundary()

Return a unique string that has a high likelihood of being usable as a part boundary. The string has the form 'hostipaddr.uid.pid.timestamp.random'.

ich bin ja nicht nativ englisch und bin deswegen auch mal durchgefallen, aber "has a high likelihood of being usable" würde doch eher auf "SHOULD NOT" passen oder versteh ich den satz falsch

Mechanics

Ja, aber du kannst es doch überprüfen. Pseudocode:

string boundary = createBoundary();
while (myTextBlock.contains(boundary))
boundary = createBoundary();

also ich will ja nicht meckern, aber wenn ich pech hab, läuft die schleife ewig

triptop schrieb:

also ich will ja nicht meckern, aber wenn ich pech hab, läuft die schleife ewig

nein, da täusch ich mich... sie läuft höchstens text länge/boundary länge...

kann mir jmd. einen besserern algo als den von Mechanics anbieten

triptop schrieb:

triptop schrieb:

also ich will ja nicht meckern, aber wenn ich pech hab, läuft die schleife ewig

nein, da täusch ich mich... sie läuft höchstens text länge/boundary länge...

auch das stimmt nicht, evtl. ist die zahl zu klein aber was solls, ich hätt gern etwas wo ich genau weiß wie lang das braucht...

Mechanics schrieb:

Ja, aber du kannst es doch überprüfen. Pseudocode:

string boundary = createBoundary();
while (myTextBlock.contains(boundary))
boundary = createBoundary();

und sie kann doch ewig laufen

Mechanics

Ja, sie kann theoretisch ewig laufen. Mach halt noch eine Abbruchbedingung rein, die nach 10 Versuchen abbricht und dann eine Fehlermeldung ausgibt. Es ist aber extrem unwahrscheinlich, dass sowas passiert. Eine Boundary ist ja schon so aufgebaut, dass es in normalen Texten nicht vorkommt, wenn du da noch was zufälliges einbaust, dann ist die Wahrscheinlichkeit, dass es in deinem Block vorkommt, sehr gering, und dass 10 zufällige Boundaries alle in dem Block vorkommen noch viel geringer.
Was anderes wirst du nicht finden. Es gibt keine Möglichkeit, eine Boundary zu finden, die garantiert nicht in dem Text vorkommt, ohne sie in dem Text zu suchen.

okay, es wird noch schlimmer, mit einem längen limit (rfc2046), befinden wir uns in einer mission impossible... http ist total fuc*** up

The only mandatory global parameter for the "multipart" media type is
   the boundary parameter, which consists of 1 to 70 characters from a
   set of characters known to be very robust through mail gateways, and
   NOT ending with white space. (If a boundary delimiter line appears to
   end with white space, the white space must be presumed to have been
   added by a gateway, and must be deleted.)  It is formally specified
   by the following BNF:

     boundary := 0*69<bchars> bcharsnospace

     bchars := bcharsnospace / " "

     bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
                      "+" / "_" / "," / "-" / "." /
                      "/" / ":" / "=" / "?"

Mechanics schrieb:

...wenn du da noch was zufälliges einbaust, dann ist die Wahrscheinlichkeit, dass es in deinem Block vorkommt, sehr gering, und dass 10 zufällige Boundaries alle in dem Block vorkommen noch viel geringer.

ja, bleibt mir nichts anderes übrig, als mich bei dateiübertragungen auf wahrscheinlichkeiten zu verlassen, traurig für ein 'elite' protokoll, welches den katakomben des cern entsprungen ist

Mechanics schrieb:

Es gibt keine Möglichkeit, eine Boundary zu finden, die garantiert nicht in dem Text vorkommt, ohne sie in dem Text zu suchen.

leider ists nicht mal mit suchen drin, traurig

Mechanics

Mit "suchen" meinte ich nachträglich vergleichen, ob die von dir generierte Boundary im Text vorkommt.
Ich weiß nicht, was du für Probleme hast. HTTP ist sicher kein Elite Protokoll, das hat schon mehr Probleme, allein schon, dass das Encoding der Anfrage nicht definiert ist. Aber das mit den Boundaries ist jetzt halt so wild, dasselbe Problem gibts bei zig anderen Protokollen, damit kann man leben. Machs einfach und vergiss es.

ich liebe nike

tntnet

Wenn ich 70 Zeichen habe und bei jedem Zeichen 6 Bit zur Verfügung habe, habe ich insgesamt 420 Bits, die ich frei vergeben darf um ein Boundary zu definieren, welches in dem Mime-parts nicht vor kommt. Unmöglich ist das, wenn meine Daten eine Größe von mindestens 2^420 Bits haben. Und das passt momentan wahrscheinlich nicht auf alle Festplatten, die jemals hier auf unserer Erde bisher hergestellt wurden. Also damit kann man schon mal sagen, dass die Unmöglichkeit eher akademischen Wert hat.

Die nächste Aufgabe ist es, einen geeigneten Boundary zu finden. Ein einfacher Algorithmus wäre, eine beliebige 420-bittige Zahl zu nehmen und zu prüfen, ob diese in den Daten vor kommt. Wenn ja, dann erhöhe ich die Zahl um 1. Das wiederhole ich, bis ich das Boundary nicht finde. Das ist nur eine Endlosschleife, wenn die obere akademische Bedingung erfüllt ist.

Noch zum Hintergrund, wie ich auf 6 Bit komme: Das Boundary soll aus Zeichen bestehen, die "known to be very robust" sind. Da fallen mir zunächst die Zeichen a-z und A-Z ein. Das sind schon mal 52 Zeichen. Das kann ich leicht durch 12 geeignete Sonderzeichen ergänzen. Damit habe ich 64 Ausprägungen in einem Byte und das sind 6 Bit Nutzdaten.

Eine einfache Möglichkeit, eine beliebige binäre Zahl in so ein geeignetes Format zu packen, wäre base-64 encoding. Also noch mal im Pseudocode:

startvalue = 12345678;
while(true)
{
  boundary = base64(startvalue);
  if (boundary not found in data)
    break;  // success
  startvalue = startvalue + 1;
}

_--

tntnet schrieb:

Wenn ich 70 Zeichen habe und bei jedem Zeichen 6 Bit zur Verfügung habe, habe ich insgesamt 420 Bits, die ich frei vergeben darf um ein Boundary zu definieren, welches in dem Mime-parts nicht vor kommt. Unmöglich ist das, wenn meine Daten eine Größe von mindestens 2^420 Bits haben. Und das passt momentan wahrscheinlich nicht auf alle Festplatten, die jemals hier auf unserer Erde bisher hergestellt wurden. Also damit kann man schon mal sagen, dass die Unmöglichkeit eher akademischen Wert hat.

allein schon der umstand, dass man vorher diese zeichenkette suchen muss... naja, so ist das eben bei sachen, die sich iwie vllt. auch nur auf grund ihrer herkunft durchsetzen.

_--

"Programming is similar to sex. If you make a mistake, you have to support it for the rest of your life." ich belasse es mit diesem satz dabei!

Mechanics

_-- schrieb:

"Programming is similar to sex. If you make a mistake, you have to support it for the rest of your life." ich belasse es mit diesem satz dabei!

Eigentlich ist es ja noch schlimmer. Wenn jemand einen Fehler macht, der sich durchsetzt, müssen das alle supporten