>> 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.

Reply via email to