>> It is working now. I fixed the header externally with formail (can't >> Postfix do that without external help?) > > It's the job of MUAs, mail applications, etc. to inject correctly > formatted mail into the email infrastructure. It's not the job of > an MTA to make arbitary content standards-compliant.
I know I am not using Postfix (in this specific machine) as originally intended by its developers (to be an MTA), but I found it is an appropriate tool (to be an email converter from non compliant to compliant) in my situation since I have an application (black box) injecting mime-less emails into my email infrastructure. I have no problems using Postfix and an external filter (formail), but I imagine a more efficient solution would have been to let Postfix add those headers itself (a feature Postfix has) and on a second pass behave like a normal MTA. > > #transport > > [EMAIL PROTECTED] sevenbit:[my.relayhost] > > [EMAIL PROTECTED] sevenbit:[my.relayhost] > > [EMAIL PROTECTED] sevenbit:[my.relayhost] > > [EMAIL PROTECTED] sevenbit:[my.relayhost] > I recommend that you run ALL mail FROM this application through > the filter so that it is always MIME compliant. Yes, that is exactly what I am doing on the first pass with formail. This transport is only used on the second pass to convert to 7 bit only email to certain destinations (the infamous Exchange 5 bug) There is no way then to remove :[my.relayhost] from these entries and let it use the one configured in main.cf? Thanks, RC.