Remove Default Email user@domain

CanadaGuy

Verified User
Joined
Nov 14, 2019
Messages
158
Is it possible to remove the default email account that is created when a domain is added? For example, if I have a DA account "user" for domain "example.com" it will create "[email protected]" email account as default that cannot be deleted from what I see.
 
No, you can not remove the default email account.

Okay, so the "real" account associated with that email is [email protected] and you access it by the username/password directly without the domain attached. So account email [email protected] is always a "special" account and forwards to the unix server account. That would be a helpful tip directly in the DA software.

Thanks!
 
Never mind. Did not knew there was a hidden forward from [email protected] to [email protected] for the unix account.
Because it uses [email protected] that's for sure.

Just wondering, if you disable this via blackhole, system messages like Softaculous notifications must be set up seperatetaly some how? They normally are automatically send to the system account, as are quota messages etc. how about fixing that?
 
username@hostname and [email protected] are identical

- username is a system account name, login to DirectAdmin
- hostname - a server's hostname
- domain.com - a domain hosted on the same server and owned by user with username
 
I know that alex.
I just thought that it was just also vitual. I had a Postfix setup in the old days with virtual an local accounts where the locals just were implentend some way in the virtual account database and user@hostname was not reachable. I did not know DA did this with a forward.

Still wondering about my question though. When disabled via blacklist, how about quota and other system messages which are by default send to the system account (so blacklist in that case)?
 
If you need to read emails sent to your system account, then do not blackhole it. Simply forward emails to a virtual email account and use Sieve filters to sort emails.
 
Oke clear. I was using auto forward to a virtual account for a long time. So that's still the best way then. Some times I got users who want those mails gone to other accounts and not use the system account. I always advise the forward or make it for them.
But it is something to think about when thinking of blacklisting the system account.
Thank you.
 
Good thread, thanks for digging into this as it has produced much better understanding of what DA is doing.

I used a Postfix setup similar to that described above, so the local vs virtual accounts were explicitly outlined. Maybe this could be added for clarity to new users.
 
I've been thinking a little more about this, and come to the conclusion that it leaves something to be desired. If I create a DA account "tom", then it means I cannot create an email account for a user named "tom".

Are there any good patterns people use to create DA usernames to avoid this issue? I was thinking something like "tomlocal" or "tomunix" or more generally "adminlocal" or "adminunix".
 
@CanadaGuy, Even they can't create email account "tom", they can still use it as a normalt email account. They must only remember that the user name for the system account is only the username, not the entire email address.

What we do, is that we manually generate a random username for every new user, so it would not be a username they would want to use when creating email accounts. Usually we pick a username from the first and last letter in the name of the customer, or in the company name of a customer, and/or a combination of both, and if needed add a one more random character so that is become minimum 3 character.

Another thing worth mention if people a considering to backhole the system accont email, is that when users use PHP to send email without SMTP authentication, if they bounce, those email will bounce back to the system account. So I think it best not to disable it.
 
To be more specific, I was referring to the scenario where I create DA user "tom" and he creates a bunch of domains including example.com. But then he has a client whose name is "tom" as well. In this scenario, [email protected] would not be available to the client, as it would already be taken by DA user "tom".

Your suggestion of pseudo-random usernames is a good one as the result is usually an undesirable email address.

Yeah, I think I understand the value and use of the default user account now. It does make things a little less intuitive from the start, so emphasis on the consequences of DA username choices might be good in the documentation.
 
What we do, is that we manually generate a random username for every new user, so it would not be a username they would want to use when creating email accounts. Usually we pick a username from the first and last letter in the name of the customer, or in the company name of a customer, and/or a combination of both, and if needed add a one more random character so that is become minimum 3 character.

This was a good tip. I did initials plus a 3 digit number for accounts. This produces accounts that are sufficiently decoupled from email address and eliminates conflicts.
 
few of accounts get their limit reached due to system email account, what should i do ? any suggestion ?
 
investigate
here is message that my DA indicate

The bosmarke account has just finished sending 200 emails.
There could be a spammer, the account could be compromised, or just sending more emails than usual.

After some processing of the /etc/virtual/usage/bosmarke.bytes file, it was found that the highest sender was [email protected], at 196 emails.

The top authenticated user was bosmarke, at 196 emails.
This accounts for 98% of the emails. The higher the value, the more likely this is the source of the emails.
An authenticated username is the user and password value used at smtp time to authenticate with exim for delivery.


The most common path that the messages were sent from is /home/bosmarke, at 196 emails (98%).
The path value may only be of use if it's pointing to that of a User's home directory.
If the path is a system path, it likely means the email was sent through smtp rather than using a script.

 
Back
Top