Re: Changing subscription address
by Abhilash Raj
> On Mar 18, 2021, at 8:29 PM, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote:
>
> Thank you for your comments, Allan!
>
> Allan Hansen writes:
>
>> On 3/15/21, 21:28 , "Stephen J. Turnbull" <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote:
>
>>> In the 'Mailman Settings' screen, List-based Preferences' tab,
>
>> You may mean the 'Subscriptions' tab.
>
> I did mean the 'List-Based Preferences' tab. The 'Subscriptions' tab
> is non-functional. It's in some sense aesthetically more pleasing
> than 'List-Based Preferences', but you have to do extra, unnecessary
> work to get anything done from the 'Subscriptions' tab. It may make
> sense to just get rid of the current 'Subscriptions' tab and rename
> 'List-based Preferences' to 'Subscriptions'.
+1 We can do that. I don’t think I’ve ever used the subscriptions tab
myself to do anything.
>
> The only functionality of 'Subscriptions' over 'List-based
> Preferences' is that it lists you once for each role and address
> (member, non-member, moderator, owner) that you have for that list.
> This is possibly more confusing than helpful for non-owners.
> Moderators get informed of their role every time they need to do
> something. And it's possible to be both a member and a non-member of
> a list, which is pretty confusing.
Yeah, technically you can be subscribed to a list with all possible roles at
the same time.
>
>> Under 'User profile for <name>', under the 'E-mail Addresses', add
>> button to ensure that 'Primary E-mail' is used for all lists.
>
> If you define "ensure" strictly, this would be a fair amount of work
> because it would require overriding the normal "cascade" of
> preferences, and incidentally a way to turn off that override. I'd
> rather not make the implementation so complicated.
>
> There does need to be a way to revert each option to inherit, and
> there currently doesn't seem to be one. The 'Preferences' interface I
> described in the previous post doesn't provide it either. I will
> think about that.
The implementation of this isn’t very difficult, but the UX of this is
something I don’t know how to implement in that page to be very
honest.
> It should be normally unnecessary to use the 'Preferences' interface,
> because the default subscription should be "use primary address". For
> people using the current versions of Mailman 3, who are already have a
> bunch of subscriptions with the same *explicit* address, I think it is
> good enough. But if there's demand for a "revert all to use primary
> address" button, that would be easy enough to add.
We do already have ability to switch from an explicit address to Primary
Address subscription. I would imagine it would be more than just a
button, but more like a dropdown to choose an email or primary address
and switch all subscriptions to that.
> Here's why I think such a button would be unnecessary in future
> versions of Mailman. What should happen if you subscribe by an
> address not already known to Mailman without creating an account in
> Postorius is
>
> 1. Mailman registers the address.
> 2. Mailman creates a User object to "own" that address, and makes
> that address the primary address for the User.
> 3. Mailman creates a subscription which links the User (not the
> address) to the mailing list so that the primary address is used.
>
> For addresses already known to Mailman, Mailman should look up the
> User registered to that address, and if the subscription address is
> the primary address, set "use primary address" for the subscription.
This is how Core actually does work[1] if you subscribe via Email and you
already have a primary address. It will lookup a user using the address
and if the address is the primary address of the user, it will subscribe
the primary address.
However, if it isn’t the primary address, and this is a new address, it will
subscribe the address instead of user because the address isn’t
verified at this point and hence can’t be a primary address. We could
extend the subscription workflow to add an additional step to set this
address as primary and subscribe the primary address.
Postorius has the full ability to define its own workflow because REST
API provides full expression capability and doesn’t enforce anything.
Previous versions didn’t had support for subscribing as Primary Address,
but that has since changed and is the default one in the dropdown.
This is for authenticated subscription, the anonymous subscribe works
similar to email -join command. Mass-subscribe is probably working the
same way.
[1]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/commands/eml_m…
>
> In this scheme, as far as I can see, your user doesn't need to do
> anything with the account until she wants to change the address. At
> that point she needs to activate the account:
>
> - visit her personal options page in Postorius
> - request a password reset (she doesn't have one yet, so she can't log
> in)
> - click the special link
> - set a password or link a social media account, and
> - finally change the address.
>
> Note that this is the bare minimum of work for her. She has to prove
> she can read mail at that address. Anything less, and *anybody* can
> change her subscriptions. We could omit requiring a new password,
> but it's not a lot of work once you've got to this point, while the
> "request, wait for email, click link, do work" dance is pretty
> annoying. Why make someone do it again next time?
>
> This is problematic if she's already lost access to the old address,
> of course, but in that case you're probably going to have to intervene
> anyway.
>
> I don't think Postorius requires her to do anything else, but if she
> wants to she can update her profile at that point.
>
> I have to check the code, and probably also ask Barry and the other
> folks who designed the current subscription mechanism in case there's
> some fatal flaw in the scheme above. But I think that should do what
> almost all "one address" users want, and it's probably what the
> majority of people who have multiple addresses and use different ones
> for different purposes want most of the time, too.
Like mentioned above, it should be possible to do what you suggest. I
am getting into the implementation details here, but the Subscription
workflow would need an additional flag that would verify an address
and use the flag to determine if it should subscribe the address or
addresses’s user if an address is provided to the workflow.
>
> Note to self of possible problems: (1) The primary address is where
> you would send administrative mail to the account holder and that
> might not be an appropriate address for the default subscription.
> (2) This is a pretty radical change from the current situation, so it
> might need to be an option for the list or domain owner.
>
>> And, indeed, new subscriptions should default to 'Use Primary.'
>
> I agree. I'm astonished that there are situations where they don't,
> to be quite honest. That's the whole point of having accounts in the
> first place -- having *one* source of information about the user
> rather than spreading it out over a bunch of lists.
>
>> Is that possible now?
>
> It is already the default for someone who subscribes by logging in to
> Postorius. I assume that it is *not* the default for someone who
> subscribes by email or mass subscription, otherwise you wouldn't have
> the problem.
>
>> Does a member have to have an account for me to set it up thus for
>> them?
>
> Yes. The primary address is an attribute of the account.
> Subscriptions can't know anything about a primary address unless there
> is an account. However, it should be possible to make this default
> for an account that hasn't been activated yet, such as in a mass
> subscription.
Primary Address is also an attribute of the Mailman User, so it should
be possible for an admin to set that for a user if the user doesn’t
have an account. When they sign up, they’d be able to manage
and update accordingly.
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. The list os “tasks” an admin can
do isn’t decided, but please feel free to write comments there about
things you’d like to be able to do as a server admin.
[2]: https://gitlab.com/mailman/postorius/-/merge_requests/605
>
> Regards,
> Steve
>
> _______________________________________________
> 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)
4 years, 3 months
Re: Mailman, etc. upgrade woes and persistent bugs
by Abhilash Raj
I am trying to distill some information from this discussion to be
used for the implementation in Postorius. I'll maybe reiterate a bit
of what Steve was saying just to confirm I am on the same page.
On Tue, Feb 16, 2021, at 7:23 AM, Stephen J. Turnbull wrote:
> No answer required, I think I understand the situation pretty well
> now. But if I'm missing something, I would very much appreciate
> criticism.
>
> Andreas Barth writes:
>
> > Well, currently these are exclusive-states, I'd rather see them as
> > or-able-states.
>
> Right, I understand that. I don't understand *why*.
>
> There are real costs to making them or-able. There are constraints:
> 'enabled' shouldn't (mustn't?) be or-able with any 'disabled-by-foo'
> state. Such invariants are finicky to code and tricky to maintain,
> compared to a simple "mutually exclusive".
>
> I guess you want to allow the or of any subset of disabled states, but
> presumably then they need to individually resettable in order for the
> admin to clear their disable without overriding a subscriber's
> preference or a bounce record. That set of controls is more complex,
> and requires additional mental effort on the part of anyone using
> them. If there are restrictions on which states can be or-ed, that's
> more coding and maintenance cost.
>
> Then there's the question whether the subscriber can override the admin's
> setting. If they can, why does the admin have this power in the first
> place?
>
> > > > - "disabled by member" (could be set by an admin as well of course)
> > >
> > > Currently this is determined by whether the logged in user is the
> > > subscriber or not. It's an interesting idea to allow it to be set by
> > > an admin. Then we could have the semantics that the only transition
> > > allowed from this state would be to enabled, so that admins would know
> > > the user had intentionally disabled and know not to enable without
> > > permission.
> >
> > Exactly.
>
> But if the admin should respect the DBS (disabled by subscriber)
> setting, DBS|DBA (disabled by admin) is logically equivalent to DBS.
> Are there use cases where the admin does not want to repect the
> subscriber's choice, and enables it anyway? What are they?
>
> > Or while importing from another server, and there are people who
> > have receiving mails disabled, this is the state that could be used
> > for it.
>
> Why wouldn't they get the exact state from the original server? Or do
> you mean from a non-Mailman server?
>
> > I expect that state to be the most-often used when setting a state
> > manually.
> >
> > For "who set that", I would consider having some kind of history as
> > useful (and displaying "last set by user / $person" to the admin but
> > not the user).
>
> Why not to the subscriber? As I explain below, the subscriber at
> least needs to be able to distinguish between DBA and DBB (disabled by
> bounce).
>
> Keeping history of who is additional complexity, consumes a minor
> amount of resources, and is insufficient to the purpose. Assuming
> that there are reasons for admins to disable/enable other than as a
> courtesy to a subscriber, that reason is presumably important. Not only
> will the subscriber not know, but one admin may forget, and there may be
> multiple admins.[1]
>
> I still don't see any reason for an admin to disable delivery other
> than as a courtesy to the subscriber or to the bounce processor.
>
> > > > - "disabled for administrative reasons" (only by admin but user
> > > > should be able to see it)
> > >
> > > I don't see why a user would need to see the difference. Unless
> > > you're suggesting that the user would not be able to reenable without
> > > asking the admin? What is the use case for this?
> >
> > I'm suggesting exactly that, yes. Why? Well, worked with user for too
> > long. ;)
> >
> > E.g. consider that seeing archives works only for subscribers. And the
> > subscriber in question complains about too many mails but still
> > re-enables getting mails. This is basically "an admin has blocked you
> > from more mails but not unsubscribed you". Might be an corner case,
> > but still. Might also be too unimportant.
>
> This is possible. If it occurs less than once in a million years,
> it's "too unimportant" to even think about.[2] Have you actually done
> this, or know anybody who has?
>
> Is it really different from "at request of subscriber"? Practically,
> the only difference I can see is if such a subscriber should be
> prevented from overriding DBA. Are you suggesting that?
>
> > > > - "bounced" (user and admin could reset it but not set it)
> > >
> > > Reenable but not set "bounced" is the current situation.
> >
> > Except if someone sets the state to "disabled" and then undo this, the
> > state is automatically cleared.
>
> This is possible, but it's not clear what harm would be done. In most
> cases, bounces are intermittent and clear themselves up, in which case
> this is the right thing. But if the subscriber bounces again, they'll
> get disabled again, only cost is a slight waste of resources.
>
> Here's how I would assess the issues. In the descriptions below, I am
> assuming that each state is the only "active" state.
>
> 1. DBS is probably a "vacation" or "post-only" setting. For that
> reason it should be re-enabled only by the subscriber (or by an
> admin at the request of the subscriber).
> 2. DBB is a "warning" and a minor convenience to the email system
> (slightly reducing traffic to mailboxes that are expected to fail,
> and perhaps avoiding some reputational damage to the list).
> Re-enabling much of the time causes no damage, as bounce disables
> are typically due to things like out of disk space, and are likely
> fixed by the time the subscription is reenabled. Most of the rest
> will be zombie mailboxes, which will rarely be reenabled, will
> quickly be redisabled by bounce, and at worst cause mild
> inconvenience. Finally, events like a Mailman upgrade and the
> April 2014 DMARC fiasco will be pretty evident, and the damage
> there has already been done, reenabling actually fixes it
> (although it may not be effective if the systemic problem hasn't
> been resolved).
> 3. DBA is interesting mostly to *subscribers*, who need to
> distinguish DBA (which the subscriber can reenable freely) from
> DBB (which warns the subscriber to get in touch with their
> postmaster). It's comforting to subscribers who may be sure they
> never disabled their subscription; otherwise, it's semantically
> identical to DBS as far as I can see.
>
> Am I missing something?
>
> It seems to me that given 1-3, assuming a 4-state design:
>
> 0. It's never unreasonable to re-enable, except DBS.
> 1. In the DBA state, changing to either DBS or DBB causes no
> problems. (Changing to DBB is unlikely, since no mail is being
> sent. However, it's possible, due to the race between Postorius
> and mail in transit, and due to spam and other spoofing of the
> list domain.)
> 2. In either of the other two states, we should never change to DBA.
> 3. In either of the other two states, if the other event occurs, you
> would want the state to be DBS|DBB. I contend that if we
> substitute DBS, little harm is done. If the subscriber reenables, it's
> on them to fix the bounce problem if it reoccurs in any case.
> Since the subscriber has deliberately set DBS, the admin should not
> reenable without permission of the subscriber (I think we're mostly in
> agreement on that).
>
> I think this 4-state design is much easier to design, validate, and
> maintain than the 16-state design you propose. If you're really
> worried about DBS|DBB, then we could have a 5-state design where
> enabling from DBS|DBB generates a warning that there may still be a
> bounce problem on the subscription. Instead, it could leave the
> subscription in state DBB, but that seems to me to be obnoxious, since
> there's little likelihood of harm from reenabling, and in many cases
> the bounce problem will have resolved itself in the meantime.
>
So it seems like we have some sort of agreement that we need all the
roles to be able to see all the 4 states. Roles here are basically Admin(
i.e. list owner/moderator/site admin) and Subscriber.
There is no access control to transition "from" any state but each value
of non-enabled states is sort of a role's way to disable the delivery. Not
all states are settable by all roles.
1. A subscriber can only transition from any to "enabled" or "by_user"
state but can see if delivery was disabled "by_admin" or "by_bounces"
as separate state in the Options page.
2. An admin can transition to "enabled", "by_user" and "by_moderator".
They should use "by_user" when acting on behalf of the user and other
when there are any administrative reason to disable delivery, whatever
that may be. I expect "by_admin" to be used sparingly, and I don't see
any use cases for it.
3. Mailman itself will use the "by_bounces" to disable delivery due to
bounces.
Is that an accurate description?
--
thanks,
Abhilash Raj (maxking)
4 years, 4 months
Django Internal Server Error on held_messages
by Hasan Berkay Çağır
Hello,
We've been running a Mailman3 instance with Debian 10's official package:
Mailman Core Version: GNU Mailman 3.2.1 (La Villa Strangiato)
Mailman Core API Version: 3.0
Mailman Core Python Version: 3.7.3 (default, Jan 22 2021, 20:04:44) [GCC 8.3.0]
For some reason, and only on some lists, when we try to see held messages on Postorius, we get an error message "An error occurred while processing your request." and the following error email:
"""
Internal Server Error: /postorius/lists/list.example.com/held_messages
KeyError at /postorius/lists/list.example.com/held_messages
'file'
Request Method: GET
Request URL: https://mailman.example.com/postorius/lists/list.example.com/held_messages
Django Version: 1.11.29
Python Executable: /usr/bin/uwsgi-core
Python Version: 3.7.3
Python Path: ['.', '', '/usr/lib/python37.zip', '/usr/lib/python3.7', '/usr/lib/python3.7/lib-dynload', '/usr/local/lib/python3.7/dist-packages', '/usr/lib/python3/dist-packages']
Server time: Thu, 24 Mar 2022 08:39:10 +0000
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/dist-packages/django/core/handlers/exception.py" in inner
41. response = get_response(request)
File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in _get_response
187. response = self.process_exception_by_middleware(e, request)
File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in _get_response
185. response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/lib/python3/dist-packages/django/contrib/auth/decorators.py" in _wrapped_view
23. return view_func(request, *args, **kwargs)
File "/usr/lib/python3/dist-packages/postorius/auth/decorators.py" in wrapper
58. return fn(*args, **kwargs)
File "/usr/lib/python3/dist-packages/postorius/views/list.py" in list_moderation
520. paginator_class=MailmanPaginator)
File "/usr/lib/python3/dist-packages/django_mailman3/lib/paginator.py" in paginate
72. objects = paginator.page(page_num)
File "/usr/lib/python3/dist-packages/django_mailman3/lib/paginator.py" in page
48. result = self.function(count=self.per_page, page=number)
File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/mailinglist.py" in get_held_page
134. return Page(self._connection, url, HeldMessage, count, page)
File "/usr/lib/python3/dist-packages/mailmanclient/restbase/page.py" in __init__
37. self._create_page()
File "/usr/lib/python3/dist-packages/mailmanclient/restbase/page.py" in _create_page
62. response, content = self._connection.call(self._build_url())
File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py" in call
99. raise HTTPError(url, response.status, content, response, None)
During handling of the above exception (HTTP Error 500: b'A server error occurred. Please contact the administrator.'), another exception occurred:
File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in inner
41. response = get_response(request)
File "/usr/lib/python3/dist-packages/postorius/middleware.py" in __call__
39. return self.get_response(request)
File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in inner
43. response = response_for_exception(request, exc)
File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in response_for_exception
93. response = handle_uncaught_exception(request, get_resolver(get_urlconf()), sys.exc_info())
File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in handle_uncaught_exception
135. extra={'status_code': 500, 'request': request},
File "/usr/lib/python3.7/logging/__init__.py" in error
1412. self._log(ERROR, msg, args, **kwargs)
File "/usr/lib/python3.7/logging/__init__.py" in _log
1519. self.handle(record)
File "/usr/lib/python3.7/logging/__init__.py" in handle
1529. self.callHandlers(record)
File "/usr/lib/python3.7/logging/__init__.py" in callHandlers
1591. hdlr.handle(record)
File "/usr/lib/python3.7/logging/__init__.py" in handle
905. self.emit(record)
File "/usr/lib/python3/dist-packages/django/utils/log.py" in emit
118. reporter = ExceptionReporter(request, is_email=True, *exc_info)
File "/usr/lib/python3/dist-packages/django/views/debug.py" in __init__
246. self.template_info = getattr(self.exc_value, 'template_debug', None)
File "/usr/lib/python3.7/tempfile.py" in __getattr__
614. file = self.__dict__['file']
Exception Type: KeyError at /postorius/lists/list.example.com/held_messages
Exception Value: 'file'
Request information:
USER: root
GET: No GET data
POST: No POST data
FILES: No FILES data
COOKIES:
rl_anonymous_id = '*'
rl_user_id = '*'
rl_group_id = '*'
rl_trait = '*'
rl_group_trait = '*'
rl_page_init_referrer = '*'
rl_page_init_referring_domain = '*'
csrftoken = '*'
sessionid = '*'
META:
CONTENT_LENGTH = ''
CONTENT_TYPE = ''
CSRF_COOKIE = '*'
DOCUMENT_ROOT = '/etc/nginx/html'
HTTPS = 'on'
HTTP_ACCEPT = 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8'
HTTP_ACCEPT_ENCODING = 'gzip, deflate, br'
HTTP_ACCEPT_LANGUAGE = 'en-US,en;q=0.5'
HTTP_CACHE_CONTROL = 'max-age=0'
HTTP_COOKIE = '*'
HTTP_DNT = '1'
HTTP_HOST = 'mailman.example.com'
HTTP_REFERER = 'https://mailman.example.com/postorius/lists/list.example.com/'
HTTP_SEC_FETCH_DEST = 'document'
HTTP_SEC_FETCH_MODE = 'navigate'
HTTP_SEC_FETCH_SITE = 'same-origin'
HTTP_TE = 'trailers'
HTTP_UPGRADE_INSECURE_REQUESTS = '1'
HTTP_USER_AGENT = 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:98.0) Gecko/20100101 Firefox/98.0'
PATH_INFO = '/postorius/lists/list.example.com/held_messages'
QUERY_STRING = ''
REMOTE_ADDR = '::1'
REMOTE_PORT = '58290'
REQUEST_METHOD = 'GET'
REQUEST_SCHEME = 'https'
REQUEST_URI = '/postorius/lists/list.example.com/held_messages'
SCRIPT_NAME = ''
SERVER_NAME = 'mailman.example.com'
SERVER_PORT = '443'
SERVER_PROTOCOL = 'HTTP/2.0'
uwsgi.core = 0
uwsgi.node = b'example.com'
uwsgi.version = b'2.0.18-debian'
wsgi.errors = <_io.TextIOWrapper name=2 mode='w' encoding='UTF-8'>
wsgi.file_wrapper = ''
wsgi.input = <uwsgi._Input object at 0x7f8f7a6bf870>
wsgi.multiprocess = False
wsgi.multithread = True
wsgi.run_once = False
wsgi.url_scheme = 'https'
wsgi.version = '(1, 0)'
Settings:
Using settings module settings
ABSOLUTE_URL_OVERRIDES = {}
ACCOUNT_AUTHENTICATION_METHOD = 'username_email'
ACCOUNT_DEFAULT_HTTP_PROTOCOL = 'https'
ACCOUNT_EMAIL_REQUIRED = True
ACCOUNT_EMAIL_VERIFICATION = 'mandatory'
ACCOUNT_UNIQUE_EMAIL = True
ADMINS = "(('Mailman Suite Admin', 'admin(a)example.com'),)"
ALLOWED_HOSTS = ['*']
APPEND_SLASH = True
AUTHENTICATION_BACKENDS = "('django.contrib.auth.backends.ModelBackend', 'allauth.account.auth_backends.AuthenticationBackend')"
AUTH_PASSWORD_VALIDATORS = '********************'
AUTH_USER_MODEL = 'auth.User'
BASE_DIR = '/usr/share/mailman3-web'
CACHES = {'default': {'BACKEND': 'django.core.cache.backends.locmem.LocMemCache'}}
CACHE_MIDDLEWARE_ALIAS = 'default'
CACHE_MIDDLEWARE_KEY_PREFIX = '********************'
CACHE_MIDDLEWARE_SECONDS = 600
COMPRESS_CACHEABLE_PRECOMPILERS = '()'
COMPRESS_CACHE_BACKEND = 'default'
COMPRESS_CACHE_KEY_FUNCTION = '********************'
COMPRESS_CLEAN_CSS_ARGUMENTS = ''
COMPRESS_CLEAN_CSS_BINARY = 'cleancss'
COMPRESS_CLOSURE_COMPILER_ARGUMENTS = ''
COMPRESS_CLOSURE_COMPILER_BINARY = 'java -jar compiler.jar'
COMPRESS_CSS_COMPRESSOR = 'compressor.css.CssCompressor'
COMPRESS_CSS_FILTERS = ['compressor.filters.css_default.CssAbsoluteFilter']
COMPRESS_CSS_HASHING_METHOD = 'mtime'
COMPRESS_DATA_URI_MAX_SIZE = 1024
COMPRESS_DEBUG_TOGGLE = None
COMPRESS_ENABLED = True
COMPRESS_JINJA2_GET_ENVIRONMENT = <function CompressorConf.JINJA2_GET_ENVIRONMENT at 0x7f8f7b50d598>
COMPRESS_JS_COMPRESSOR = 'compressor.js.JsCompressor'
COMPRESS_JS_FILTERS = ['compressor.filters.jsmin.JSMinFilter']
COMPRESS_MINT_DELAY = 30
COMPRESS_MTIME_DELAY = 10
COMPRESS_OFFLINE = True
COMPRESS_OFFLINE_CONTEXT = {'STATIC_URL': '/mailman3/static/'}
COMPRESS_OFFLINE_MANIFEST = 'manifest.json'
COMPRESS_OFFLINE_TIMEOUT = 31536000
COMPRESS_OUTPUT_DIR = 'CACHE'
COMPRESS_PARSER = 'compressor.parser.AutoSelectParser'
COMPRESS_PRECOMPILERS = "(('text/less', 'lessc {infile} {outfile}'), ('text/x-scss', 'sassc -t compressed {infile} {outfile}'), ('text/x-sass', 'sassc -t compressed {infile} {outfile}'))"
COMPRESS_REBUILD_TIMEOUT = 2592000
COMPRESS_ROOT = '/var/lib/mailman3/web/static'
COMPRESS_STORAGE = 'compressor.storage.CompressorFileStorage'
COMPRESS_TEMPLATE_FILTER_CONTEXT = {'STATIC_URL': '/mailman3/static/'}
COMPRESS_URL = '/mailman3/static/'
COMPRESS_URL_PLACEHOLDER = '/__compressor_url_placeholder__/'
COMPRESS_VERBOSE = False
COMPRESS_YUGLIFY_BINARY = 'yuglify'
COMPRESS_YUGLIFY_CSS_ARGUMENTS = '--terminal'
COMPRESS_YUGLIFY_JS_ARGUMENTS = '--terminal'
COMPRESS_YUI_BINARY = 'java -jar yuicompressor.jar'
COMPRESS_YUI_CSS_ARGUMENTS = ''
COMPRESS_YUI_JS_ARGUMENTS = ''
CSRF_COOKIE_AGE = 31449600
CSRF_COOKIE_DOMAIN = None
CSRF_COOKIE_HTTPONLY = False
CSRF_COOKIE_NAME = 'csrftoken'
CSRF_COOKIE_PATH = '/'
CSRF_COOKIE_SECURE = False
CSRF_FAILURE_VIEW = 'django.views.csrf.csrf_failure'
CSRF_HEADER_NAME = 'HTTP_X_CSRFTOKEN'
CSRF_TRUSTED_ORIGINS = []
CSRF_USE_SESSIONS = False
DATABASES = {'default': {'ENGINE': 'django.db.backends.mysql', 'NAME': 'mailman3web', 'USER': 'mailman3web', 'PASSWORD': '********************', 'HOST': 'localhost', 'PORT': '', 'OPTIONS': {'init_command': "SET sql_mode='STRICT_TRANS_TABLES'", 'charset': 'utf8mb4'}, 'ATOMIC_REQUESTS': False, 'AUTOCOMMIT': True, 'CONN_MAX_AGE': 0, 'TIME_ZONE': None, 'TEST': {'CHARSET': None, 'COLLATION': None, 'NAME': None, 'MIRROR': None}}}
DATABASE_ROUTERS = []
DATA_UPLOAD_MAX_MEMORY_SIZE = 2621440
DATA_UPLOAD_MAX_NUMBER_FIELDS = 1000
DATETIME_FORMAT = 'N j, Y, P'
DATETIME_INPUT_FORMATS = ['%Y-%m-%d %H:%M:%S', '%Y-%m-%d %H:%M:%S.%f', '%Y-%m-%d %H:%M', '%Y-%m-%d', '%m/%d/%Y %H:%M:%S', '%m/%d/%Y %H:%M:%S.%f', '%m/%d/%Y %H:%M', '%m/%d/%Y', '%m/%d/%y %H:%M:%S', '%m/%d/%y %H:%M:%S.%f', '%m/%d/%y %H:%M', '%m/%d/%y']
DATE_FORMAT = 'N j, Y'
DATE_INPUT_FORMATS = ['%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', '%b %d %Y', '%b %d, %Y', '%d %b %Y', '%d %b, %Y', '%B %d %Y', '%B %d, %Y', '%d %B %Y', '%d %B, %Y']
DEBUG = False
DEBUG_PROPAGATE_EXCEPTIONS = False
DECIMAL_SEPARATOR = '.'
DEFAULT_CHARSET = 'utf-8'
DEFAULT_CONTENT_TYPE = 'text/html'
DEFAULT_EXCEPTION_REPORTER_FILTER = 'django.views.debug.SafeExceptionReporterFilter'
DEFAULT_FILE_STORAGE = 'django.core.files.storage.FileSystemStorage'
DEFAULT_FROM_EMAIL = 'postorius(a)example.com'
DEFAULT_INDEX_TABLESPACE = ''
DEFAULT_TABLESPACE = ''
DISALLOWED_USER_AGENTS = []
EMAILNAME = 'example.com'
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
EMAIL_HOST = 'localhost'
EMAIL_HOST_PASSWORD = '********************'
EMAIL_HOST_USER = ''
EMAIL_PORT = 25
EMAIL_SSL_CERTFILE = None
EMAIL_SSL_KEYFILE = '********************'
EMAIL_SUBJECT_PREFIX = '[Django] '
EMAIL_TIMEOUT = None
EMAIL_USE_LOCALTIME = False
EMAIL_USE_SSL = False
EMAIL_USE_TLS = False
FILE_CHARSET = 'utf-8'
FILE_UPLOAD_DIRECTORY_PERMISSIONS = None
FILE_UPLOAD_HANDLERS = ['django.core.files.uploadhandler.MemoryFileUploadHandler', 'django.core.files.uploadhandler.TemporaryFileUploadHandler']
FILE_UPLOAD_MAX_MEMORY_SIZE = 2621440
FILE_UPLOAD_PERMISSIONS = None
FILE_UPLOAD_TEMP_DIR = None
FILTER_VHOST = False
FIRST_DAY_OF_WEEK = 0
FIXTURE_DIRS = []
FORCE_SCRIPT_NAME = None
FORMAT_MODULE_PATH = None
FORM_RENDERER = 'django.forms.renderers.DjangoTemplates'
HAYSTACK_CONNECTIONS = {'default': {'ENGINE': 'haystack.backends.whoosh_backend.WhooshEngine', 'PATH': '/var/lib/mailman3/web/fulltext_index'}}
HOSTNAME = 'localhost.local'
IGNORABLE_404_URLS = []
INSTALLED_APPS = "('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')"
INTERNAL_IPS = []
LANGUAGES = [('af', 'Afrikaans'), ('ar', 'Arabic'), ('ast', 'Asturian'), ('az', 'Azerbaijani'), ('bg', 'Bulgarian'), ('be', 'Belarusian'), ('bn', 'Bengali'), ('br', 'Breton'), ('bs', 'Bosnian'), ('ca', 'Catalan'), ('cs', 'Czech'), ('cy', 'Welsh'), ('da', 'Danish'), ('de', 'German'), ('dsb', 'Lower Sorbian'), ('el', 'Greek'), ('en', 'English'), ('en-au', 'Australian English'), ('en-gb', 'British English'), ('eo', 'Esperanto'), ('es', 'Spanish'), ('es-ar', 'Argentinian Spanish'), ('es-co', 'Colombian Spanish'), ('es-mx', 'Mexican Spanish'), ('es-ni', 'Nicaraguan Spanish'), ('es-ve', 'Venezuelan Spanish'), ('et', 'Estonian'), ('eu', 'Basque'), ('fa', 'Persian'), ('fi', 'Finnish'), ('fr', 'French'), ('fy', 'Frisian'), ('ga', 'Irish'), ('gd', 'Scottish Gaelic'), ('gl', 'Galician'), ('he', 'Hebrew'), ('hi', 'Hindi'), ('hr', 'Croatian'), ('hsb', 'Upper Sorbian'), ('hu', 'Hungarian'), ('ia', 'Interlingua'), ('id', 'Indonesian'), ('io', 'Ido'), ('is', 'Icelandic'), ('it', 'Italian'), ('ja', 'Japanese'), ('ka', 'Georgian'), ('kk', 'Kazakh'), ('km', 'Khmer'), ('kn', 'Kannada'), ('ko', 'Korean'), ('lb', 'Luxembourgish'), ('lt', 'Lithuanian'), ('lv', 'Latvian'), ('mk', 'Macedonian'), ('ml', 'Malayalam'), ('mn', 'Mongolian'), ('mr', 'Marathi'), ('my', 'Burmese'), ('nb', 'Norwegian Bokmål'), ('ne', 'Nepali'), ('nl', 'Dutch'), ('nn', 'Norwegian Nynorsk'), ('os', 'Ossetic'), ('pa', 'Punjabi'), ('pl', 'Polish'), ('pt', 'Portuguese'), ('pt-br', 'Brazilian Portuguese'), ('ro', 'Romanian'), ('ru', 'Russian'), ('sk', 'Slovak'), ('sl', 'Slovenian'), ('sq', 'Albanian'), ('sr', 'Serbian'), ('sr-latn', 'Serbian Latin'), ('sv', 'Swedish'), ('sw', 'Swahili'), ('ta', 'Tamil'), ('te', 'Telugu'), ('th', 'Thai'), ('tr', 'Turkish'), ('tt', 'Tatar'), ('udm', 'Udmurt'), ('uk', 'Ukrainian'), ('ur', 'Urdu'), ('vi', 'Vietnamese'), ('zh-hans', 'Simplified Chinese'), ('zh-hant', 'Traditional Chinese')]
LANGUAGES_BIDI = ['he', 'ar', 'fa', 'ur']
LANGUAGE_CODE = 'en-us'
LANGUAGE_COOKIE_AGE = None
LANGUAGE_COOKIE_DOMAIN = None
LANGUAGE_COOKIE_NAME = 'django_language'
LANGUAGE_COOKIE_PATH = '/'
LOCALE_PATHS = []
LOGGING = {'version': 1, 'disable_existing_loggers': False, 'filters': {'require_debug_false': {'()': 'django.utils.log.RequireDebugFalse'}}, 'handlers': {'mail_admins': {'level': 'ERROR', 'filters': ['require_debug_false'], 'class': 'django.utils.log.AdminEmailHandler'}, 'file': {'level': 'INFO', 'class': 'logging.handlers.RotatingFileHandler', 'filename': '/var/log/mailman3/web/mailman-web.log', 'formatter': 'verbose'}, 'console': {'class': 'logging.StreamHandler', 'formatter': 'simple'}}, 'loggers': {'django.request': {'handlers': ['mail_admins', 'file'], 'level': 'INFO', 'propagate': True}, 'django': {'handlers': ['file'], 'level': 'INFO', 'propagate': True}, 'hyperkitty': {'handlers': ['file'], 'level': 'INFO', 'propagate': True}, 'postorius': {'handlers': ['file'], 'level': 'INFO', 'propagate': True}}, 'formatters': {'verbose': {'format': '%(levelname)s %(asctime)s %(process)d %(name)s %(message)s'}, 'simple': {'format': '%(levelname)s %(message)s'}}}
LOGGING_CONFIG = 'logging.config.dictConfig'
LOGIN_REDIRECT_URL = 'list_index'
LOGIN_URL = 'account_login'
LOGOUT_REDIRECT_URL = None
LOGOUT_URL = 'account_logout'
MAILMAN_ARCHIVER_FROM = "('127.0.0.1', '::1')"
MAILMAN_ARCHIVER_KEY = '********************'
MAILMAN_REST_API_PASS = '********************'
MAILMAN_REST_API_URL = '********************'
MAILMAN_REST_API_USER = '********************'
MANAGERS = []
MEDIA_ROOT = ''
MEDIA_URL = ''
MESSAGE_STORAGE = 'django.contrib.messages.storage.fallback.FallbackStorage'
MESSAGE_TAGS = {40: 'danger'}
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')"
MIDDLEWARE_CLASSES = ['django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware']
MIGRATION_MODULES = {}
MONTH_DAY_FORMAT = 'F j'
NUMBER_GROUPING = 0
PASSWORD_HASHERS = '********************'
PASSWORD_RESET_TIMEOUT_DAYS = '********************'
POSTORIUS_TEMPLATE_BASE_URL = 'https://mailman.example.com/'
PREPEND_WWW = False
Q_CLUSTER = {'timeout': 300, 'save_limit': 100, 'orm': 'default', 'poll': 5}
ROOT_URLCONF = 'urls'
SECRET_KEY = '********************'
SECURE_BROWSER_XSS_FILTER = False
SECURE_CONTENT_TYPE_NOSNIFF = False
SECURE_HSTS_INCLUDE_SUBDOMAINS = False
SECURE_HSTS_PRELOAD = False
SECURE_HSTS_SECONDS = 0
SECURE_PROXY_SSL_HEADER = None
SECURE_REDIRECT_EXEMPT = []
SECURE_SSL_HOST = None
SECURE_SSL_REDIRECT = False
SERVER_EMAIL = 'root(a)example.com'
SESSION_CACHE_ALIAS = 'default'
SESSION_COOKIE_AGE = 1209600
SESSION_COOKIE_DOMAIN = None
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_NAME = 'sessionid'
SESSION_COOKIE_PATH = '/'
SESSION_COOKIE_SECURE = False
SESSION_ENGINE = 'django.contrib.sessions.backends.db'
SESSION_EXPIRE_AT_BROWSER_CLOSE = False
SESSION_FILE_PATH = None
SESSION_SAVE_EVERY_REQUEST = False
SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'
SETTINGS_MODULE = 'settings'
SHORT_DATETIME_FORMAT = 'm/d/Y P'
SHORT_DATE_FORMAT = 'm/d/Y'
SIGNING_BACKEND = 'django.core.signing.TimestampSigner'
SILENCED_SYSTEM_CHECKS = []
SITE_ID = 1
SOCIALACCOUNT_PROVIDERS = {}
STATICFILES_DIRS = '()'
STATICFILES_FINDERS = "('django.contrib.staticfiles.finders.FileSystemFinder', 'django.contrib.staticfiles.finders.AppDirectoriesFinder', 'compressor.finders.CompressorFinder')"
STATICFILES_STORAGE = 'django.contrib.staticfiles.storage.StaticFilesStorage'
STATIC_ROOT = '/var/lib/mailman3/web/static'
STATIC_URL = '/mailman3/static/'
TEMPLATES = [{'BACKEND': 'django.template.backends.django.DjangoTemplates', 'DIRS': [], 'APP_DIRS': True, 'OPTIONS': {'context_processors': ['django.template.context_processors.debug', 'django.template.context_processors.i18n', 'django.template.context_processors.media', 'django.template.context_processors.static', 'django.template.context_processors.tz', 'django.template.context_processors.csrf', 'django.template.context_processors.request', 'django.contrib.auth.context_processors.auth', 'django.contrib.messages.context_processors.messages', 'django_mailman3.context_processors.common', 'hyperkitty.context_processors.common', 'postorius.context_processors.postorius']}}]
TEST_NON_SERIALIZED_APPS = []
TEST_RUNNER = 'django.test.runner.DiscoverRunner'
THOUSAND_SEPARATOR = ','
TIME_FORMAT = 'P'
TIME_INPUT_FORMATS = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M']
TIME_ZONE = 'UTC'
USE_ETAGS = False
USE_I18N = True
USE_L10N = True
USE_THOUSAND_SEPARATOR = False
USE_TZ = True
USE_X_FORWARDED_HOST = True
USE_X_FORWARDED_PORT = False
WSGI_APPLICATION = 'wsgi.application'
X_FRAME_OPTIONS = 'SAMEORIGIN'
YEAR_MONTH_FORMAT = 'F Y'
"""
I've tried to debug this issue as much as I can but couldn't figure out anything. I wonder if anyone has encountered something like this or might have a clue about what's the problem here?
Thanks in advance,
Berkay
3 years, 3 months