No content body when the email pass through an Exchange server

[Zurd]

eMail works as expected pretty much everywhere except when one of the email relay is an exchange server.

As stated in RFC821: http://www.faqs.org/rfcs/rfc821.html
Each line in an email should end with a CRLF. eMail adds a \r\n at every end of line.

The \r is a Carriage return (CR):
http://en.wikipedia.org/wiki/Carriage_return

The \n is a Newline (LF):
https://en.wikipedia.org/wiki/Newline

As I understand, the \r adds a CR and the \n adds a LF so it should work but it doesn't. If you just use a simple \r it will work though.

Example of an email using "eMail" (note the double ^M):

To: someone@somewhere.com^M^M
Date: Tue, 05 May 2015 00:33:18 -0400^M^M
Mime-Version: 1.0^M^M
Content-Type: text/plain^M^M
X-Mailer: Cleancode.email v3.2.3-git ^M^M
^M^M
1^M^M
2^M^M
3^M^M
^M^M
^M^M
^M
^M

This email will be received just fine everywhere with the body content

1
2
3

However, there will be no body content if it passes through an Exchange server. I was able to fix the issue by replacing all references to \r\n to \n in those files:

file_io.c
message.c
mimeutils.c
smtpcommands.c
utils.c

Re-compile everything and this fix the issue, I can now see the body content.

[david3x3x3]

\n and LF are not the same thing. \n represents the end of line character (or characters). It sometimes represents CRLF. Take a look at this page (especially the OCRNL part):

http://pubs.opengroup.org/onlinepubs/7908799/xsh/termios.h.html

[deanproxy]

I'm not completely sure, but to me this indicates a poorly setup Exchange server that is trying to compensate for poorly written e-mail clients that just use \n instead of the RFC compliant \r\n.

Can you turn on debugging and post the actual output to the exchange server before it hits the server? You can do this by recompiling email with the DEBUG_SMTP macro set.

[Zurd]

I don't own the Exchange server, I can only say that they have a lot of clients and it works extremely well except with "eMail". I can't really troubleshoot this further. If you think it's not an issue with "eMail" feel free to close this bug, at least it will be documented on the internet and I found a fix.

One thing I noticed after manually compiling "eMail" is that the body content is empty, however the signature of "eMail" is found at the bottom because these lines end with "\r" only. So in the same email, you have some lines with \r\n and others automatically added with \r only. These lines are

Sent using Email 3.2.3-git
http://www.cleancode.org/projects/email

[deanproxy]

Removing the RFC compatibility just to communicate with a specific exchange server isn't really a "fix" though...

Maybe we can get some other people that have this problem to chime in and debug it as I have suggested. I have an exchange server at work, but I'm not having the same issues as you are, so I'm not an appropriate tester in this situation.

I will take a look at the signature file only having \r instead of \r\n.

[Zurd]

I did some more testing. There's no problem when using "eMail" in PLAIN login on port 25, no encryption.

But I can't use "eMail" on port 465 as I'm getting timeout error. I think you've said that "eMail" only works in TLS and not SSL which might be the cause. As a solution I use "ssmtp" and configure the SSL in there (/etc/ssmtp/ssmtp.conf). I tried with 2 different SMTP servers, it works with one but I can reproduce the error with the other SMTP server.

So, the only way I can reproduce the problem is by using "eMail" with "ssmtp" in cygwin with a specific SMTP server and an Exchange server. I don't know exactly where the problem lies but it's quite specific and deep.

Since you confirmed that a \r\n is the official way, I don't think there's an issue anymore. I probably just stumbled upon some misconfigured email server.

[deanproxy]

it's certainly possible that eMail is not handling sending mail correctly. The double ^M on your example above is what makes me believe something is possibly wrong with the output. I'll leave this bug open until somebody can come along and run eMail with the DEBUG_SMTP option so we can analyze the string of data being sent to the server before the server receives it and confirm if it is or is not properly formatted per the RFC.

[Zurd]

How do I compile with DEBUG_SMTP ? I see some references in smtpcommands.c but nowhere else.

[deanproxy]

open the Makefile and add -DDEBUG_SMTP to the CFLAGS macro. Then recompile everything.

[Zurd]

It's done. So where can I find the debug file now?

[deanproxy]

Sorry, make sure you add that to the src/Makefile and not the top level one.

Once you run it after recompiling, it will dump debug info to stdout.

[Zurd]

Whatever I try it's not dumping anything to sdout.

In details, I add -DDEBUG_SMTP at the end of the CFLAGS line in src/Makefile, I then do make clean, make and make install. The software work but there's nothing in the console.

[WalterHof]

Hi,
I see the same issue with current 64 bit version. Works with any Linux based mail server but will not work with Exchange 2013 or Exchange 2016. Any ideas how to solve this issue?

Walter

[Zurd]

You can always recompile with the fix in my first post.

Personally I'm not with mutt, it's also even available in cygwin!

[WalterHof]

Hi,

I am not a compiler guy, so I search for a solution without compiling.

Walter

[inkarkat]

I just ran into a similar issue in that suddenly parts of the header leaked into the email body, and the From address also wasn't recognized any longer. (Note: This is the email body, as shown in the mailer):

From: Ingo Karkat <REDACTED>
To: <REDACTED>
Date: Wed, 03 May 2023 08:45:28 +0200

Mime-Version: 1.0

Content-Type: text/plain

X-Mailer: Cleancode.email v3.2.3-git

Message-Id: <1683096328.476949.1696916.nullmailer@tecci>

Hello,

-- regards, ingo

Emails are sent through nullmailer to an SMTP remote that I don't control. The problem appeared suddenly, also with functioning email binaries that were compiled years ago. So I guess something changed on the email server side.

Sending directly via sendmail still works, though, so I captured both spooled emails and found out that the one sent by email has a mix of newlines and CR-LFs:

Received: (nullmailer pid 1704061 invoked by uid 4646);
        Wed, 03 May 2023 06:56:39 -0000
Subject: Testing 123^M
From: Ingo Karkat <REDACTED>
To: <REDACTED>
Date: Wed, 03 May 2023 08:56:39 +0200^M
Mime-Version: 1.0^M
Content-Type: text/plain^M
X-Mailer: Cleancode.email v3.2.3-git ^M
Message-Id: <1683096999.927092.1704060.nullmailer@tecci>

Hallo again,^M
-- ingo^M
^M
^M

My workaround has been to simply remove the Control-M's via dos2unix:

,----[ .email.conf ]----
| SENDMAIL_BIN = 'dos2unix | /usr/bin/nullmailer-inject'
`----

This might also help people like @WalterHof who've asked for a workaround that doesn't involve patching email itself. It requires use of SENDMAIL_BIN, though.

[deanproxy]

It looks like the headers that are only using LF instead of CRLF are being added by the server you’re using. For instance, Message-Id. To be RFC compliant, CRLF is a requirement for every new line. If the server is adding headers with just LF, then it will definitely break the message and other RFC compliant servers will get confused.