On Fri, 9 Sep 2016 16:05:28 -0300 Daniel Bareiro <daniel-lis...@gmx.net> 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=<x...@lkeusa.com>, 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 > > 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? > > 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=<x...@lkeusa.com>, 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
