Impacted versions

• Modoboa: 1.10.1
• installer used: Yes ?
• Webserver: Nginx

OS: centos 7.4

Steps to reproduce

Upgrade from 1.9.0

Current behavior

Can't open quarantine - Internal Error I have put Debug on, should open the debug log on modoboa ? can't see nothing on log files.

Impacted versions

• Modoboa: 1.8.2
• installer used: Yes
• Webserver: Nginx

When logging in to modoboa, for one particular domain I am unable to edit anything. For example, if I try to disable the domain and click update nothing happens. For that matter, any field I edit -- once I click update nothing happens. Changes are not saved and there are no error messages. However, I can go into the individual accounts within that domain and edit them without a problem. I can login to webmail without a problem. The accounts are able to send and receive email.

Impacted versions

• OS Type: Debian/Ubuntu
• OS Version: 20.0
• installer used: Yes
• Webserver: Nginx

Steps to reproduce

I installed my server Connect with admin and create simple user email Send my first email and it work Receive my first email and it work I connect my account to outlook with: mail server: mail.exemple.com username: [email protected] pass: pass Incoming port: 993 SSL Outgoing port: 587 STARTTLS I connected successfuly and I can see my email

Current behavior

When I try to send email from outlook I got an error I connected my account with node mailer and I got this error message: response: '451 4.3.5 [email protected]: Recipient address rejected: Server configuration problem'

Expected behavior

I should be able to send my mail from outlook as I do from my webmail

On my Modoboa server, the policyd upload limit is not reset every day.

So, my sending limit is lowered each time I send a mail, and never goes back up.

Impacted versions; 2.0.1

• Tested with Ubuntu 22.04 (But is almost certainly the same no matter what distro/version.)
• Modoboa: 2.0.1
• installer used: Yes
• Webserver: Nginx

Steps to reproduce

Simply do a standard setup with the installer. Go into the API documentation link

I have not checked EVERY API call, but I've checked quite a number and it's been the same in every case.

The examples when you "Try it out" show the "Authorization" header like this: -H 'Authorization: API Key Here'

However this ALWAYS FAILS, because it's wrong. (You get a warning/error that you haven't authenticated., and indeed, contrary to what you might think, you haven't "properly" authenticated.)

The proper header is -H 'Authorization: Token API Key Here'

So, for example, if the API Key was ABCDE the header should look like this: -H 'Authorization: Token ABCDE'

This works. Personally tested and verified.

I'd be glad to try to generate a PR to fix this error in the docs/examples, but have no idea where to find it in the code/project. Some simple greps haven't been helpful. So, some pointers would be good.

Hello everyone,

I don't think i'm the only one to have this issue. When I do all the configuration for domain and the DKIM box it's green, my mail don't pass dkim on gmail or other webmail, can someone help me to fix that please, i read some articles about openDKIM on mobodoa website or github but don't work for me, or I fail somewhere.

Thanks in advance for your answer.

Hi, I'm trying to install the Radicale module, but whenever I try to run python manage.py migrate it gives me this error:

Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 302, in execute
    settings.INSTALLED_APPS
  File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 55, in __getattr__
    self._setup(name)
  File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 43, in _setup
    self._wrapped = Settings(settings_module)
  File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 99, in __init__
    mod = importlib.import_module(self.SETTINGS_MODULE)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/srv/modoboa/instance/instance/settings.py", line 255, in <module>
    from modoboa_amavis.settings import *
ImportError: No module named modoboa_amavis.settings

I got to say that this is a fresh installation.

Any idea what is missing?

Thanks.

I'm not experienced with Python, Postgre.

I have Modoboa 1.6.0 running on my mailserver . My install method was the 'easy', Python script method:

$ git clone https://github.com/modoboa/modoboa-installer $ cd modoboa-installer $ sudo ./run.py <mail server hostname>

I have read the docs describing how to update modoboa with new version, but I'm stuck on the deploy instructions.

Example from the docs: $ modoboa-admin.py deploy modoboa_example --collectstatic [--dburl default:database-url] [--extensions extensions]

What do I replace modoboa_example with?

How do I determine my --dburl values?

Any help is very appreciated!

Running the cronjobs (no matter under what account) triggers warning in syslog, like this

Dec 15 13:51:01 {hostname} mysqld: 141215 13:51:01 [Warning] Aborted connection {conn_id} to db: '{db_name}' user: '{db_user}' host: '{db_host}' (Unknown error)

example cronjob definition

0 0 * * * python /{modoboa_instance_path}/manage.py cleanlogs

Is this known issue, or problem of instance configuration? I'm not running it in virtualenv or anything special.

hi, i have new error without any reasson .. maybe restart or update any package .. but now have this :/

debian 10, maria 10.5 , nginx mainline, --

Mar 18 16:56:16 mail postfix/postscreen[20786]: CONNECT from [127.0.0.1]:57479 to [127.0.0.1]:25 Mar 18 16:56:16 mail postfix/postscreen[20786]: WHITELISTED [127.0.0.1]:57479 Mar 18 16:56:16 mail postfix/smtpd[20787]: connect from localhost[127.0.0.1] Mar 18 16:56:17 mail postfix/smtpd[20787]: warning: problem talking to server 127.0.0.1:9999: Success Mar 18 16:56:17 mail postfix/smtpd[20787]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 451 4.3.5 [email protected]: Recipient address rejected: Server configuration problem; from=[email protected] to=[email protected] proto=ESMTP helo=<email.domain1.net> Mar 18 16:56:17 mail postfix/smtpd[20787]: disconnect from localhost[127.0.0.1] ehlo=1 auth=1 mail=1 rcpt=0/1 rset=1 quit=1 commands=5/6

