Wietse Venema wrote: > Jason Bailey: > > I've got notification emails from a legacy system passing through a > > Postfix install I'm using to relay messages to the proper outbound
Are the notification mails coming from an internal system? That's okay. But why are the recipients undeliverable? If it is valid and the internal system is generating a bounce message from the MAILER-DAEMON (which uses <> as the MAIL FROM address) then that is operating correctly too. Who is getting the bounce messages? That admin receiving the bounce messages should then know that something is broken and go fix it so that those notification messages can be delivered to the address of an admin designated to receive those notifications. Or those notifications should be disabled to prevent the bounces. Bounce messages internally on the LAN are okay. It's all people living in the same house. They are simply notifications. Bounce messages to the outside world to innocent 3rd parties are problematic however. > > server. Things are working great except occasionally messages are sent > > from the legacy system with a null sender address (e.g. "MAIL > > FROM: <>"). > > These are normally sent when an email address was undeliverable. To clarify a little bit... It would be an error to map <> to a non-bounce address as that would likely create conditions for an infinite loop. Loop avoidance depends upon a bounce of an address from the MAILER-DAEMON <> being dropped in order to prevent mail loops continuing infinitely. The problem description. A mail relay accepts an undeliverable message and tries to relay it onward. Can't. Generates a bounce message. Bounce messages are from MAILER-DAEMON <> by design. If *that* message, the bounce message, cannot be delivered then we don't want it to generate *another* bounce message. That would be bad. It would be infinite. Therefore if delivery from MAILER-DAEMON <> fails the message is simply discarded in order to avoid an infinite loop. In general the situation of generating bounce messages should be avoided whenever possible. Because most spam uses forged from addresses and any bounce message would become "backscatter" spam to innocent 3rd parties. They should validly report you as a spammer for generating the backscatter spam. Therefore messages from the outside world inbound to your network that are undeliverable should be rejected at SMTP time. That avoids the creation of a later bounce message and avoids the possibility of becoming a backscatter spam source. It is the spammer that is connecting at SMTP time and rejecting the message then rejects the spam at the spammer directly. > The correct fix is to configure the inbound mail relay to not accept > mail for undeliverable recipients. This is what the Postfix features > relay_recipient_maps or reject_unverified_recipient are used for. > > > Is there a way to get Postfix to replace those null sender addresses > > with a valid, predefined address before Postfix forwards the messages > > to its smart host? > > No. Fix the right problem: don't accept mail for an invalid address. For example if you must have a machine A accept mail for another internally connected machine B then on machine A one needs to have a list of every valid email address for which mail can be delivered. Let's say I have an internal system foo.example.net and it has the following valid recipients. ab...@example.net postmas...@example.net al...@example.net b...@example.net I would convert that into a relay_recipient_maps like this: ab...@example.net OK postmas...@example.net OK al...@example.net OK b...@example.net OK Then update the associated relay_recipient.foo.example.net.db file. # postmap relay_recipient.foo.example.net Then configure main.cf like this: relay_recipient_maps = hash:/etc/postfix/relay_recipient.foo.example.net Then when spammers try to send spam to mall...@example.net to the system the system looks up the address in the relay_recipient_maps to see if it is valid. If so then it would accept the message. If not, and here it is not a valid addres, then it is rejected at SMTP time. No bounce message is created. Hope that helps clarify things. Bob
