Re: Problems with New MM3 Installation
by Jeff
Thanks Mark and Abhilash (who responded separately).
I have worked out all the issues I was having and now the list is running smoothly. The trick for POSTORIUS_TEMPLATE_BASE_URL with uwsgi was "http://[hostname]/mailman3/ <http://[hostname]/mailman3/>“.
I appreciate all the help I’ve received from this mailing list.
> On May 11, 2021, at 11:43 PM, Mark Sapiro <mark(a)msapiro.net> wrote:
>
> On 5/11/21 7:46 PM, Jeff wrote:
>>
>> I really appreciate your assistance. New messages are now being archived as expected, but I still have a few small remaining issues to work out with my MM3 installation:
>>
>> 1) some emails that arrived before I got the archive working are still sitting in:
>>
>> /usr/local/mailman3/mm/var/archives/prototype/[listname]@[domain]/new
>>
>> Strangely this includes at least one email that was archived. Should this directly be cleared as messages are archived? Is there a way to force it to be cleared?
>
> /usr/local/mailman3/mm/var/archives/prototype/[listname]@[domain] is a
> collection of messages in maildir format. This is how the prototype
> archiver stores messages. This has nothing to do with HyperKitty. It is
> a separate archiver. If you don't want messages to be stored there, you
> can disable the prototype archiver for the list by unchecking prototype
> in Postorius -> Settings -> Archiving -> Active archivers or disable it
> entirely for the installation by setting
> ```
> [archiver.prototype]
> enable: no
> ```
> in mailman.cfg
>
>> 2) Some messages that arrived while I was having other problems with the setup have been stored in:
>>
>> /usr/local/mailman3/mm/var/queue/shunt
>>
>> What should I do to get these messages processed?
>
>
> Assuming the issues that caused them to be shunted have been fixed, just
> run the command
> ```
> mailman unshunt
> ```
>
>> 3) Similar to above, some messages are in:
>>
>> /usr/local/mailman3/mm/var/queue/bad
>>
>> How can I get these messages processed?
>
>
> First examine the messages with
> ```
> mailman qfile /usr/local/mailman3/mm/var/queue/bad/<file>
> ```
> To be sure you want them. Also examine mailman.log for the times they
> were stored in the `bad` queue. You are looking for 'Skipping and
> preserving unparseable message: <file>' and/or 'SHUNTING FAILED,
> preserving original entry: <file> messages and you want to determine
> which runner preserved the message. There may be a 'whichq' entry in the
> message's metadata in which case, that's the answer.
>
> Once you have determined the queue, you can just move the .psv file from
> the bad queue to the appropriate queue, renaming it from .psv to .pck in
> the process.
>
>
>> 4 Modified the template for “list:admin:action:post” through Postorious and emails that arrived after that were put in the “shunt” queue. I traced this problem to POSTORIUS_TEMPLATE_BASE_URL. By default, it is set to "http://localhost:8000 <http://localhost:8000/>” which is where uwsgi is listening. However, uwsigi is listening for uwsgi:/ not http://. Should I change POSTORIUS_TEMPLATE_BASE_URL to “uwsgi://localhost:8000 <uwsgi://localhost:8000>” or keep http but make it something else?
>
>
> I know little about uwsgi. setting it to `uwsgi://localhost:8000` might
> work. You could also set it to the base URL that a user would use to
> access the web UI, e.g. `https://example.com` and that would presumably
> be proxied to uwsgi. For example, on the server for this list we have
> ```
> POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.mailman3.org'
> ```
> which gets proxied to gunicorn, but the idea is the same.
>
> --
> Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
> San Francisco Bay Area, California better use your sense - B. Dylan
> _______________________________________________
> Mailman-users mailing list -- mailman-users(a)mailman3.org
> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
4 years, 1 month
signup / registration error - permissions and cert chains
by David Newman
I'd like for regular (non-admin) list subscribers to be able to manage
their subscription preferences and view list archives.
However, when new users attempt to create logins from the Postorius
"Sign Up" page, the server returns the error pasted below, and displays
a "server error" page to users.
If I'm reading the error correctly, this is related to an inability to
verify the cert chain. The /etc/mailman3/settings.py file points to the
same cert and key files used by Nginx, Postfix, and Dovecot. Since TLS
works OK with these other services, it appears the cert and key are
valid. (Viewing the cert in a web browser also supports this.)
The keyfile has 0400 permissions. I tried changing this to 0640 and
making the keyfile owned by root:mailman. Even after restarting mailman3
and mailmanweb the same error occurs. (Permissions in the cert and key
directories and above are not blocking access.)
The etc/mailman3/settings.py file includes these settings:
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
EMAIL_HOST = 'localhost'
EMAIL_PORT = 25
EMAIL_HOST_USER = 'dnewman(a)networktest.com'
EMAIL_HOST_PASSWORD = 'wouldnt-you-like-to-know'
EMAIL_USE_TLS = 'True'
EMAIL_SSL_CERTFILE = '/etc/ssl/certs/myhost.crt'
EMAIL_SSL_KEYFILE = '/etc/ssl/private/myhost.key'
But this might only be for email, not Postorius/Django. I checked the
Mailman Web docs and settings reference but didn't see anything relevant
on either page.
https://docs.mailman3.org/en/latest/config-web.html
https://docs.mailman3.org/projects/mailman-web/en/latest/settings.html
What additional configuration is needed to allow regular users to create
and manage their own accounts?
Thanks.
dn
ERROR 2021-12-30 16:03:53,787 436935 django.request Internal Server
Error: /accounts/signup/
Traceback (most recent call last):
File
"/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/exception.py",
line 34, in inner
response = get_response(request)
File
"/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/base.py",
line 115, in _get_response
response = self.process_exception_by_middleware(e, request)
File
"/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/base.py",
line 113, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File
"/opt/mailman/venv/lib/python3.9/site-packages/django/views/generic/base.py",
line 71, in view
return self.dispatch(request, *args, **kwargs)
File
"/opt/mailman/venv/lib/python3.9/site-packages/django/utils/decorators.py",
line 43, in _wrapper
return bound_method(*args, **kwargs)
File
"/opt/mailman/venv/lib/python3.9/site-packages/django/views/decorators/debug.py",
line 76, in sensitive_post_parameters_wrapper
return view(request, *args, **kwargs)
File
"/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/views.py", line
230, in dispatch
return super(SignupView, self).dispatch(request, *args, **kwargs)
File
"/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/views.py", line
74, in dispatch
response = super(RedirectAuthenticatedUserMixin, self).dispatch(
File
"/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/views.py", line
204, in dispatch
return super(CloseableSignupMixin, self).dispatch(request, *args,
**kwargs)
File
"/opt/mailman/venv/lib/python3.9/site-packages/django/views/generic/base.py",
line 97, in dispatch
return handler(request, *args, **kwargs)
File
"/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/views.py", line
102, in post
response = self.form_valid(form)
File
"/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/views.py", line
248, in form_valid
return complete_signup(
File
"/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/utils.py", line
209, in complete_signup
return perform_login(
File
"/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/utils.py", line
175, in perform_login
send_email_confirmation(request, user, signup=signup, email=email)
File
"/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/utils.py", line
346, in send_email_confirmation
email_address.send_confirmation(request, signup=signup)
File
"/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/models.py",
line 62, in send_confirmation
confirmation.send(request, signup=signup)
File
"/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/models.py",
line 169, in send
get_adapter(request).send_confirmation_mail(request, self, signup)
File
"/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/adapter.py",
line 464, in send_confirmation_mail
self.send_mail(email_template,
emailconfirmation.email_address.email, ctx)
File
"/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/adapter.py",
line 136, in send_mail
msg.send()
File
"/opt/mailman/venv/lib/python3.9/site-packages/django/core/mail/message.py",
line 284, in send
return self.get_connection(fail_silently).send_messages([self])
File
"/opt/mailman/venv/lib/python3.9/site-packages/django/core/mail/backends/smtp.py",
line 102, in send_messages
new_conn_created = self.open()
File
"/opt/mailman/venv/lib/python3.9/site-packages/django/core/mail/backends/smtp.py",
line 67, in open
self.connection.starttls(keyfile=self.ssl_keyfile,
certfile=self.ssl_certfile)
File "/usr/lib/python3.9/smtplib.py", line 772, in starttls
context = ssl._create_stdlib_context(certfile=certfile,
File "/usr/lib/python3.9/ssl.py", line 787, in _create_unverified_context
context.load_cert_chain(certfile, keyfile)
PermissionError: [Errno 13] Permission denied
3 years, 6 months
Re: Non-ascii characters missing from Pipermail archive txt and gz downloads
by Ruth Ivimey-Cook
Hi Mark
I'm not sure, but I think the problems are to do with the program you
are using to view the txt file.
A modern mail reader understands the Content-type: header and will
adjust its character processing accordingly, but a .txt file has no
default character encoding, so any text editor will have to "use its
best judgement". Some will default to utf-8, because that is compatible
with 7-bit ASCII (NOT Latin1) while others will just put characters out
and hope for the best (esentially leaving the result to the encoding of
the font).
In theory, a UTF-encoded text file can begin with the "BOM" marker, a
sequence of characters which is supposed to indicate which variety of
Unicode is in use, but this is rarely present, especially for UTF-8.
Try looking at your text file with a UTF-8 capable text editor **and
ensure that you tell the editor to use the UTF-8 encoding**. I expect it
will look ok then.
Hope this helps,
Ruth
On 09/04/2021 13:52, Mark Dale via Mailman-users wrote:
> Mailman 2.1.34
> Debian 10
> Postfix
>
> Hi
>
> I'm hoping someone can shine a light on character encoding issue I've encountered.
>
> A plain-text email with non-ascii characters in the body gets posted to the list.
>
> As per Mark Sapiro's guide I've captured the incoming message to file.
>
> - https://www.mail-archive.com/mailman-users@python.org/msg73469.html
>
> The message is received by Mailman with the non-ascii characters displaying correctly.
>
> The header of that message has:
>
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
> Thunderbird/78.9.0
> MIME-Version: 1.0
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-AU
> Content-Transfer-Encoding: 8bit
>
> In the list's mbox file and archive webpage, the message displays the non-ascii characters correctly.
>
> In the archive's downloaded .txt (and also .gz) file, the non-ascii characters are missing and displayed as "?".
>
> I've copied the message text in below, from both the correct one from the email and the erroneous .txt file. Hopefully they won't get scrambled up when I send this.
>
> Any advice on getting the non-ascii characters written into the archive .txt file would be gratefully received.
>
> Thanks,
> Mark
>
>
> === Message text as okay in mbox and as shown on the archive webpage ===
>
> If one goes by the definition of veḷippaṭai as given in the Tamil Lexicon that the meaning of an ambiguous word should be disambiguated by a qualifying word, then aruvi āmpal does not conform to that definition since in the case of aruvi āmpal in Patiṟṟuppattu 63, aruvi is really made up of aru+vi, a compound. Moreover, the expression aṭai aṭuppu aṟiyā is already there to clarify that āmpal is a number and not a flower. Thus, aruvi simply provides information in addition to aṭai aṭuppu aṟiyā that āmpal is not a flower. The modern commentator Aruḷampalavaṉār also does not call it veḷippaṭai.
>
> ===
>
> === Message text with missing characters in te archive's txt and gz downloads ==
>
> If one goes by the definition of ve?ippa?ai as given in the Tamil Lexicon that the meaning of an ambiguous word should be disambiguated by a qualifying word, then aruvi ?mpal does not conform to that definition since in the case of aruvi ?mpal in Pati??uppattu 63, aruvi is really made up of aru+vi, a compound. Moreover, the expression a?ai a?uppu a?iy? is already there to clarify that ?mpal is a number and not a flower. Thus, aruvi simply provides information in addition to a?ai a?uppu a?iy? that ?mpal is not a flower. The modern commentator Aru?ampalava??r also does not call it ve?ippa?ai.
>
> ===
> _______________________________________________
> Mailman-users mailing list -- mailman-users(a)mailman3.org
> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
--
Software Manager & Engineer
Tel: 01223 414180
Blog: http://www.ivimey.org/blog
LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
4 years, 2 months
Hyperkitty - 'MySQL server has gone away'
by dancab＠caltech.edu
I just deployed Mailman3 last night. This is the first error message I've encountered from Hyperkitty. It looks like a MySQL configuration issue. I've done some tuning to the wait/timeouts but I'm still getting the error message. I suspect the root cause is the size of the message. mailman qfile shows the message has 84746 lines and the .pck file is 6.9M.
Let me know if there's more specific tuning that needs to be done to cover larger messages.
My MySQL wait/timeouts are set as follows:
MySQL [mysql]> SHOW VARIABLES LIKE "%timeout%";
+-----------------------------+----------+
| Variable_name | Value |
+-----------------------------+----------+
| connect_timeout | 120 |
| delayed_insert_timeout | 300 |
| have_statement_timeout | YES |
| innodb_flush_log_at_timeout | 1 |
| innodb_lock_wait_timeout | 50 |
| innodb_rollback_on_timeout | ON |
| interactive_timeout | 28800 |
| lock_wait_timeout | 31536000 |
| net_read_timeout | 90 |
| net_write_timeout | 90 |
| rpl_stop_slave_timeout | 31536000 |
| slave_net_timeout | 60 |
| wait_timeout | 28800 |
+-----------------------------+----------+
13 rows in set (0.002 sec)
MySQL [mysql]> SHOW VARIABLES LIKE "%wait%";
+---------------------------------------------------+----------+
| Variable_name | Value |
+---------------------------------------------------+----------+
| innodb_lock_wait_timeout | 50 |
| innodb_spin_wait_delay | 6 |
| lock_wait_timeout | 31536000 |
| performance_schema_events_waits_history_long_size | 0 |
| performance_schema_events_waits_history_size | 0 |
| wait_timeout | 28800 |
+---------------------------------------------------+----------+
6 rows in set (0.004 sec)
##############################################
#######################
ERROR 2021-11-05 09:26:28,656 261 django.request Internal Server Error: /hyperkitty/api/mailman/archive
Traceback (most recent call last):
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/backends/utils.py", line 86, in _execute
return self.cursor.execute(sql, params)
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/backends/mysql/base.py", line 74, in execute
return self.cursor.execute(query, args)
File "/opt/mailmanve/lib/python3.6/site-packages/MySQLdb/cursors.py", line 206, in execute
res = self._query(query)
File "/opt/mailmanve/lib/python3.6/site-packages/MySQLdb/cursors.py", line 319, in _query
db.query(q)
File "/opt/mailmanve/lib/python3.6/site-packages/MySQLdb/connections.py", line 259, in query
_mysql.connection.query(self, query)
MySQLdb._exceptions.OperationalError: (2006, 'MySQL server has gone away')
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/mailmanve/lib/python3.6/site-packages/django/core/handlers/exception.py", line 34, in inner
response = get_response(request)
File "/opt/mailmanve/lib/python3.6/site-packages/django/core/handlers/base.py", line 115, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/opt/mailmanve/lib/python3.6/site-packages/django/core/handlers/base.py", line 113, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/opt/mailmanve/lib/python3.6/site-packages/django/views/decorators/http.py", line 40, in inner
return func(request, *args, **kwargs)
File "/opt/mailmanve/lib/python3.6/site-packages/hyperkitty/views/mailman.py", line 118, in _decorator
return func(request, *args, **kwargs)
File "/opt/mailmanve/lib/python3.6/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
return view_func(*args, **kwargs)
File "/opt/mailmanve/lib/python3.6/site-packages/hyperkitty/views/mailman.py", line 164, in archive
add_to_list(mlist_fqdn, msg)
File "/opt/mailmanve/lib/python3.6/site-packages/hyperkitty/lib/incoming.py", line 153, in add_to_list
email.save()
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/models/base.py", line 749, in save
force_update=force_update, update_fields=update_fields)
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/models/base.py", line 787, in save_base
force_update, using, update_fields,
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/models/base.py", line 890, in _save_table
results = self._do_insert(cls._base_manager, using, fields, returning_fields, raw)
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/models/base.py", line 929, in _do_insert
using=using, raw=raw,
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/models/manager.py", line 82, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/models/query.py", line 1204, in _insert
return query.get_compiler(using=using).execute_sql(returning_fields)
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/models/sql/compiler.py", line 1394, in execute_sql
cursor.execute(sql, params)
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/backends/utils.py", line 68, in execute
return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/backends/utils.py", line 77, in _execute_with_wrappers
return executor(sql, params, many, context)
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/backends/utils.py", line 86, in _execute
return self.cursor.execute(sql, params)
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/utils.py", line 90, in __exit__
raise dj_exc_value.with_traceback(traceback) from exc_value
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/backends/utils.py", line 86, in _execute
return self.cursor.execute(sql, params)
File "/opt/mailmanve/lib/python3.6/site-packages/django/db/backends/mysql/base.py", line 74, in execute
return self.cursor.execute(query, args)
File "/opt/mailmanve/lib/python3.6/site-packages/MySQLdb/cursors.py", line 206, in execute
res = self._query(query)
File "/opt/mailmanve/lib/python3.6/site-packages/MySQLdb/cursors.py", line 319, in _query
db.query(q)
File "/opt/mailmanve/lib/python3.6/site-packages/MySQLdb/connections.py", line 259, in query
_mysql.connection.query(self, query)
django.db.utils.OperationalError: (2006, 'MySQL server has gone away')
3 years, 8 months
Re: Race condition when mass subscribing same email addresses to two lists?
by Abhilash Raj
> On Oct 28, 2021, at 6:46 AM, Stephen J. Turnbull <stephenjturnbull(a)gmail.com> wrote:
>
> Alan So writes:
>
>> 1) Create two lists with default setting
>> 2) Prepare a list of 1000 fresh email addresses not added to the
>> system before
>> 3) Mass subscribe both lists of these 1000 email addresses around
>> the same time with all three Pre (confirm, approved, verified)
>> checked
> [...]
>> (psycopg2.errors.UniqueViolation) duplicate key value violates
>> unique constraint "ix_address_email"
>> DETAIL: Key (email)=(testemail999(a)example.com) already exists.
>
> I think there's some kind of race condition. I would bet it's in
> Mailman core, not in the RDMBS code or the ORM. The process is
>
> 1. Check if the address is known.
> 2. If yes:
> a. Get the address's user.
> b. Add the subscription pair (address, list) to the user.
> c. Add the address to the list.
> 3. If no:
> a. Create the address object.
> b. Create a user for the address, and link them together.
> c. Add the subscription pair (address, list) to the user.
> d. Add the address to the list.
>
> Each line is a separate database query, I suspect, so the race is
> between 1 and 3a. If two requests for the same new address arrive at
> the "same" time, both will try to create the address, only one can
> succeed.
>
> I guess we should catch the error and retry. Raising and handling
> exceptions in Python is relatively slow, so even in your well
> constructed worst case, this shouldn't happen on every address, so I
> don't think having a separate queue or putting the whole thing in a
> transaction would be better. If you still have the log, I'd be
> curious to know how many unique errors you got.
So, at this point, the mass subscribe feature will call the API once for
each address. Each REST call in Core is wrapped in a transaction, so
when one address is already created by a separate web worker, it
will fail the transaction when others try to create.
I am not sure if we have an easy way to handle this kind of races. From
the purposes of the API code, they both were able to successfully subscribe
the user and create the address but the database rejected the changes
from being committed and transaction was rolled back as it violated the
constraints. By the time this exception is raised, the entire API code is
done executing, so where do handle the psycopg2.errors.UniqueViolation
exception is a big question.
With the multiprocessing model of runners and multiple web workers,
this kind of situation is basically what we would want where the integrity
of the database is preserved by constraints we put in the table definitions
and the runners/web workers can continue to work assuming they have
the full control of the database without separately synchronizing with
each other.
The code for this lives here[1], which subscribes a new address to a
mailing list. It is the POST /3.1/members endpoint handler in API.
This is how we wrap every call to the WSGI app, i.e. each API call into
a transaction[2].
[1]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/rest/members.p…
[2]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/rest/wsgiapp.p…
Being able to prevent this kind of race condition is difficult if we want
to continue the support for multiple web workers for performance. I’ll
think more about how we can re-try on such errors though. It could
be either a client side re-try if we can figure out a way to signal the
client that this error was re-tryable.
Whether or not we are able to translate a UniqueViolation directly into
a retryable error code for Client really depends on whether there is
code in Core that relies on EAFP from database for functioning correctly,
since in those situations, the error, if raised, wouldn’t really be re-tryable
IMO. Fun problem to solve!
A pretty obvious workaround is to subscribed users serially instead of
parallell.
--
thanks,
Abhilash Raj (maxking)
3 years, 8 months
Unable to get mailman3 working on Ubuntu 20.04 LTS
by Michael Heseltine
Hi all,
after upgrading an older server to Ubuntu 20.04, I tried to first upgrade my old mailman 2 installation to mailman 3. I've been on it for three weeks now, but unable to get anything working. I have long forgone the idea of upgrading and thus purged everything from mailman2 on my machine, and installed and removed mailman3 several times to no avail.
My most recent try (it is currently an empty mailman installation) was done by calling
apt install mailman3 mailman3-full mailman3-web
and saying "yes" to every question. I'm using Mariadb as the database, and two databases called mailman3 and mailman3web (plus two users with the same names) have been created. I have configured a virtual host for apache (see below) and changed the mailman.cfg and mailman-weg.cfg to match (also see below).
I have restarted both mailman3 and mailman3-web several times now, but when I try to access the site, I just get
| Something went wrong
| Mailman REST API not available. Please start Mailman core.
plus an e-mail with subject
| [Django] ERROR (EXTERNAL IP): Service Unavailable: /mailman3/postorius/lists/
I'm running
| GNU Mailman 3.3.3b1 (Tom Sawyer)
| Python 3.8.10 (default, Sep 28 2021, 16:10:42)
Can anybody tell me what is going on? Also, the confirmation e-mail I got for registering a user says "example.com" in its subject line, even though I replaced every mention in the config files below with my actual URL.
Any help is appreaciated, I can provide logs or other data on request.
Cheers,
michael
/etc/mailman.mailman3.cfg
==================
site_owner: postmaster@<site>
noreply_address: noreply
default_language: en
sender_headers: from from_ reply-to sender
email_commands_max_lines: 10
pending_request_life: 3d
cache_life: 7d
pre_hook:
post_hook:
layout: debian
filtered_messages_are_preservable: no
html_to_plain_text_command: /usr/bin/lynx -dump $filename
listname_chars: [-_.0-9a-z]
[shell]
prompt: >>>
banner: Welcome to the GNU Mailman shell
use_ipython: no
history_file:
[paths.debian]
var_dir: /var/lib/mailman3
queue_dir: $var_dir/queue
bin_dir: /usr/lib/mailman3/bin
list_data_dir: $var_dir/lists
log_dir: /var/log/mailman3
lock_dir: $var_dir/locks
data_dir: $var_dir/data
cache_dir: $var_dir/cache
etc_dir: /etc/mailman3
ext_dir: $var_dir/ext
messages_dir: $var_dir/messages
archive_dir: $var_dir/archives
template_dir: $var_dir/templates
pid_file: /run/mailman3/master.pid
lock_file: $lock_dir/master.lck
[database]
class: mailman.database.mysql.MySQLDatabase
url: mysql+pymysql://mailman3:<password>@localhost/mailman3?charset=utf8&use_unicode=1
debug: no
[logging.debian]
format: %(asctime)s (%(process)d) %(message)s
datefmt: %b %d %H:%M:%S %Y
propagate: no
level: info
path: mailman.log
[webservice]
hostname: <site>
port: 8001
use_https: yes
show_tracebacks: yes
api_version: 3.1
admin_user: restadmin
admin_pass: <pass>
[mta]
incoming: mailman.mta.exim4.LMTP
outgoing: mailman.mta.deliver.deliver
smtp_host: localhost
smtp_port: 25
smtp_user:
smtp_pass:
lmtp_host: 127.0.0.1
lmtp_port: 8024
configuration: python:mailman.config.exim4
virtual host in Apache
===============
<VirtualHost <site>:443>
AssignUserID www-data www-data
ServerAdmin webmaster@<site>
ServerName <site>
SSLEngine on
DocumentRoot /webspace/mailman/www
ErrorLog /var/log/apache2/mm3_error_log
TransferLog /var/log/apache2/mm3_access_log
Alias /mailman3/favicon.ico /var/lib/mailman3/web/static/postorius/img/favicon.ico
Alias /mailman3/static /var/lib/mailman3/web/static
<Directory "/var/lib/mailman3/web/static">
Require all granted
</Directory>
<IfModule mod_proxy_uwsgi.c>
ProxyPass /mailman3/favicon.ico !
ProxyPass /mailman3/static !
ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost
</IfModule>
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/<site>/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/<site>/privkey.pem
</VirtualHost>
/etc/mailman3/mailman-web.cfg
=========================
SECRET_KEY = <secret>
ADMINS = (
('Mailman Suite Admin', 'root@localhost'),
)
ALLOWED_HOSTS = [
#"localhost", # Archiving API from Mailman, keep it.
# "lists.your-domain.org",
# Add here all production URLs you may have.
'*'
]
MAILMAN_REST_API_URL = 'http://localhost:8001'
MAILMAN_REST_API_USER = 'restadmin'
MAILMAN_REST_API_PASS = ''
MAILMAN_ARCHIVER_KEY = <secret>
MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1')
INSTALLED_APPS = (
'hyperkitty',
'postorius',
'django_mailman3',
'django.contrib.admin',
# 'django.contrib.admindocs',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
'rest_framework',
'django_gravatar',
'compressor',
'haystack',
'django_extensions',
'django_q',
'allauth',
'allauth.account',
'allauth.socialaccount',
'django_mailman3.lib.auth.fedora',
)
DATABASES = {
'default': {
# Use 'sqlite3', 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
'ENGINE': 'django.db.backends.mysql',
'NAME': 'mailman3web',
'USER': 'mailman3web',
'PASSWORD': <passwd>,
'HOST': 'localhost',
'PORT': '',
'OPTIONS': {
# Set sql_mode to 'STRICT_TRANS_TABLES' for MySQL. See
# https://docs.djangoproject.com/en/1.11/ref/
# databases/#setting-sql-mode
'init_command': "SET sql_mode='STRICT_TRANS_TABLES'",
},
}
}
USE_X_FORWARDED_HOST = True
LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = True
USE_L10N = True
USE_TZ = True
EMAILNAME = '<site>'
DEFAULT_FROM_EMAIL = 'postorius@{}'.format(EMAILNAME)
SERVER_EMAIL = 'root@{}'.format(EMAILNAME)
ACCOUNT_DEFAULT_HTTP_PROTOCOL = "https"
SOCIALACCOUNT_PROVIDERS = {
}
COMPRESS_OFFLINE = True
POSTORIUS_TEMPLATE_BASE_URL = 'http://localhost/mailman3/'
3 years, 8 months
Problems with web interface after upgrade
by Victoriano Giralt
Hi, I just applied all the recipes that have been recently posted for
upgrading (pip install --upgrade of all pieces, migrate, collectstatic)
The compress part refuses to work "OFF_LINE", whatever that is. I tried
with mailman running and stopped.
I can access hte main Postorius page and the basic list information,
but I cannot login nor access the archives. Operations end on two
exceptions logged to the log file (and two mail messages to the owner =
me). Very similar to what I get if I try to --force the "compress".
I'm sure I'm missing somethning, but do not know what ...
Thanks!
Traceback:
ERROR 2021-02-09 19:57:41,414 726 django.request Internal Server Error:
/listas/accounts/login/
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/compressor/base.py",
line 263, in precompile
mod = import_module(mod_name)
File "/usr/lib64/python3.6/importlib/__init__.py", line 126, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 994, in _gcd_import
File "<frozen importlib._bootstrap>", line 971, in _find_and_load
File "<frozen importlib._bootstrap>", line 953, in
_find_and_load_unlocked
ModuleNotFoundError: No module named 'sassc -t compressed {infile}
{outfile}'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-
packages/django/core/handlers/exception.py", line 34, in inner
response = get_response(request)
File "/usr/local/lib/python3.6/site-
packages/django/core/handlers/base.py", line 145, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/usr/local/lib/python3.6/site-
packages/django/core/handlers/base.py", line 143, in _get_response
response = response.render()
File "/usr/local/lib/python3.6/site-
packages/django/template/response.py", line 106, in render
self.content = self.rendered_content
File "/usr/local/lib/python3.6/site-
packages/django/template/response.py", line 83, in rendered_content
content = template.render(context, self._request)
File "/usr/local/lib/python3.6/site-
packages/django/template/backends/django.py", line 61, in render
return self.template.render(context)
File "/usr/local/lib/python3.6/site-
packages/django/template/base.py", line 171, in render
return self._render(context)
File "/usr/local/lib/python3.6/site-
packages/django/template/base.py", line 163, in _render
return self.nodelist.render(context)
File "/usr/local/lib/python3.6/site-
packages/django/template/base.py", line 937, in render
bit = node.render_annotated(context)
File "/usr/local/lib/python3.6/site-
packages/django/template/base.py", line 904, in render_annotated
return self.render(context)
File "/usr/local/lib/python3.6/site-
packages/django/template/loader_tags.py", line 150, in render
return compiled_parent._render(context)
File "/usr/local/lib/python3.6/site-
packages/django/template/base.py", line 163, in _render
return self.nodelist.render(context)
File "/usr/local/lib/python3.6/site-
packages/django/template/base.py", line 937, in render
bit = node.render_annotated(context)
File "/usr/local/lib/python3.6/site-
packages/django/template/base.py", line 904, in render_annotated
return self.render(context)
File "/usr/local/lib/python3.6/site-
packages/django/template/loader_tags.py", line 150, in render
return compiled_parent._render(context)
File "/usr/local/lib/python3.6/site-
packages/django/template/base.py", line 163, in _render
return self.nodelist.render(context)
File "/usr/local/lib/python3.6/site-
packages/django/template/base.py", line 937, in render
bit = node.render_annotated(context)
File "/usr/local/lib/python3.6/site-
packages/django/template/base.py", line 904, in render_annotated
return self.render(context)
File "/usr/local/lib/python3.6/site-
packages/compressor/templatetags/compress.py", line 131, in render
return self.render_compressed(context, self.kind, self.mode,
forced=forced)
File "/usr/local/lib/python3.6/site-
packages/compressor/templatetags/compress.py", line 107, in
render_compressed
rendered_output = compressor.output(mode, forced=forced)
File "/usr/local/lib/python3.6/site-packages/compressor/css.py", line
49, in output
ret.append(subnode.output(*args, **kwargs))
File "/usr/local/lib/python3.6/site-packages/compressor/css.py", line
51, in output
return super(CssCompressor, self).output(*args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/compressor/base.py",
line 295, in output
output = '\n'.join(self.filter_input(forced))
File "/usr/local/lib/python3.6/site-packages/compressor/base.py",
line 235, in filter_input
for hunk in self.hunks(forced):
File "/usr/local/lib/python3.6/site-packages/compressor/base.py",
line 205, in hunks
precompiled, value = self.precompile(value, **options)
File "/usr/local/lib/python3.6/site-packages/compressor/base.py",
line 268, in precompile
return True, filter.input(**kwargs)
File "/usr/local/lib/python3.6/site-
packages/compressor/filters/base.py", line 229, in input
return super(CachedCompilerFilter, self).input(**kwargs)
File "/usr/local/lib/python3.6/site-
packages/compressor/filters/base.py", line 196, in input
raise FilterError(err)
compressor.exceptions.FilterError: Error: It's not clear which file to
import for '@import "../libs/bootstrap/stylesheets/bootstrap"'.
Candidates:
../libs/bootstrap/stylesheets/_bootstrap.scss
../libs/bootstrap/stylesheets/bootstrap.scss
Please delete or rename all but one of these files.
on line 4 of static/hyperkitty/sass/hyperkitty.scss
>> @import "../libs/bootstrap/stylesheets/bootstrap";
^
--
Victoriano Giralt Innovation Director
Digital Transformation Vicerectorate University of Malaga
+34952131415 SPAIN
==================================================================
Note: signature.asc is the electronic signature of present message
A: Yes.
> Q: Are you sure ?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email ?
4 years, 4 months
Re: Error when disabling signup
by Abhilash Raj
> On Aug 17, 2021, at 3:31 AM, Rainer Herbst <rainer.herbst(a)aip.de> wrote:
>
> Dear all,
>
> over the last couple of weeks, I have installed and configured mailman3 using the docker containers.
>
> It took me some time, but now it works quite well. At last, I wanted to disable the sign-up because only LDAP users should be able to login.
>
> As described in django_mailman3/views/user_adapter.py, I added the following line
> to my settings_local.py:
> ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'
This isn’t going to work unless you are using the ‘rolling’ releases. The changes for disabling signups haven’t yet been released unfortunately.
>
>
> After that, an error is thrown:
> ModuleNotFoundError at /accounts/login/
> No module named 'django_mailman3.views.user_adapter'
>
> What could be the reason for that and how to solve it?
>
> Thanks in advance!
> Rainer
>
> Here is the traceback:
> Environment:
>
> Request Method: GET
> Request URL: https://mailman.aip.de:1443/accounts/login/?next=%2Faccounts%2Flogin%2F
>
> Django Version: 2.2.19
> Python Version: 3.8.5
> Installed Applications:
> ['hyperkitty',
> 'postorius',
> 'django_mailman3',
> 'django.contrib.admin',
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.sites',
> 'django.contrib.messages',
> 'django.contrib.staticfiles',
> 'rest_framework',
> 'django_gravatar',
> 'compressor',
> 'haystack',
> 'django_extensions',
> 'django_q',
> 'allauth',
> 'allauth.account',
> 'allauth.socialaccount']
> Installed Middleware:
> ('django.contrib.sessions.middleware.SessionMiddleware',
> 'django.middleware.common.CommonMiddleware',
> 'django.middleware.csrf.CsrfViewMiddleware',
> 'django.middleware.locale.LocaleMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> 'django.contrib.messages.middleware.MessageMiddleware',
> 'django.middleware.clickjacking.XFrameOptionsMiddleware',
> 'django.middleware.security.SecurityMiddleware',
> 'django_mailman3.middleware.TimezoneMiddleware',
> 'postorius.middleware.PostoriusMiddleware')
>
>
>
> Traceback:
>
> File "/usr/lib/python3.8/site-packages/django/core/handlers/exception.py" in inner
> 34. response = get_response(request)
>
> File "/usr/lib/python3.8/site-packages/django/core/handlers/base.py" in _get_response
> 115. response = self.process_exception_by_middleware(e, request)
>
> File "/usr/lib/python3.8/site-packages/django/core/handlers/base.py" in _get_response
> 113. response = wrapped_callback(request, *callback_args, **callback_kwargs)
>
> File "/usr/lib/python3.8/site-packages/django/views/generic/base.py" in view
> 71. return self.dispatch(request, *args, **kwargs)
>
> File "/usr/lib/python3.8/site-packages/django/utils/decorators.py" in _wrapper
> 45. return bound_method(*args, **kwargs)
>
> File "/usr/lib/python3.8/site-packages/django/views/decorators/debug.py" in sensitive_post_parameters_wrapper
> 76. return view(request, *args, **kwargs)
>
> File "/usr/lib/python3.8/site-packages/allauth/account/views.py" in dispatch
> 146. return super(LoginView, self).dispatch(request, *args, **kwargs)
>
> File "/usr/lib/python3.8/site-packages/allauth/account/views.py" in dispatch
> 74. response = super(RedirectAuthenticatedUserMixin, self).dispatch(
>
> File "/usr/lib/python3.8/site-packages/django/views/generic/base.py" in dispatch
> 97. return handler(request, *args, **kwargs)
>
> File "/usr/lib/python3.8/site-packages/allauth/account/views.py" in get
> 90. response = super(AjaxCapableProcessFormViewMixin, self).get(
>
> File "/usr/lib/python3.8/site-packages/django/views/generic/edit.py" in get
> 133. return self.render_to_response(self.get_context_data())
>
> File "/usr/lib/python3.8/site-packages/allauth/account/views.py" in get_context_data
> 173. signup_url = passthrough_next_redirect_url(
>
> File "/usr/lib/python3.8/site-packages/allauth/account/utils.py" in passthrough_next_redirect_url
> 444. next_url = get_next_redirect_url(request, redirect_field_name)
>
> File "/usr/lib/python3.8/site-packages/allauth/account/utils.py" in get_next_redirect_url
> 45. if not get_adapter(request).is_safe_url(redirect_to):
>
> File "/usr/lib/python3.8/site-packages/allauth/account/adapter.py" in get_adapter
> 535. return import_attribute(app_settings.ADAPTER)(request)
>
> File "/usr/lib/python3.8/site-packages/allauth/utils.py" in import_attribute
> 155. ret = getattr(importlib.import_module(pkg), attr)
>
> File "/usr/lib/python3.8/importlib/__init__.py" in import_module
> 127. return _bootstrap._gcd_import(name[level:], package, level)
>
> File "<frozen importlib._bootstrap>" in _gcd_import
> 1014. <source code not available>
>
> File "<frozen importlib._bootstrap>" in _find_and_load
> 991. <source code not available>
>
> File "<frozen importlib._bootstrap>" in _find_and_load_unlocked
> 973. <source code not available>
>
> Exception Type: ModuleNotFoundError at /accounts/login/
> Exception Value: No module named 'django_mailman3.views.user_adapter'
>
>
>
> Viele Grüße,
>
> Rainer Herbst
> Leiter IT-Service
> Phone: +49 331 7499-257
> e-mail: rainer.herbst(a)aip.de
> https://www.aip.de
>
> -----------------------------------------------------------------------------------------------
> Leibniz-Institut für Astrophysik Potsdam (AIP)
> An der Sternwarte 16, 14482 Potsdam
>
> Vorstand: Prof. Dr. Matthias Steinmetz, Wolfram Rosenbach
> Stiftung bürgerlichen Rechts
> Stiftungsverzeichnis Brandenburg: 26 742-00/7026
> -----------------------------------------------------------------------------------------------
>
> _______________________________________________
> Mailman-users mailing list -- mailman-users(a)mailman3.org
> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
--
thanks,
Abhilash Raj (maxking)
3 years, 10 months
Re: User management page [was: Changing subscription address]
by Abhilash Raj
> On Mar 20, 2021, at 6:22 AM, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote:
>
> Core implementation details, so I beinging this here from Mailman
> Users @ mailman3.org.
>
> Abhilash Raj writes:
>
>> I have started working on designing a User management page[2] in
>> Core which should make it easy for superuser to manage several
>> things about a User, including the ones that don’t have an account
>> in Postorius to manage their own.
>
> I don't understand this design with a "page in Core”.
Typo :( Page in Postorius is what I meant to say.
> I was thinking
> about this kind of problem, and tentatively came to the conclusion
> that any reference to something that can be resolved to a User should
> generate a Django account for that User in Postorius or HyperKitty.
Is that necessarily required? Every user in Django has a corresponding
user in Core, but the converse isn’t true and I am not sure if that is even
required.
The purpose of a Django account is to manage my own email
addresses and subscriptions. An admin can manage a Core User that
does or doesn’t have a Django account. The only thing that changes
is what they can do with that user. See below for my thoughts on the
actions an admin would be able to perform.
The high level design of that user management page is that it will provide
a list of Users straight from Core. When you go to an individual User’s
management page,
You will be able to see:
- Does the user have a Django account?
- All Subscriptions for the User
- All addresses of the User
You will be able to perform following actions:
- Add or remove a user’s address
- Verify or un-verify an address
- Set any address as primary for the user
- Update display name of the user
- Update address on any of the subscriptions
If the User has a Django account, you also be able to:
- Manage the User’s password *if* they are using password
for login and not social auth.
- Reset “social login” for the user?
- View some of the RO info about the Django User model, like
last login, superuser status or few other attributes that we feel
is useful for admin in any situation.
What I am on fence about:
- Provide a full blown preferences menu to the admin for that user. This
will also make the UI extremely complex to see and implement.
> Authorization to use that account would still require authentication
> via the usual email verification dance, or some level of admin
> privilege.
>
> The thing is that emails that have not been added to a User are
> unique. They will be the only Address attached to User created to
> manage them until authenticated, and transitively the only address
> attached to an automatically-created Django account (since those are
> 1-1 with core Users if they exist AFAIK).
In Core, when a new address (email1) comes in, a Mailman User(user1)
is created for it.
But, when you have an account in Django with a different email
(email2) and a different Mailman user (user2) and you add a second
email (email1) to your account and are able to prove ownership by
verifying the address, Django will ask Core to add that second address
(email1) to your Mailman user (user2) and absorb “user1”. This
process is already implemented.
However, if two Django accounts are created for “user1” and “user2”
then situation becomes more tricky and currently we don’t have a
way to resolve that short of delete one of the accounts and add the
addresses to other account.
> What's missing here is the ability to merge core Users and their
> corresponding Django accounts. Doing this with nothing more than the
> usual email verification dance is not *obviously* provably secure to
> me, so we need to be careful, but I think it probably will turn out to
> be as secure as you can get. It seems to me that User merging is the
> most pressing problem of this kind. (At least, it affects me on a
> couple of list hosts, as well as on GitHub and GitLab.)
>
>> [2]: https://gitlab.com/mailman/postorius/-/merge_requests/605
>
> I'll take a look tomorrow or early next week.
It is far from actually usable, so you can actually skip it for now ;-) I
can announce it when it is in semi-usable state.
--
thanks,
Abhilash Raj (maxking)
4 years, 3 months
Re: Mailman, etc. upgrade woes and persistent bugs
by Abhilash Raj
On Fri, Feb 12, 2021, at 8:52 PM, Stephen J. Turnbull wrote:
> Abhilash Raj writes:
>
> > The is definitely a bug, caused due to the fact that "Delivery Status" field
> > only has two options, "Enabled" and "Disabled". Internally, this field can
> > have 4 values, "enabled", "by_user" (maps to "Disabled" in Postorius),
> > "by_admin" (means disabled by admin) and "by_bounces" (means
> > disabled due to bounces). So, when the value of the field is among
> > the last two options, it appears as "unset" with no options selected,
> > which unfortunately is also how it looks by default since all options
> > are "unset" from start.
> >
> > The "fix" for this issue would be simply adding a new choice to the
> > delivery_status field with a caveat that it is only a Readonly option to
>
> I don't see why most users would care (there will always be somebody
> who cares "just because", of course). For those who don't care, I
> expect it will be confusing. I think it's better just to treat all of
> the disabled settings as just "disabled" in the UI for members.
I don't have any strong opinions on treating all disabled options as just
disabled for the user. Would List admins be interested in knowing more
details about that or should it be the same for them? I feel they might
be interested in such details. Brian mentioned that Affinity actually
details explicit value of the delivery_status, so maybe it is useful
for them?
>
> > We could also go a step further and show it on the List's info page
> > when their delivery is disabled due to excessive bounce and allow
> > the them to re-enable it themselves without admin intervention.
>
> This is probably a good idea, but in a situation where we know the
> problem is excessive bouncing we should caution them that there is
> almost certainly a probably with delivery *to their specific address*
> and that Mailman and the admins *can do nothing about that*, so if
> that isn't fixed they'll just get disabled again. I suppose it would
> be good to add that frequently these are due to occasional problems
> like disk full that "management" at their site normally takes care of,
> so there's little if any harm to just reenabling.
Yeah, a link to an FAQ entry in documentation perhaps?
I am thinking that most addresses disabled due to bounces would
really either be spam subscriptions or abandoned/invalid email
addresses that once were working. There would be few with problems
with delivery which would want to re-enable as soon as they can, but
definitely letting them know that there is an issue with delivery is a
good idea.
>
> > to the list's info page, but I guess that is the first place you'd go to
> > debug when you get an email that your delivery was disabled?
>
> Surely we can help them go directly there?
I guess yes, but that brings up the whole discussion about how does
Core know about the URLs. Custom templates can help get there
easily, but that will not solve the problem, only put the onus on list/server
admins to set that on a per-installation basis.
Although, we can add "Goto your list subscriptions to re-enable" your
subscription. Maybe even a new email command that allows re-enabling
subscription without logging into P?
>
> > https://gitlab.com/mailman/postorius/-/issues/470
> >
> > I don't know if there are any downsides to letting users re-enable
> > their delivery on their own.
>
> I don't see any myself. Maybe if the list is planning a surprise
> party for them? ;-)
Oh just Ban them in that case ;-)
> There is a specific downside, which is that if you only allow them to
> reenable if they disabled it themselves, you have to show them the
> other cases.
I was initially thinking that maybe we can disable changing the delivery
status if it was disabled by an admin ("by_admin" value), but AFAIK, there
is really no way to even set that right now and no real use case for that
has come up, so I am going to punt on that idea until someone really
asks for it with a valid use case ;-)
--
thanks,
Abhilash Raj (maxking)
4 years, 4 months