| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
| |
field to better explain where it is used.
|
| |
|
|
|
|
|
|
| |
the remaining number of bounces a member is allowed (within the
stipulated time frame) before exceeding the limit. If this is right,
with the other bounce-handling refinements i feel a lot more confident
about predicatable, well-mannered behavior from the bounce management
stuff...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bouncing address - before sending the notice, check whether the
bouncing address is among the list owner addresses.
And otherwise, include (attach) a copy of the actual bounce notice in
the admin-action message. Otherwise there is no record the
administrator can examine.
Finally, send both failed and successful admin-action notifications to
the list administrator. Before, failed action (e.g. inability to
locate the specific user) were sent to the mailman site admin - this
was while i was debugging the bounce handling, but it looks a lot
better now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ScanMessage(): added final-step massage of all candidates to remove
encompassing <, > angle brackets, if any, and check against already
processed candidates.
(In order to change something to enable a checkin i made a spelling
change of something trivial that i resisted for a while - substituted
"message_grokked" for "message_groked". I'm pretty sure the double k
is right, but don't have a copy of stranger in a strange land happy to
check. Anyway, i keep reading "groked" like it would rhyme with
"stoked", which just can't be right...-)
|
| |
|
|
|
|
|
|
|
|
|
| |
disabled. The idea is that numerous outstanding bounces do not each
require renotification of the admin.
DisableBouncingAddress(), RemoveBouncingAddress(): changed return
signatures to indicate whether email notification is necessary for
this action, and in Disable version, indicate not necessary when user
is already disabled. In all other cases, notification is indicated,
whatever the status.
|
| |
|
|
|
|
|
|
|
| |
prominently point out when the user's delivery is disabled. (When a
user's email is disabled due to bounces, they probably would not
notice the checked button way down the page.)
Using "from htmlformat import *" to simplify references to formatting
objects.
|
| |
|
|
| |
well as the rest of the stuff.
|
| |
|
|
| |
default message footer.
|
| |
|
|
|
| |
separates a detail elaboration from the brief description, so its lack
made the two into a long brief description).
|
| |
|
|
|
| |
Changed mailman URL to point to john's site, and included a comment
explaining what it is for.
|
| |
|
|
| |
is doing the right thing right off the bat.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Digest messages now keep all headers except 'received',
'errors-to', and all 'x-*' ones (and any continuations of these).
- Mime digest messages now properly (i believe) contain mime
attachments. (The key was preserving the original content-type
header.)
- It may be that some more headers should be trimmed, ie for the sake
of the non-mime recipients - but actually, it doesn't look
cluttered, for the few sample messages i tried.
- The entries in the table-of-contents have the redundant
subject-prefix string removed.
Digest: Redundant "Vol" in masthead string removed.
I took a look at rfc 934 (thanks, barry), which is the pre-Mime standard
for encapsulating (nesting) messages in other messages, and it looks
like the key is to have an "encapsulation boundary" that starts with a
"-" dash - looks like mime extended from this. However, the old rule
for nesting an encapsulated message within another encapsulated
message is to insert a "- " space in front of the original
encapsulation boundary. Unfortunately, this would break mime
encapsulation, so i'm not implementing this part of the old
burstable-digests standard. The rest of it *may* be ok, though, in
case anyone has the old-style bursting readers...
Anyway, i've done about as much as i was hoping to do with the digests
format - i don't forsee devoting much more attention to features, just
to ironing out bugs.
|
| | |
|
| |
|
|
| |
for the real_name setting - in the brief description.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(together with the 'host_name' setting) is crucial for lists that use
some alternate address of a host that has multiple identities. (I
have to go through everything to make sure these addresses are
utilized everwhere they ought to be, but this capability will be
crucial for, eg, clients of ISP's that have their own client domains,
and of course want to have their mailman setup reflect that domain!)
.GetConfigInfo(): Added long descriptions for several variables that
needed them, including particularly the real_name - have to make sure
that people know they can change the case, but not anything else about
it, and why.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
neutral format, and then can present as either plain or mime format.
Much cleaner than when the digest structure and layout was combined
with the other logic in .SendDigest().
.SendDigest(): Use new Digest() class to compose the digest and then
present it in either (or both) formats. Much simplified as the digest
structure and layout logic is now in the digest class.
Added DIGEST_MASTHEAD, removed DIGEST_HEADER_TEMPLATE and
DIGEST_CLOSE_TEMPLATE.
|
| |
|
|
|
| |
will be used, and it uses maillist-specific digest stuff
(e.g. DIGEST_MASTHEAD).
|
| |
|
|
|
| |
take care of incorporating the header and footer, and shouldn't have
to specify null ones...)
|
| |
|
|
|
| |
distributed. (I'm sticking with it as default here at python.org,
until i get complaints.)
|
| |
|
|
| |
relocate the repository.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
instead of the ad-hoc one. This should be more robust and more likely
to not break sendmails out there...
(There actually has been lots of restructuring, in preparation for
using a digest object that will provide for better mixed multipart
mime presentation...)
|
| |
|
|
| |
another.
|
| | |
|
| |
|
|
| |
for reflection loops.
|
| | |
|
| |
|
|
| |
from .SetHeaders() so the __delitem__ can use it.
|
| |
|
|
|
|
|
|
| |
mailer-daemon, postmaster, orphanage, postoffic) - they're almost
certainly delivery-failure notices.
I'm going to poll the mailman-developers list for suggestions about
refinements to this approach.
|
| |
|
|
| |
list to each digest entry. (From janne sinkkonen, more or less.)
|
| |
|
|
|
|
|
|
|
| |
mailer-daemon, postmaster, orphanage, and postoffice - on the
presumption that they're failed subscribe instructions, bouncing back
to the -request addr.
I think this'll take care of that sticky problem fairly safely.
Nobody should be sending commands from those accounts, anyway...
|
| |
|
|
|
|
|
|
|
| |
extraction, with testing. We now avoid all the silly elipses cases...
(Unfortunately i could not test the bounce handling on glyph due to
some subtleties in the sendmail setup. Fortunately, bounce handling
is a sufficiently uncommon event that i could work on the production
system without much fear of disruption.)
|
| | |
|
| | |
|
| |
|
|
|
|
| |
domain among those iterated among valid_toplevels. Depending on
ensuing discussion on the mailman-developers list, i'll probably cut
this out completely.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of bounce violators, and also reduce if not eliminate the number of
invalid address targets.
.ScanMessage(): Instead of handling each email addr as it's encountered,
collect together all the candidates and go through them all at the
end, rejecting duplicates. This way, candidates found repeatedly in
different cases won't be processed multiple times.
.ExtractBouncingAddr(): Prevent a commonly recurrent aberrant address
gleaning, eg: "<klm@python.org>..." - many error notice lines have
that elipsis after the address, and it was not being adequately
filtered. Now it is.
|
| | |
|
| |
|
|
| |
Regularize the digest header list info section slightly.
|
| | |
|
| |
|
|
|
| |
body, so initial body lines that looked like header would be
incorporated in header.
|
| |
|
|
|
|
|
|
|
| |
Changed digest header format slightly, but changed the code more to
use keyword format strings instead of order-dependent ones, to make
reorganizing the text a lot less fragile.
(I'm coming to think that having a footer is mostly undesirable, so
mm_cfg.DEFAULT_DIGEST_FOOTER should be the empty string.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
thanks to janne sinkkonen.
Date: 14 Apr 1998 01:22:26 +0300
From: Janne Sinkkonen <janne@avocado.pc.helsinki.fi>
To: klm@python.org
Subject: Re: [Mailman-developers] late on new mailman release - soon
I guess this patch is necessary to get sensible welcome messages:
*** mm_deliver.py Tue Apr 14 01:21:27 1998
--- mm_deliver.py~ Sun Apr 12 04:37:30 1998
***************
*** 168,175 ****
header = ''
welcome = ''
! body = (SUBSCRIBEACKTEXT % (self.real_name, self.host_name,
! header, welcome,
self.GetScriptURL('listinfo'),
self.GetOptionsURL(name),
self.real_name, self.host_name,
--- 168,175 ----
header = ''
welcome = ''
! body = (SUBSCRIBEACKTEXT % (header, welcome,
! self.real_name, self.host_name,
self.GetScriptURL('listinfo'),
self.GetOptionsURL(name),
self.real_name, self.host_name,
--
Janne Sinkkonen <janne@iki.fi> <URL: http://www.iki.fi/~janne/ >
|
| |
|
|
| |
whatever mail delivery agent is there.
|
| | |
|
| |
|
|
|
| |
provided a refinement of the code that's not naive about continuation
lines.)
|
| | |
|