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
