On May 4, 2020 9:45 AM, Kris Deugau <kdeu...@vianet.ca> 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.
