Subject: SMTP relay issue with emails to specific domain

From: Daniel Bareiro <[email-masked]>
Date: Thu, 8 Sep 2016 13:56:50 -0300

Hi all!

I recently set up an relay SMTP server on a host of Digital Ocean, using
Debian and Postfix.

The main reason for setting up this relay is that the cPanel VPS is
hosted at Godaddy, and they force everyone to send email through their
shared SMTP relay. As expected, that shared relay is continually being
flagged for spam.

So the outgoing emails are routed through this server. Usually
everything worked smoothly. Mails to accounts on Google, Yahoo, Hotmail
and other servers are delivered. But I found a problem with a specific
domain:

-----------------------------------------------------------------------
Sep  7 14:36:11 smtp postfix/smtp[8036]: 5EAA520AAD:
to=<[email-masked]>, relay=lkeusa.com[50.87.144.56]:25], delay=13,
delays=0.91/0.06/6.1/5.9, dsn=5.0.0, status=bounced (host
lkeusa.com[50.87.144.56] said: 550-Please turn on SMTP Authentication in
your mail client, or login to the 550-IMAP/POP3 server before sending
your message.  smtp.server.com 550-[x.y.z.t]:41988 is not permitted to
relay through this server 550 without authentication. (in reply to RCPT
TO command))
-----------------------------------------------------------------------

I'm not sure why this specific domain is complaining in this way.

Another thing that is strange to me is that apparently a dig query is
not returning nothing:

-----------------------------------------------------------------------
$ dig -t mx lkeusa.com

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> -t mx lkeusa.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31796
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;lkeusa.com.                    IN      MX

;; Query time: 531 msec
;; SERVER: 10.1.0.6#53(10.1.0.6)
;; WHEN: Thu Sep 08 13:48:38 ART 2016
;; MSG SIZE  rcvd: 39
-----------------------------------------------------------------------

But Postfix was trying to deliver the mail in 50.87.144.56.

Maybe they were making changes to the remote server?

Thanks in advance.

Kind regards,
Daniel

---

From: Daniel Bareiro <[email-masked]>
Date: Thu, 8 Sep 2016 14:36:08 -0300

> and other servers are delivered. But I found a problem with a specific

Well, it seems that in the absence of an MX record, Postfix uses the A
record that it find by querying that domain and in that IP address an
Exim server responds:

-----------------------------------------------------------------------
# telnet lkeusa.com 25
Trying 50.87.144.56...
Connected to lkeusa.com.
Escape character is '^]'.
220-gator3037.hostgator.com ESMTP Exim 4.86_1 #1 Thu, 08 Sep 2016
12:15:19 -0500
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
-----------------------------------------------------------------------

But I have not yet determined what the cause of that error 550 which is
not present with other SMTP servers like Gmail.

I will continue investigating. Any comments that shed some more light on
this will be appreciated.

Kind regards,
Daniel

---

From: Stephan Beck <[email-masked]>
Date: Fri, 09 Sep 2016 18:05:00 +0000

Hi Daniel,

>> and other servers are delivered. But I found a problem with a specific

I think it's because it requires SMTP authentication, whereas apparently
the other servers you mention don't (mails are delivered). Have you
checked if the mail client's option mail.smtpserver.default.authMethod
is set to 0, which means there is no SMTP authentication at all. That
could explain the issue.
For a list of methods, see (1)
Looking at exim's server ready 220 response below, it does not like
people to send spam or bulk email.
The 550 return code means that the mailbox you are trying to reach can't
be found or you are lacking access rights. In your case it's the latter,
as the server response indicates.

(1) http://www.afterlogic.com/mailbee/docs/SMTP_props_AuthMethod.htm

Stephan

[...]

---

From: Daniel Bareiro <[email-masked]>
Date: Fri, 9 Sep 2016 16:05:28 -0300

> Hi Daniel,

Hi, Stephan. Thanks for your reply.

