email to suspended user -> why delivered to root?

Hello,

If you'd like, what you can do as a workaround, is to activate the domain, and suspend each email account.
This would allow email to come in normally, but wouldn't allow them to login to download it.

1) To do this, rename:
/etc/virtual/domain.com_off

back to:
/etc/virtual/domain.com

(don't worry, DA does a check when unsuspending the User so the already active domain should be fine)

2) Then edit:
/etc/virtual/domain.com/passwd

and for each line, eg:
Code: 
test:$1$Jtd0a1sr$cryptedpass:123:12::/home/user/imap/domain.com/test:/bin/false
change the password value to have a ! character at the front, eg:
Code: 
test:[b]!$1$[/b]Jtd0a1sr$cryptedpass:123:12::/home/user/imap/domain.com/test:/bin/false
which is the usual way an account is suspended in unix.. the password crypt gets a ! in front, making it non-useable, but it can be un-suspended by removing the ! character.

John
 
This would allow email to come in normally, but wouldn't allow them to login to download it.
Click to expand...
Thanks John, but if email would come in normally and he can't download it, the mailbox will get full soon and I will be getting emails that a users account or mailbox is over quota or such things.

Isn't there another workaround so mail to this domain just will be rejected?

I also still wonder why with 2 suspended accounts on the same server, 1 is working as designed (mail-delivery failed), and the other one has this problem that mail is forwarded to root.
 
I also still wonder why with 2 suspended accounts on the same server, 1 is working as designed (mail-delivery failed), and the other one has this problem that mail is forwarded to root.
Click to expand...
Actually, check your hostname. Ensure it's something like server.domain.com.
Admin Level -> Admin Settings.

If your hostname is the same as one of the domains, that would explain everything. A hostname must not be the same value as a User Level domain.

Isn't there another workaround so mail to this domain just will be rejected?
Click to expand...
Sure, instead of editing the passwd file to add the ! character, rename it to passwd.backup, and create a new empty one (ensure correct permissions/ownership).
Then make sure that the aliases file has:
Code: 
*: :fail:
so that they all fail, and none are accepted. (except any other forwarders that exist in aliases)

John
 
Actually, check your hostname. Ensure it's something like server.domain.com
Click to expand...
Well that's also not the cause of the problem, because both suspende domains are owned by clients and the server hostname is from a domain belonging to our company so it couldn't even be the same.
Our hostname is actually server.ourcompany.nl and both suspended domains have completely different domain names.

The workaround you suggested does not work.
The domain already has an empty passwd file.
And the aliases file is:
accountname: accountname
*: :fail:
Click to expand...

Edit: I found a difference. The correct working suspended domain has this:
drwxr-x--x 2 majordomo daemon 4.0K Mar 27 2010 majordomo
Click to expand...
This is not present in the faulty domain. Could this have something to do with it?
 
Last edited:
@Richard,

I doubt it, as majordomo is a mailing list manager, so it's used only on one domain.

Did you try to enable full logging in Exim and trace an email for both domains in logs or in console?
 
I did not trace the email for the working domain yet, but this is the log for the domain which is not rejecting the mail:
2012-01-08 07:08:34 1Rjlvl-0001yK-T2 DKIM: d=senderdomain.com s=key1 c=relaxed/relaxed a=rsa-sha1 [email protected] [verification succeeded]
2012-01-08 07:08:34 1Rjlvl-0001yK-T2 <= [email protected] H=mailer5.senderdomain.com [208.112.84.51] P=esmtp S=7207 id=senderdomain.coma894901664b6498c8b68d4f5ae7d1f02@senderdomain.com T="Active Search Results Search Engine - Membership Confirmation" from <[email protected]> for [email protected]
2012-01-08 07:08:34 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1Rjlvl-0001yK-T2
2012-01-08 07:08:34 cwd=/tmp 4 args: /usr/sbin/exim -oMr spam-scanned -bS
2012-01-08 07:08:37 1Rjlvm-0001yO-7E <= [email protected] U=mail P=spam-scanned S=7687 id=senderdomain.coma894901664b6498c8b68d4f5ae7d1f02@senderdomain.com T="Active Search Results Search Engine - Membership Confirmation" from <[email protected]> for [email protected]
2012-01-08 07:08:37 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1Rjlvm-0001yO-7E
2012-01-08 07:08:37 1Rjlvm-0001yO-7E => technics <[email protected]> F=<[email protected]> R=virtual_user T=virtual_localdelivery S=7820
2012-01-08 07:08:37 1Rjlvm-0001yO-7E Completed
2012-01-08 07:08:37 1Rjlvl-0001yK-T2 => info <[email protected]> F=<[email protected]> R=spamcheck_director T=spamcheck S=7564
2012-01-08 07:08:37 1Rjlvl-0001yK-T2 Completed
Click to expand...

I only see one line mentioning "technics", so I don't understand what's happening.

This is a log of the domain which does mail-delivery failed as it should.
2012-01-12 15:53:44 H=smtp-out3.tiscali.nl [195.241.xx.xxx] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2012-01-12 15:53:44 H=smtp-out3.tiscali.nl [195.241.xxx.xxx] incomplete transaction (QUIT) from <[email protected]>
Click to expand...

This user only has a system email account as email.
 
I thought newaliases was not needed with Exim. Anyway I ran it.

