I've been doing something similar for a good long time.
Blogged about it here:
https://www.spamresource.com/2015/12/mail-forwarding-in-dmarc-world.html
The current version of my forwarding script rewrites the from address,
disables the authentication headers (re-authenticating the message
anew upon sending), rewrites the message ID (which I found to be very
handy if you want to re-forward the same message more than once,
either in testing or in real life) and I usually drop the original
sender's address both into a hidden x-header and the reply-to header.

Cheers,
Al Iverson

On Wed, Jan 11, 2023 at 2:53 AM Hans-Martin Mosner via mailop
<[email protected]> wrote:
>
> I've written something like that a while ago. It's in Rust, it's probably too 
> specialized and restricted for general use, but it does mostly what you 
> describe (in addition, it keeps sender addresses secret becaue I've 
> encountered too many cases of hacked e-mail accounts where address books have 
> been exfiltated).
> I chose Rust because, well, I'm doing much of my side project hacking in Rust 
> nowadays, and it creates stand-alone binaries which simplifies deployment on 
> arbitrary Linux servers. The data is held in a simple sqlite database, and 
> the binary serves both as the actual forwarding filter as well as database 
> management tool, so it's somewhat scriptable.
> I could clean it up a bit and put int into my github account, but as I said, 
> it's probably not general enough and would need some polishing before being 
> ready for public consumption.
>
> Cheers,
> Hans-Martin
>
> 10. Januar 2023 22:59, "Dan Mahoney via mailop" <[email protected]> schrieb:
>
> > All,
> >
> > Sometimes a problem comes across your desk that you say “wait, how is this 
> > not solved yet?”.
> >
> > At the day job, we have a contact list for our customers that comes from 
> > our ticket system, and
> > it’s stuffed into an alias file with :include:.
> >
> > The way postfix handles these aliases, is that it preserves the original 
> > envelope sender and
> > recipient (which we don’t want anyway), and o365 is rejecting on that 
> > envelope sender/recipient
> > (that it’s not allowed to deliver to our internal envelope recipient, which 
> > is not unreasonable,
> > but still surprising we haven’t hit it before.
> >
> > The obvious answer is: “Don’t use the :include: mechanism, just use a 
> > mailing list manager.” Which,
> > for one alias in a system, feels like overkill. I don’t need membership 
> > management. I don’t need
> > archiving. I don’t need bounce detection.
> >
> > 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.
> >
> > Could I knock something together myself in perl in a half hour? Sure.
> >
> > Would it likely have its own untested edge cases for us to discover? 
> > Absolutely.
> >
> > 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.
> >
> > 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.
> >
> > If someone knows of something, let me know.
> >
> > -Dan
> > _______________________________________________
> > mailop mailing list
> > [email protected]
> > https://list.mailop.org/listinfo/mailop
> _______________________________________________
> mailop mailing list
> [email protected]
> https://list.mailop.org/listinfo/mailop



-- 

Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop

Reply via email to