Date | Commit message (Collapse) |
|
Address::names is sufficient to handle what from_name did.
|
|
It is important to show the decentralized nature of
communication in our web views.
|
|
We may remove from_name in the future.
...And disallow quotes in email addresses.
Technically I believe they're allowed, but they're definitely
uncommon and unlikely to show up in legitimate mail.
|
|
This quiets a (hopefully harmless) warning when a ref remains
alive through several expiry timeouts.
|
|
This only affects Linux users with MSG_MORE support.
We can avoid extra TCP overhead for sub-optimal chunk sizes
by using MSG_MORE even with chunk trailers under Linux.
This breaks real-time apps which require <= 200ms latency for
streaming small packets (e.g. implementing "tail -F"), but the
public-inbox WWW code does not (and will never) do such things.
|
|
We want to avoid sending 10 or 20-byte gzip headers as
separate TCP packets to reduce syscalls and avoid wasting
bandwidth.
|
|
Apparently git-http-backend exits with a non-zero
status on shallow clones (due to git-upload-pack),
so there is a to-be-fixed bug in git.git
http://mid.gmane.org/20160621112303.GA21973@dcvr.yhbt.net
http://mid.gmane.org/20160621121041.GA29156@sigill.intra.peff.net
|
|
Instead of relying on a timer with immediate callback,
arm a pipe to watch for writability, ensuring the callback
always fires.
|
|
We want to maximize fairness for large responses which may
download the entire mbox.
|
|
Trashed messages and drafts are probably not intended for
importing, so do not import them. Dovecot uses extra flags via
lowercase letters, so we must support those (as that's the
server I use).
|
|
Mailing lists I watch and mirror may not have the best spam
filtering, and an extra layer should not hurt.
|
|
We do not actually do spam checking, here; but will
do spam checking before adding a message in the future.
|
|
And improve documentation for existing dependencies, too.
|
|
This should hopefully make it easier to try other anti-spam
systems (or none at all) in the future.
|
|
When running mailing list mirrors, one needs to be careful
spammers do not try to sidestep the list server we want to
mirror from and inject email into our mail directly by setting
the appropriate list headers (e.g. "X-Mailing-List" or
"List-Id"). We trust the top-most Received: header is
the one our own mail server got the mail from.
Bcc:-ing a public mailing list is a very likely indicator of
spam in my experience, so throw in an extra rule mark it.
While public-inbox-mda rejects Bcc: entirely, public-inbox-watch
needs to mirror lists which allow Bcc.
==> list_mirror.cf <==
loadplugin PublicInbox::SaPlugin::ListMirror
ifplugin PublicInbox::SaPlugin::ListMirror
header LIST_MIRROR_RECEIVED eval:check_list_mirror_received()
describe LIST_MIRROR_RECEIVED Received does not match trusted list server
score LIST_MIRROR_RECEIVED 10
header LIST_MIRROR_BCC eval:check_list_mirror_bcc()
describe LIST_MIRROR_BCC Mailing list was Bcc-ed
score LIST_MIRROR_BCC 1
endif
==> ~/.spamassassin/user_prefs <==
ifplugin PublicInbox::SaPlugin::ListMirror
list_mirror X-Mailing-List git@vger.kernel.org *.kernel.org git@vger.kernel.org
endif
|
|
I've setup my own mirror on https://git-htmldocs.bogomips.org/
since kernel.org is no longer updated, and I don't believe
in endorsing commercial hosting sites or interests.
Unfortunately, it still contains JavaScript and CSS, but it's
generated by AsciiDoc. Oh well, it's all Free Software, at
least.
Junio C Hamano writes:
> On Wed, Jun 22, 2016 at 12:00 PM, Eric Wong <e@80x24.org> wrote:
> > Just wondering, who updates
> > https://kernel.org/pub/software/scm/git/docs/
> > and why hasn't it been updated in a while?
> > (currently it says Last updated 2015-06-06 at the bottom)
>
> Nobody. It is too cumbersome to use their upload tool to update many
> files (it is geared towards updating a handful of tarballs at a time).
ref:
http://mid.gmane.org/20160622190018.GA786@dcvr.yhbt.net/
http://mid.gmane.org/CAPc5daUiUv-EEv7ouQ=K+Q8S64QVV5wn4H6+TuF0wLeo123K5Q@mail.gmail.com
http://mid.gmane.org/20160622214811.GA19633@dcvr.yhbt.net
|
|
We want to ensure the actual message gets shown, and less
important info does not destroy things.
|
|
This fixes a bug where a message replying to a ghost would
accidentally be added to the wrong topic in the index/topic
view.
Before commit 76d8f68dc273e54809ad69cfe49e141003f790ef ("view:
avoid recursion in topic index"), we would refuse to indent a
topic which started with a ghost which hid the problem. Now we
inform the user the thread started elsewhere.
|
|
Showing "(no subject)" seems like a common fallback for
messages without a Subject header.
|
|
Some mailing lists allow empty Subject headers and we shall support
searching and indexing them.
|
|
Checking stdin/stdout/stderr is not sufficient as the daemon
without setsid can still be under the control of a terminal.
Unfortunately this means systemd users cannot use SIGWINCH,
either.
|
|
We failed to discard old thread IDs when vivifying ghosts
due to out-of-order message arrival. This rectifies the
failure and will trigger a re-index.
|
|
Remove some worthless parameters and redundant no-ops
to make the next (important) patch easier-to-review.
|
|
Since we have a common pattern, for walking threads,
extract it into a function and reduce the amount of code
we haev.
This will make it easier to switch to an event-driven interface
for getline, too.
|
|
Recursion can cause problems, so do our best to avoid it
even in the topic index.
|
|
As before, recursion can cause problems sooner than unshifting
objects into the head of a queue.
|
|
This should let us generate HTML for arbitrarily deep
threads without blowing the stack.
How it renders on the client side is another matter...
|
|
This should help prevent OOM errors from arbitrarily
deep threads and will make our streaming interface
easier-to-implement.
|
|
We can stuff this into the state hash to reduce stack size and
hopefully improve readability.
|
|
This makes the string creation somewhat simpler hopefully
makes the code easier-to-reason with.
|
|
fork failures are unfortunately common when Xapian has
gigabytes and gigabytes mmapped.
|
|
This abstracts out the path lookup logic and and allow us
potentially allow different heads in the same repository.
We may also bypass slow tree name lookups in the future
by storing the raw blob ID in the Xapian document.
Followup-to: 4b313dc74bc9 ("feed: various object-orientation cleanups")
|
|
Ugh, and I will still need to write better tests for this
(and a billion other things :x)
Fixes: 4b313dc74bc9 ("feed: various object-orientation cleanups")
|
|
lookup_mail is safer since it won't inadvertently load ghosts.
|
|
This should help avoid having too many fake top-level
messages in the topic view since we only have a partial
window for threading results.
|
|
They're needless for actual display once outside of email
headers. But we will still show them when displaying mock
headers in the permalink view.
|
|
Inboxes are normally created by Config, but having the
population logic in Inbox should make it easier to mock
for testing.
|
|
Favor Inbox objects as our primary source of truth to simplify
our code. This increases our coupling with PSGI to make it
easier to write tests in the future.
A lot of this code was originally designed to be usable
standalone without PSGI or CGI at all; but that might increase
development effort.
|
|
Prefer to return strings instead, so Content-Length can be
calculated for caching and such.
|
|
We do not need feed options there (or anywhere, hopefully).
|
|
We'll be switching to a getline/close response body
to give the HTTP server more control when dealing
with slow clients.
|
|
We overuse streaming, here. Allow Content-Length to be
calculated in this case.
|
|
And add a check-manifest target to the Makefile to
ensure we're up-to-date with git (but do not depend on
git).
|
|
Because sometimes folks will want to download gigantic mboxes
or make large clones over Tor which are not resume-friendly.
Note: the timeout logic in nntpd is somewhat over-aggressive
and can break some large slrnpulls. This ought to be easily
recoverable on the client-side, though, since it's based on
per-message fetches.
|
|
This seems like a nasty thing which breaks downloads of
large mailboxes.
|
|
This allows us to yield control to other clients gracefully if
getline takes too long to generate a chunk. This is more
expensive but should not cost a syscall on modern 64-bit systems.
|
|
Use the EvCleanup::asap handler to reschedule our writes
after yielding to other clients.
|
|
This allows consistency between different invocations from
roughly the same period and is no worse for caching any any of
our existing HTML and Atom feeds.
We cannot set the timestamp to the end date since messages
may be added to the repository while we are iterating
(and this streaming mechanism will pick them up).
|
|
Only mark seen messages as spam, otherwise it could be
too aggressive and cause problems or over training.
We wouldn't want a wayward FIFO ruining our day, either :)
|
|
Because our WatchMaildir module is liberal about what
it accepts, we can potentially have messages without a
subject.
|