Re: [mailop] Simple mailing list expander program for aliases files?

[Slavko via mailop]

Dňa 26. januára 2023 12:11:50 UTC používateľ Florian Vierke via mailop 
 napísal:

>If you implement DMARC as a recipient, you must check for DKIM and for SPF, 
>exactly because one of them is sufficient to pass. If you do only check SPF as 
>a receiver and the sender is authenticating via DKIM, an SPF fail would 
>directly lead to a DMARC fail, which isn't correct.

My understanding is the same, in other words (excluding align
for now):

+ standalone SPF pass is enough for DMARC pass
+ standalone SPF not pass is not enough for DMARC fail

The same for DKIM.

Thus if one doesn't do DKIM verify (and does only SPF), it **can**
result in DMARC pass, but not DMARC fail, and DMARC hasn't other
states, only pass or fail (apply policy)...

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[Adam D. Barratt via mailop]

On Thu, 2023-01-26 at 12:11 +, Florian Vierke via mailop wrote:
> I have understood it that way:
> 
> If you implement DMARC as a recipient, you must check for DKIM and
> for SPF, exactly because one of them is sufficient to pass. If you do
> only check SPF as a receiver and the sender is authenticating via
> DKIM, an SPF fail would directly lead to a DMARC fail, which isn't
> correct.
> 

Sure, but you don't appear to be disagreeing with my point. :-) The
poster I was replying to was arguing about policy decisions from
*senders*, not recipients.

As the recipient, you must check both but be prepared to accept the
mail if SPF passes and there is no (or no valid) DKIM signature
attached to the mail - i.e. it is perfectly valid for a sender to
publish a DMARC policy and an SPF record but not DKIM-sign their mails.

Regards,

Adam

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[Christof Meerwald via mailop]

On Thu, Jan 26, 2023 at 08:25:20AM +, Gellner, Oliver via mailop wrote:
> So to get back to the question of Jason, I wouldn't call it luck. Your 
> mailing lists work as designed and will continue to work. Other mailing lists 
> just rewrite the From headers because they like to compose new messages based 
> on the content of the original message, so they cannot keep the original From 
> headers.

At least exim seems to sign (non-existent) List headers by default, so
adding List headers would break those DKIM signatures.


Christof

-- 

https://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org   xmpp:cmeerw at cmeerw.org
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[Gellner, Oliver via mailop]

On 2023-01-26 00:09, John Levine via mailop wrote:

> It appears that jmurray--- via mailop  said:
>>So what I'm hearing is "luck". Perhaps I should revisit the policy.
>>Didn't even realize DMARC with no DKIM was a thing at this point. Thank
>>you.

> Most of the SPF-only DMARC I see is from government agencies who get a
> command from above to do DMARC and do it the cheapest quickest way
> they can, by publishing SPF and DMARC records and doing nothing else.
> I used to host the mail for my local town government and was having trouble
> losing fairly important mail from the US Census bureau that was SPF-only.

A domain with a DMARC enforcement policy but no DKIM signing will have various 
delivery problems anyway, completely independent of mailing lists. All auto 
responders and NDRs will fail authentication, as well as each and every 
forwarded email. When looking at past DMARC reports, a small percentage of 
messages may also fail either SPF or DKIM authentication due to DNS timeouts or 
other temporary problems, so if you only set up one of them from the beginning, 
you risk that a small amount of your messages will bounce or end up in the spam 
quarantine over and over again.

I cannot remember a sender domain that only deployed SPF and DMARC but not 
DKIM, but then again we do not communicate with US government agencies.

So to get back to the question of Jason, I wouldn't call it luck. Your mailing 
lists work as designed and will continue to work. Other mailing lists just 
rewrite the From headers because they like to compose new messages based on the 
content of the original message, so they cannot keep the original From headers.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[John Levine via mailop]

It appears that jmurray--- via mailop  said:
>> Do you add subject tags or list footers?  If you just pass messages through 
>> without
>> changing them, it's only slightly surprising that DMARC aligns.  But most 
>> lists
>> change the messages which make the aligned DKIM signature fail.
>
>Nope, I'm staunchly agin it. 

OK, but let's just say that's a minority position in mailing lists in general.

>This is a limited community, mostly gov't and uni traffic, with a few
>freemails here and there. 
>
>So what I'm hearing is "luck". Perhaps I should revisit the policy.
>Didn't even realize DMARC with no DKIM was a thing at this point. Thank
>you.

Most of the SPF-only DMARC I see is from government agencies who get a
command from above to do DMARC and do it the cheapest quickest way
they can, by publishing SPF and DMARC records and doing nothing else.
I used to host the mail for my local town government and was having
trouble losing fairly important mail from the US Census bureau that was
SPF-only.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[John Levine via mailop]

It appears that Slavko via mailop  said:
>Dňa 25. januára 2023 20:52:39 UTC používateľ John Levine via mailop 
> napísal:
>
>>A certain number of domains assert a DMARC policy but only use SPF, no
>>DKIM signatures, so you'd expect them to fail alignment. That's the
>>slightly surprising part.
>
>That cannot be named DMARC, as it is SPF **or** DKIM based.
>That even cannot be named SPF, as SPF is based on MAIL FROM
>domain.

