Mails from Univention-Customer-Feedback stated as "unknown_content_type.bin



  • As stated above:

    mails form the Univention Customer feedback were displayed empty with an attachment of the type stated above

    In other mail programs all is displayed correct.

    Any hints?

    TIA

    Uwe


  • Kopano

    Hi @zash1958 ,

    you’d have to share such an email to help reproduce the problem. If you don’t want to post it here publicly I would recommend to create a support case for this.



  • @fbartels

    No problem, but HOW can I paste or forward such an email completely here?


  • Kopano

    Hi @zash1958 ,

    you can configure the following option within kopano-dagent to log messages before delivery:

    # Log raw message to a file, please specify a username,
    # separate users with a space, or use 'all' to log all
    #log_raw_message = no
    

    ps: I have moved your thread from the deskapp subsection to the kopano groupware core subsection.



  • BUT:

    the message is already in my postbox and there will be no new one for next time? Does it help to forward it to another account in our Kopano?


  • Kopano

    No, just forwarding won’t help, as the message has already been processed by the dagent and therefore its not good anymore for a reproduction case.

    If you have imap enabled for this specific inbox you could also export the eml from webapp. But you need a relatively recent kopano-server so that this will actually spit out the original rfc message.



  • From customer-feedback@univention.de Mon Jul 23 09:01:30 2018
    Return-Path: <customer-feedback@univention.de>
    Received: from kmail.xxxxxx-datentechnik.de ([::ffff:127.0.0.1]:39094)
    	by kmail (kopano-dagent) with LMTP;
    	Mon, 23 Jul 2018 09:01:30 +0200 (CEST)
    Received: from xxxserver.xxxxxx-datentechnik.de (unknown [192.168.1.251])
     by kmail.xxxxxx-datentechnik.de (Postfix) with ESMTPS id C19EB431A1 for
     <userxxx@xxxxxx-datentechnik.de>; Mon, 23 Jul 2018 09:01:30 +0200 (CEST)
    Received: from mailin3.mk.de (mailin3.mk.de [85.220.139.162]) by
     xxxserver.xxxxxx-datentechnik.de (8.14.9/8.14.9) with ESMTP id
     w6N740fd024564 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384
     bits=256 verify=NO) for <userxxx@xxxxxx-datentechnik.de>; Mon, 23 Jul
     2018 09:04:02 +0200
    Received: from localhost (localhost [127.0.0.1]) by mailin3.mk.de (Postfix)
     with ESMTP id 1592823F240 for <userxxx@xxxxxx-datentechnik.de>; Mon, 23
     Jul 2018 09:01:28 +0200 (CEST)
    X-Virus-Scanned: by MK Netzdienste
    X-Spam-Flag: NO
    X-Spam-Score: -0.077
    X-Spam-Level: 
    X-Spam-Status: No, score=-0.077 tagged_above=-9999 required=4
    	tests=[AWL=-0.149, BAYES_00=-1.9, DEAR_SOMETHING=1.973,
    	RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
    Received: from mailin3.mk.de ([127.0.0.1])
    	by localhost (mailin3.mk.de [127.0.0.1]) (amavisd-new, port 10024)
    	with ESMTP id 0OG5Xg56PYtW for <userxxx@xxxxxx-datentechnik.de>;
    	Mon, 23 Jul 2018 09:01:27 +0200 (CEST)
    X-policyd-weight:  NOT_IN_SPAMCOP=-1.5 NOT_IN_IX_MANITU=-1.5
     CL_IP_EQ_HELO_IP=-2 (check from: .univention. - helo: .mail.univention. -
     helo-domain: .univention.)  FROM/MX_MATCHES_HELO(DOMAIN)=-2; rate: -7
    Received: from mail.univention.de (mail.univention.de [82.198.197.8]) by
     mailin3.mk.de (Postfix) with ESMTPS id 10A9323EFE6 for
     <userxxx@xxxxxx-datentechnik.de>; Mon, 23 Jul 2018 09:01:26 +0200 (CEST)
    Received: from localhost (localhost [127.0.0.1]) by
     solig.knut.univention.de (Postfix) with ESMTP id AF9D32875AD3 for
     <userxxx@xxxxxx-datentechnik.de>; Mon, 23 Jul 2018 09:01:24 +0200 (CEST)
    X-Virus-Scanned: by amavisd-new-2.10.1 (20141025) (Debian) at
    	knut.univention.de
    Received: from mail.univention.de ([127.0.0.1]) by localhost
     (solig.knut.univention.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
     id Osd6z9uAgoWN; Mon, 23 Jul 2018 09:01:21 +0200 (CEST)
    Received: from tyda.knut.univention.de (tyda.knut.univention.de
     [192.168.0.93]) by solig.knut.univention.de (Postfix) with ESMTPS id
     1559E287597D; Mon, 23 Jul 2018 09:00:35 +0200 (CEST)
    Received: by tyda.knut.univention.de (Postfix, from userid 114)
    	id 0F301484347; Mon, 23 Jul 2018 09:00:35 +0200 (CEST)
    Date: Mon, 23 Jul 2018 09:00:35 +0200
    From: Customer Feedback <customer-feedback@univention.de>
    To: userxxx@xxxxxx-datentechnik.de
    Subject: Satisfied with our service? (Ticket #2018071921000488)
    Message-ID: <20180723070035.GA24115@tyda.knut.univention.de>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=unknown-8bit
    Content-Disposition: inline
    User-Agent: Mutt/1.5.23 (2014-03-12)
    X-Securepoint:
     CTASD:str=0001.0A0C020E.5B557D4A.0104,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0
    X-Evolution-Source: 4fb7d16b224545bf67c21935c39238148b91635e
    Content-Transfer-Encoding: 8bit
    
    Sehr geehrte Damen und Herren,
    Dear Sir or Madam,
    (You will find an English version of this text below)
    
    ------------------- DEUTSCH -------------------------
    
    Sie hatten in den vergangenen Wochen Kontakt mit einem unserer Kollegen.
    In unserem Ticketsystem wurde das Ticket 2018071921000488 mit
    dem Betreff "[UMC-Feedback] Traceback" geschlossen.
    
    Wir sind immer bestrebt, die Service-Leistungen für Sie zu
    verbessern und legen daher großen Wert auf Ihre Meinung. Sie können uns helfen,
    unsere Service-Leistungen weiter zu verbessern und wir freuen uns über Ihre
    Antwort auf die folgenden Fragen.
    
    1. Haben Sie durch unseren Mitarbeiter die erwartete Hilfe bekommen?
    
    2. Waren Sie mit der Bearbeitungszeit (Zeit bis zur Bearbeitung durch uns und
        Dauer der Bearbeitung selbst) zufrieden?
    
    3. Waren Sie mit der Art und Weise der Bearbeitung durch unseren Mitarbeiter
        einverstanden?
    
    4. Haben Sie weitere Kommentare oder Anregungen für uns?
    
    Mit freundlichen Grüßen
    Univention GmbH
    
    ------------------- ENGLISH -------------------------
    
    In the past weeks, you have contacted our colleagues and ticket #2018071921000488 
    with the subject "[UMC-Feedback] Traceback" has been created in our ticket system.
    
    We are continually striving to improve our services for you and set
    great store by your opinion. You can also help us to continue to
    improve our services and we would be grateful if you could answer the
    following questions for us.
    
    1. Did you receive the help you were expecting from our support staff?
    
    2. Were you satisfied with the processing time (time it took us to
    process the request and the processing itself)?
    
    3. Did you agree with the way in which our employee processed your request?
    
    4. Do you have any further comments or suggestions?
    
    
    Best regards,
    Univention GmbH
    


  • At first sight looks absolutely normal ???


  • Kopano

    @zash1958 English please



  • Content-Type: text/plain; charset=unknown-8bit

    If the sender does not even know what the fruit his charset is supposed to be (“unknown-8bit” is a name not registered with IANA, too), there is no way KC can answer it either.



  • Maybe, but all other Clients like Thunderbird, KMail and Evolution have absolutely no problem with it ???



  • @zash1958 said in Mails from Univention-Customer-Feedback stated as "unknown_content_type.bin:

    Maybe, but all other Clients like Thunderbird, KMail and Evolution have absolutely no problem with it ???

    TBird, KMail, Outlook-IMAP and Outlook-ActiveSync are mail clients operating on RFC822/2822/5322 data. WebApp (WA) and Outlook-zarafa6client (OL/Z6) are operating on MAPI data however.

    Most Internet email traffic is RFCx22-style, so there is a conversion step when feeding mail into a MAPI system such as KC, or MS Exchange. Because MAPI’s uncanny design does not allow for unknown character sets of bodytext, you have two options:

    1. pretend that “unknown-8bit” means “cp1252”. Or “iso-8859-1”. Or “koi8-r”. Since it is impossible to tell, someone will get gibberish at some point, and it will not be recoverable.
    2. store raw bytes and leave the interpretation to a 3rd-party software. This involves saving raw data as a (MAPI) attachment, or a RFCx22 data stream (or both).

    TBird gets passed the RFCx22 data stream, which it then has to parse - and somehow make sense of “unknown-8bit”. It usually just pretends it is ASCII or something, and the user can switch charsets manually until the result makes sense to him.

    WA and OLZ6 are MAPI clients and receive the MAPI attachment. Since it is an attachment to them, they don’t do any further parsing by default. IIRC, opening the attachment in Outlook gives you a new sub-window. That should also default to ASCII or something, and the user can again switch charsets manually until the result makes sense to him.