So, ... I'm looking for recommendations.
The basic context:
using /etc/aliases (or equivalent) to simply and directly forward/alias email out onto The Internet at large, is in general a bad idea (particularly in the days of spam, and anti-spam, etc., among other factors).
Our existing old hosting on DreamHost.com uses a fair bit of that. 8-O Need to migrate that functionality off of DreamHost.com. I'm looking for a way to make that migration that at least partially fixes the issues with such overly simplistic aliases. Notably such "aliased"/forwarded email ought be sent out with appropriate Sender: or similar header(s) (Resent-From: ?) and envelope FROM showing (re)origination from domain of the forwarding host (@balug.org or subdomain thereof). Ideally, a relatively simple near-drop-in replacement that could go into /etc/alises, that would, rather than do overly simple (and problematic) aliases such as: some-alias@balug.org: bob@example.com jane@example.com ... might implement something more like: some-alias@balug.org: "|resend bob@example.com jane@example.com" Also, for these purposes, do not want the complexity of mail lists, e.g. don't need or want subscribe/unsubscribe, archives, etc. At present @balug.org has at least 28 distinct aliases - certainly don't want to manage or have to deal with 28+ additional email lists.
The target infrastructure is: Debian oldstable Debian GNU/Linux 8.9 (jessie) x86_64 MTA: exim4 (will get upgraded to stable at some point, but for the short to medium-term future or so, it's oldstable, and need to implement solution on oldstable).
Thanks in advance regarding recommendations/pointers. :-)
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
So, ... I'm looking for recommendations.
The basic context:
using /etc/aliases (or equivalent) to simply and directly forward/alias email out onto The Internet at large, is in general a bad idea (particularly in the days of spam, and anti-spam, etc., among other factors).
Our existing old hosting on DreamHost.com uses a fair bit of that. 8-O Need to migrate that functionality off of DreamHost.com. I'm looking for a way to make that migration that at least partially fixes the issues with such overly simplistic aliases. Notably such "aliased"/forwarded email ought be sent out with appropriate Sender: or similar header(s) (Resent-From: ?) and envelope FROM showing (re)origination from domain of the forwarding host (@balug.org or subdomain thereof).
At the risk of being useless in this matter: I got nuttin'. In hopes this will render my comment more usefuL: Basically the only thing I've ever found that is a functionally superior alternative to overly complex /etc/aliases tables is MLMs (mailing list managers).
On the minus side, those are a bit of overkill. On the plus side, they don't screw up envelope headers the way use of /etc/aliases or ~/.forward for redirecting mail intersystem does.
What do I do? I use /etc/aliases freely for redirecting mail intra-system, and with reservations to a _minor_ extent for redirecting mail cross-system. The latter are mostly legacy, old entries from the days before the spam war escalated to the insane extent it's reached currently. So, for example, around 1998 I set up an entry in /etc/aliases so that 'don@linuxmafia.com' reaches Don Marti -- but in 2017 any mail actually transiting that alias is likely to arrive looking pretty spammy to receiving MTAs.
I seriously doubt you're going to find a credible middle option. However, if you find one, I'm going to be fascinated to hear about it.
(Greetings from Helsinki.)
Yeah, ... trying to find as reasonably simple to implement as feasible solution, that, within reason, will give something hopefully at least less broken than the current situation.
What almost looks somewhat promising, -f option to exim4 (relatively similar to sendmail) ... " -f <address> Allowing untrusted users to change the sender address does not of itself make it possible to send anonymous mail. Exim still checks that the From: header refers to the local user, and if it does not, it adds a Sender: header " ... but that may possibly cause other breakage ... e.g. DKIM, etc.? Might be other ways to process, munge, and resend/reinject the email, perhaps with less (to zero?) breakage ... but I'm still hoping for as simple as feasible. :-)
From: "Rick Moen" rick@linuxmafia.com Subject: Re: [BALUG-Talk] Recommendations for email resender/"forwarder"? (infrastructure: Debian oldstable amd64, MTA exim4) Date: Sat, 12 Aug 2017 08:02:59 -0700
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
So, ... I'm looking for recommendations.
The basic context:
using /etc/aliases (or equivalent) to simply and directly forward/alias email out onto The Internet at large, is in general a bad idea (particularly in the days of spam, and anti-spam, etc., among other factors).
Our existing old hosting on DreamHost.com uses a fair bit of that. 8-O Need to migrate that functionality off of DreamHost.com. I'm looking for a way to make that migration that at least partially fixes the issues with such overly simplistic aliases. Notably such "aliased"/forwarded email ought be sent out with appropriate Sender: or similar header(s) (Resent-From: ?) and envelope FROM showing (re)origination from domain of the forwarding host (@balug.org or subdomain thereof).
At the risk of being useless in this matter: I got nuttin'. In hopes this will render my comment more usefuL: Basically the only thing I've ever found that is a functionally superior alternative to overly complex /etc/aliases tables is MLMs (mailing list managers).
On the minus side, those are a bit of overkill. On the plus side, they don't screw up envelope headers the way use of /etc/aliases or ~/.forward for redirecting mail intersystem does.
What do I do? I use /etc/aliases freely for redirecting mail intra-system, and with reservations to a _minor_ extent for redirecting mail cross-system. The latter are mostly legacy, old entries from the days before the spam war escalated to the insane extent it's reached currently. So, for example, around 1998 I set up an entry in /etc/aliases so that 'don@linuxmafia.com' reaches Don Marti -- but in 2017 any mail actually transiting that alias is likely to arrive looking pretty spammy to receiving MTAs.
I seriously doubt you're going to find a credible middle option. However, if you find one, I'm going to be fascinated to hear about it.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
" ... but that may possibly cause other breakage ... e.g. DKIM, etc.?
To my knowledge, the only means for redirecting mail intersystem that has a prayer of not triggering the more aggressive antiforgery tecchnologies (DKIM, DMARC) is MLMs.
MLMs can achieve this, imperfectly, and are overkill. But they're not magic, they just screw with the headers so downstream can't detect the envelope or body changes.
Have you tried to use the pipe syntax of aliases, eg don@linuxmafia.org: | /usr/sbin/DKIMstripper-sendmail.sh donmarti@whereever.com // I just made this up, don't shoot me to forward via a munging script that: - removes any header containing DKIM (including some non-standard workalikes such as X-Google-DKIM-Signature) - possibly remove other provenance headers (eg I'm suspicious of X-Gm-Message-State) that could allow a downstream who is also upstream to wonder where their headers went - forwards whats left on to sendmail
HTH
glen
On 8/12/2017 9:03 AM, Rick Moen wrote:
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
" ... but that may possibly cause other breakage ... e.g. DKIM, etc.?
To my knowledge, the only means for redirecting mail intersystem that has a prayer of not triggering the more aggressive antiforgery tecchnologies (DKIM, DMARC) is MLMs.
BALUG-Talk mailing list BALUG-Talk@temp.balug.org https://temp.balug.org/cgi-bin/mailman/listinfo/balug-talk
Quoting Glen Martin (glen@glen-martin.com):
MLMs can achieve this, imperfectly, and are overkill. But they're not magic, they just screw with the headers so downstream can't detect the envelope or body changes.
What you call screwing with the headers is, in my experience, the only way that retransmitted mail is going to arrive at its end-destination not seeming like an attempt to forge the upstream sender's domain.
Have you tried to use the pipe syntax of aliases, eg don@linuxmafia.org: | /usr/sbin/DKIMstripper-sendmail.sh donmarti@whereever.com // I just made this up, don't shoot me
Alas, shell pipelines in /etc/aliases are so notoriously a security hazard that modern MTAs of my experience disable parsing them by default, and you re-enable that parsing at your peril.
Of course, there are other ways of stripping DKIM headers, and that's tempting. I can imagine any number of reasons why this action might end up having adverse consequences, though.
Rick rather correctly pointed out:
shell pipelines in /etc/aliases are so notoriously a security hazard
that modern MTAs of my experience disable parsing them by default, and you re-enable that parsing at your peril.
I completely agree with that! I'd imagined, perhaps erroneously, that this query was about a local system over which posters have ~exclusive control and thus some confidence of security, rather than work or some multi-user system.
You can probably configure a milter to strip pre-existing DKIM on outbound. I haven't tried. Maybe the milter stretches that way, maybe you need to hack it. opendkim seems to have a config switch, RemoveOldSignatures.
But as I mentioned, you may have to go a little further than just the proper DKIM headers, eg non-standard DKIM and other provenance headers. Google seems to be trying to hard to catch removal of DKIM .. there are more than a couple of X-G* and other headers in there that will give away that they've seen the message before. I don't immediately see a way to remove those trivially in opendkim milter.
Unforseen consequences notwithstanding, I haven't had a complaint from my recipients for a while, neither for something going missing, nor for the flag of shame on my list messages, so I guess it is working. Part of it might just be that I have a somewhat working DKIM, DMARC, SPF, etc alphabet soup. :)
HTH
glen
On 8/12/2017 5:28 PM, Rick Moen wrote:
Quoting Glen Martin (glen@glen-martin.com):
MLMs can achieve this, imperfectly, and are overkill. But they're not magic, they just screw with the headers so downstream can't detect the envelope or body changes.
What you call screwing with the headers is, in my experience, the only way that retransmitted mail is going to arrive at its end-destination not seeming like an attempt to forge the upstream sender's domain.
Have you tried to use the pipe syntax of aliases, eg don@linuxmafia.org: | /usr/sbin/DKIMstripper-sendmail.sh donmarti@whereever.com // I just made this up, don't shoot me
Alas, shell pipelines in /etc/aliases are so notoriously a security hazard that modern MTAs of my experience disable parsing them by default, and you re-enable that parsing at your peril.
Of course, there are other ways of stripping DKIM headers, and that's tempting. I can imagine any number of reasons why this action might end up having adverse consequences, though.
BALUG-Talk mailing list BALUG-Talk@temp.balug.org https://temp.balug.org/cgi-bin/mailman/listinfo/balug-talk