email to suspended user -> why delivered to root?

meliux

Verified User
Joined
Jul 5, 2008
Messages
15
Hi guys,
not sure if this behaviour is by design, config issue, or bug...

I suspended a user today for nonpayment and it would appear any email they receive is now being delivered to root (which gets delivered to my account via /etc/aliases).

Is this normal? Is it possible to have email delivered to a suspended user either a) delivered to the user mailbox like normal, or b) queued in the exim mail spool like what happens for users with over quota mailboxes.

judging by the logs, exim accepts the email just fine because its a valid user, routes it through to spamassassin nicely, gets scanned, then its at that point that exim gives it to me.

mail log samples, config, etc available if required
cheers
 
Mail to both virtual mailboxes at suspended users and the main suspended username should be returned to sender as undeliverable. I just tested this on a system using SpamBlocker3 exim.conf, Dovecot, and SpamAssassin.

Are you using all standard setup? Which vesion of exim.conf?

Jeff
 
as far as i'm aware, its just standard exim 4.69 with dovecot 1.2.5, spamassassin 3.2.5, and clamav 0.96.1. (exim.conf modified slightly to pass the mail through clam).

from the top of exim.conf:
SpamBlocker.exim.conf.2.1.1-release 05-Jun-2007

The fact that its version 2 of the script rather than v3 which you said you're using, do you reckon that'd be the issue? Where/how do i get the new version?
 
If the only modification you made to your exim.conf file was to uncomment certain lines, then it should work as I stated previously. If you've made other changes I suggest strongly that you revert to a standard exim.conf file, at least for testing purposes.

I would not recommend you switch to SpamBlocker version 3 at this time; it's too close to the final release.