Email is coming in just in original format with addressed to to [email protected] not as attachment or forward.
This one is from the mainlog after doing the newaliases command:
2012-01-12 20:33:08 1RlQOa-00036U-Gz <= [email protected] H=smtp-out2.tiscali.nl [195.241.79.177] P=esmtps X=TLSv1:AES256-SHA:256 S=976 id=F38EA68410A34595A37ADFF409125E87@pcxp1038 T="test" from <[email protected]> for [email protected]
2012-01-12 20:33:08 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1RlQOa-00036U-Gz
2012-01-12 20:33:08 cwd=/tmp 4 args: /usr/sbin/exim -oMr spam-scanned -bS
2012-01-12 20:33:08 1RlQOa-00036Y-IW <= [email protected] U=mail P=spam-scanned S=1366 id=F38EA68410A34595A37ADFF409125E87@pcxp1038 T="test" from <[email protected]> for [email protected]
2012-01-12 20:33:08 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1RlQOa-00036Y-IW
2012-01-12 20:33:08 1RlQOa-00036Y-IW => technical <[email protected]> F=<[email protected]> R=virtual_user T=virtual_localdelivery S=1488
2012-01-12 20:33:08 1RlQOa-00036Y-IW Completed
2012-01-12 20:33:08 1RlQOa-00036U-Gz => info <[email protected]> F=<[email protected]> R=spamcheck_director T=spamcheck S=1243
2012-01-12 20:33:08 1RlQOa-00036U-Gz Completed
Click to expand...

And this is the source of my email program (outlook) how the mail arrives:
Return-path: <[email protected]>
Envelope-to: [email protected]
Delivery-date: Thu, 12 Jan 2012 20:33:08 +0100
Received: from mail by server.mycompany.nl with spam-scanned (Exim 4.76)
(envelope-from <[email protected]>)
id 1RlQOa-00036Y-IW
for [email protected]; Thu, 12 Jan 2012 20:33:08 +0100
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on server.mycompany.nl
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
Received: from smtp-out2.tiscali.nl ([195.241.xx.xxx])
by server.mycompany.nl with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76)
(envelope-from <[email protected]>)
id 1RlQOa-00036U-Gz
for [email protected]; Thu, 12 Jan 2012 20:33:08 +0100
Received: from [195.240.119.89] (helo=pcxp1038)
by smtp-out2.tiscali.nl with esmtp (Exim)
(envelope-from <[email protected]>)
id 1RlQOa-0001Qr-1J
for [email protected]; Thu, 12 Jan 2012 20:33:08 +0100
From: "Richard G" <[email protected]>
To: <[email protected]>
Subject: test
Date: Thu, 12 Jan 2012 20:33:04 +0100
Message-ID: <F38EA68410A34595A37ADFF409125E87@pcxp1038>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Thread-Index: AczRYQEFiK27wNhITSups5miJv397g==
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
Click to expand...
 
Last edited:
I seem to have overlooked post #9 in this thread, which is probably causing this behaviour at our server too:
eg: [email protected] matches the "info: root" line in /etc/aliases!
Click to expand...
So I removed the "info: root" and some other strange lines which shouldn't be there standardly (like marketing, sales and support) and hope problem will be over now.

It would be good to not have common used email addresses send to root by the alias file standardly. I only don't know if this is done by the OS or by Directadmin.
 
Code: 
/etc/aliases
       is a table providing a mechanism to redirect mail for local recipients.
       /etc/aliases is a text file which is roughly compatible with  Sendmail.
       The file should contain lins of the form
       name: address, address, ...
       The  name is a local address without domain part. All local domains are
       handled equally. For  more  detailed  documentation,  please  refer  to
       /usr/share/doc/exim4-base/spec.txt.gz,     chapter     22,    and    to
       /usr/share/doc/exim4-base/README.Debian.gz. Please note that it is  not
       possible  to use delivery to arbitrary files, directories and to pipes.
       This is forbidden in Debian's exim4 default configuration.

       You should at least set up an alias for postmaster in the  /etc/aliases
       file.


http://man.he.net/man5/etc-aliases
 
Yes, but I wondered what the use was in a directadmin envoirment. I looked into it and it seems they only work for alias@hostname normally.
I guess diradmin (http://help.directadmin.com/item.php?id=225) makes sense to have there, but I don't see a reason for example webmaster or news.
If they cause trouble for suspended users it wouldn't be a crazy idea to have DA remove all but diradmin and maybe abuse from the file by default.
 
News, webmaster, postmaster etc. are mostly already put in the aliases file standardly by the operating system.
The info, marketing, sales and support aliases are put in there by the OS (at least Centos) nowadays too.
So it's not something DA put's in there. DA mostly leave things originally if possible, which is a good thing.
 
Richard G said:
So it's not something DA put's in there. DA mostly leave things originally if possible, which is a good thing.
Click to expand...

Didn't say it did. But if its true that if you have a suspended user with info@, and theres info in /etc/aliases, and therefore e-mails of your customer are being delivered to root; it should be prevented? Or if there is a bug elsewhere okay, but it seemed to me this was the problem for you.
 
Didn't say it did.
Click to expand...
Correct, I just mentioned it to make clear why DA will probably not remove it, because they don't put it in there and they would normally leave standard OS files "as is" if possible.

However, I agree with you that there will be lots of places where an info@ or support@ or one of the other 2 often used addresses will be present on the server, which can be a pain when such account get's suspended and admin/root starts getting emails of those domains.
Took me some time too before discovering why it happened with 1 account and did not with the other. This was indeed a problem for me until I removed those aliases.

Preventing this would mean DA have to make their own aliases file with those aliases not in it.
We could make a suggestion for it, but I don't know if these aliases are also present in fedora, debian or one of the others. It would be better anyway to make such suggestion to the makers of the OS who put in the aliases file.
If uses want such aliases, they should make them themselves, not the OS.
 
You must log in or register to reply here.
Back
Top