On 16 Jul 2011, at 07:18, Stephen J. Turnbull wrote:
Barry Warsaw writes:
Do you really think it needs to be configurable? I mean, if we
can't think of a reason to not make it 5xx, why not just wait for
the first wishlist bug report? :)
No, on second thought after reviewing the codes,
Barry Warsaw writes:
Do you really think it needs to be configurable? I mean, if we
can't think of a reason to not make it 5xx, why not just wait for
the first wishlist bug report? :)
No, on second thought after reviewing the codes, the only appropriate
5xx code is 550. So there's no
On Jul 13, 2011, at 01:34 PM, Stephen J. Turnbull wrote:
Barry Warsaw writes:
But maybe the OP has a different use case in mind and we could have a need
for
both a long-term, permanently failing retired lists, and shorter term,
temporarily failing disabled lists.
I don't really
* Barry Warsaw ba...@list.org:
OTOH, I can imagine that for some purposes you might want a different
status code, and I don't see any good reason for making that
configurable and then restricting it to 5xx. Rather, document it as
this SHOULD be a 5xx code (in the RFC 2119 sense, ie, with
On Jul 15, 2011, at 09:23 PM, Patrick Ben Koetter wrote:
A configurable reply could provide a hint along the 550 like this:
550 See: http://list.example.com/550/listname
The listname ressource could inform why the list was retired e.g. because it
was relocated or closed or where to find
On 12 Jul 2011, at 16:11, Barry Warsaw wrote:
On Jul 12, 2011, at 01:06 PM, Ian Eiloart wrote:
Bouncing certainly is suboptimal, since it may create collateral spam. Better
to reject the message at SMTP time with a 5xx response than to bounce.
That's an interesting take on it. The LMTP
On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw wrote:
It sounds like a lot, but I'd think it's only a day or two of work, and I'm
happy to answer questions, review code, etc.
I would like to get the design right first, after reading the full
thread a couple of times, some thoughts:
By bounce I
HI Paul, or all others who want to get involved into mm3 WebUI
development.
I'm closly listening your dicsussion.
The WebUI is work in progress and there is nothing stable yet.
However if you're interested taking a look at the dev snippets take a
look at the following branches:
HI Paul, or all others who want to get involved into mm3 WebUI
development.
I'm closly listening your dicsussion.
The WebUI is work in progress and there is nothing stable yet.
However if you're interested taking a look at the dev snippets take a
look at the following branches:
I think bouncing at the MTA is slightly sub-optimal and that mailman
could generate a more informative bounce indicating how to contact the
server admin to get the list revived. Probably in the web interface
there could be a disabled lists category. Server admins would
probably want to be
On Jul 11, 2011, at 06:37 PM, Paul Wise wrote:
With our current setup the disabled (or graveyarded) list is removed
from the /var/lib/mailman/lists dir and the aliases regenerated, so
the MTA bounces messages to it and the admin interface for it cannot
be logged into. Disabled lists are listed in
On Jul 12, 2011, at 01:06 PM, Ian Eiloart wrote:
Bouncing certainly is suboptimal, since it may create collateral spam. Better
to reject the message at SMTP time with a 5xx response than to bounce.
That's an interesting take on it. The LMTP server in Mailman could reject
messages addressed to
Hi Barry, it's just a matter of seconds to add this enabled flag to the
django webui, just let me know once it is in core.
Am Dienstag, den 12.07.2011, 11:10 -0400 schrieb Barry Warsaw:
On Jul 11, 2011, at 06:37 PM, Paul Wise wrote:
With our current setup the disabled (or graveyarded) list
* Barry Warsaw ba...@list.org:
On Jul 12, 2011, at 01:06 PM, Ian Eiloart wrote:
Bouncing certainly is suboptimal, since it may create collateral spam. Better
to reject the message at SMTP time with a 5xx response than to bounce.
That's an interesting take on it. The LMTP server in Mailman
On Tue, 2011-07-12 at 17:23 +0200, Patrick Ben Koetter wrote:
Is disabling a list a temporary measure? If it is, should the server reply a
temporary error?
In my humble opinion, an intentionally disabled list should cause the
mail system to generate a 500 class error (permanent error). 400
* Lindsay Haisley fmo...@fmp.com:
On Tue, 2011-07-12 at 17:23 +0200, Patrick Ben Koetter wrote:
Is disabling a list a temporary measure? If it is, should the server reply a
temporary error?
In my humble opinion, an intentionally disabled list should cause the
mail system to generate a 500
On Jul 12, 2011, at 08:52 PM, Patrick Ben Koetter wrote:
550 Requested action not taken: mailbox unavailable (e.g., mailbox
not found, no access, or command rejected for policy reasons)
http://www.rfc-editor.org/rfc/rfc5321.txt, section 4.2.3. Reply
Codes in
Barry Warsaw writes:
But maybe the OP has a different use case in mind and we could have a need
for
both a long-term, permanently failing retired lists, and shorter term,
temporarily failing disabled lists.
I don't really understand under what circumstances a list owner would
want to
On Jul 11, 2011, at 12:22 AM, Paul Wise wrote:
For the Indymedia Mailman 2 install, we have a patch that allowed list
disabling (and later re-enabling). Disabled lists had their
settings/archives saved, did not accept mail and were listed on a
separate page to listinfo. For a long-lived large
On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw ba...@list.org wrote:
I've thought about this on and off over the years and still think it's a good
idea. No, MM3 does not have such a thing yet.
...
Yep
Ok, great.
but I'd like to understand the semantics first. Do messages to the list
get
Hi all,
For the Indymedia Mailman 2 install, we have a patch that allowed list
disabling (and later re-enabling). Disabled lists had their
settings/archives saved, did not accept mail and were listed on a
separate page to listinfo. For a long-lived large mailman server
serving local groups in
21 matches
Mail list logo
