| Date | Commit message (Collapse) |
|---|
|
git has stricter requirements for ident names (no '<>')
which Email::Address allows.
Even in 1.908, Email::Address also has an incomplete fix for
CVE-2015-7686 with a DoS-able regexp for comments. Since we
don't care for or need all the RFC compliance of Email::Address,
avoiding it entirely may be preferable.
Email::Address will still be installed as a requirement for
Email::MIME, but it is only used by the
Email::MIME::header_str_set which we do not use
|
|
The offset argument must be an integer for Xapian,
however users (or bots) type the darndest things.
AFAIK this has no security implications besides triggering
a warning (which could lead to out-of-space-errors)
|
|
Having a file start with '.' or '-' can be confusing
and for users, so do not allow it.
|
|
For attachments without a filename or description, reduce
the amount of precious screen space required to display
a link to it.
|
|
We shall ensure links continue working for this.
|
|
This can be useful for lists where the convention is to
attach (rather than inline) patches into the message body.
|
|
msg_iter lets us know the index of the attachment,
allow us to make more sensible labels and in a future
commit, hyperlinks to download attachments.
|
|
Or is it "encoding"? Gah, Perl character set handling
confuses me no matter how many times I RTFM :<
This contains placeholders for attachment downloading
which will be in a future commit.
|
|
Oops, but perhaps the "reply" endpoint should be embedded
into the permalink message view itself to reduce URLs.
|
|
Remove unnecessary wrapper subroutines and constants
which are only used once.
|
|
Oops, we need to escape Message-IDs since they can contain
bad characters such as '%' in them. '@' actually seems fine
and does not need to be escaped; however, but we've been
doing it forever.
|
|
A public-inbox is NOT necessarily a mailing list, but it
could serve as an input point for zero, one, or infinite
mailing lists :D
|
|
Broken threads should be exposed to hopefully encourage people to
use proper mail clients which set In-Reply-To headers.
|
|
This can makes navigation easier with some browsers or
or browser extensions.
ref: https://www.w3.org/TR/html/links.html#sequential-link-types
|
|
Oops, gotta test this :x
|
|
This shouldn't show up in other browsers (tested with w3m, too),
but the extra newline makes a difference for delineating
messages when viewed with lynx.
|
|
This will allow potential tinkerers to switch away from the '` '
prefix more easily.
|
|
Allowing readers new to a topic to follow in chronological order
probably makes the most sense. Reverse chronological order may
reduce scrolling (e.g. log view); but nearly all non-threaded
conversation displays seem to be chronological so perhaps
there's a good reason for that.
|
|
Allow the Subject: <-> skeleton line to point to each other so
the reader can bounce around between them without refocusing
their browser.
|
|
Quote-folding was a major design mistake pre-1.0. Since this
project is still in its infancy and unlikely to be in wide
use at the moment, redirect the /f/ endpoints back to the
plain message.
|
|
...And mark quotes as <span class="q"> since it barely
costs us anything and allows users to choose colors
themselves with custom, user-supplied CSS.
Reduce allocations of the Linkify object, too.
|
|
Quote-folding can be detrimental as it fails to hide the
real problem of over-quoting.
Over-quoting wastes bandwidth and space for all readers, not
just WWW readers of the public-inbox. So hopefully removing
quote-folding support from the WWW interface can shame those
repliers into quoting only relevant portions of what they reply
to.
|
|
Oops, $MESSAGE_ID/f/R/ screws up rather badly.
|
|
Oops. While we're at it, simplify the calls to do threading
slightly by reducing the places where we touch Mail::Thread
globals.
Fixes: 56164afc2034 (view: allow topics to be "bumped" by new replies)
|
|
This ought to prevent new replies from getting lost for readers
relying on the WWW index interface.
|
|
In the per-message view, we still need to account for threads
lacking a common parent. This can happen when threads are
broken by some broken clients or if somebody sends the same
message twice to the same inbox with a different Message-ID.
|
|
Shorten lines used for long Message-IDs in the
inline thread view for per-message views for readability.
|
|
Keeping readers informed of ghost messages is important,
so do not ever prune them. Previously, ghosts could get
pruned and sole children would get promoted as the new
root.
|
|
These were the vestigial remains of our previous use of
of Message-ID compression.
|
|
The "next/prev" links seem a bit awkward and I don't use them as
much as I expected to. However, move the "raw" message link
near the top since it's most useful for checking or reinforcing
the validity of the message via GPG or just reading headers.
Turn the Subject line into a permalink to the message, since
that's probably the common behavior anyways for other messaging
systems. Make the "[threaded|flat]" view links to always
visible for bookmark-ability despite the lack of a "permalink"
label.
|
|
Reduce stack depth of arguments and rely more on state hashref
to store response state. We may end up shoving everything
in ctx eventually.
|
|
It's probably a bad idea to strip extraneous whitespace
from some headers as an extra space may convey useful
information.
Newlines don't seem to be preserved by Email::MIME or
Email::Simple anyways, so there's no danger in breaking
formatting.
|
|
Ugh, this enabled-iff-xapian-is-available code really
needs better testing...
|
|
Message-IDs should not be MIME encoded, but in case they are,
use the raw form for compatibility with ssoma and possibly
other tools. This prevents a potential problem where a
malicious client could confuse our storage layer into indexing
incorrect contents.
|
|
This will allow us to more easily reuse it elsewhere.
|
|
We now keep intermediate blank lines in messages, since it
could be used to denote logical gaps in the message
(such as giving readers a chance to opt out of "spoiler"
information).
However leading blank lines, trailing blank lines, and
trailing whitespace have no useful value we can discern;
so drop those entirely to prevent clients from eating up
vertical whitespace.
|
|
It's often not that much information and may be useful
to reduce HTTP requests a reader will want to make.
|
|
Setting the "In-Reply-To:" header via mailto: links is not
well-supported and should probably not be encouraged unless
the client situation improves.
So instead, teach users more widely-supported ways of setting
the In-Reply-To: header to ensure proper threading of replies.
|
|
For future changes, this will allow us to more quickly notice
if we keep the heavy Email::MIME object around too long.
It has the side effect of avoiding extra method calls with
Email::MIME which forwards header calls to the header_obj.
|
|
In an single-message thread with a ghost parent, we need to
go up level from the current Message-ID before appending the
parent message to us.
|
|
Dropping "[FOO]" prefixes for the purposes of summarization
is tricky and we end up with odd display behavior.
Just show Subject line changes as the writer intended
(with the exception of normalization to strip the "Re: ")
|
|
We should not hide the parent Message-ID in this view;
give the user the option to find the message in other archives.
|
|
The word "skip" can be confusing. Instead, spell out "scroll down"
for the user to read and only display that text when the thread
is sufficiently long.
|
|
There's no need to HTML escape a timestamp we generate ourselves.
We need to preserve the leading space and can't use the "oneline"
semantics to preserve alignment.
|
|
Inevitably, somebody will care about semantic HTML; but
preserving the original intent of the email author is
important.
|
|
Oops :x
|
|
Not needed, but this is good documentation. Some of these values
should never have newlines.
|
|
The threaded search view is somewhat alien to new users,
so ensure we label the word "relevance" for them.
|
|
Oops, the rarely-accessed threaded search view was completely
broken. Additionally, the normal threading depths were broken
when we attempted to go up-thread and replies got nested
improperly
Followup to commit be984ce279776d4513b4ca1bff05ebecafdd1bad
("view: thread using <ul> instead of <table>")
|
|
Linking to the expanded thread page probably makes more sense
as it avoid unnecessary scanning for the thread summary.
|