Re: [Mailman-Developers] MM3: list disabling/enabling?
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 able to login to the disabled lists in the web interface, but maybe not the list admins.
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.
However, it's probably possible to do what you want by putting the list on emergency moderation, and changing the message, is it not? Or something similar?
If that is possible, then what's required is simply a web interface to simplify that process.
-- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148
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 disabled lists, and that 5xx error should propagate through the MTA.
-Barry
- Barry Warsaw <barry@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 could reject messages addressed to disabled lists, and that 5xx error should propagate through the MTA.
Is disabling a list a temporary measure? If it is, should the server reply a temporary error?
421 <domain> Service not available, closing transmission channel
(This may be a reply to any command if the service knows it
must shut down)
450 Requested mail action not taken: mailbox unavailable
(e.g., mailbox busy)Or is it permanent?
550 Requested action not taken: mailbox unavailable
(e.g., mailbox not found, no access, or command rejected
for policy reasons)p@rick
-- state of mind () Digitale Kommunikation
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
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 class errors (temporary errors) are generally reserved for situations where the _intention_ is that the mail should go through but is prevented from doing so by problems for which a solution is in progress. A 400 class error causes the originating system to cache and re-try delivery, so if a list returns a 400 class error, it's just "delayed", not truly "disabled". This may be a fine distinction, and if a list is disabled for technical reasons with the intention of bringing it back up in short order without losing traffic, then perhaps a 400 class error would be more appropriate.
-- Lindsay Haisley | "We have met the enemy, and it is us." FMP Computer Services | 512-259-1190 | -- Pogo http://www.fmp.com |
- Lindsay Haisley <fmouse@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 class error (permanent error). 400 class errors (temporary errors) are generally reserved for situations where the _intention_ is that the mail should go through but is prevented from doing so by problems for which a solution is in progress. A 400 class error causes the originating system to cache and re-try delivery, so if a list returns a 400 class error, it's just "delayed", not truly "disabled". This may be a fine distinction, and if a list is disabled
ACK. Looking at the available codes I guess the best return code would probably be 550:
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 Numeric Order>
p@rick
-- state of mind ()
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
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 Numeric Order>
That would be my preference too. I recently had a use case for something like this. The import-sig on python.org was retired a few years ago, but I just resurrected it for the PEP 382 discussion. I probably would have used this feature for these sigs.
It does lead me to think that "retired" might be a better term, and it makes me wonder whether actions like subscribing to a retired list would still be allowed.
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.
-Barry
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 disable the *whole list* and at the same time leave retries up to arbitrary MTAs out on the Internet. The poster may or may not get a DSN. Etc, etc.
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 sufficient reason it could be a 4xx code, but we don't know of any examples offhand :-)."
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 understand under what circumstances a list owner would want to disable the *whole list* and at the same time leave retries up to arbitrary MTAs out on the Internet. The poster may or may not get a DSN. Etc, etc.
I agree. I think I like the term "retire" better than "disable" to more clearly designate a step in a list's life between active and deleted.
A retired list would still exist, and people could (maybe?) still subscribe to it, etc. I think the core wouldn't treat retired lists much different than active lists except to either omit its aliases from regeneration, or give the appropriate LMTP code. One thing to think about is how MTAs like Exim will work since they don't use an alias file.
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 sufficient reason it could be a 4xx code, but we don't know of any examples offhand :-)."
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? :)
-Barry
- Barry Warsaw <barry@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 sufficient reason it could be a 4xx code, but we don't know of any examples offhand :-)."
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? :)
A configurable reply could provide a hint along the 550 like this:
550 See: http://list.example.com/550/listnameThe listname ressource could inform why the list was retired e.g. because it was relocated or closed or where to find the retired lists archives ...
p@rick
-- state of mind ()
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
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/listnameThe listname ressource could inform why the list was retired e.g. because it was relocated or closed or where to find the retired lists archives ...
That's not a bad idea. So, we'd definitely want to record a reason for the status change to "retired".
-Barry
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 reason I can think of for configurability at this point.
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, the only appropriate 5xx code is 550. So there's no reason I can think of for configurability at this point.
Sure, 550 is appropriate, but an rfc1893/2034 enhanced error code should be used, too. These might be useful:
X.1.0 Other address status X.1.6 Destination mailbox has moved, No forwarding address X.2.1 Mailbox disabled, not accepting messages
Also, there's a case for customising the text returned, if not the error code.
-- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148
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 server in Mailman could reject messages addressed to disabled lists, and that 5xx error should propagate through the MTA.
Yes, this should be used in combination with a call forward from the MTA at RCTP TO, so that it the MTA can determine the status of the mailing list *before* giving a reply to the sending MTA.
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.ac.u...
Security Policy: http://wiki.list.org/x/QIA9
-- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148
participants (5)
-
Barry Warsaw -
Ian Eiloart -
Lindsay Haisley -
Patrick Ben Koetter -
Stephen J. Turnbull