| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
| |
message. This is especially the case when debugging your filtering
rules. To support this we now have a "filter action" which can be
Discard, Reject, Forward to Admin, Preserve on disk.
Here, set the default action to discard. Also set the flag that
allows owners to preserve filtered messages on disk to true.
|
| | |
|
| |
|
|
|
| |
had their Reply-To header pointing at the posting address, and that
there was no good reason not to continue this tradition <wink>.
|
| |
|
|
|
| |
pass_mime_types entries. They have to look more like a content
maintype or maintype/subtype.
|
| |
|
|
| |
to multipart/alternative (we meant ctype).
|
| |
|
|
| |
Updated Dutch catalog from Danny Terweij.
|
| | |
|
| | |
|
| |
|
|
| |
list name is invalid.
|
| |
|
|
| |
proposed list name is invalid.
|
| |
|
|
| |
exception.
|
| |
|
|
|
|
|
| |
posting address. If not, reject the proposed new list. We use
DEFAULT_EMAIL_HOST because at this point we don't know what the
host_name of the list is (and in fact the attribute isn't set), but it
doesn't matter anyway.
|
| | |
|
| | |
|
| |
|
|
|
| |
realname either to a byte string if it contains just ascii characters,
or to a unicode.
|
| |
|
|
| |
language into the canonstr() call to properly display the fullname.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
message did not bounce match, or if no member addresses could be
extracted from it.
maybe_forward(): MIME Forward the given message to the list owner +
list moderator, if bounce_unrecognized_goes_to_list_owner is true.
Otherwise it discards the message. Write a log entry in either case.
|
| |
|
|
|
|
|
|
| |
problem reported a few weeks ago. We do here largely what we do in
CookHeaders.py for encoding non-ascii Subject prefixes. First, we
convert the string to Unicode (possibly throwing out characters if
necessary), then we use the Header class to properly RFC 2047 encode
the name.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
needs to be "safe" for the given charset, which will be the charset
for the list's language, and the charset the page will be rendered
in.
If it's a Unicode and can be encoded in the desired charset, fine,
just return the encoded byte string. If it's already a byte string
encoded in the charset, again that's fine, just return the string.
Otherwise, html-ify the string and return it as a byte string.
|
| |
|
|
|
| |
that the member's name gets encoded safely for the list's language's
charset, which is the charset the page is going to be rendered in.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
encode_p(): Removed.
_isunicode(): Helper for unicode type testing.
prefix_subject(): Better algorithm for handling unicode subject
prefixes. Now we always set the Subject header to a Header instance
if we're adding the prefix. Always convert the prefix and all
previous Subject header bits to unicode (possibly with character
replacements) so that the Header class does the right thing, i.e. does
the us-ascii, charset hint, utf-8 encoding. Because of this, if the
list's charset is us-ascii, we'll substitute iso-8859-1 for a slightly
wider character coverage.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CookHeaders.py will now be aware that subject_prefix can be a unicode
string.
_setValue(): Capture changes to subject_prefix and canonstr() it,
meaning convert html references to unicode characters.
getValue(): Capture access of subject_prefix and uncanonstr() it,
meaning convert any non-list-charset characters to their html refs for
error free display.
|
| |
|
|
|
|
|
|
|
|
| |
text is calculated. Because msg['subject'] could be a Header
instance, we need to str-ify it before appending it to the body
lines.
uncanonstr(): Coerce the return value to a byte string when html ref
substitution is done. Note that this code probably needs to be
converted to a type test of s (unicode vs. str).
|
| | |
|
| |
|
|
|
|
|
| |
only if the cgi script runs to completion successfully do we write the
entire output to the real stdout (connected to the web server). This
way, if any exception occurs during the rendering of the page (e.g. in
"print doc.Format()") we won't mess up the diagnostics page.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
options.html
|