> (1) http://www.afterlogic.com/mailbee/docs/SMTP_props_AuthMethod.htm

Hmmmm... I do not quite understand this situation. That is, lkeusa.com
asked to use SMTP authentication, but this would make sense if the email
client connects directly to lkeusa.com for deliver the email. And this
is not the case. The client connects to an intermediate server, the
relay server, which is the one delivering the email to lkeusa.com. Or
maybe I'm missing something?

Kind regards,
Daniel

---

From: Joe <[email-masked]>
Date: Fri, 9 Sep 2016 20:58:15 +0100

On Fri, 9 Sep 2016 16:05:28 -0300
Daniel Bareiro <[email-masked]> wrote:

> >>> I recently set up an relay SMTP server on a host of Digital
> >>> Ocean, using Debian and Postfix.
> >>>
> >>> The main reason for setting up this relay is that the cPanel VPS
> >>> is hosted at Godaddy, and they force everyone to send email
> >>> through their shared SMTP relay. As expected, that shared relay
> >>> is continually being flagged for spam.
> >>>
> >>> everything worked smoothly. Mails to accounts on Google, Yahoo,
> >>> Hotmail and other servers are delivered. But I found a problem
> >>> with a specific domain:
> >>>
> >>> to=<[email-masked]>, relay=lkeusa.com[50.87.144.56]:25],
> >>> delay=13, delays=0.91/0.06/6.1/5.9, dsn=5.0.0, status=bounced
> >>> (host lkeusa.com[50.87.144.56] said: 550-Please turn on SMTP
> >>> Authentication in your mail client, or login to the 550-IMAP/POP3
> >>> server before sending your message.  smtp.server.com
> >>> 550-[x.y.z.t]:41988 is not permitted to relay through this server
> >>> 550 without authentication. (in reply to RCPT TO command))
> > I think it's because it requires SMTP authentication, whereas
> > apparently the other servers you mention don't (mails are
> > delivered). Have you checked if the mail client's option
> > mail.smtpserver.default.authMethod is set to 0, which means there
> > is no SMTP authentication at all. That could explain the issue.
> > The 550 return code means that the mailbox you are trying to reach
> > can't be found or you are lacking access rights. In your case it's
> > the latter, as the server response indicates.
> > 
> > 
> > (1)
> > http://www.afterlogic.com/mailbee/docs/SMTP_props_AuthMethod.htm  
> 
> asked to use SMTP authentication, but this would make sense if the
> email client connects directly to lkeusa.com for deliver the email.
> And this is not the case. The client connects to an intermediate
> server, the relay server, which is the one delivering the email to
> lkeusa.com. Or maybe I'm missing something?
> 
>
An email client connects to its SMTP smarthost using SMTP, so there's no
way a given SMTP server can tell whether it's a client (MUA) or another
SMTP server (MTA) trying to connect to it.

That said, a SMTP server should accept mail addressed to a valid
recipient of a domain for which it is authoritative, unconditionally, it
should not ask for authentication. Authentication will only be required
for relaying, i.e. expecting lkeusa to pass the message on to someone
who is not a local recipient. If this were not the case, anyone sending
email to anyone else would be expected to be able to authenticate to
the recipient's server, which is nonsense.

The error message you are seeing seems to involve relaying. Are you
definitely sending email to a valid recipient on the lkeusa.com domain?
If so, no relaying is being requested, the error message you are seeing
does not make sense ("to=<[email-masked]>, relay=lkeusa.com") and you
need to contact the postmaster for the domain to ask what is going on.

P.S. A quick dig at lkeusa.com shows no MX record, and mxtoolbox.com
confirms this. 50.87.144.56 is the IP address given by an A record for
the domain name itself, and the only other DNS records are the hosting
company's nameservers. This may have something to do with the problem.

-- 
Joe

---

From: Greg Wooledge <[email-masked]>
Date: Fri, 9 Sep 2016 16:13:10 -0400

> SMTP server (MTA) trying to connect to it.

