E-mail sender information

fbartels

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

Jo-TL

@fbartels
WebApp: 3.4.5.1202+46.1
Kopano Core: 8.4.3.4

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

[~] # telnet 10.45.8.1 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
DATA
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

From: knownsender@trusted.de <unknownsender@untrusted.net>
Subject: testmail

The webapp frontend only shows:

Testmail
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 (127.0.0.1:59782) by server6-kopano
 (kopano-dagent)  with LMTP; Tue, 13 Feb 2018 08:49:13 +0100
Received: from there (unknown [10.45.8.2])  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.

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