Re: SMTP relay issue with emails to specific domain

[Daniel Bareiro]

Hi, Joe.

Thanks for your reply.

On 09/09/16 18:06, Joe 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.  

>> 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.  

> 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.

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:
.   1799IN  SOA ns6073.hostgator.com.
root.gator3037.hostgator.com. 1372031250 86400 7200 360 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



signature.asc
Description: OpenPGP digital signature

Re: SMTP relay issue with emails to specific domain

[Joe]

On Fri, 9 Sep 2016 16:13:10 -0400
Greg Wooledge  wrote:

> On Fri, Sep 09, 2016 at 08:58:15PM +0100, Joe 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.  
> 
> 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.  

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

Re: SMTP relay issue with emails to specific domain

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Sep 09, 2016 at 04:05:28PM -0300, Daniel Bareiro wrote:
> 
> 
> On 09/09/16 15:05, Stephan Beck wrote:

[...]

> H... 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?

What I miss from cursory reading of the other answers: the intermediate
server can also authenticate (playing the role of client) with the next
server. For exim, this is described in exim4_passwd_client(5)

Regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfTHWIACgkQBcgs9XrR2kYsUgCfd4Mmx/oQgJDKKS22tqOc0wUr
s6cAnArPQ6cqldgmFf0esGcV/N6p2WXA
=NgmA
-END PGP SIGNATURE-

Re: SMTP relay issue with emails to specific domain

[Greg Wooledge]

On Fri, Sep 09, 2016 at 08:58:15PM +0100, Joe 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.

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.

Re: SMTP relay issue with emails to specific domain

[Joe]

On Fri, 9 Sep 2016 16:05:28 -0300
Daniel Bareiro  wrote:

> On 09/09/16 15:05, Stephan Beck wrote:
> 
> > Hi Daniel,  
> 
> Hi, Stephan. Thanks for your reply.
> 
> >>> 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=, 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.  
> 
> > 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  
> 
> H... 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?
> 
>
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=, 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

Re: SMTP relay issue with emails to specific domain

[Daniel Bareiro]

On 09/09/16 15:05, Stephan Beck wrote:

> Hi Daniel,

Hi, Stephan. Thanks for your reply.

>>> 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=, 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.

> 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

H... 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



signature.asc
Description: OpenPGP digital signature

Re: SMTP relay issue with emails to specific domain

[Stephan Beck]

Hi Daniel,

Daniel Bareiro:
> 
> On 08/09/16 13:56, Daniel Bareiro 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.
>>
>> 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=, 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.

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

[...]
> 
> 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.
> ---
> 

Re: SMTP relay issue with emails to specific domain

[Daniel Bareiro]

On 08/09/16 13:56, Daniel Bareiro 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.
> 
> 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=, 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?

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



signature.asc
Description: OpenPGP digital signature

SMTP relay issue with emails to specific domain

[Daniel Bareiro]

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=, 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



signature.asc
Description: OpenPGP digital signature