| Date | Commit message (Collapse) |
|---|
|
Most notably, the INSTALL is geared towards potential server admins,
whereas the README is also for interested "drive-by" readers.
|
|
We do not need to use CGI::Util internals here.
|
|
This should make it easier to support non-CGI uses,
as well as making it easier to generate static sites.
|
|
Passing a giant argument list is to error prone and
hard-to-document.
|
|
We serve the short, abridge-quote version by default since
it is (unfortunately) common practice to over-quote on mailing lists.
|
|
This wording is probably clearer to everyone, and also used by at
least one other mailing list WWW interface.
|
|
Avoid adding extraneous whitespace in HTML content, as it
increases bandwidth usage of network, disk and memory.
|
|
This reduces duplicated/similar code and hopefully makes things more
consistent.
|
|
Our Filter class now passes through application/octet-stream
if it looks like text (because some mailers suck); so we
cannot trust the specified Content-Type of a message.
|
|
This is lightly tested.
|
|
CGI::escape is not a documented subroutine, so the chances of
it going away are higher.
|
|
We no longer use DateTime::Format::Mail.
|
|
This is a smaller module dependency-wise and should be easier-to-install
for folks with limited packaging systems or network/disk capacity.
We do not need very powerful date parsing, as bad date formats are
likely the work of spammers.
|
|
We should be able to wire up the rest, soon.
|
|
We will just use the fallback in Email::Filter to
reduce configuration knobs. Failed messages are failed
messages, do not classify them beyond that.
|
|
This still needs to be fleshed out.
|
|
Unfortunately, quoting is often excessive, so hide multi-line quotes
by default and provide anchored links to full messages instead.
|
|
Hopefully this makes for less ad-hoc hash access in case
our config format changes.
|
|
Mainly, start with URL routes since that's what users usually
see, first.
|
|
We'll go with .html and .txt suffixes on MIDs to benefit
static hosting setups.
|
|
We will be reusing the config parsing code for the CGI
script, too.
|
|
We will also be using the RECIPIENT env in the future, since
that takes aliases into account.
Reducing the possible callsites to check ENV means we can more
easily update the code in the future.
|
|
|
|
This should be safer than running file(1), which has had its share
of vulnerabilities this year (early 2014) We really only care about
diffs and maybe short log files, here.
|
|
We may keep PGP signatures for messages we do not modify.
However, we have no way of verifying them on the server-side.
|
|
|
|
Some mailers do not correctly detect/set the Content-Type header; so
attempt to keep messages based on our server-detected MIME type if
application/octet-stream was specified.
|
|
|
|
This should make it easier for non-ssoma users to follow.
|
|
Valid emails should not arrive without a Message-ID.
|
|
This is to keep content accessible to search engines.
|
|
We may add more checks before we go to spamc.
|
|
|
|
We'll be using git config files after all...
|
|
Due to the higher latency of a pull-based email, we want to
encourage the use of reply-to-all for public-inbox.
|
|
SpamAssassin doesn't seem to have this heuristic, but the lack of
the intended email address in To:/Cc: headers cannot be a good
sign (especially when this is a _public_ inbox).
|
|
|
|
Unfortunately we slurp, but expect our MTA to provide its own
limit on message sizes.
|
|
Just use $0 for now, since I suck at naming things.
|
|
We generate them when publishing.
|
|
|
|
|
|
|