| Date | Commit message (Collapse) |
|---|
|
We will reuse it for thread views when powered by Xapian.
|
|
Give changes in subject their own line to reduce line wrapping,
but avoid showing any redundant subjects by maintaining a hash
of subjects already displayed.
|
|
We'll be sharing the same threading, so it makes sense to sort
replies using the same code and message headers without repeating
ourselves.
This also standardizes on sorting on X-PI-TS (Unix epoch in seconds)
instead over using X-PI-Date differently in two different places
|
|
This can be used to quickly scan for replies in a message without
displaying an entire thread.
|
|
This will relieve callers of the need to decode the data
we store internally in Xapian
|
|
Quit repeating ourselves and use a common MID module
instead.
|
|
We need to make the indexer executable and installable
while we're at it.
|
|
This shall allow us to search for replies/threads more easily.
|
|
This fixes a minor test failure in t/cgi.t
Tested with perl 5.18.2-2ubuntu1 on Ubuntu 14.04.3 LTS
|
|
Unneeded since commit e022d3377fd2c50fd9931bf96394728958a90bf3
("huge refactor of encoding handling")
|
|
This fixes the fallback to message encoding if the message
itself was not UTF-8
|
|
We must inject headers properly for injecting ham, otherwise
List-Id headers get dropped.
|
|
It's seems less ambiguous to parse a consistent in quiet lists
where messages are sparse.
|
|
We'll be using this in the future for displaying per-thread
views.
|
|
We want to be able to reject errors back to the MTA.
|
|
This should hopefully reduce the delay between when a user fails
to send plain-text to when an admin such as myself notices the
HTML mail in a sea of spam.
Unfortunately, this can lead to backscatter, so avoid doing it
until its passed through spamc, at least.
|
|
This avoids some runtime penalties associated with recompiling
a regexp based on a constant local variable.
|
|
This is probably more compliant, and saves us a few bytes
on the uncompressed HTML.
|
|
Oops, noticed by manual inspection. One day we'll run tidy in tests
to validate.
|
|
We want to be able to prioritize spam downstream to check for
borderline cases.
|
|
We can't add newlines to links, unfortunately, because
quote-folding is line-based and (being regexp-based) needs
to happen after linkification.
|
|
SpamAssassin queries URI blacklists, so it's probably OK
to enable this without being used as a linkfarm.
|
|
SpamAssassin queries URI blacklists, so it's probably OK
to start generating links in the future...
|
|
This prevents process growth when importing large messages.
Memory growth could be due to the sliding sbrk window in glibc malloc
or a circular reference in the Email::* Perl code somewhere.
|
|
PublicInbox::Config->lookup won't return unknown keys
|
|
This should alleviate fears of interrupting the process.
|
|
|
|
Some mailing lists (e.g. git@vger.kernel.org) accept messages
via Bcc: and possibly other things which get rejected by
the strict PublicInbox::Filter rules. So rely on ssoma-mda
instead.
This prefers a recent revision of ssoma-mda (commit 7fce38e9
onwards) to display subject/author/date information in the
commit message.
|
|
Newer systems may use .json instead of .yml
|
|
Some mailers may omit the Content-Type header entirely,
so do detection and try to get the message through.
|
|
Apparently it's not a problem with recent archives.
|
|
We start with zero and only store the next valid ID.
|
|
This allows incremental imports of slrn spools, ideal for
tracking lists via gmane.
|
|
This allows us to generate links without caring about discoverability
and remains reasonably WYSIWYG for folks editing our documentation in
their favorite $EDITOR
|
|
Occasionally we'll use these for links.
|
|
Sometimes people send HTML email and I forget to fixup in my
MUA during moderation. Automatically strip out HTML portions
instead.
|
|
Ugh, apparently there's a (yet-to-be-fixed) bug in the Filter
code which caused an HTML message portion of a multipart message
to be displayed on the web UI. Account for that and nuke it.
|
|
This is occasionally useful and we're not as starved for screen
space now now that sender+timestamps are on a separate line.
|
|
These may not be permanent, after all.
Better threading support can be done for message views, so
and the current index layout is still too busy and suboptimal.
|
|
I often forget how to run this
|
|
"original" is a bit misleading, since we strip needless junk
like HTML from messages before it ever hits git.
|
|
Because some folks will want to receive email.
|
|
|
|
While we're at it, fix up a typo.
|
|
This reduces unnecessary white space and consistently places
the attribution under the Subject.
|
|
At the cost of some vertical whitespace.
More bikeshedding...
|
|
We must support multi-address mailing lists, so we do not
clobber existing addresses. However, we need to ensure
idempotency and ensure existing addresses are not reset.
Furthermore, we were not parsing the existing config correctly
due to a leaking $/.
|
|
Often times any succession of "---" denotes the rest of the
message is too long to review at once.
|
|
This hopefully allows easier setup.
|
|
Unix line endings are LF-only, so do not introduce or preserve
CRLF line endings when reading from lynx.
|