Back to Community Threads
2
Mails are rejected due to incorrect From header
Problem reported by Roger - 5/20/2024 at 4:57 AM
Submitted
We receive masses of complaints from customers that mails to GMX, Yahoo and other providers cannot be delivered because the From: and, in my personal opinion, the To: are not written in quotation marks in the header.

It should look like this:
From: "Sender name" <sender@example.com>

In SmarterMail (latest version 8902) it is like this:
From: Sender name <sender@example.com>

This is apparently specified in https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.

Reject from GMX with the following error message:

host mx01.emig.gmx.net [212.227.17.5]
SMTP error from remote mail server after end of data:
554-Transaction failed
554-Reject due to policy restrictions.


Reject from other providers like Yahoo etc with the following error message:

filter10.antispamcloud.com [130.117.54.106] 550 From contains invalid characters.
mta6.am0.yahoodns.net [67.195.228.110] 554 Message not allowed - [299]

I have opened a ticket with support in the hope that there will be a bugfix as soon as possible before Thursday.

10 Replies

Reply to Thread
0
Douglas Foster Replied
5/20/2024 at 6:14 AM
Correct.  Friendly names follow the same format rules in all of the address headers.   Quotes are required when the name has embedded white space, as in the example.   They are a good idea in every case.  Also need white space between the end of the friendly name and the angle bracket delimiting the address.
0
Roger Replied
5/20/2024 at 6:46 AM
It is now not only optional but mandatory, otherwise you can no longer send mails to some recipients such as GMX, Yahoo, etc. They don't arrive because the server rejects them and that's why we are now getting masses of complaints.
2
Kyle Kerst Replied
5/20/2024 at 9:31 AM
Employee Post
I just wanted to follow up here to confirm I was able to replicate this and have it escalated to development now. The non-english characters in Roger's particular example was the culprit, but I've noted all of the above findings in the task I escalated so that should get them going in the right direction!
Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com
1
Roger Replied
5/20/2024 at 9:46 AM
Thank you very much Kyle. I think simply putting the display name in quotes should solve the problem. But this has to be done by SmarterMail when processing the outgoing message.
0
Douglas Foster Replied
5/20/2024 at 10:48 AM
Header contents must be 7-bit, so non-ascii characters must be UTF-8 encoded.   Quotes will not be sufficient.
0
Roger Replied
5/20/2024 at 11:39 AM
I have found various things about this:

Email headers must actually be 7-bit compatible, as the original email protocol (according to RFC 822 and later RFC 5322) only supports 7-bit characters. Non-ASCII characters (i.e. characters that are not contained in the 7-bit ASCII character set) must therefore be specially encoded so that they can be transmitted securely.

The correct method for encoding non-ASCII characters in e-mail headers is to use "MIME encoded-word" syntax according to RFC 2047. In this case, UTF-8 is not normally used directly, but the characters are encoded either as Base64 or as a quoted printable, whereby UTF-8 is usually specified as the character set.

An example of such coding looks like this:
Subject: =?UTF-8?B?w6TDtsOcw7bDpMO8?=


  1. UTF-8 Encoding in Headers: RFC 6532 allows email headers to contain UTF-8 encoded characters directly, expanding the capability of email systems to handle a wide variety of international characters. This approach is preferable to the older method of using MIME encoded-words, which is more complex and restrictive.
  2. Use of MIME Encoded-Words: Although MIME encoded-words (RFC 2047) are traditionally used to encode non-ASCII text within email headers using methods like Base64 or Quoted-Printable, RFC 6532 now advises against using MIME encoded-words when UTF-8 can be directly used in headers. This simplifies processing and increases compatibility across different email systems.
  3. Transmission and Interoperability: For emails containing non-ASCII headers and sent over systems that might not support these extensions, such messages should be encoded in a way that ensures compatibility. The message/global MIME type, introduced in RFC 6532, supports UTF-8 headers but can be treated as application/octet-stream in systems not supporting this format, ensuring broader interoperability.
These standards aim to enhance the email system's ability to handle international content directly and efficiently, moving away from older ASCII restrictions to embrace UTF-8 universally. This shift allows for a more seamless and integrated global email communication system
0
Kyle Kerst Replied
5/20/2024 at 12:24 PM
Employee Post
You're very welcome Roger, happy to get this going in the right direction. Just for the record though, I do not see trouble when sending addresses that simply include spaces in the display name values like you are seeing there, so I think we might need to do some more testing around that. In the meantime, according to that RFC the quotes are an optional component in the display name and I've not run into any rejections elsewhere with these not present. The only time I see Yahoo and others reject my test messages is when using non-english accent characters in the display name under our beta branch.
Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com
0
Hey Kyle. For the special characters you mentioned above, can you verify this will cover Hawaiian Language as well ? A number of words, especially names use an Okina, sort of looks like a reversed apostrophe
In addition there are a number of other special characters too in names.
www.HawaiianHope.org - Providing technology services to non profit organizations, low income families, homeless shelters, clean and sober houses and prisoner reentry programs. Since 2015, We have refurbished over 11,000 Computers !
0
Kyle Kerst Replied
5/22/2024 at 4:27 PM
Employee Post
It definitely should, as it's an overall handling mechanism that should account for the non-english characters. I can test that though! Do you have an example name you can direct message to me?
Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com
0
Kyle Kerst Replied
5/22/2024 at 4:37 PM
Employee Post
I did a quick test by setting my Display Name value to ʻokina and that went through without issue, so it should work there too!
Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com
Back to Community Threads

Reply to Thread

Related Knowledge Base Articles

Set up Autodiscover for SmarterMailSmarterMail > Installation and Configuration
Cannot Send Email MessagesSmarterMail > Troubleshooting
554 Error - MTA Poor Reputation FixesSmarterMail > Troubleshooting
Deploying Rspamd For Use With SmarterMailSmarterMail > Server Configuration and Management
Configure an Alternative Linux Web Server for SmarterMailSmarterMail > Server Configuration and Management