You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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:
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).
The text was updated successfully, but these errors were encountered: