On 1/10/23 2:59 PM, Dan Mahoney via mailop wrote:
Sometimes a problem comes across your desk that you say “wait, how is this not solved yet?”.
Ya....I too have wanted something like this to enhance ~/.forward files on servers that I manage, while addressing all the problems that you're describing.
So I’ve gone down the rabbit hole, looking for various combinations of remailer scripts, forwarder scripts, group forwarder scripts, mailing list expanders, etc. And I’m coming up surprisingly short.
I'm actually not surprised that you're coming up surprisingly short.
Could I knock something together myself in perl in a half hour? Sure.
This is one of those things that you can get proof of concept code in 90 minutes.
Would it likely have its own untested edge cases for us to discover? Absolutely.
But you'll spend too much time over the next 3 days / weeks / months dealing with edge cases.
In a world of DKIM/DMarc compliance, especially, where “blow away the original headers and forward anew” is the best answer, I’m shocked to not find something like this as well.
I'm convinced that the best thing to do is to attach the incoming message as message/rfc822 MIME part.
1) Don't butcher the message that you may want redacted data from.2) Create a new message from the local source (envelope & headers) that is fully authorized and clean.
I just haven't found sufficient round-2-its to sit down and do this yet, despite the fact that I would deploy it to a bunch of systems darn near immediately.
It doesn't help that part of me wants to integrate the SMTP client into the script instead of relying on the local MTA stack / infrastructure. If I'm doing that I want to support TLS. I don't want to embed credentials to relay in a script. I don't want to deal with certificate based authentication.... AAaaaa.... EINSUFFICIENTROUND2ITS
Our needs are simple: a unix program we can pipe a message to that will preserve the original message mime portions and subject, but discard most of the previous other headers. How in 30 years of email, something that I can’t just pkg install isn’t easily findable baffles me.
Because not many people want to do this particular activity. The overlap between those that want to do so adhering to contemporary and evolving email standards is shockingly small.
If someone knows of something, let me know.
Pick your language de jure, burn a few hours, and fix problems as they come up. That's my plan anyway.
But I'm serious about the suggestion of attaching the incoming message as a message/rfc822 MIME attachment. At least unless you have a specific reason to NOT do so.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
