|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: rc (nospam+rcassel
sinderman.com)
Date: Thu Oct 02 2008 - 01:56:31 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>> 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
> > some1
user.com sevenbit:[my.relayhost]
> > some2
user.com sevenbit:[my.relayhost]
> > some3
user.com sevenbit:[my.relayhost]
> > some4
user.com 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.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]