I have sender_dependent_default_transport_maps
all set-up for virtual domains with their own IPs for outgoing mail – they work.
However when postfix's sendmail
adds an email to the queue, apparently it still passes the email through the host domain and adds a header to the email !
Received: by hostname.blah
Before passing it onto the proper virtual hostname and IP for mailing out
(note the Return-Path and sender IP is all correct in the email)
Why is postfix so stupid and passes the email through the host server despite the sender transport map?
Do I have to find another MTA ?
Is there maybe another option I can use with its sendmail
mta (I'm already using -f
)
Another way of asking this is
Can postfix's sendmail change "received: by" based on sender envelope ?
or
Can I tell postfix's sendmail where the message is coming from on the command line?
It occurs to me if postfix listens on port 25 locally I might be able to initiate from the proper virtual host IP and it might figure this out. But that is overly complex.
Best Answer
Some clarification:
In case above, postfix is just a messenger. The source of the email was program who invoking postfix sendmail binary. One of responsibility of an email messenger was stamping every email with
Received:
header every time it received email. It documented in RFC 5231 Section "Received Lines in Gatewaying".Now, when postfix sendmail binary adds an email to postfix queue, it put the email in maildrop binary without
Received
header. The one who putReceived
header was pickup daemon. When addingReceived
header, basically it tells us, "Hi, I have received email from sendmail binary userid xxx."Your
sender_dependent_default_transport_maps
will be invoked when in routing stage. Postfix won't evaluate it when receiving stage.You can always manipulated postfix header using
header_checks
feature. Taken the idea from this post: Remove sensitive information from email headers with postfix, you can use this pcre line to remove the unwated header.