On Fri, 9 Sep 2016 16:13:10 -0400 Greg Wooledge <wool...@eeg.ccf.org> 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
