On 1/11/23 3:39 AM, Jaroslaw Rafa via mailop wrote:
Why?Your script will run as a part of existing mail flow anyway, within an existing MTA. Making use of this existing MTA seems to be the logical choice, instead of trying to replicate its function yourself.
Consider a scenario where the local MTA is rather ... limited or an environment where the local MTAs don't have an SMTP route out to the world. So messages piped into STDIN of sendmail (either proper name or wrapper) don't make it out to the world.
In short, there are times when I want to send the message directly to the receiving MTA / infrastructure with as little interaction with the sending MTA / infrastructure as possible. Independent of hat color.
For me it's like trying to not rely on OS's file system, but implement a filesystem on your own and making direct writes/reads to disk blocks...
I think it's a bit different and more nuanced than that. Consider a brain dead installation that only knows how to deliver messages locally, possibly even with localhost.localdomain domain parts.
IMHO there is a reasonable chance that more needs to be configured correctly both on the system and out on the Internet for receiving email servers to accept messages.
I feel like there are times when bypassing the local MTA stack / infrastructure has advantages.
Another way to think about it is if the ~/.forward wrapper was gatewaying message into another non-SMTP protocol. Would the "Why?" question be any different if I wanted to push the message from STDIN into something MQueue? It seems to me like the client portion of the output side would quite likely be independent of the local system's MTA stack / infrastructure.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
