On Tue, Aug 12, 2008 at 3:23 PM, Noel Jones <[EMAIL PROTECTED]> wrote: > Jeff wrote: >> >> We have an email gateway appliance at the network edge for spam/virus >> filtering. It relays mail to multiple postfix+imap servers behind the >> firewall. The back-end servers communicate directly with each other >> for internal mail accoss our VPN. The appliance will do smtp level >> recipient verification provided that our back-end services have it >> implemented. The problem is that we have some recipient addresses >> (linux /etc/alias entries as well as Active Directory distribution >> lists) that are intended for internal use only. We do not want these >> aliases to appear as valid recipients to the outside world. >> >> So, is there a way to configure postfix to report one set of valid >> recipients to our internal mail servers and clients and report a >> subset of valid recipients to the gateway appliance? I can easily >> break the recipient lists into separate maps, I just don't know how to >> apply them based on the address of the relay or client. The internal >> interface of the gateway appliance is on the same subnet as everything >> else, but does have a static IP address that could be used to identify >> it. >> >> # postconf -n >> alias_database = hash:/etc/aliases >> alias_maps = hash:/etc/aliases >> command_directory = /usr/sbin >> config_directory = /etc/postfix >> daemon_directory = /usr/libexec/postfix >> debug_peer_level = 2 >> inet_interfaces = $myhostname, localhost >> local_destination_concurrency_limit = 5 >> local_destination_recipient_limit = 300 >> local_recipient_maps = $alias_maps, ldap:/etc/postfix/ldap-users.cf, >> ldap:/etc/postfix/ldap-aliases.cf >> mail_owner = postfix >> mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp >> mailq_path = /usr/bin/mailq.postfix >> manpage_directory = /usr/share/man >> mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain >> mynetworks = 192.168.0.0/16, 127.0.0.0/8 >> myorigin = $mydomain >> newaliases_path = /usr/bin/newaliases.postfix >> queue_directory = /var/spool/postfix >> readme_directory = /usr/share/doc/packages/postfix/README_FILES >> sample_directory = /usr/share/doc/packages/postfix/samples >> sendmail_path = /usr/sbin/sendmail.postfix >> setgid_group = postdrop >> smtpd_recipient_restrictions = permit_mynetworks, >> reject_unauth_destination, reject_unverified_recipient >> transport_maps = hash:/etc/postfix/transport >> unknown_local_recipient_reject_code = 550 >> >> The ldap-alias.cf and ldap-users.cf are lookups for Active Directory >> distribution lists and real users. >> > > > If all your internal clients are listed in mynetworks you can just create a > recipient blacklist and reject mail to those addresses when it arrives from > outside. > > # main.cf > smtpd_recipient_restrictions = > permit_mynetworks > reject_unauth_destination > check_recipient_access > hash:/etc/postfix/recipients > reject_unverified_recipient > > # recipients > internal-example.com REJECT restricted recipient > > For this to work, you may need to remove your gateway appliance from > mynetworks: > # main.cf > mynetworks = !ip.of.gate.way 192.168.0.0/16 127.0.0.0/8
It took me a while before I could test this. The recommended solution succeeds at blocking the specified aliases when relayed through our gateway, but it does not do so at the SMTP level. It generates bounce notifications, which in the end will create back-scatter. The bounce message I got in testing gave an error code of 554. Some additional background: Our gateway appliance acts as a proxy for recipient verification. When the gateway wants to test for a valid recipient, it opens an SMTP connection to the appropriate back-end server and pretends to send a mail to the recipient from [EMAIL PROTECTED] If it get's a 550 from the back-end, it returns 550 to the sending MTA. So it seems that when it receives a 554 from the internal server as it did in this case, the gateway creates a bounce message instead of immediately notifying the external MTA of the failure. Can I tweak this so that the map in check_recipient_access returns 550 instead of 554? -- Jeff
