When running Amazon Linux (or RHEL5/CentOS derivatives) on EC2, you'll encounter a specific hostname management issue. The instance receives a DHCP-assigned internal hostname (like ip-10-12-34-56.ec2.internal) that conflicts with proper SMTP operation since mail servers require a valid public hostname.

While setting HOSTNAME=yourdomain.com in /etc/sysconfig/network seems logical, the DHCP client overrides this during network initialization. The hostname gets reset every time the network service restarts or the instance reboots.

The cleanest approach is to modify the DHCP client configuration to preserve your chosen hostname:

# Edit the DHCP client configuration
sudo vi /etc/dhcp/dhclient.conf

# Add this line to prevent hostname updates from DHCP
send host-name "your-public-hostname.com";

# Optional: Add these lines to completely ignore DHCP hostnames
supersede host-name "your-public-hostname.com";
option host-name "your-public-hostname.com";

For systems using NetworkManager (some CentOS/RHEL variants):

# Create or edit network manager configuration
sudo vi /etc/NetworkManager/conf.d/no-hostname.conf

# Add these contents to prevent hostname changes
[main]
dhcp=dhclient
dhcp-hostname=none

After making changes, test your configuration:

# Restart networking services
sudo service network restart

# Verify the hostname persists
hostname -f

# Check syslog for DHCP interactions
sudo grep dhclient /var/log/messages

For additional assurance, set the hostname in multiple locations:

# Set immediately
sudo hostname your-public-hostname.com

# Make persistent across reboots
echo "your-public-hostname.com" | sudo tee /etc/hostname
echo "127.0.0.1 your-public-hostname.com" | sudo tee -a /etc/hosts

For mail servers, also ensure your hostname resolves properly:

# Test forward and reverse DNS
host $(hostname)
host your.elastic.ip.address

When running Amazon Linux (or RHEL5/CentOS derivatives) on EC2, you'll encounter a peculiar situation where DHCP automatically assigns an internal hostname that looks something like ip-10-0-1-1.ec2.internal. While this works for basic networking, it creates serious issues for services like Postfix/Sendmail that require a valid FQDN for proper SMTP operation.

Many administrators try setting the HOSTNAME variable in /etc/sysconfig/network, only to find the DHCP client overwrites it during network initialization. This happens because the DHCP client daemon (dhclient) actively manages hostname assignments.

# Typical /etc/sysconfig/network content
NETWORKING=yes
HOSTNAME=yourdomain.com
NOZEROCONF=yes

The cleanest approach is to modify dhclient's behavior through its configuration file:

# Create or edit /etc/dhcp/dhclient.conf
supersede host-name "mail.yourdomain.com";
prepend domain-name "yourdomain.com";

This tells dhclient to:

1. Ignore the DHCP-provided hostname (supersede)
2. Use your specified domain (prepend)

For systems where you want complete control:

# Add to /etc/dhcp/dhclient.conf
send host-name = gethostname();

This makes dhclient report the current hostname rather than accepting a new one from DHCP.

After making changes, test with:

# Release and renew DHCP lease
sudo dhclient -r eth0
sudo dhclient eth0

# Verify settings
hostname -f

For maximum reliability, combine these approaches with traditional hostname setting:

# Set hostname immediately
sudo hostname mail.yourdomain.com

# Make persistent (Amazon Linux/RHEL5)
echo "mail.yourdomain.com" > /etc/hostname

Remember to also update /etc/hosts with your FQDN:

127.0.0.1 mail.yourdomain.com mail localhost

After implementing these changes, verify your mail server configuration:

postconf -n | grep myhostname
sendmail -d0.1 -bv root

Your output should now show the proper FQDN instead of the EC2 internal hostname.