SMTP config error: mail loops back to me

[SethRobertson]

When an SMTP client connects to davmail and issues a EHLO, davmail spews back a bunch of 250s. The problem is, the FIRST 250 contains the reflected hostname that the client sent on the EHLO. This causes some SMTP implementions (e.g. sendmail) to believe that by some black magic it is talking to itself so the email is rejected by the client with the error "config error: mail loops back to me (MX problem?)".

With EHLO/250, the client provides its name in the EHLO message, and the server provides its name in the 250 response. While what you are doing is technically correct (well, assuming a local client connecting to itself, it is clearly wrong for off-server clients), at least in terms of client compatibility, putting literally anything other than the name you just got would be better. If you want to be conceptually RFC compliant, let the user specify the hostname (instead of the hardcoded "davmail" like I did below) so they can specify a suitable domain name.

I don't have a clean repo to submit a pull request with, so here is a patch:

diff --git a/src/java/davmail/smtp/SmtpConnection.java b/src/java/davmail/smtp/SmtpConnection.java
index baa011ef..66614ee9 100644
--- a/src/java/davmail/smtp/SmtpConnection.java
+++ b/src/java/davmail/smtp/SmtpConnection.java
@@ -90,7 +90,7 @@ public class SmtpConnection extends AbstractConnection {
                     } else if ("NOOP".equalsIgnoreCase(command)) {
                         sendClient("250 OK");
                     } else if ("EHLO".equalsIgnoreCase(command)) {
-                        sendClient("250-" + tokens.nextToken());
+                        sendClient("250-davmail");
                         // inform server that AUTH is supported
                         // actually it is mandatory (only way to get credentials)
                         sendClient("250-AUTH LOGIN PLAIN");

Relevant quotes from RFC-5321:

client normally sends the EHLO command to
the server, indicating the client's identity

In the EHLO command, the host sending the command identifies itself;
the command may be interpreted as saying "Hello, I am " (and,
in the case of EHLO, "and I support service extension requests").

The argument clause contains the fully-qualified domain name
of the SMTP client, if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see
Section 4.1.3).

ehlo           = "EHLO" SP ( Domain / address-literal ) CRLF
ehlo-ok-rsp    = ( "250" SP Domain [ SP ehlo-greet ] CRLF )

[mguessan]

Interesting, this line was introduced in 2008 to fix iPhone SMTP support!

I understand this issue does not impact any existing SMTP client, only SMTP servers like sendmail?

[esabol]

I used to use sendmail, but we use Postfix now. I'm pretty sure Postfix works ok with the current code, fwiw.

[SethRobertson]

Sendmail is both a SMTP client and a server. However, it is true that only dual-role systems would have this problem.

For what it is worth, sendmail is not the only MTA that has this issue. The following URL suggests that Postfix, Qmail or Exim also have this issue (directly contradicting esabol, but it is also much older).

https://www.gypthecat.com/how-to-fix-mail-loops-back-to-myself

Ah, it looks like sendmail has an escape hatch. The "k" mailer flag will bypass this. Still, it would be nice if there was a way to change the EHLO (and HELO) response to bypass this to prevent actual misconfigured systems from having problems.

k
Normally when sendmail connects to a host via SMTP, it checks to make sure that this isn't accidently the same host name as might happen if sendmail is misconfigured or if a long-haul network interface is set in loopback mode. This flag disables the loopback check. It should only be used under very unusual circumstances.