| Date | Commit message (Collapse) |
|---|
|
Of course, we need to figure out if RFC 4685 is supported anywhere,
first.
|
|
They increase HTML size and add to visual noise without telling
enough useful information.
|
|
Improve error messages and use a better regexp for detecting
printable characters in attachments.
|
|
Oops, there is no longer a 3rd element.
Fixes: 759efc037728a766ee80f1b0d3c1fd7b8c76a05f
("view: remove attribution for topics in top-level view")
|
|
It clutters up the page unnecessarily, as identity of the topic
starter/updater probably doesn't matter if there's no exact
message to attribute the message to.
|
|
Network connections may use OpenSSL for TLS (as other libraries,
such as GNUTLS do not appear well-supported under Perl). So
give this exception in case somebody needs TLS support for NNTP.
|
|
Downloaded mboxen can be archived/stored indefinitely, try to
make it easy for future archaelogists to find the online
archive location.
|
|
It may be present in messages imported from NNTP.
|
|
Having per-thread Atom feeds and downloadable mboxen is powerful
and should be more easily visible/accessible to casual readers.
|
|
For list where we are not the primary archival entry point,
defaulting to filter=scrub makes sense since their list
conventions may be more tolerant of HTML and other crap
than we are.
|
|
Xapian has this limit for terms, and there are likely no
legitimate Message-IDs (or single header lines) this long; so
there's no need to workaround this limit.
|
|
We use it as a general compressor for identifiers such as
subject paths, so using the "mid_" prefix probably is not
appropriate.
|
|
Ensure we are executable for consistency and documentation.
MakeMaker already makes this executable, but we might as
well do the same...
|
|
This doesn't seem to do anything on my older system, but maybe it
will in newer or future versions of DBD::SQLite. Anyways it can
be helpful for documentation purposes, too.
|
|
Sometimes subjects are excessively long and hit Xapian's 245-byte
term limit. We can still perform subject-only searches with
a probabilistic prefix.
|
|
It may be hard to tell what command triggered an error,
otherwise.
|
|
Oops
|
|
We don't want to waste precious server memory on clients which
have been idle for longer than 3 minutes.
|
|
While we're at it, reject non-plain-text top-level messages,
too. They probably do not exist in practice, but we cannot
afford to scrub given policies implemented by overzealous
mail providers.
While we're at it, update the comment for strip_multipart.
|
|
Oops, I forgot to run the syntax check for this.
|
|
It's often part of idiotic policies to prevent mailing lists
from working at all.
|
|
This is probably unsafe
|
|
The last message in a thread _display_ is not necessarily the
latest message in the thread. We must go by the Date: header
on the messages themselves as a best-guess. Of course Date:
headers may lie, but most mail clients trust them by default,
so we will, too.
|
|
That's right, we now have our NNTP server running and are
self-hosting a read-only news gateway at:
nntp://news.public-inbox.org/inbox.comp.mail.public-inbox.meta
|
|
'+' is more shoter and more readable in query parameters than '%20'
|
|
More testing is good, especially since clients I use
don't implement all the commands.
|
|
Multiline responses must end with "\r\n.\r\n", so we won't
break out early in case the OS doesn't support MSG_MORE.
|
|
The document data of a search message already contains a good chunk
of the information needed to respond to OVER/XOVER commands quickly.
Expand on that and use the document data to implement OVER/XOVER
quickly.
This adds a dependency on Xapian being available for nntpd usage,
but is probably alright since nntpd is esoteric enough that anybody
willing to run nntpd will also want search functionality offered
by Xapian.
This also speeds up XHDR/HDR with the To: and Cc: headers and
:bytes/:lines article metadata used by some clients for header
displays and marking messages as read/unread.
|
|
We shall remove slow, unoptimized headers in XHDR/HDR to avoid
becoming an easy DoS target.
|
|
Redundantly confirm to clients we do not accept posting with the
MODE READER command.
ref: RFC 3977 5.3.1
|
|
We don't have something like CGI or Plack to build an NNTP
server on top on, so we implemented one using Danga::Socket
for epoll/kqueue abstraction.
|
|
We cannot avoid requiring ::Config, so do not hide it.
|
|
Users may log output to a pipe, so ensure these outputs are
unbuffered in userspace and go to the operating system ASAP
for other processes to pick up.
|
|
It doesn't actually give performance improvements unless we
use types with "my", but we don't do that. We'll only continue
using fields with Danga::Socket-derived classes where they're
required.
|
|
No point in sending such a short, bounded response with
multiple syscalls.
|
|
This is stipulated by RFC 3977 8.5.1, but apparently I misread it.
|
|
We probably won't be supporting this in the public API
|
|
When using user-switching in a single process, we must be
careful to not inadvertantly create new Msgmap sqlite3 files.
We must also ensure we set proper permissions on any files
we create.
Additionally, our refactoring was broken as we failed to
actually daemonize or preserve the parent FD in a worker
process.
Finally, default to one worker process since our code may
be fatally broken and it's nice to be able to scale to multiple
cores via SIGTTIN if needed.
|
|
Using a signal-based timer can hurt throughput on a machine that's
overloaded. Ensure there's always forward progress and reduce the
number of syscalls we make, too.
|
|
Micro-optimization, but it make using Danga::Socket for watching
pipe readability easier at some point.
|
|
I've yet to hit it, but syswrite has chance of returning EINTR
on a blocking pipe.
|
|
This can help us track down what request patterns clients
will perform when we have multiple clients.
|
|
Oops, we must increment our range even if we yield or
get blocked on output buffering.
|
|
It seems like it was never used
|
|
This is required by RFC 3977, section 3.2.1
|
|
RFC 3977, section 8.5.2 states metadata lookups can be done
with HDR.
|
|
We'll probably be supporting read-only IMAP, or maybe
we'll just implement a custom HTTP server so users can
manage/upgrade the same way as the nntpd while being
immune to slow clients.
|
|
We may support SIGUSR2 in single-process mode as long
as permissions aren't wonky.
|
|
We can use the UNIVERSAL::can to better encapsulate the shutdown
process, in case we need to implement a gopher or HTTP daemon.
|
|
Oops :x
|