My experience with mailing list software revolves around qmail
With a few small scripts, I was able to support a wide variety of new use cases
not inherently supported by
ezmlm-idx itself. The features that are generically
useful outside of The Apache Software Foundation are
laid out below. To use these files follow this layout unless you
are comfortable adjusting the paths in the scripts yourself.
BATV and SRS¶
bin/sender-demunger is a little wrapper script that
SENDER demunging for
ezmlm-idx. To use it you simply
add it as a prefix to all of the lines in your
</manager/> blocks within
.ezmlmrc and run
ezmlm-make -+ on your lists, or in a pinch assuming you will not
ezmlm-make again on your lists, edit the
manager files within
your list directories.
SRS pose unique problems
ezmlm-idx because unlike other mailing list software it operates on the
MAIL FROM portion of the
SMTP envelope, not the "From" address in the message headers.
Both specifications revolve around providing temporary addresses to the
envelope portion, which embed the original address in an easily decipherable way. But
these temporary addresses are anathema to
ezmlm-idx's subscription and moderation systems,
sender-demunger script mentioned above will fix that once deployed.
See bin/ezmlm-dmarc-filter and
lib/pull_header.pm. To use these scripts,
change the lines in your
</editor/> section of
ezmlm-send, to look like the following:
|/path/to/bin/ezmlm-dmarc-filter '<#D#>/dmarc' | /path/to/bin/ezmlm-seekable-stdin /path/to/bin/sender-demunger <#B#>/ezmlm-gate -rY '<#D#>' '<#D#>' '<#D#>/digest' '<#D#>/allow' '<#D#>/mod' |/path/to/bin/ezmlm-dmarc-filter '<#D#>/dmarc' | /path/to/bin/sender-demunger <#B#>/ezmlm-store '<#D#>' |/path/to/bin/ezmlm-dmarc-filter '<#D#>/dmarc' | <#B#>/ezmlm-send -r '<#D#>'
This assumes you will touch a file named
dmarc in any list directories where you want
to enable the filter. You can configure
.ezmlmrc to do this by adding the following block
to that file:
</-dmarc#FXT/> </dmarc#f/> </dmarc#t/> </dmarc#x/>
The only list configurations that run afoul of
DMARC are those with
The above configuration will adjust for that.
In case you haven't kept up with the times, there is a recent movement afoot to introduce
strong DMARC policies that reject messages which
fail DKIM signature tests.
Facebook, Twitter, LinkedIn, Yahoo! and now AOL have been leading this
charge into new territory, forcing mailing list operators to deal with the situation.
ezmlm-dmarc-filter does, and this isn't the only possible solution to the problem,
is drop the
DKIM-Signature header for any such domain, and add an
.INVALID suffix to the
From header address. It has the advantage of being one of the simplest solutions that
works, so I'm offering it here. So far the domains that deploy strict
DMARC policies all
Reply-To headers, so these changes made by
not impact the operation of any RFC-compliant email responses to such messages.
$Date: 2014-07-17 15:32:01 +0000 (Thu, 17 Jul 2014) $