E-mail sender information

  • There is a problem within the handling of e-mail senders from the header.

    If I get the fake mail:

    From:  knownsender@trusted.de <falsesender@untrusted.net>

    It’s shown as

    knownsender@trusted.de <knownsender@trusted.de>

    the real sender is not extracted by webapp, because it seams to match only the first adress that can be found. Thats a risk in this times.

  • Kopano

    Please also post the version you are using and if possible an eml file with which the error can be reproduced.

  • @fbartels
    Kopano Core:

    The problem are spam mails with sender spoofing like this test, that can’t be identified in webapp because of the wrong handling:

    [~] # telnet 25
    220 server6-kopano ESMTP Postfix (Ubuntu)
    ehlo there
    mail from: unknownuser@trusted.net
    250 2.1.0 Ok
    rcpt to: me@example.de
    250 2.1.5 Ok
    354 End data with <CR><LF>.<CR><LF>
    From: knownsender@trusted.de <unknownsender@untrusted.net>
    Subject: testmail
    Testing 123
    250 2.0.0 Ok: queued as 79447160250

    In the message options the full internet header is shown

    Return-Path: <unknownuser@trusted.net>
    Received: from server6-kopano (
    	by server6-kopano (kopano-dagent) with LMTP;
    	Tue, 13 Feb 2018 08:49:13 +0100 (CET)
    Received: from there (unknown [])
    	by server6-kopano (Postfix) with ESMTP id 79447160250
    	for <me@example.de>; Tue, 13 Feb 2018 08:48:10 +0100 (CET)
    From: knownsender@trusted.de <unknownsender@untrusted.net>
    Subject: testmail

    The webapp frontend only shows:

    knownsender@trusted.de <knownsender@trusted.de>

    the mail object in the frontend is not created with all possible informations.

    The eml file is created from the mail object

    Return-Path: <unknownuser@trusted.net>
    Received: from server6-kopano ( by server6-kopano
     (kopano-dagent)  with LMTP; Tue, 13 Feb 2018 08:49:13 +0100
    Received: from there (unknown [])  by server6-kopano (Postfix) with
     ESMTP id 79447160250 for <me@example.de>; Tue, 13 Feb 2018 08:48:10 +0100
    Subject: testmail
    From: knownsender@trusted.de
    To: undisclosed-recipients:;
    Date: Tue, 13 Feb 2018 08:58:17 +0100
    Mime-Version: 1.0
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable
    Testing 123

    The spoofing was sucessfull.

  • additional header information in the webapp frontend would be awesome


  • Kopano

    I’ ve created https://jira.kopano.io/browse/KW-2367 to fix the issue

    https://jira.kopano.io/browse/KW-2368 for the detailed info

    Thanks for the feedback.

  • In addition to the ticket:
    it would be better if kopano match the last found email address instead of the first one and take the beginning of the from field as name string.

    In that way no information’s will be lost and it’s more save against spoofing attacks.

  • Kopano

    fyi we have opened a pull request at the upstream library (vmime). the pr can be found at https://github.com/kisli/vmime/pull/192

  • push, what’s going on with this security fix?

  • Kopano

    Hi @Jo-TL ,

    the issue was resolved through the patch with the upstream library. If you are using our packages you have meanwhile received an updated libvmime-kopano1 package. If you are using other packages you have to bug the maintainer of your libvmime package.

  • An upgrade didn’t solve the issue for me.

    Kopano Core: 8.6.8
    libvmime-kopano1/stable,now amd64 [installiert]

    It seams to be parsed not correctly for webapp


  • Kopano

    Hi @Jo-TL ,

    when you last posted in this thread I have verified the behaviour with the example posted in https://jira.kopano.io/browse/KC-1044. For me it did show up correctly in WebApp (although I cannot say with certainty which webapp version I used during the test).

    Can you provide a test message that still shows the old behaviour?

  • ok, then a part of the problem is already fixed, but there are also spoofing mails like the following.

    the best solution would be to match the end of the string

    Return-Path: <m.alberts@kopano.com>
    Received: from malberts-kopano.zarafa.lan ([::ffff:]:48640)
    	by malberts-kopano (kopano-dagent) with LMTP;
    	Tue, 13 Feb 2018 09:30:41 +0100 (CET)
    Received: from malberts-kopano (localhost [])
    	by malberts-kopano.zarafa.lan (Postfix) with ESMTP id 75950940008
    	for <m.alberts@kopano.com>; Tue, 13 Feb 2018 09:30:41 +0100 (CET)
    Received: by malberts-kopano (kopano-spooler) with MAPI; Tue, 13 Feb 2018
     09:30:41 +0100
    Subject: martijn eml
    From: Your Boss <yourboss@kopano.de> <secretlysomeoneelse@kopano.net>
    To: =?utf-8?Q?martijn_Test?= <m.alberts@kopano.com>
    Date: Tue, 13 Feb 2018 09:30:41 +0100
    Mime-Version: 1.0
    Content-Type: text/html; charset=utf-8
    Content-Transfer-Encoding: quoted-printable
    X-Priority: 3 (Normal)
    X-Mailer: Kopano 8.5.80
    Message-Id: <kcim.5a82a231.1b9c.741b3c847dcfcaaf@malberts-kopano>
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
      <meta name=3D"Generator" content=3D"Kopano WebApp vdevel">
      <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
      <title>martijn eml</title>
    <p style=3D"padding: 0; margin: 0;"><span style=3D"font-size: 10pt; font-=
    family: tahoma, arial, helvetica, sans-serif;"><br /></span></p>

  • Kopano

    Hi @Jo-TL ,

    thanks for the example. So the difference in these two cases is:

    $ diff martijn.eml email-spoof.eml
    < From: yourboss@kopano.de <secretlysomeoneelse@kopano.net>
    > From: Your Boss <yourboss@kopano.de> <secretlysomeoneelse@kopano.net>

    I have created https://jira.kopano.io/browse/KC-1350 with some additional details for followup.

  • That message is clearly a spam message.
    If you look you see : From "Some name " <some@email.tld> <someotherspammer@email.tld>

    Add this to you spamassassin config.

    header MULTI_FROM_ADDRESS From =~ /^.*<.*@.*>.*<.*@.*>/i
    score MULTI_FROM_ADDRESS 5.0
    describe MULTI_FROM_ADDRESS Multiple senders in From: header

  • welcome to RFC2822 headers is non verifiable and even good mail servers exploit the idiocy of these headers ie “From: YourPersonalServices” and is meant to be a proper service. The header From can have anything it wants and it’s up to your mail system (not really kopano) to block this if it looks wrong.

    My exim verifies many conditions before it even hits rspamd rules and I kick quite a lot of spam/invalid/faked emails.
    exim can pull out the header from domain in the email address, if empty, it’s invalid… good or bad…

    I’ve moved away from postfix due to the cumbersome ways to put filters and I used it for many years too.

  • Sure it’s a spam massage.

    But kopano/vmime gives a “wrong result” parsing the from field, so obfuscated sender in spoofing mails stay hidden.
    Everybody can block mails like this, but a correct result in the frontend makes the world better ;)

  • In addition of the vmime pull request/open ticket from november:

    In my opinion it should match the following from types:
    Named Sender sender@domain.com
    Named Sender fakedSender@domain.com sender@domain.com

Log in to reply