E-mail sender information

Jo-TL

additional header information in the webapp frontend would be awesome

https://forum.kopano.io/topic/852/feature-request-show-more-detailed-sender-information

marty

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

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

Thanks for the feedback.

Jo-TL

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.

fbartels

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

Jo-TL

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

fbartels

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.

Jo-TL

An upgrade didn’t solve the issue for me.

WebApp: 3.4.24.1929+84.1
Kopano Core: 8.6.8
libvmime-kopano1/stable,now 0.9.2.50+11.1 amd64 [installiert]

It seams to be parsed not correctly for webapp

Example

fbartels

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?

Jo-TL

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:127.0.0.1]:48640)
	by malberts-kopano (kopano-dagent) with LMTP;
	Tue, 13 Feb 2018 09:30:41 +0100 (CET)
Received: from malberts-kopano (localhost [127.0.0.1])
	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=
w.w3.org/TR/html4/loose.dtd"><html>
<head>
  <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>
</head>
<body>
<p style=3D"padding: 0; margin: 0;"><span style=3D"font-size: 10pt; font-=
family: tahoma, arial, helvetica, sans-serif;"><br /></span></p>
</body>
</html>

fbartels

Hi @Jo-TL ,

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

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

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

thctlo

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

djtremors

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.

Jo-TL

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 ;)

Jo-TL

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

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