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: . 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
Attachment:
signature.asc
Description: OpenPGP digital signature