Quoting Simon Hobson (linux@???):

> Correction noted.

I truly appreciate your hearing it in the spirit intended. Thank you,
Simon. (We'll want to wind this up soon, as it has little to do with
Devuan, and discussion has veered away from Dng's adoption of Mailman
DMARC-mitigation munging starting 2018-12-06.)

> However, in my defence my issues (which I no longer have to deal with)
> were with mail forwarding in servers rather than mailing lists (IIRC
> our mailing list hosting had dwindled to just a couple of announce
> lists before the problem raised it's head) - so a different set of
> related issues which was primarily SPF at the time. I did get as far
> as having a look at SRS - but unfortunately the plugin for Postfix was
> incompatible with the greylisting I used due to the order of
> operations which prevented whitelisting of "known" greylisting
> triplets.

I think I know/remember a little bit about this.

Not all forwarding is alike. MLM (mailing list manager) forwarding, the
operation where the MLM retransmits a received post to each subscriber,
involves writing an entirely new SMTP envelope on the outgoing
subscriber copies. Other forwarding mechanisms such as /etc/aliases and
~/.forward entries do _not_. Those just hurl the received message back
out with envelope unchanged. (SRS was a kludge proposed for non-MLM
forwarders on account of this difference to help them preserve SPF
validity, a matter I'll return to shortly.).

Back in the day, I gave out /etc/aliases entries to friends that
leveraged the 'mafia' theme of my linuxmafia.com domain, e.g.,
'capo@???' reaches Chris di Bona, then a co-worker at VA
Linux Systems and now Linux Community Manager at Google.
'don@???' was a natural fit as an alias for _Linux Journal_
editor Don Marti's personal mailbox dmarti@???. And so on.
However, following wide adoption of aggressive hardfail SPF policies,
those and all other cross-domain /etc/aliases entries more-or-less broke
(well, became selectively unreliable, depending on the sending domain),
because any mail transiting the alias would arrive at the other-domain
end-destination unable to pass SPF scrutiny for the claimed sending
domain, which in turn was because my MTA at linuxmafia.com wasn't in the
sending domain's SPF-published list of authorised sending IPs.

SRS (sender rewriting scheme) was SPF creator Meng Wong's kludge for
salvaging /etc/alias and ~/.forward (when used cross-domain) from
unintended collateral SPF damage. Wong provided a Perl wrapper script
to rewrite the SMTP envelope on the outbound copy, emulating what MLMs
do.

At the time, I couldn't be bothered reimplementing all of those
cross-domain /etc/aliases entries using an SRS wrapper, so they have
simply become not-very-reliable reflectors, and what I tell users is
'/etc/aliases and ~/.forward are no longer best practices for
cross-domain mail redirection, unless you're willing to do more work
than I personally am volunteering for.'

But the point is that MLM-redirection, by contrast, never had that
problem because of its smarter way of handling the envelope header.

In hindsight, SRS-wrapping seems like small potatoes compared to the
order-of-magnitude-greater hassle of DKIM and DMARC (but I personally
elect to eschew all three).

-- 
Cheers,                                            "He who laughs last, lasts."
Rick Moen                                                       -- Leo Rosten
rick@???
McQ! (4x80)