3.2.3 Mail Header fehlerhaft / References

[PhyrePhoX]

Hi,

hatte heute das Problem, dass mein Mailserver eine Mail, die vom OTRS kommt, nicht rausschickt. Da es keine Fehlermeldung gab, war die Fehlersuche etwas schwierig, aber ich glaube den Fehler gefunden zu haben:

In dem Ticket wurden einige Mails hin- und hergeschrieben, insgesamt gibt es in dem Ticket schon 27 "Items".
Nun ist es ja so, dass OTRS bei rausgehenden Mails in JEDE Mail die Reference IDs der vorhergehenden Mails mitsendet. Was u.a. dafür sorgt, dass wenn der Kunde antwortet, seine Antwort wieder im richtigen Ticket landet (sofern sein Client den Header mit den References richtig behandelt).

In der Mail, die nicht rausging, sah diese References Zeile im Header der Mail so aus:

References: <2BC79C2C77A77747980F43D2AF9A6A4F03BE91@EFNPNCY125.xyz-intra.net><1365688825.354752.852445487.1636.9@otrs.xyz1.ab.xyz-intra.net><1365686113.316155.471562311.1636.9@otrs.xyz1.ab.xyz-intra.net><2BC79C2C77A77747980F43D2AF9A6A4F039F93@EFNPNCY125.xyz-intra.net><2BC79C2C77A77747980F43D2AF9A6A4F039F7E@EFNPNCY125.xyz-intra.net><2BC79C2C77A77747980F43D2AF9A6A4F039F69@EFNPNCY125.xyz-intra.net><2BC79C2C77A77747980F43D2AF9A6A4F039463@EFNPNCY125.xyz-intra.net><2BC79C2C77A77747980F43D2AF9A6A4F039443@EFNPNCY125.xyz-intra.net><2BC79C2C77A77747980F43D2AF9A6A4F03940A@EFNPNCY125.xyz-intra.net><2BC79C2C77A77747980F43D2AF9A6A4F038A80@EFNPNCY125.xyz-intra.net> <1365506596.30969.3956189476.1636.9@otrs.xyz1.ab.xyz-intra.net> <1365512860.460095.580934974.1636.9@otrs.xyz1.ab.xyz-intra.net> <1365513331.804442.241143745.1636.9@otrs.xyz1.ab.xyz-intra.net> <1365664130.67797.6158515661.1636.9@otrs.xyz1.ab.xyz-intra.net> <1365667890.27709.1459393297.1636.9@otrs.xyz1.ab.xyz-intra.net> <136566847!
0.570130.077639367.1636.9@otrs.xyz1.ab.xyz-intra.net> <1365752251.368694.773270716.1636.9@otrs.xyz1.ab.xyz-intra.net>

Das sind mehr als 1024 Zeichen. Sobald man den Header der Mail auf dem Server manuell ändert, also diese Zeile auf weniger als 1025 Zeichen ändert, nimmt der Mailserver sie problemlos an und schickt sie raus.
Jetzt hat Recherche ergeben, dass man normalerweise diese Zeilen mit mehr als 1024 Zeichen füllen kann, allerdings NUR wenn sie durch ein Tabulator Zeichen getrennt werden.

Die Frage: Ist das jetzt ein Bug im OTRS? Ich würde sagen, ja. Wie seht ihr das?
Das Problem werden wohl eher weniger Leute haben, da normalerweise nicht so viele E-Mails pro Ticket hin- und hergehen.

[jojo]

Hallo,

es handelt sich um einen Bug in Deiner Mailserverimplementierung. Schau Dir bitte mal RFC 5322 bzgl. der Mailheader an....

[PhyrePhoX]

Also wenn man sich diese RFC mal ansieht, findet man diverse, die References Zeile betreffende, Abschnitte (Siehe unten).

Ich zitiere mal meinen Mail Admin:

Damit ist die "References:"-Headerzeile der letzten Mail des "Problem" Tickets
soweit syntaktisch korrekt, außer, dass sie die definierte
Maximallänge von 998 Zeichen nicht eingehalten hat. Meine manuelle
Änderung, die Message-IDs der "References:"-Headerzeile jeweils auf
eine eigene Zeile, eingeleitet durch ein TAB-Zeichen, zu verteilen,
hat die "References:"-Headerzeile wieder der Definition in RFC 5322
angepasst (auch wenn ein Leerzeichen am Anfang jeder Zeile ausgereicht
hätte).

