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: firstname.lastname@example.org <email@example.com>
It’s shown as
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.
Please also post the version you are using and if possible an eml file with which the error can be reproduced.
Kopano Core: 22.214.171.124
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: firstname.lastname@example.org 250 2.1.0 Ok rcpt to: email@example.com 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> From: firstname.lastname@example.org <email@example.com> Subject: testmail Testing 123 . 250 2.0.0 Ok: queued as 79447160250
In the message options the full internet header is shown
Return-Path: <firstname.lastname@example.org> Received: from server6-kopano (127.0.0.1:59782) by server6-kopano (kopano-dagent) with LMTP; Tue, 13 Feb 2018 08:49:13 +0100 (CET) Received: from there (unknown [10.45.8.2]) by server6-kopano (Postfix) with ESMTP id 79447160250 for <email@example.com>; Tue, 13 Feb 2018 08:48:10 +0100 (CET) From: firstname.lastname@example.org <email@example.com> Subject: testmail
The webapp frontend only shows:
Testmail firstname.lastname@example.org <email@example.com>
the mail object in the frontend is not created with all possible informations.
The eml file is created from the mail object
Return-Path: <firstname.lastname@example.org> 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 <email@example.com>; Tue, 13 Feb 2018 08:48:10 +0100 Subject: testmail From: firstname.lastname@example.org 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
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.
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?
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-kopano1package. 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 0.9.2.50+11.1 amd64 [installiert]
It seams to be parsed not correctly for webapp
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 last edited by 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: <email@example.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 <firstname.lastname@example.org>; 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 <email@example.com> <firstname.lastname@example.org> To: =?utf-8?Q?martijn_Test?= <email@example.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>
Hi @Jo-TL ,
thanks for the example. So the difference in these two cases is:
$ diff martijn.eml email-spoof.eml 11c11 < From: firstname.lastname@example.org <email@example.com> --- > From: Your Boss <firstname.lastname@example.org> <email@example.com> 34d33 <
I have created https://jira.kopano.io/browse/KC-1350 with some additional details for followup.
thctlo last edited by thctlo
That message is clearly a spam message.
If you look you see :
From "Some name " <firstname.lastname@example.org> <email@example.com>
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 last edited by
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: