Date | Commit message (Collapse) |
|
We may be breaking some parsers or allowing more breakage
to slip through without quotes. We waste some bytes, though.
|
|
This may be useful for generating List-Id headers and HTML pages.
|
|
We do not have all messages in the top-level index
(and we need to adjust the test while we're at it).
|
|
Message-IDs could have embedded '<' and '>'
|
|
This makes it possible to gradually migrate to new address in case
of list name changes, and is one step closer to operating in
"stealth hijack mode" :)
|
|
I often forget the subtleties of Perl regexps and newlines,
so I suspect others do, too. Use explicit capture so it's
more familiar to users of non-Perl regexps.
|
|
Code should be consistent with the design docs
(and we will need better tests).
|
|
This prevents ambiguity when switching URLs between static
file servers and CGI.
The /$LISTNAME/index.html URL appearing in the wild is inevitable
because of our static file server support. Worst yet, there's
no easy/consistent way to get all installations detect and 301
them to the shorter /$LISTNAME/. So we make the CGI support
/$LISTNAME/index.html.
The downside of this is the potential duplicate entry in all caches.
|
|
We may occasionally encounter horrid HTML which lynx cannot
handle, so improve error reporting.
|
|
We will be using it when setting GIT_COMMITTER_NAME
|
|
Using JWZ threading might work decently for this.
Haven't checked in lynx, yet.
|
|
We should reject values which are too short to be useful or sane.
|
|
Composers may screw up and leave the subject out, so
reject those messages.
|
|
We will need it for HTML indices, too.
|
|
Passing a giant argument list is to error prone and
hard-to-document.
|
|
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.
|
|
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.
|
|
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.
|
|
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).
|
|
|