Alias Deliverability Mystery
Answered
AlmaLinux v8.10.0 STANDARD kvm
WHM 120.0.16
OK, this is a weird one.
One of the domains I manage uses its valiases file to handle distributing messages sent to a sales@ address to intended domain recipients. There's no actual sales@ eamil account, just a bunch of forwarders in valiases going to sub-groups ('branch managers' which goes to those folks, others for 'general staff' that also see sales@, 'executives' that want to monitor the firehose, and so on).
When any staff member that 'sees' sales@ goes on vacation, we turn on an auto-responder, but first remove them from the relevant valiases entry so the sender (and all sales@ recipients) do not see the vacation reply. Until we add them back in to sales@, only messages sent directly to their actual address would get delivered (and the sender gets the "I'm out until ..." reply).
This is the way it's been working for years.
Yesterday, a staff member who'd never had an auto-reply wanted one as she was going out of town for a few days.
After removing her actual address from anything sales@ touches in valiases, the autoresponder was activated.
Somehow, she still kept receiving sales@, so the auto-replies kicked in. Annoying, and slightly embarrassing, as the sender might not even know her or deal with her location so why would they be getting a reply? Had to turn the responder back off.
Double-checked the aliases file, and her address is definitely not attached to sales@, nor is any other user attached to sales@ sending copies to her.
The only other place I could think to look was /etc/antivirus.empty. There are a couple of unseen delivers there, but those are so managers can monitor outbound for newly trained staff members. Nothing in there references sales@, they just bcc the respective manager when a new staff member sends out.
Have restarted Exim, and the server, yet the behavior continues.
We checked the inbound messages themselves, and she's not getting a cc. It's all messages to sales@ somehow still being sent to her.
Is there anywhere else I might look to see how this user could still be getting sales@ messages, when their address is definitely not present in the domain's vailiases file?
Please advise. Thanks!
-
Hey there! I would check the Exim log directly at /var/log/exim_mainlog as that would show any and all activity related to mail. If you have a forwarder or filter in place that would also show up in the log, so you'd see what was causing her to get the message.
0 -
Ah, should have checked that. The logs know all.
Hadn't noticed before that when processing a message, exim_mainlog dutifly shows all the possible recipients for any user as they exist in the aliases file. That was the clue.
There's another set of alias entries that takes care of messages sent directly to folks not on the sales@ firehose, but still have company email (phone order processors and so on). Just in case a customer gets ahold of their address, any messages sent directly to them results in a cc to their respective manager, as it might still be sales related.
One of those folks had been updated to start getting sales@, but their corresponding "cc the manager" entry in valiases had not been removed.
So long as that "cc the manager" alias was in place, every time that user got a sales@ email, Exim would forward a copy to the manager who had been taken off of sales@ itself but still had this active vacation auto-responder turned on...
Thanks for getting me to double-check!
0 -
I'm glad that got you pointed in the right direction!
0 -
Oh, I should point out that to keep updating valiases easier, positions like manager are not the actual email account name, rather "mgr.location@tld.com", etc., with another entry for that alias pointing to the actual account. That way when staff changes we only have to update the mgr.location entry once, even though it may point to several other aliases.
Most folks only send out as sales@, so it's not like they're trying to spam or anything; this is all just for internal organization.
That's why I didn't spot the affected user's entry right away. Yes, her email account name wasn't there explicitly, but other things referred to it, and I didn't notice at first that one of her staff was simultaneously on sales@ and, such as it is, nosales@, a condition which should never occur.
0
Please sign in to leave a comment.
Comments
4 comments