Changing root and cron ‘from’ and ‘to’ addresses

I just forgot about virtusertable and edited /etc/mail/aliases file instead, adding the lines:

webmaster:    myaccount@gmail.com
contact:      myaccount@gmail.com

then I executed newaliases and everything peachy.

Now, about proper config of the daemon to listen on 127.0.0.1 and also on any other interface editing sendmail.mc instead of sendmail.cf I've found this: http://lists.samba.org/archive/linux/2002-August/004310.html

which basically tells to simply place dnl at the front of the line which specifies the daemon options, which will make sendmail listen on all available network interfaces. e.g:

dnl DAEMON_OPTIONS('Port=smtp,Addr=127.0.0.1, Name=MTA')

of course after doing that it's necessary to rebuild the config files (m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf) and restart sendmail.

Some background

Postfix inherited some features from older sendmail like milter and aliases. The file /etc/aliases is part of aliases inheritance and implemented by alias_maps. On the other side, postfix has virtual_maps/virtual_alias_maps for handle email aliasing. So what's the difference between them?

Parameter alias_maps

• Used only for local(8) delivery

• According to address class in postfix, email will delivery by local(8) if the recipient domain names are listed in the mydestination

• The lookup input was only local parts from full email addres (e.g myuser from myuser@example.com). It discard domain parts of recipient.

• The lookup result can contains one or more of the following:

  • email address: email will forwarded to email address
  • /file/name: email will be appended to /file/name
  • |command: mail piped to the command
  • :include:/file/name: include alias from /file/name

Parameter virtual_alias_maps

• Used by virtual(5) delivery

• Always invoked first time before any other address classes. It doesn't care whether the recipient domain was listed in mydestination, virtual_mailbox_domains or other places. It will override the address/alias defined in other places.

• The lookup input has some format

  • user@domain: it will match user@domain literally

  • user: it will match user@site when site is equal to $myorigin, when site is listed in $mydestination, or when it is listed in $inet_interfaces or $proxy_interfaces. This functionality overlaps with functionality of the local aliases(5) database.

  • @domain: it will match any email intended for domain regardless of local parts

• The lookup result must be

  • valid email address
  • user without domain. Postfix will append $myorigin if append_at_myorigin set yes

Why do we need /etc/aliases when having the email inside virtual aliases map seems to override it?

As you can see above, alias_maps(/etc/aliases) has some additional features (beside forwarding) like piping to command. In contrast with virtual_alias_maps that just forwards emails.

What is the purpose of having these 2 separate aliases mapping and when do we decide when to use what?

The alias_maps drawback is that you cannot differentiate if the original recipient has root@example.com or root@example.net. Both will be mapped to root entry in alias_maps. In other words, you can define different forwarding address with virtual_alias_maps.

Why did fail2ban (which is configured to email to root@localhost) first follow email address given in alias_maps (/etc/aliases/) and later decides to ignore that once virtual_alias_maps was added?

Before virtual_alias_maps added: root@localhost was aliased by alias_maps because localhost was listed in mydestination.

After virtual_alias_maps defined: The entry root (in virtual_alias_maps) doesn't have domain parts and localhost was listed in mydestination, so it will match root me@example.com.

Why doesn't all services read email aliases mentioned in /etc/aliases and they only work when the email aliases are added in virtual alias map?

Command mail root will send email to root. Because lacks of domain parts, postfix trivial-rewrite will append myorigin to domain parts. So, mail will be send to root@myorigin.

Before virtual_alias_maps added: Unfortunately, myorigin isn't listed in mydestination, so it won't be processed by alias_maps.

After virtual_alias_maps added: The entry root (in virtual_alias_maps) doesn't have domain parts and myorigin (obviously) same as myorigin, so it will match root me@example.com.