Auch: Meine Beschreibung der Fehlerbehebung war nicht ganz richtig. Die
1024 Zeichen waren eine Vermutung des Mailadmins, die aber dem in der
RFC definierten Wert 998 recht nahe kommt. Er hat die einzelnen
Message-IDs der "References:"-Headerzeile auch nicht nur durch
Tabulatoren-Zeichen, sondern durch ein Zeilenende gefolgt von einem
Tabulatoren-Zeichen getrennt, sodass jede Message-ID auf einer eigenen
Zeile stand. Ein Leerzeichen anstelle eines Tabulatoren-Zeichens hätte
auch gereicht (per Definition sind beide Zeichen White Space).

Ich bin also weiterhin der Meinung, dass es ein Fehler im OTRS ist, der scheinbar aber von einigen Mailservern toleriert wird, da das Problem sicher sonst viel früher bemerkt worden wäre.
Wir nutzen übrigens Sendmail in der Version 8.14.4.

2.1.1. Line Length Limits

There are two limits that this specification places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.

The 998 character limit is due to limitations in many implementations
that send, receive, or store IMF messages which simply cannot handle
more than 998 characters on a line. Receiving implementations would
do well to handle an arbitrarily large number of characters in a line
for robustness sake. However, there are so many implementations that
(in compliance with the transport requirements of [RFC5321]) do not
accept messages containing more than 1000 characters including the CR
and LF per line, it is important for implementations not to create
such messages.

The more conservative 78 character recommendation is to accommodate
the many implementations of user interfaces that display these
messages which may truncate, or disastrously wrap, the display of
more than 78 characters per line, in spite of the fact that such
implementations are non-conformant to the intent of this
specification (and that of [RFC5321] if they actually cause
information to be lost). Again, even though this limitation is put
on messages, it is incumbent upon implementations that display
messages to handle an arbitrarily large number of characters in a
line (certainly at least up to the 998 character limit) for the sake
of robustness.

[...]

Desweiteren 2.2.3 & 3.6.4:

2.2.3. Long Header Fields

Each header field is logically a single line of characters comprising
the field name, the colon, and the field body. For convenience
however, and to deal with the 998/78 character limitations per line,
the field body portion of a header field can be split into a
multiple-line representation; this is called "folding". The general
rule is that wherever this specification allows for folding white
space (not simply WSP characters), a CRLF may be inserted before any
WSP.

For example, the header field:

Subject: This is a test

can be represented as:

Subject: This
is a test

Note: Though structured field bodies are defined in such a way
that folding can take place between many of the lexical tokens
(and even within some of the lexical tokens), folding SHOULD be
limited to placing the CRLF at higher-level syntactic breaks. For
instance, if a field body is defined as comma-separated values, it
is recommended that folding occur after the comma separating the
structured items in preference to other places where the field
could be folded, even if it is allowed elsewhere.

The process of moving from this folded multiple-line representation
of a header field to its single line representation is called
"unfolding". Unfolding is accomplished by simply removing any CRLF
that is immediately followed by WSP. Each header field should be
treated in its unfolded form for further syntactic and semantic
evaluation. An unfolded header field has no length restriction and
therefore may be indeterminately long.

[...]

3.6.4. Identification Fields

[...]

The "Message-ID:" field contains a single unique message identifier.
The "References:" and "In-Reply-To:" fields each contain one or more
unique message identifiers, optionally separated by CFWS.

[...]

[jojo]

Dann mach bitte einen Bug auf und poste die Nummer hier

[PhyrePhoX]

http://bugs.otrs.org/show_bug.cgi?id=9345

[PhyrePhoX]

Wurde als Bug confirmed und es gibt auch mittlerweile einen Fix.

https://github.com/OTRS/otrs/commit/30d ... 8ff8b19a5a

http://bugs.otrs.org/show_bug.cgi?id=9345

Ich schätze, in einer der nächsten Versionen wird der Patch enthalten sein.