Date | Commit message (Collapse) |
|
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.
|
|
'+' is more shoter and more readable in query parameters than '%20'
|
|
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
|
|
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.
|
|
Oops :x
|
|
This is better encapsulated and hopefully more readable.
While we're at it, check for being inside a long response, too.
|
|
Oops, we need to test commands more closely :x
Add a missing prototype while we're at it for extra
checking.
|
|
This is similar to XHDR, but differs in how it handles Message-ID
lookups.
|
|
This is allowed by RFC 2980 and HDR (to-be-implemented) in
RFC 3977 supports it, too.
|
|
We'll require some modifications for HDR support, though.
|
|
This is just like the XOVER command, but allows a single Message-ID
to be given.
|
|
These are internal metadata should be calculated, so avoid
leaking it into the header.
|
|
It's common for mail bodies to end with LF-only, so end them with
CRLF to avoid triggering errors in clients.
|
|
RFC 3977 supports YYYYMMDD dates while retaining backwards
compatibility for old YYMMDD dates.
|
|
RFC 3977 stipulates the use of UTF-8 as the default charset,
so we shall try using that and hopefully not mangle things.
|
|
Apparently, my mental model of Perl internals is still incorrect
after all these years. I am but a simple *nix programmer:
everything is a bag of bytes to me.
This fixes a problem with UTF-8 headers from Xapian (via
"XHDR Subject [range]") triggering partial writes and writing an
extra newline to the outputs.
|
|
Reserializing the message to a string to check size wastes
considerable time and should be able to get by with slightly
less accuracy.
|
|
We could also start displaying Xref in XOVER as rtin seems to
prefer it. Anyways this is nearly 100 times faster now and
requires no DB changes.
|
|
This doesn't actually change anything as the constant is still
usable in other subroutines, but helps with consistency and
readability IMHO.
|
|
Using non-hierarchical mailing list names for newsgroups
might confuse traditional newsreader software and perhaps
some humans. Allow administrators to configure newsgroups
names and hierarchies to their liking.
Sorting the grouplist alphabetically should probably be
done anyways to improve usability for some clients which
won't sort themselves.
|
|
public-inboxen may be aliased to multiple email addresses,
and we have always favored the first.
|
|
We cannot use the push_back_read functionality of Danga::Socket
since it will trigger event_read on buffered data. This would
allow a malicious (or badly implemented) client to burn CPU
without actually sending us anything.
So we still do buffering ourselves and play some tricks with
timers re-enable readability.
|
|
Long responses may leave the buffer momentarily empty,
but we must prevent read events from firing at that point.
|
|
Avoid depending on IO::Socket::INET if we can help it,
we do not need to bloat ourselves with lot of that
functionality.
|
|
Lynx seems to rely on this behavior for "ARTICLE <message-id>"
Tested with Lynx Version 2.8.8dev.12 (22 Feb 2012) on Debian wheezy.
|
|
This will allow us to redirect stdout/stderr more easily
for logging.
|
|
Article number is optional, but we need to update the
article number of the client connection if it was specified
(but not if it was given a Message-ID) as stipulated by
RFC 977
|
|
It's misleading to show short times on long responses.
Instead, show the long response as a separate entry on
completion or failure.
|
|
This may be helpful for sorting out duplicates.
|
|
Using Xapian allows us to implement XROVER without forking
new processes.
|
|
We can use our msgmap database to implement "XHDR Message-ID [range]"
commands quickly. This helps immensely with slrnpull, which prefers
XHDR to LISTGROUP for some reason...
|
|
XOVER uses the current article if no range is given as
stipulated in RFC 2980.
|