A
accolon

  • 8 hours ago
  • Joined Jul 28, 2021
  • 0 discussions
  • 202 posts
  • 36 best answers
  • Post posted... wait what? You got likes! I have something to say. Full-Time-Poster Pure love!+ 4 More
  • accolon The check is done via JavaScript on the client

    As @accolon pointed out this is done in your browser and not on the mailcow server! So maybe use your mobile in the regular mobile network, not your WiFi, and check again

  • That’s indeed a good solution. Thanks for the suggestion, @accolon!
    I do have stable private keys. I forgot that one can have multiple TLSA records.

    However, it would still be nice to have an automated solution in case the Let’s Encrypt intermediate gets compromised and has to be replaced.

  • Apologies for delay. This issue is still current, here is an update.

    I tried removing the deactivated domain, and then renewing the LE CT again. This had no effect. So the issue does not seem to be caused by the presence of a deactivated domain that doesn’t have the correct auto DNS records.

    Also, I’ve checked the logs as @esackbauer suggested and @accolon added to, and I don’t see any additional logs anywhere. I think what tiny-acme sends to std-out, is what appears in the CT shell, is what appears in Redis, and is what appears in the GUI log view. Am I wrong about this, is there some additional log somewhere?

    So - Can I start this up again by asking whether the generation of the autoconfig.* and autodiscover.* SANs in the LE cert has ever been known to work for anyone? If you have this working could you reply to confirm here please?

    I have a hunch what it could be, so I would like some examples to reference working. Thanks all in advance!

  • Hello @accolon, thank you for your reply.

    Unfortunately it seems the process has changed in nightly :

    I use roundcube with another stable mailcow stack and there is no trouble with classic authentication. Actually I am asking specifically for OIDC mechanism.

  • Update: Created a separate vars.local.inc.php file and added SESSION_LIFETIME parameter equal to 1,209,600 seconds which is equal to 14 days. Left the tab open, closed the browser and went to bed.
    Today, started computer, opened browser and found that I am still logged into admin GUI. So, it works.

    Thank you, @accolon

      • boospy

          Moolevel 9

        Aja, genau. Mehr wollte ich gar nicht wissen 🙂 🙂 . Hatte mir das schon so gedacht.

        Lieben Dank @accolon

      • Thanks for your quick replies!

        @DocFraggle Thanks for the advice, I’ve checked it with this tool, another pen-testing tool as well to lookout for the SUBMISSION port and in both scenarios the SUBMISSION port was reachable from outside.

        @accolon That’s a true bummer. I’ve read online, that relay services from amazon or setting up a VPN tunnel to another server, and redirecting the SMTP traffic from the VPN endpoint might work to overcome this ISP blockage issue, but unfortunately all of these methods cost too much in contrast to what I have. I don’t send many emails, it’s not for business use.

        Any ideas or advice to get over this?

        Any insights or solutions would be greatly appreciated. Thank you up until now!

        • pkernstock

          • Forum Staff
          • volunteer
          Moolevel 57
        • Edited

        Johnnii360 Echt jetzt… 4 Tage vergangen und keiner hat eine Idee oder ähnliches?! Das ist schon irgendwie… na ja…

        Es ist auch, wie der Name sagt, ein Community-Forum. Mit einem englischen Post haettest du auch hoechstwahrscheinlich eine groessere Nutzermenge erreicht.

        Johnnii360 Aktiviertes TLS 1.0 und 1.1 ist ziemlich fahrlässig, wenn man nur moderne Mail-Programme nutzt.

        Wie @accolon ansprach geht es hierbei um Server-to-Server Kommunikation. Meines Wissens nach: Wenn nur TLSv1.2 und TLSv1.3 hinterlegt ist und aeltere Mail-Server (soll vorkommen) weder noch supporten, wird keine Verschluesselung verwendet. In anderen Worten: Schlechtere Verschluesselung ist besser als gar keine.

        • ok I fixed the issue, obviously was my faulty configuration. Specifically:

          • the MAIL.DOMAIN.TLD nginx proxy config was faulty (thanks @accolon for the hint that allowed me to understand, I thought that SOGo needed a much more complex nginx proxy configuration)
          • The error on Sogo WebUI login (password policy 65535) was telling me that I was not allowed to login directly from the SOGo web interface. The reason was that my email user was missing a tick in the checkbox in the Mailcow web configuration under E-Mail -> Configuration -> (select and edit the email user) -> Tick the checkbox to allow direct login to SOGo.
        • @accolon

          thanks for your reply.

          Yes, it was indeed an upgrade from 1.5.x and I already did the extra steps mentioned in the docs.
          This is what my /web/rc/config/config.inc.php looks like:

          GNU nano 4.8 config.inc.php
          <?php
          error_reporting(0);
          if (!file_exists('/tmp/mime.types')) {
          file_put_contents("/tmp/mime.types", fopen("http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types", 'r'));
          }
          $config = array();
          $config['db_dsnw'] = 'mysql://' . getenv('DBUSER') . ':' . getenv('DBPASS') . '@mysql/' . getenv('DBNAME');
          $config['imap_host'] = 'tls://dovecot:143';
          $config['smtp_host'] = 'tls://postfix:587';
          $config['smtp_user'] = '%u';
          $config['smtp_pass'] = '%p';
          $config['support_url'] = '';
          $config['product_name'] = 'Roundcube Webmail';
          $config['des_key'] = 'XXX';
          $config['log_dir'] = '/dev/null';
          $config['temp_dir'] = '/tmp';
          $config['plugins'] = array(
          'archive',
          'managesieve',
          'password'
          );
          $config['mime_types'] = '/tmp/mime.types';
          $config['imap_conn_options'] = array(
          'ssl' => array('verify_peer' => false, 'verify_peer_name' => false, 'allow_self_signed' => true)
          );
          $config['enable_installer'] = true;
          $config['smtp_conn_options'] = array(
          'ssl' => array('verify_peer' => false, 'verify_peer_name' => false, 'allow_self_signed' => true)
          );
          $config['db_prefix'] = 'mailcow_rc1';
          #inserted to allow sender editing
          $config['identities_level'] = 0;

          Looks fine for me, what do you think?

          I also tried to set the COMPOSER variable, but it seems like he wants to resolve some package dependencies.

          `d481a5a4f70b:/web/rc# COMPOSER=composer.json php composer.phar update –no-dev –with-all-dependencies
          Loading “roundcube/plugin-installer” which is a legacy composer-installer built for Composer 1.x, it is likely to cause issues as you are running Composer 2.x.
          Loading composer repositories with package information
          Package “–no-dev” listed for update is not locked.
          Updating dependencies
          Your requirements could not be resolved to an installable set of packages.

          Problem 1
          - Root composer.json requires pear/net_smtp 1.10.0, found pear/net_smtp[1.10.0, 1.10.1] but the package is fixed to 1.8.1 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
          Problem 2
          - Root composer.json requires pear/net_sieve 1.4.5, found pear/net_sieve[1.4.5, 1.4.6] but the package is fixed to 1.4.4 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
          Problem 3
          - Root composer.json requires roundcube/plugin-installer 0.3.1, found roundcube/plugin-installer[0.3.1, 0.3.2] but the package is fixed to 0.2.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
          Problem 4
          - Root composer.json requires masterminds/html5 2.7.0, found masterminds/html5[2.7.0, …, 2.7.6] but the package is fixed to 2.5.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
          Problem 5
          - phpunit/phpunit is locked to version 5.7.27 and an update of this package was not requested.
          - phpunit/phpunit 5.7.27 requires php 5.6 || 7.0 -> your php version (8.1.14) does not satisfy that requirement.`

        • I have tried quite hard @accolon but guys at AWS aren’t granting me that, so I’m gonna change my hosting provider, literally spend 8 hours trying to understand what’s wrong.

        • Just to note: Testing TCP/25 from the internal network won’t necessarily mean it’s accessible from outside, as we saw comparing the output.

          I also agree with @accolon that a mailserver at home is a terrible idea. Especially as usually ISPs not always allow modifying the rDNS/PTR, often block TCP/25 incoming as well as outgoing and the receiving mailservers usually negatively rate IP ranges for home internet connections and makes reliable email delivery a lottery.

        • jon_will
          For what it’s worth, I have a server running for a couple of weeks with four domains and about two mailboxes per domain. It’s low volume but it works on a 1GG RAM and 1CPU on a VPS. I have a 1.5G swap but use a third of it. I have solr, clamav and SoGo disabled.

          @accolon is right, you can find good cheap VPS, mine costs $5/month. Just make sure they let you host a mail server.

          Hope this helps. I was discouraged with the minimal settings found on the mailcow website but it’s not that bad if you disable the above.

          Best of luck.