SMTP 550, User not authorized

[modem]

Hey all,

I have a really weird issue that just started happening yesterday morning. This issue happened as I was working on troubleshooting SpamAssassin and Exim. The issue itself has nothing to do with SpamAssassin. Rather all of a sudden I started getting swamped with telephone calls that clients were unable to send email. After calming them down and getting them to tell me the error, they were recieving bounce-back emails from "System Administrator" with the error message of "SMTP 550 - User not Authorized to send". Or something very similiar to that wording. Needless to say that shocked me because for 2 years my system has been running with SMTP port 25 without requiring authorization to send email. I'll debate on whether that was good or bad later. Instead this worried me that something serious was going on.

For a quick technical rundown, I have been running the DirectAdmin control panel with Exim 4.60 since January. I previously had ran and upgraded from Exim 4.24 to each subsequent version thereafter. I took the time and liberty to backup my working exim.conf file each time to make sure that it didn't get overwritten. Anyway soon as I made a troubleshooting change by reinstalling Exim 4.60 yesterday to help fix my SA problem, is when this issue appeared. I decided I'd replace the exim.conf file with it's duplicate backup copy just in case I fubared something in the current exim.conf file. To no avail, the issue persisted. I finally had to drive to my clients offices today and go into Outlook and turn on the check box to require SMTP authorization for outgoing mail.

While their email is now working and everything is working for the moment, I have serious concerns as to why this happened to begin with. I even backed up my working exim.conf file to replace it with an older one from months back and that had no affect on it whatsoever. Here are parts from my Exim.conf file that pertain to accepting mail from different hosts/users and the restrictions thereof. Please critique or offer thoughts and opinions.

# These options specify the Access Control Lists (ACLs) that
# are used for incoming SMTP messages - after the RCPT and DATA
# commands, respectively.

acl_smtp_rcpt = check_recipient
acl_smtp_data = check_message

# define local lists

addresslist whitelist_senders = lsearch;/etc/virtual/whitelist_senders
addresslist blacklist_senders = lsearch;/etc/virtual/blacklist_senders
domainlist blacklist_domains = lsearch;/etc/virtual/blacklist_domains
domainlist whitelist_domains = lsearch;/etc/virtual/whitelist_domains
domainlist local_domains = lsearch;/etc/virtual/domains
domainlist relay_domains = lsearch;/etc/virtual/domains : localhost
domainlist use_rbl_domains = lsearch;/etc/virtual/use_rbl_domains
hostlist auth_relay_hosts = *
hostlist bad_sender_hosts = lsearch;/etc/virtual/bad_sender_hosts
hostlist bad_sender_hosts_ip = net-lsearch;/etc/virtual/bad_sender_hosts
hostlist relay_hosts = net-lsearch;/etc/virtual/pophosts : 127.0.0.1
hostlist whitelist_hosts = lsearch;/etc/virtual/whitelist_hosts
hostlist whitelist_hosts_ip = net-lsearch;/etc/virtual/whitelist_hosts
.....
# By default we do NOT require sender verification.
# Sender verification denies unless sender address can be verified:
# If you want to require sender verification, i.e., that the sending
# address is routable and mail can be delivered to it, then
# uncomment the next line. If you do not want to require sender
# verification, leave the line commented out

#require verify = sender
....
# accept if message comes for a host for which we are an outgoing relay
# recipient verification is omitted because many MUA clients don't cope
# well with SMTP error responses. If you are actually relaying from MTAs
# then you should probably add recipient verify here

accept hosts = +relay_hosts
accept hosts = +auth_relay_hosts
endpass
message = authentication required
authenticated = *
deny message = relay not permitted

 

[nobaloney]

Did this ever get resolved?

Jeff

 

[modem]

Yes, this issue did get resolved. Appearantly something got corrupted in the /var/log/maillog file due to the size or something. Once I went back and replaced it with one of a recent backup (two days before the issue started) and restarted the da-popb4smtp service, all has seemed to work since.

I did send a reply to the exim mailing list noting the issue as resolved, but I left my office (on vacation) and haven't returned since.

 

[elbarto]

I'm not sure if this has to do with the same problem or if it's something completely different.

I'm having a problem with one specific client. In a server with many hosted domains, when I send emails to one of them in particular, I get 550 authentication required.

I tried sending the emails from different accounts and the response is always de same.

Here is my mailog (I changed the addresses for obvious reasons):

2009-01-11 20:57:00 H=rv-out-0708.google.com [209.85.198.241] F=<[email protected]> rejected RCPT <[email protected]>: authentication required
2009-01-11 20:57:00 H=rv-out-0708.google.com [209.85.198.241] F=<[email protected]> rejected RCPT <[email protected]>: authentication required
2009-01-11 20:57:01 H=rv-out-0708.google.com [209.85.198.241] F=<[email protected]> rejected RCPT <[email protected]>: authentication required
2009-01-11 20:57:01 H=rv-out-0708.google.com [209.85.198.241] incomplete transaction (QUIT) from <[email protected]>

None of the accounts of that domain has problems sending emails but they cannot receive them.

Thanks in advance!

 

[nobaloney]

Presuming you've not made any changes to the exim.conf file, the error generally means that the domain's email isn't properly set up to use your server. Make sure there's a directory for the domain in /etc/virtual. From the user-level control panel make sure that the MX Records page has the X properly set.

Jeff

 

[elbarto]

Thanks Jeff!

It turns out that the client had configured his MX records to use Google for domains. But actually the DNS that we use is on another machine, so those records did nothing but cause this trouble. I had done a nslookup to the domain and the MX records were ok, but I hadn't checked on DA.

Thanks again.