thanks a lot !

I am considering switching from ASSP to modoboa and I was curious if it is possible to setup things up so that modoboa is configured as a mail gateway with all mail (and users) residing on another system (like xmail or hMailServer)?

I know that I can do this with postfix and setting up relay_domains, relay_receipients, and transport configuration files, The question is -- will modoboa continue to work with this confirmation (including support for quarantine)?

Impacted versions

• Modoboa: 2.0.3

Steps to reproduce

python manage.py modo manage_dkim_keys

Notice it creates private_keys and populates the admin_domain table with public keys and a path to private key.

Expected behavior

Given the need to add a TXT record at the DNS end for each domain it would be very useful if this command provided them. That is it should for each .pem it creates spit something out like:

$ python manage.py modo manage_dkim_keys
Creating keys for mydomain.tld:
    private key written to: <path_to_private_key>
    public key: <the_public_key>
    DNS TXT record required:
        host: <selector>._domainkey.myserver.tld
        value: v=DKIM1; k=rsa; p=<the_public_key>
Creating keys for mydomain2.tld:
   ... etc

Arguably only if verbosity is greater than the default (of 1), i.e. 2 or 3, which assumes https://github.com/modoboa/modoboa/issues/2737 is fixed.

As it stands to create the text record I could not find any guidance, nor sign of the public key in the modoboa web interface, so fished it out of the admin_domain with pgadmin.

Impacted versions

• OS Type: Debian Linux
• OS Version: Bullseye
• Database Type: PostgreSQL
• Database version: 13
• Modoboa: 2.0.3
• installer used: No
• Webserver: Nginx

Steps to reproduce

• Have modoboa corncobs configured and run
• Observe entries in auth.log

Current behavior

The current model setup in Modoboa relies on a custom PasswordHasher implementation that uses doveadm pw -l to list all available password schemes in the local dovecot implementation.

From my observations this can lead to lots of unnecessary calls made during model initialisation, each of which results in a call to sudo and corresponding log entries, depending on the amount of users configured in the modoboa instance:

Biggest culprit seems to be the generate_rights command, which seems to initialise Models anew for each iteration of a loop, leading to pages of entries in auth.log just for a single invocation of the cron job.

While this issue can be alleviated somewhat by setting DOVECOT_SUPPORTED_SCHEMES in settings.py (which also allows "limiting" the schemes to only strong hashes), it makes the setup unresponsive to changes in the dovecot configuration (which seems like the original intent of the implementation).

Expected behavior

Ideally the results of the call should be cached, or maybe even retrieved in a separate cron job and stored in a config. While the configuration could change between calls to the user tables, the probability is comparatively low and the reduction of log spam would be appreciated.

Impacted versions

• Modoboa: 2.0.3

Steps to reproduce

Current behavior

Try this $ python manage.py modo manage_dkim_keys from an account that lacks write permissions for dkim_keys_storage_dir. It crashes, but it adds a dkim_private_key_path to the admin_domain table all the same, so that on subsequent runs, this command does nothing because the query for missing values does not return this domain any more.

So on fixing the write permissions, or running it from a privileged account, nothing happens unless you manually edit the database and inset an empty string in domain's dkim_private_key_path, after which a new .pem file is created as expected.

Expected behavior

If for any reason the .pem file cannot be created then the associated dkim_private_key_path field in the admin_domain table should be an empty string not and invalid path (pointing to a file that does not exist). Data integrity basically.

Impacted versions

• Modoboa: 2.0.3

Current behavior

try this:

Unknown command: '--verbosity'
Type 'manage.py help' for usage.

Expected behavior

Expect all commands and subcommands to honor the tips provided by help:

 python manage.py help modo
usage: manage.py modo [-h] [--version] [-v {0,1,2,3}] [--settings SETTINGS] [--pythonpath PYTHONPATH] [--traceback] [--no-color] [--force-color] [--skip-checks] {export,import,check_mx,manage_dkim_keys,repair} ...

Modoboa top management command.

options:
  -h, --help            show this help message and exit
  --version             show program's version number and exit
  -v {0,1,2,3}, --verbosity {0,1,2,3}
                        Verbosity level; 0=minimal output, 1=normal output, 2=verbose output, 3=very verbose output
  --settings SETTINGS   The Python path to a settings module, e.g. "myproject.settings.main". If this isn't provided, the DJANGO_SETTINGS_MODULE environment variable will be used.
  --pythonpath PYTHONPATH
                        A directory to add to the Python path, e.g. "/home/djangoprojects/myproject".
  --traceback           Raise on CommandError exceptions
  --no-color            Don't colorize the command output.
  --force-color         Force colorization of the command output.
  --skip-checks         Skip system checks.

subcommands:
  {export,import,check_mx,manage_dkim_keys,repair}
    export              Export domains or identities using CSV format
    import              Import identities from a csv file
    check_mx            Check defined domains.
    manage_dkim_keys
    repair              Check and fix known problems.

That includes -v

I haven't tried others, but expect they too got lost in the process.

After tinkering with the request headers for a bit, I've found that the Accept-Language (if it contains a supported and available translated language) will take precedence over the language actually setup in the modo boa profile.

Removing the header will revert this behaviour, which seems to have been introduced by the v2.0.0 interface (which also has the same issue).

Discussed in https://github.com/modoboa/modoboa/discussions/2519

hope this is sufficient, else let me know if you would change something. Bash won't be a login shell but since we clear the enviroment with sudo -i this should not have any meaningful impact