But the bad news is I can no longer offer forum-based support for version 2; hopefully someone else, who still uses it (I don't), can.

Jeff
 
I've just had this happen too. A reseller was suspended for going over bandwidth limits, and all the clients under the reseller had their email diverted to me.

This meant that people sending emails didn't know they hadn't got through so I had to forward them on one by one. Plus I'd rather not have to explain to people why I have their emails.

I've pasted the top of the exim.conf file from /etc below.

Any help gratefully recieved!

Thanks,
James


################################################################################
# DirectAdmin exim.conf 13-Feb-2008 #
# SpamBlocker with Optional VirusBlocker #
# Dovecot Only #
# Version 3.1-beta #
# Exim configuration file for DirectAdmin/Exim 4.60 and above #
# Requires exim.pl as distributed by DirectAdmin here: #
# http://files.directadmin.com/services/exim.pl #
# Dated 31-Oct-2007 10:11 or later #
 
It's been some time now since this thread was opened. All support for SpamBlocker Version 3 (betas) by me has been discontinued as SpamBlocker-powered exim.conf version 4 has been released.

That said, there's no reason why this should happen. I've never noticed it happen to me.

I'd suggest running exim as exim -bh and tracing exactly what happens to the email.

Jeff
 
Hiya,

Thanks for the response.

I'm happy to do an update. I tend to keep the system up to date with a mixture of directadmin updater, yum & custombuild, but it'd seem this hasn't been updated.

Could you give me a pointer on where I should be looking to upgrade it?

Thanks,
James
 
As I wrote above, it shouldn't happen in any version, even old versions.

DirectAdmin doesn't yet support SpamBlocker-powered exim.conf, version 4; they're still installing An older version, version 2.

Information on the latest version can be found in these forums, here. Or directly at my website, here (nobaloney.net).

I still believe you should run exim as exim -bh and tracing exactly what happens to the email.

If you decide to purchase installation from me (see my site link above) I'll do the tracing for you to see if I can tell why it's happening. I'll run the exim -bh command for you and let you know the results.

But you can install it and update it yourself if you wish. If you do, it's important that you read and follow everything in the ReadMe file. I do NOT guarantee it'll fix the problem, because I don't know why you're having it.

Jeff
 
Finally figured it out! :eek:

I've got multiple suspended users now and was wondering why I wasn't receiving emails for all of them. Turns out, in Exim when it gets to the final "system_aliases" check to see if it can deliver the email to a local aliased user, it finds an entry if the first part of the email address matches one of the aliases!

eg: [email protected] matches the "info: root" line in /etc/aliases!

so now i gotta go through the entries in the aliases file and remove anything that could possibly be a legitimate username match.

Unless there is a better fix...? Should it not be detecting the fact that the whole domain is suspended and not proceed with the checks?
btw I've upgraded to spamblocker 4
 
Last edited:
The same is for us. But I've never tried to find out reasons.

But I've recently received an email for system_user_name@userdomain (default email account) on my email. All emails from root a forwarded to me. But there's no alias for system_user_name in /etc/aliases
 
This has to do with the way DirectAdmin suspends mail for a user: it simply renames the /etc/virtual/USERNAME file to /etc/virtual/USERNAME_off.

I've never had a problem reported to me, nor seen email I shouldn't, so I haven't even looked at it.

If it's a problem for a lot of admins, I suppose we can check on the exim-user list to see if anyone has a way to limit the general /etc/aliases file to not work for a specific domain name.

Jeff
 
For me it is organized the other way /etc/virtual/domainname_off:

Code:
# ls -l | grep off
drwx--x--x 4 mail      mail   4096 Я********в 10 04:11 h*****k.ru_off
drwx--x--x 4 mail      mail   4096 Я********в 10 03:48 ki*****i.ru_off
drwx--x--x 4 mail      mail   4096 Я********в 10 04:07 m*****m.ru_off
drwx--x--x 4 mail      mail   4096 Я********в 10 03:47 p*****n.ru_off
drwx--x--x 4 mail      mail   4096 Я********в 10 04:11 u*****m.ru_off
# ls -l | grep susp
#

I'm a little bit confused, shouldn't directadmin delete suspended domain from /etc/virtual/domains? Why domain is kept there, while it's suspended?
 
I should have written off it was a simple error, which I've now corrected by editing my post.

If DirectAdmin deleted the directory it couldn't recreate it when you unsuspended the user; it wouldn't have the information.

It could be moved to a directory where it's being saved, but why bother, since renaming it has the same effect.

Jeff
 
That's not exactly what I meant. Sorry, if I misled you.

I don't suggest deleting domain's directory from /etc/virtual. There's a file /etc/virtual/domains, which contains the list of all domains, that are allowed to except incoming emails. When a letter arrives exim checks domain against that list. And if it's there in the list, exim proceeds with the letter.

So my question was and is, shouldn't directadmin temporary delete a certain domain from the file /etc/virtual/domains if the domain is suspended, while /etc/virtual/domain_off is kept undeleted.
 
Hello,

By default, suspended domains are left in the /etc/virtual/domains file, and the /etc/virtual/domain.com is renamed to /etc/virtual/domain.com_off.

However, removing the domain from /etc/virtual/domains will likely solve the /etc/aliases issue. I can't recall if there was a reason I did it that way (many years ago)..

it might be due to the fact that the "Local Mailserver" option is allowed to remove the domain from the /etc/virtual/domains file. If a domain uses an external email account, is supended, then unsuspended, DA would probably end up re-adding the domain to the /etc/virtual/domains file, when it shouldn't. We can add a flag somewhere else to take note that the domain isn't local. Removing a suspended domain from /etc/virtual/domains would probably solve the /etc/aliases issue.

John
 
Hello John,

Thanks for your reply. It would be nice, if you add a flag somewhere else to take note that the domain isn't local. Will you put in your queue for one of next releases?
 
Hello John,

Thanks for your reply. It would be nice, if you add a flag somewhere else to take note that the domain isn't local. Will you put in your queue for one of next releases?

Yes, that will be nice.
 
This thread is from some time ago, but I have exactly the same problem.
I got 2 suspended domains, and from one domain I'm getting the emails. My /etc/virtual for this user looks like this:
drwx--x--x 3 mail mail 4.0K Jan 5 12:02 suspendeddomain.com_off
drwx--x--x 3 mail mail 4.0K Jan 5 12:02 suspendeddomain.eu_off
drwx--x--x 3 mail mail 4.0K Jan 5 12:02 suspendeddomain.nl_off

The other suspende domain looks the same, but is working as designed, so senders will get the mail-delivery failed notice.

I'm using Custombuild 1.1 with spamassassin, Centos 5.5 and Mod_ruid2.
Next to that SpamBlocker.exim.conf.2.1.1-release with some changes. However, I don't think that is the problem, because then it would occur on both suspended domains, not only on one.

I could remove the domain from /etc/virtual but it should work this way and the other domain is going like it should.
I also tried to unsuspend the domain, and then suspend it again, but that did not help either.
 
I just found something out, could that be the problem?
I went looking in the /etc/virtual/suspendeddomain.com_off directory from the wrongly working domain into the aliases file present there.
It says this:
user2: user2
*: :fail:

Notice the space in the username reference.

Now I had a look in the suspended domain which worked well, and there it is like this:
user1:user1
*: :fail:
There is no space here in the username reference. Could that cause the problem with the mails from user2?
 
There is no space here in the username reference. Could that cause the problem with the mails from user2?

I doubt it, as I've got records with and without spaces. Anyway you might try it out to get assured.

Code:
# cat /etc/aliases
Code:
# grep user1 /etc/aliases
Code:
# grep user2 /etc/aliases
 
Back
Top