This might be a good time to reread RFC 7489 and learn how DMARC actually works.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[Slavko via mailop]

Dňa 25. januára 2023 20:52:39 UTC používateľ John Levine via mailop 
 napísal:

>A certain number of domains assert a DMARC policy but only use SPF, no
>DKIM signatures, so you'd expect them to fail alignment. That's the
>slightly surprising part.

That cannot be named DMARC, as it is SPF **or** DKIM based.
That even cannot be named SPF, as SPF is based on MAIL FROM
domain.

In better case they do own filtering rules on "my server, my rules"
base. In worst case, they do not understand standards and breaks
interoperability.

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[jmurray--- via mailop]

* John Levine via mailop  [230125 15:54]:
> It appears that Jason Murray via mailop  said:
> >We process DMARC reports on the daily, and have never had an email from our 
> >lists fail alignment except in a couple of cases where we had blocked DNS 
> >queries
> >coming from destination domains' resolvers (oops).
> >
> >Is this just wild luck? Are we an anomaly, or an accident waiting to happen? 
> 
> Do you add subject tags or list footers?  If you just pass messages through 
> without
> changing them, it's only slightly surprising that DMARC aligns.  But most 
> lists
> change the messages which make the aligned DKIM signature fail.

Nope, I'm staunchly agin it. 

> 
> A certain number of domains assert a DMARC policy but only use SPF, no
> DKIM signatures, so you'd expect them to fail alignment. That's the
> slightly surprising part.

This is a limited community, mostly gov't and uni traffic, with a few
freemails here and there. 

So what I'm hearing is "luck". Perhaps I should revisit the policy.
Didn't even realize DMARC with no DKIM was a thing at this point. Thank
you.

> 
> R's,
> John
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[John Levine via mailop]

It appears that Jason Murray via mailop  said:
>We process DMARC reports on the daily, and have never had an email from our 
>lists fail alignment except in a couple of cases where we had blocked DNS 
>queries
>coming from destination domains' resolvers (oops).
>
>Is this just wild luck? Are we an anomaly, or an accident waiting to happen? 

Do you add subject tags or list footers?  If you just pass messages through 
without
changing them, it's only slightly surprising that DMARC aligns.  But most lists
change the messages which make the aligned DKIM signature fail.

A certain number of domains assert a DMARC policy but only use SPF, no
DKIM signatures, so you'd expect them to fail alignment. That's the
slightly surprising part.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[Jason Murray via mailop]

* Dan Mahoney via mailop  [230110 17:18]:
> 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.
> 

The more often I see this stated the more I feel as if I live in bizarro land. 
We are a very small operation, but we do run several chatty mailing lists, each 
with a few thousand users on a few hundred domains, mostly limited to 
subscribers who are part of one weird little professional community.

Our list software of course provides the return path, and we over-sign DKIM, we 
do add List-* headers, but we don't touch From, Subject, or the body.

We process DMARC reports on the daily, and have never had an email from our 
lists fail alignment except in a couple of cases where we had blocked DNS 
queries coming from destination domains' resolvers (oops).

Is this just wild luck? Are we an anomaly, or an accident waiting to happen? 

Warmest regards,

J
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[Ángel via mailop]

On 2023-01-10 at 13:59 -0800, Dan Mahoney wrote:
> 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.

Postfix is keeping the alias as envelope recipient?? Or just in the To:
header?

I think O365 is simply seeing that the sender is a mail it should be
handling itself but the mail comes from outside and rejects it.

I'm sure it's possible to configure it to allow that. I don't know how
to do that, though. Marking the sender and external and the postfix IP
as trusted, probably.

Regards




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[Grant Taylor via mailop]

On 1/11/23 3:39 AM, Jaroslaw Rafa via mailop wrote:

Why?


Another primary use case I have is a company owner moved a system from 
the office to their house as they moved states and the new ISP filters 
destination TCP port 25.  So having something in the mail wrapper being 
able to communicate directly to the central server bypasses many such 
restrictions.


It's sort of the MTA vs MSA type solution.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[Grant Taylor via mailop]

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
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[Al Iverson via mailop]

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
 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"  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
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
> ___
> mailop mailing list
> mailop@mailop.org
> 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
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[Jaroslaw Rafa via mailop]

Dnia 10.01.2023 o godz. 22:40:56 Grant Taylor via mailop pisze:
> 
> 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.

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.

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...
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[Grant Taylor via mailop]

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  AA  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

Re: [mailop] Simple mailing list expander program for aliases files?

[Simon Lyall via mailop]

I remember thining about this about 6 months ago and looking around for a 
solution. I think I was even going to put it in my "fun projects I could do" list.


Best I could find was:

https://github.com/zoni/postforward

but I didn't test it out.


On Tue, 10 Jan 2023, Dan Mahoney via mailop wrote:

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
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


--
Simon Lyall  |  Very Busy  |  Web: http://www.simonlyall.com/
"To stay awake all night adds a day to your life" - Stilgar
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Simple mailing list expander program for aliases files?

[Dan Mahoney via mailop]

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
mailop@mailop.org
https://list.mailop.org/listinfo/mailop