Configuration of mail server to relay emails

Question

This is part of a project wherein I have to send mail...

I have a mail-server with domain abc.com. How do I allow that mail-server to receive mail from another domain, cde.com?

And how do I transfer all mail to the root user?

For the first question, I think I need the mail-server configured in open relay.
Using postfix, the default configuration is for open relay...right?

Solution 1

No. As default postfix is not configure as an open relay, it will only accept local mail.

And you don't want to configure it as an Open Relay. In a couple of days some spammer is going to find it and start using it. As a result:

• Your computer is going to be bogged down sending thousands of emails.
• Your server is going to be blocked by most other mail servers in the world in a couple of days. Including all the major ones (gmail, yahoo, hotmail, mines ;)).

So you will be unable to send mails and the internet will a little worse for the rest of us.

If you want to be able to send mail from some IPs without authentication you need to set (or add) this options in /etc/postfix/main.cf

mynetworks = 127.0.0.0/8, 192.168.1.0/24
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

Of course the IP that defines mynetwork should be changed to one that fits you.

Solution 2

Main should never be delivered to the root account. Normally there is an alias for root in /etc/aliases to deliver the email to the another account. If you have a limited number of accounts you need to consolidate, the easiest way is to add entries to /etc/aliases. This can be configured to send the email to an address on another server if desired.

To send email configure your mailserver to use a Smarthost. I generally recommend using your ISPs relay server. If all your mail will be going to one domain, you may be able to use that domain's MX (mail exchange) as your Smarthost. You can verify delivery by looking at /var/log/mail.log (or wherever postfix logs its messages).

If you want to reliably send email directly to the Internet, get a static address. See email delivery management grievances for some guidance.

Reliable incoming mail delivery requires a static IP address. There are programs to fetch mail from another server such as fetchmail that work well when mail is delivered to another server.

If you mail server is MX for abc.com it will be able to accept mail for its domain without being an open relay. Configuring an open relay is not a good idea.

I would recommend you use a name like mail.abc.com or even www.abc.com for your mail server rather than abc.com. It will be able to send mail for abc.com. It is a good idea to configure it as an MX for abc.comif it is doing so. Second level domains are rarely used by legitimate mail servers.

Comments

[Vinod K]

actually this mail server is local...i want to send mail and just show tht these mail were received by the mail server...

[Javier Rivera]

Added some info about how to enable it to relay mail from the local network.

[Vinod K]

how do i let all mails whether any user come to 1 account....the root account

[Javier Rivera]

It's better for future reference and easy of use of the site if you ask this in a different question not in a comment. But for a quick answer, adding to the virtual file @domain.com root should do the trick.

[belacqua]

There are sometimes policy reasons to leave mail in a particular account/mail spool/directory. These may or may not be good reasons, but I'm reluctant to endorse the idea that mail should 'never' be delivered to root. I agree with everything else you're saying, and it is great to show the usual mechanism (/etc/aliases) for redirecting root's mail. This is probably what the OP (and almost everyone else) should be doing.

[BillThor]

@jgbelacqua The reason mail should never be delivered to mail is security. Anything executable that is delivered to root runs the risk of totally compromising the system. Any policy stating that mail must be delivered to root is asking for a system compromise.

[belacqua]

I'm not disagreeing that it's (almost always) a bad idea. If you are the administrator, it almost certainly is. In the case where I saw this, there was a separate (internal) security group which set policy. One group controlled the server, a third group administered the network-attached storage to which the mail was directed. Mail was managed by a fourth group. (And this is simplifying things.) In this case, the infosec group wanted to be able to obfuscate who had access to what (e.g., admin mail). It was also heavily filtered by the time it reached the inbox. C'est la vie.

[belacqua]

And that's my upvote, by the way. :)

[BillThor]

@jgbelaxqua: Thanks. Nothing like management by committees. I've managed to get executable software mailed out of heavily a filtered system. (Really needed the patch.) Wonder if I could have got it back in?