Topic: Change where system emails go?

[pwarren]

Hi there.

A few of our clients already have an 'admin@domain.com' email address, that they want to keep. So, we've enabled forwarding at the upstream mail endpoint, so that 'admin@' goes to the 'accounts@' email address.

We had thought this would allow system generated emails that go to the admin user, to be sent to the local admin user, and hence get forwarded on to our techs.  This does not appear to work. In particular, smartd, sends emails to admin@domain.com which ends up at the upstream mail point, and gets forwarded to accounts@domain.com, and our techs never see it.

I've worked out that I can change the smartd email address reasonably easily:

Code: [Select]

config setprop smartd email="-m admin@domain.local"
And that appears to work properly, after restarting smartd.

But what should I be doing to make sure that all system generated emails go to admin@domain.local, rather than admin@domain.com?

[janet]

pwarren

Edit the admin user in server manager, & nominate the forwarding address.

[pwarren]

Thanks for the response Mary,

In the user page of the server manager, the admin user currently has it's forwarding address set to the 'techs' group, which includes the local IT guys, and an email account that forwards to us.

The problem appears to be that a lot of system generated emails, get delivered to admin@domain.com, rather than admin@domain.local, and aside from smartd, there does not seem to be an easy way to change that email address. For example, for raid failures and rebuilds, it looks to be hardcoded in /sbin/e-smith/mdevent, and sends to admin_raidreport@domain.com, which we get, because it's not admin@domain.com.

I'm wondering what other system messages we're not seeing, becasue they go to admin@domain.com instead of admin@domain.local.

Thanks.
Paul.

[janet]

pwarren

Change the server main domain name to domain.com. It is not good practice to use domain names styled like domain.local, that is moreso Windows server parlance, and doing so creates various issues.

Local system mail should then be delivered to admin@domain.com (or to the tech group if forwarded on).

Is there any real reason you need to use domain.local ?

Ultimately wean your users off the use of admin@.... email addresses.
They are a real spam magnet anyway and are best disabled for incoming externally sourced email messages.

You can configure procmail or mailsorting rules for the admin@domain.com account (on the sme server), and filter email messages based on topic or source (eg root@domain.com) to different end user recipients as required, either as a long term solution or temporarily until accounts@domain.com is in full (advertised) use. You could also setup a reply responder to advise senders to use the new correct accounts address during the changeover phase.