Quoting Simon Hobson ([email protected]): > 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., '[email protected]' reaches Chris di Bona, then a co-worker at VA Linux Systems and now Linux Community Manager at Google. '[email protected]' was a natural fit as an alias for _Linux Journal_ editor Don Marti's personal mailbox [email protected]. 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 [email protected] McQ! (4x80) _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
