Postfix Internal SMTP Relay for Device Alerts - 夜莺博客

Postfix Internal SMTP Relay for Device Alerts

Half of the infrastructure that needs to send mail cannot do authenticated SMTP over TLS: switches emit SYSLOG-style alerts, UPS cards send plain SMTP with no credentials, and monitoring servers just want a local MTA. The clean answer is a small Postfix instance that accepts mail only from trusted internal addresses and hands it to one smarthost. This guide is the configuration that stays an internal relay -- and does not become an open relay.

Install and the directives that matter

sudo apt-get install postfix mailutils
# /etc/postfix/main.cf
myhostname = relay1.corp.local
myorigin   = $myhostname
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost

# who may relay (must be an explicit list you control)
mynetworks_style = host
mynetworks = 127.0.0.0/8, 10.20.0.0/24, 10.30.40.0/24

# never accept mail for arbitrary internet domains
relay_domains =

# everything goes out through the corporate smarthost
relayhost = [smtp.corp.local]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

smtpd_relay_restrictions = permit_mynetworks, reject

mynetworks_style = host is deliberate: it stops Postfix from treating every directly connected subnet as trusted. Each monitoring VLAN or device range is then listed explicitly. Setting relay_domains = empty means the server will never forward mail for a domain it does not own, which removes the classic abuse path.

Credentials and mail host mapping

echo '[smtp.corp.local]:587 relayuser:relaypassword' | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo systemctl restart postfix

If the smarthost only accepts a specific envelope sender, add smtp_generic_maps or set an explicit sender for each alert source rather than rewriting everything to a single address -- receivers and SPF both care.

Test from a device's point of view

# from the relay itself
echo "relay test" | mail -s "postfix relay test" admin@example.com

# from an alert source, simulating a device with no auth/TLS
sendmail -S relay1.corp.local admin@example.com <<EOF
Subject: SNMP trap test
linkDown on core-sw1 Gi1/0/24
EOF

# watch the transaction
sudo tail -f /var/log/mail.log

A healthy trace shows the message reaching relay=smtp.corp.local[] and getting a 250 response. Repeated "Relay access denied" means the source address is not in mynetworks.

Hygiene checklist

  • Verify you are not an open relay: postconf -n | grep -i mynetworks should list your ranges only, and smtpd_relay_restrictions must end in reject.
  • Rate-limit noisy senders so a flapping link cannot flood the helpdesk: smtpd_client_message_rate_limit and anvil_rate_time_unit.
  • Log rotation and retention for /var/log/mail.log; alert delivery failures are themselves worth monitoring.
  • Keep device alert policies narrow. Device-side filters, such as Cisco EEM Applets: Automate with event syslog Triggers, reduce the flood before it reaches the relay, and the trap severity design in Zabbix SNMP Switch Monitoring with LLD decides what is worth an email at all.

原文链接:https://www.postfix.org/BASIC_CONFIGURATION_README.html