I've a bash script in Linux for sent email. I'm using SMTP by openssl and s_client.
It's multilanguage, so sometimes there are special characters (è, à...), that are shown correctly in the body but not in subject for any Microsoft based (Outlook, Hotmail...).
Using openssl
I use the following command:
openssl s_client -crlf -quiet -starttls smtp -connect <smarhost.server>:<port> < <configuration_and_body_file>
The <configuration_and_body_file>
is a plain text file which contains the connection protocol and the data for the email as follows
MAIL FROM: example@example.com
RCPT TO: emailto@emailto.com
DATA
From: Sender <example@example.com>
To: emailto@emailto.com
Subject: accès à ...
Some text with special characters as (è, à, ë...)
.
QUIT
If I send it to a Gmail or any different than Microsoft (Outloik, Hotmail) the subject and body are right. But when the receiptent is working with Hotmail or Outlook the special characters are wrong decoded as Ã
or others.
The output of the command is as follows:
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign GCC R3 DV TLS CA 2020
verify return:1
depth=0 CN = *.<foodomain>
verify return:1
250 DSN
250-gefwml03e.<foodomain>
250-PIPELINING
250-SIZE 31457280
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
250 2.1.0 Ok
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF>
250 2.0.0 Ok: queued as 27C77671AE7_3E83FBF
221 2.0.0 Bye
Maybe the 250-8BITMIME in this case how can I change it? I tried adding -utf8 but it doesn't works.
Using mailx and postfix
I've install mailutils package and configure postfix. Adding the smarthost to relayhost
and setting inet_interfaces = loopback-only
I've sent the email using following commmand:
echo "Some text with special characters è à" | mailx -s "From: Some text with special characters è à" -a "Sender <norepley@sender.com>" some_email@example.com
I get and error because of the UTF8 from the smarthost:
status=bounced (SMTPUTF8 is required, but was not offered by host <smarthost>
I've added to postfix the parameter to avoid that error smtputf8_enable = no
If I execute the last mail command to send the email, the email is sent but the special characters are wrong printed in Microsoft emails based but are right in Gmail.
As workaround I've created a fail with the body that contains special characters too. I send as:
mailx -s "Some text with special characters è à" -a "From: Sender <norepley@sender.com>" some_email@example.com < body.txt
This email is shown with the special characters in the right way for the body in all email accounts but Subject is still wrong in Microsoft based ones.
Some clue about how can force the subject to be also printed in the right way for Microsoft emails based on?
Thanks in advance
There is a lot to discuss here:
SMTPUTF8
extension, you cannot use UTF-8 in header fields.8BITMIME
extension only indicates that 8-bit content (such as UTF-8, whereas ASCII is only 7-bit content) is preserved in the body. As a client, you indicate that you send an 8-bit body with MAIL FROM:<example@example.com> BODY=8BITMIME
once the server indicated that it supports 8BITMIME
in its response to your EHLO
command.8BITMIME
, you should mark your body as such for the receiving mail client with the headers MIME-Version: 1.0
, Content-Transfer-Encoding: 8bit
, and Content-Type: text/plain; charset=utf-8
. If not everyone supports 8BITMIME
, you have to use a Content-Transfer-Encoding
.SMTPUTF8
is not widely supported, you have to encode non-ASCII with the Encoded-Word encoding according to RFC 2047. For example, the subject ¡Buenos días!
can be encoded as =?ISO-8859-1?Q?=A1Buenos_d=EDas!?=
.MAIL FROM
and RCPT TO
commands. Your example has to be MAIL FROM:<example@example.com>
and RCPT TO:<emailto@emailto.com>
.STARTTLS
the client and the server are reset to their initial state. As a client, you should send another EHLO
command, to which the server can respond with a different list of extensions than before the TLS handshake.PIPELINING
and even if they do, you should wait for the initial greeting before sending any command and wait for the server's response to the EHLO
and DATA
commands before continuing. While what you do can work, not adhering to the RFC standard can be used to filter spam.Date
is a mandatory header field.