Malformed email address

BrettR

Server Information
osTicket Version v1.14.1 (f1e9e88) — Up to date
Web Server Software Microsoft-IIS/10.0
MySQL Version 5.7.29
PHP Version 7.0.21

We have had a few instances now of email addresses for new users being set to simply @. This results in email sending failures which are not noticed until the logs are checked as the ticket itself does not have any indication of a failure (client creates another ticket asking why they have not received an answer so we check the logs).

Here are the headers from an email we recently received that showed this behavior:

Received-SPF: none (knowbase.co.za: goodline.info does not designate permitted sender hosts)
Received: from 95-181-45-234.goodline.info ([95.181.45.234]) by knowbase.co.za with
MailEnable ESMTP; Fri, 31 Jan 2020 15:51:01 +0200
Received: from unknown (36.40.183.137)
by smtp18.yenddx.com with QMQP; Fri, 31 Jan 2020 13:34:00 -0800
Received: from mailout.endmonthnow.com [165.45.104.219] by snmp.otwaloow.com with SMTP; Fri, 31 Jan 2020 13:22:51 -0800
Received: from mtu23.bigping.com ([Fri, 31 Jan 2020 13:21:16 -0800])
by mtu23.bigping.com with SMTP; Fri, 31 Jan 2020 13:21:16 -0800
Received: from unknown (60.127.161.83)
by mail.naihautsui.co.kr with ASMTP; Fri, 31 Jan 2020 13:12:12 -0800
Message-ID: <FBBFA25D.6BA59961@goodline.info>
Date: Fri, 31 Jan 2020 13:12:12 -0800
From: =?utf-8?B?IkFsZWlzaGEiIDxBbGVpc2hhQGdvb2RsaW5lLmluZm8+?=
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: <xxxx@knowbase.co.za>
Subject: =?utf-8?B?SSBNaXNzZWQgRnVja2J1ZGR5IE1lc3NhZ2U=?=
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: base64
X-Envelope-Sender: Aleisha@goodline.info
X-ME-Spam: Low (45)
Return-Path: <Aleisha@goodline.info>

ntozier

BrettR From: =?utf-8?B?IkFsZWlzaGEiIDxBbGVpc2hhQGdvb2RsaW5lLmluZm8+?=

This looks like a problem. You're From line doesn't have an email in it.

BrettR

The RFC2047 MIME decode of the utf-8 string in the From line translates to "Aleisha" <Aleisha@goodline.info>

ntozier

RFC 2407 does not appear to mention email at all.
Maybe you mean 2047. It's my understanding (I am not an expert) but it provides support for encoding non-ASCII values such as real names and subject lines in email header. I didn't see anything that mentions email addresses.

But either way I would bet that you encoding email addresses is what is breaking your instance.

BrettR

Yes, it is the encoding that is breaking the system. Lots of spam emails use this method to obfuscate the sender address. I have seen it before in a subject line where the inclusion of a Unicode character caused such an encoding.

We would obviously prefer that osTicket handles the possibility of receiving emails with such address encoding rather than us finding out weeks later that replies to a new client ticket were never actually sent due to the failure to correctly extract the reply address, and the only indication of failure being contained in the Admin logs.