That's outdated information.

SMTP is used to exchange messages between mail servers (MTAs), but
a client submitting a new message to its designated relay may use
the "Submission" protocol on port 587 instead.  (Really old clients
may still use SMTP.)

Relay control is a pretty important, nontrivial field.  Some servers
rely on an "SMTP AUTH" protocol that involves a username and password
to authenticate the client.  A few may still use the old "POP before SMTP"
hack, in which a client that performs an authenticated POP3 retrieval
opens up permission to use SMTP for some time period.  I don't know
how widespread this practice still is; it's quite antiquated.

And of course some servers may simply whitelist their clients by IP
address.  This works extremely well in internal corporate settings,
but very poorly if you have people working from home, on the road, etc.
(I've seen the phrase "road warriors" used to refer to these clients.)

Internet service providers probably use some variant of this, magically
knowing who their customers are by IP address.  This is outside of my
experience.

DJB proposed authenticating client emails by having them be PGP-signed,
with the server holding the public keys necessary to validate the
clients' signatures.  I've never seen this actually implemented, though.

So, long story short, you have to get permission to use a given host
as your mail submission/relay.  And how you do that is up to the owner
of that host.

---

From: Joe <[email-masked]>
Date: Fri, 9 Sep 2016 22:06:07 +0100

On Fri, 9 Sep 2016 16:13:10 -0400
Greg Wooledge <[email-masked]> wrote:

> > An email client connects to its SMTP smarthost using SMTP, so
> > there's no way a given SMTP server can tell whether it's a client
> > (MUA) or another SMTP server (MTA) trying to connect to it.  
> 
> Relay control is a pretty important, nontrivial field.  

And a separate issue in this case, where no relaying was requested. The
protocol used is still SMTP, possibly with a few bells and whistles
bolted on, and does not vary depending on whether a mail client or
server is the originator. The port and authentication required vary
according to whether local delivery or relaying is occurring, not
according to what kind of software is on the transmitting end.

I've used a SMTP server to send authenticated mail to another server,
as it was necessary in that time and place. The receiving server
couldn't tell that the sender was another server. I've used a terminal
window, a mail client by anyone's standards, to send unauthenticated
port 25 SMTP directly to a recipient's server, something a client is
not normally expected to do.

The issue in this case is that a SMTP server *seems* to be demanding
authentication for local delivery. There may be more to it than that,
but certainly there are DNS irregularities. There is no MX record for
the domain (which, to be honest, I would have thought meant that no
delivery was even attempted), and the domain administrators may have
made other configuration errors. It may just be that the OP's postfix
installation is failing to find the MX, getting confused, and returning
an error message which is less than helpful.

-- 
Joe

---

From: Daniel Bareiro <[email-masked]>
Date: Fri, 9 Sep 2016 20:17:11 -0300

Hi, Joe.

Thanks for your reply.

> an error message which is less than helpful.

Apparently, in Hostgator they don't have an MX record for this domain.
Even making the query directly to the Google DNS, it returns nothing:

-----------------------------------------------------------------------
$ dig -t mx @8.8.8.8 lkeusa.com

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> -t mx @8.8.8.8 lkeusa.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17815
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;lkeusa.com.                    IN      MX

;; AUTHORITY SECTION:
.                       1799    IN      SOA     ns6073.hostgator.com.
root.gator3037.hostgator.com. 1372031250 86400 7200 3600000 86400

;; Query time: 254 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep 09 20:09:22 ART 2016
;; MSG SIZE  rcvd: 106
-----------------------------------------------------------------------

According to the Section 5 of RFC 5321 [1], if no MX record is present
mail servers should fall back to the A record for the domain. This is
probably what's happening in this case. Although not clarify the problem
of authentication that I am observing.

Tomorrow I'll try to make a test from the other side to see if I get the
same error.

Kind regards,
Daniel

[1] https://tools.ietf.org/html/rfc5321#section-5