Postfix: sending email copies of all incoming and outgoing mails to another domain or account

How to send an BCC copy of every incoming and outgoing email to another account? This is fairly simple to do with postfix. First open you main.cf and add or edit following lines:

# vim /etc/postfix/main.cf

now add these two lines:

sender_bcc_maps = regexp:/etc/postfix/archive_domain
recipient_bcc_maps = regexp:/etc/postfix/archive_domain

just a small explanation:

sender_bcc_maps is a regex based text file containing the mapping for outgoing mail
recipient_bcc_maps is a regex based text file containing the mappings for incoming mail

and here is an example line in the archive_domain file:

/^([^@]+)\@example\.com$/    $1@archive.example.com

the above line explained: every user @example.com will have a BCC copy send to that user @archive.example.com

 

Setting Apache2.2 prefork settings correctly

Apache's memory consumption is regulated by the spawned server processes and can easily consume all of your servers memory. If the prefork-module is used following paramters needs to be configured in your httpd.conf:

StartServers          18
MinSpareServers       3
MaxSpareServers       6
ServerLimit           60
MaxClients            60
MaxRequestsPerChild   4000

Now to get this parameters right use the following script to determine the actual memory consumption of one apache child process:

​pgrep httpd | xargs -n1 -I{} cat /proc/{}/smaps | awk '{if ($0 ~ /stack/) {pids+=1} else if ($0 ~/^Shared_/) {shared+=$2} else if ($0 ~ /^Pss:/) {priv+=$2}} END {printf "%.2f MB\n",(priv+shared/(pids*pids))/1024}'

Now to get MaxClients simply take the amount you want to give to apache and divide it with the consumption of one process, depending on the actual load the results may vary. Typically one process took between 30MB and 50MB. The above mentioned configuration is set for 3GB RAM (3*1024MB). Here a thumbrule:

StartServers          = 30% of MaxClients
MinSpareServers       = 5% of MaxClients
MaxSpareServers       = 10% of MaxClients
ServerLimit           = MaxClients
MaxClients            = total memory / one process memory (round down to be safe)
MaxRequestsPerChild   4000

Enabling Jumbo Frames on ESXi

The default maximum size for data transmission on Ethernet is 1500 bytes for legacy compatibility reasons, unfortunately for newer high-speed networks breaking up data into 1500 byte chunks called frames creates too much overhead and prevents one from utilizing the full capabilities of the network hardware.  For example on a 10Gbit link you are only able to transmit about 3-4Gbit of data between machines using 1500 byte frames due to the overhead of processing so many small frames of data while we were able to easily saturate 10Gbit when using jumbo frames. Modern full-featured network equipment can transmit larger frame sizes if configured to do so, usually up to 9000 bytes, allowing for full utilization of the available resources.  Jumbo frames are usually only used in a controlled and segmented environment, for example an iSCSI SAN, as they can cause additional overhead from the need for packet fragmentation at the point when converting between a 9000 byte frame network and a standard 1500 byte frame network.

Configuring Jumbo Frames on an ESX VM server

Support for jumbo frames is included in ESX and ESXi but is not exposed in the GUI for the default vSwitch implementation, in addition remote configuration for vSwitches is not enabled on ESXi using the free license from the API using PowerCLI or VMware CLI.

Example for vSwitch:

esxcfg-vswitch --list
esxcfg-vswitch --mtu 9000 vSwitch0

Example for VMkernel interface (for vMotion or iSCSI):

esxcfg-vmknic --list
esxcfg-vmknic --mtu 9000 "VMkernel Portgroup Name"

Note:  When configuring a VMkernel interface for Jumbo Frames make sure that the underlying vSwitch is also configured for Jumbo Frames.

Configuring Jumbo Frames on ESX VM guest

The default emulated Intel E1000 network device presented to guests in VMware ESX does not support Jumbo Frames, one must install VMware Tools and enable a VMXNET3 interface to take advantage.

Source: https://kb.wisc.edu/ns/page.php?id=17243