Traveler/Domino MIME-Version: 1.0 mehrmals vorhanden

[hallo.dirk]

Client IMSMO 2.0.1.3
Outlook 2010

Könnt ihr folgendes reproduzieren?

Haltet auf dem IMSA Server den Router an, versendet eine neue Mail.
Schaut euch in der Mailbox den Seitenquelltext an (Ansicht/Anzeigen/Seitenquelltext)

Wenn ich richtig liege sieht dass dann wie in meinem Bild aus...

Dass da MIME-Version: 1.0 3x auftaucht ist doch nicht richtig! Das ist doch ein Bug oder?


Aufgefallen ist es, weil eine Spam Engine eines Kunden diese Mails als stark verdächtig erkannt hat.

(Betreff geändert)

[pimpfling]

Wenn ich ne Mail über unseren Traveler per Verse schicke, sieht das bei mir genauso aus. (3x Mime Version 1.0)

Hängt das mit der Meldung der Spam SW wirklich am 3x Mime Version.. Eintrag?

OK, meine Frage kannste ignorieren: http://www-10.lotus.com/ldd/nd85forum.nsf/DateAllFlatWeb/7ab294a475ebc56d85257ba3003c6987?OpenDocument

[hallo.dirk]

Ja:

Im Zielsystem (beim Kunden) passiert dann so etwas:

X-Virus-Scanned:        amavisd-new at tritium.com.au
X-Amavis-Alert:        BAD HEADER SECTION, Header field occurs more than once:
"MIME-Version" occurs 3 times

Ich habe mir die RFC noch nicht dahingehend angeschaut, aber ich bezweifle mal dass diese Feldlder mehrfach vorkommen dürfen.

[pimpfling]

Hab noch nen IBM Link zu diesem Thema gefunden: http://www-01.ibm.com/support/docview.wss?uid=swg1LO58760

[hallo.dirk]

"not able to reproduce" oha


RFC 2045                Internet Message Bodies            November 1996

MIME-Version Header Field


   Since RFC 822 was published in 1982, there has really been only one
   format standard for Internet messages, and there has been little
   perceived need to declare the format standard in use.  This document
   is an independent specification that complements RFC 822.  Although
   the extensions in this document have been defined in such a way as to
   be compatible with RFC 822, there are still circumstances in which it
   might be desirable for a mail-processing agent to know whether a
   message was composed with the new standard in mind.

   Therefore, this document defines a new header field, "MIME-Version",
   which is to be used to declare the version of the Internet message
   body format standard in use.

   Messages composed in accordance with this document MUST include such
   a header field, with the following verbatim text:

     MIME-Version: 1.0

   The presence of this header field is an assertion that the message
   has been composed in compliance with this document.

   Since it is possible that a future document might extend the message
   format standard again, a formal BNF is given for the content of the
   MIME-Version field:

     version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

   Thus, future format specifiers, which might replace or extend "1.0",
   are constrained to be two integer fields, separated by a period.  If
   a message is received with a MIME-version value other than "1.0", it
   cannot be assumed to conform with this document.

  Note that the MIME-Version header field is required at the top level
   of a message.  It is not required for each body part of a multipart
   entity.  It is required for the embedded headers of a body of type
   "message/rfc822" or "message/partial" if and only if the embedded
   message is itself claimed to be MIME-conformant.

   It is not possible to fully specify how a mail reader that conforms
   with MIME as defined in this document should treat a message that
   might arrive in the future with some value of MIME-Version other than
   "1.0".

   It is also worth noting that version control for specific media types
   is not accomplished using the MIME-Version mechanism.  In particular,
   some formats (such as application/postscript) have version numbering
   conventions that are internal to the media format.  Where such
   conventions exist, MIME does nothing to supersede them.  Where no
   such conventions exist, a MIME media type might use a "version"
   parameter in the content-type field if necessary.


   NOTE TO IMPLEMENTORS:  When checking MIME-Version values any RFC 822
   comment strings that are present must be ignored.  In particular, the
   following four MIME-Version fields are equivalent:

     MIME-Version: 1.0

     MIME-Version: 1.0 (produced by MetaSend Vx.x)

     MIME-Version: (produced by MetaSend Vx.x) 1.0

     MIME-Version: 1.(produced by MetaSend Vx.x)0

   In the absence of a MIME-Version field, a receiving mail user agent
   (whether conforming to MIME requirements or not) may optionally
   choose to interpret the body of the message according to local
   conventions.  Many such conventions are currently in use and it
   should be noted that in practice non-MIME messages can contain just
   about anything.

   It is impossible to be certain that a non-MIME mail message is
   actually plain text in the US-ASCII character set since it might well
   be a message that, using some set of nonstandard local conventions
   that predate MIME, includes text in another character set or non-
   textual data presented in a manner that cannot be automatically
   recognized (e.g., a uuencoded compressed UNIX tar file).

[hallo.dirk]

Ich habe mal einen PMR aufgemacht.

[pimpfling]

Ich habe mal einen PMR aufgemacht.

Viel Glück

[hallo.dirk]

Natürlich kann der Support das nicht nachstellen.

Es muss aber etwas am IMSMO Clinet oder am Travler Server liegen, keine Ahnung wer die Mails codiert und in der mailbox hinterlegt.

Aus Spass habe ich das Mal mit der Traveler App getestet, da ist es auch 3x vorhanden

Wie dem auch sein, per Zufall habe ich aber einen workaround gefunden, der mir zumindest hilft, die 2 überflüssigen Einträge am ausgehenden SMTP Server wieder  zu löschen: die iQ Suite

Der Advanced Trailer hat die Option Richtext Mails nach Mime zu konvertieren, mit dieser Option wird der Head neu geschrieben und die Felder fliegen raus.


Der PMR ist weiterhin offen, ich halte euch auf dem laufenden..

[hallo.dirk]

So es ist reproduzierbar in Verse wie auch über den IMSMO Client.
Traveler übergibt zwar dem Domino Server die korrekten Daten, in der Mailbox tauchen dann aber die überflüssigen Werte auf.

Dazu gibt es nun 2 SPR's:

APAR LO79904 / SPR# DPBE9HYDR4 (VERSE)
When sending a message from Traveler multiple (2 or more) instances of "MIME-Version:" occurs in MIME header

APAR LO91952 / SPR # NKEYAKWJ6Q (IMSMO)
Imsmo - Issue With Multiple "Mime-version: 1.0" Headers In Mail Created In Imsmo

Wer also Interesse daran hat, dass diese Problem abgestellt wird, bitte einen PMR aufmachen.