On May 1, 2020 8:13 PM, Bob Proulx <b...@proulx.com> wrote: 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 On May 1, 2020 8:13 PM, Bob Proulx <b...@proulx.com> wrote: 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 It is indeed being generated internally. The RCPT TO is there, but because it lacks a MAIL FROM, we are seeing some email providers drop the message, presumably because it looks like UCE/spam. We are trying to get the manufacturer of the system to acknowledge the problem and address it, but they're currently insisting there's no problem. In the mean time I've got important emails that aren't getting delivered. I was hoping to get Postfix to fill it in so that the resulting email traversing the public Internet was standards compliant and less likely to get filtered by someone else's UCE solution. To be clear, this system sends out two sets of email. The first includes all the proper headers and is not an issue. The second set is missing the MAIL FROM all together. JB On May 1, 2020 8:13 PM, Bob Proulx <b...@proulx.com> wrote: 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 *Confidentiality Notice* This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this email message is strictly prohibited. If you have received this email in error, please immediately notify the sender and delete this email message from your computer.
