Re: Replace null sender addresses?
Kris Deugau: > To my reading of Jason's first message, the widget/appliance/app that's > generating the original emails is, in and of itself, (mis)using the null > sender on (some of) its own original messages, because Reasons. > > Jason wants to take those messages, and overwrite a correct envelope > sender address onto them. In that case, you may be able to get away with /etc/postfix/main.cf: smtpd_command_filter = pcre:/etc/postfix/command_filter /etc/postfix/command_filter: # Don't lose command parameters. /^MAIL FROM:<>(.*)/ MAIL FROM:$1 http://www.postfix.org/postconf.5.html#smtpd_command_filter But this changes the sender for real bounces, too. If you need a be more selective solution, like only do this for specific SMTP clients, a Milter coukld do it (in Python, Perl, ...). Wietse
Re: Replace null sender addresses?
On May 4, 2020 9:45 AM, Kris Deugau wrote: Bob Proulx wrote: > Jason Bailey wrote: >> 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. > > "some email providers"? That makes it sound like you are generating > bounces to random places on the net. That makes it sound like you > have an open relay problem. > >> 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. > > Your description is too vague to be useful. Details, or it didn't > happen. > >> 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. > > Bounce messages from the MAILER-DAEMON using <> *are* standards > compliant. That isn't the problem. It is definitely not the first > problem to be solved. The first problem to be solved is to debug and > fix why you are generating those bounce messages. To my reading of Jason's first message, the widget/appliance/app that's generating the original emails is, in and of itself, (mis)using the null sender on (some of) its own original messages, because Reasons. Jason wants to take those messages, and overwrite a correct envelope sender address onto them. -kgd Correct. It is part of our voice offerings and this particular vendor isn't being very helpful. In all fairness I think they are just short staffed and doing the best that they can. I can certainly sympathize, but that doesn't exactly help my situation not does it help our customers. These messages may look like bounce backs given the null sender address, but they're not. They leave our network as notification emails. Some types are valid and are delivered without issue. These, unfortunately, are hit and miss. Some email providers accept them but others do not. Anyone who has managed a mail system for any length of time knows that any outbound mail that is full of bogus sender info (invalid fqdn comes to mind) is likely the be flagged as spam at a minimum or even dropped. A missing sender's address can look pretty bogus too depending on who or what is doing the looking. Naturally I'd prefer to see the vendor fix the problem on their end (especially since we can't -- their tac has to), but until then I'm simply trying to mitigate the problem. We all know Postfix is a powerful and flexible tool and indeed I've used it to correct other mail issues in the past when necessity warranted it. Jason *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.
Re: Replace null sender addresses?
Bob Proulx wrote: Jason Bailey wrote: 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. "some email providers"? That makes it sound like you are generating bounces to random places on the net. That makes it sound like you have an open relay problem. 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. Your description is too vague to be useful. Details, or it didn't happen. 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. Bounce messages from the MAILER-DAEMON using <> *are* standards compliant. That isn't the problem. It is definitely not the first problem to be solved. The first problem to be solved is to debug and fix why you are generating those bounce messages. To my reading of Jason's first message, the widget/appliance/app that's generating the original emails is, in and of itself, (mis)using the null sender on (some of) its own original messages, because Reasons. Jason wants to take those messages, and overwrite a correct envelope sender address onto them. -kgd
Re: Replace null sender addresses?
RFC 7208, Sender Policy Framework (SPF) section 2.4 has a nice summary in paragraph 2: [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in [RFC5321]). In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document defines the "MAIL FROM" identity to be the mailbox composed of the local-part "postmaster" and the "HELO" identity (which might or might not have been checked separately before). I agree with the general consensus that such messages should be delivered locally or within the "family". If you're getting e.g. undeliverable messages from the wild internet and sending out postmaster notifications in response, rethink the externalities (or find someone who can) or expect a lot of your mail to be undeliverable in practice. -- Fred Morris
Re: Replace null sender addresses?
Hello Jason, I do not know why but you sent out three copies of my email message in full unquoted as a reply. And then in between the 2nd and 3rd copies you wrote your own response. That made the message rather unreadable. Please in the future double check the message before hitting send. Jason Bailey wrote: > 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. "some email providers"? That makes it sound like you are generating bounces to random places on the net. That makes it sound like you have an open relay problem. > 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. Your description is too vague to be useful. Details, or it didn't happen. > 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. Bounce messages from the MAILER-DAEMON using <> *are* standards compliant. That isn't the problem. It is definitely not the first problem to be solved. The first problem to be solved is to debug and fix why you are generating those bounce messages. > 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. I am glad you are happy with the first set. That's great. That second set you as you have described them so far match the description of a bounce message. Bounce messages will contain a body part with the original message. And there will be an explanation of the action which generated it. Reading those messages will say what is happening. It is also possible, and perhaps even likely given what we know now, that you have a system that is an open relay and has been found by spammers who are exploiting it. Spammers often use forged from addresses. Which if so would explain why you are getting rejects from those email providers. Bob
Re: Replace null sender addresses?
On May 1, 2020 8:13 PM, Bob Proulx 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 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
Re: Replace null sender addresses?
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
Re: Replace null sender addresses?
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 > 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. 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. Wietse
