1. 21 Feb, 2016 1 commit
  2. 07 Dec, 2015 1 commit
  3. 18 Oct, 2015 1 commit
  4. 12 Oct, 2015 1 commit
  5. 06 Sep, 2015 1 commit
  6. 19 Aug, 2015 2 commits
  7. 14 Aug, 2015 1 commit
  8. 20 Jul, 2015 2 commits
    • David Piggott's avatar
    • David Piggott's avatar
      Add support for bidirectional mail alias controls · 3fdfad27
      David Piggott authored
      This is an extension of #427. Building on that change it adds support in the
      aliases table for flagging aliases as:
       1. Applicable to inbound and outbound mail.
       2. Applicable to inbound mail only.
       3. Applicable to outbound mail only.
       4. Disabled.
      
      The aliases UI is also updated to allow administrators to set the direction of
      each alias.
      
      Using this extra information, the sqlite queries executed by Postfix are
      updated so only the relevant alias types are checked.
      
      The goal and result of this change is that outbound-only catch-all aliases can
      now be defined (in fact catch-all aliases of any type can be defined).
      
      This allow us to continue supporting relaying as described at
      https://mailinabox.email/advanced-configuration.html#relay
      without requiring that administrators either create regular aliases for each
      outbound *relay* address, or that they create a catch-all alias and then face a
      flood of spam.
      
      I have tested the code as it is in this commit and fixed every issue I found,
      so in that regard the change is complete. However I see room for improvement
      in terms of updating terminology to make the UI etc. easier to understand.
      I'll make those changes as subsequent commits so that this tested checkpoint is
      not lost, but also so they can be rejected independently of the actual change
      if not wanted.
      3fdfad27
  9. 04 Jul, 2015 1 commit
  10. 30 Jun, 2015 2 commits
  11. 06 Jun, 2015 1 commit
  12. 28 May, 2015 2 commits
  13. 03 May, 2015 1 commit
  14. 21 Apr, 2015 1 commit
  15. 19 Apr, 2015 1 commit
  16. 09 Apr, 2015 2 commits
    • Joshua Tauberer's avatar
      prevent accidental domain control validation hijacking by limiting use of... · 072aeca1
      Joshua Tauberer authored
      prevent accidental domain control validation hijacking by limiting use of admin@ etc. addresses in users/aliases
      072aeca1
    • Joshua Tauberer's avatar
      store IDNs (internationalized domain names) in IDNA (ASCII) in our database, not in Unicode · 322a5779
      Joshua Tauberer authored
      I changed my mind. In 1bf8f199 I allowed Unicode domain names to go into the database. I thought that was nice because it's what the user *means*. But it's not how the web works. Web and DNS were working, but mail wasn't. Postfix (as shipped with Ubuntu 14.04 without support for SMTPUTF8) exists in an ASCII-only world. When it goes to the users/aliases table, it queries in ASCII (IDNA) only and had no hope of delivering mail if the domain was in full Unicode in the database. I was thinking ahead to SMTPUTF8, where we *could* put Unicode in the database (though that would prevent IDNA-encoded addressing from being deliverable) not realizing it isn't well supported yet anyway.
      
      It's IDNA that goes on the wire in most places anyway (SMTP without SMTPUTF8 (and therefore how Postfix queries our users/aliases tables), DNS zone files, nginx config, CSR 'CN' field, X509 Common Name and Subject Alternative Names fields), so we should really be talking in terms of IDNA (i.e. ASCII).
      
      This partially reverts commit 1bf8f199, where I added a lot of Unicode=>IDNA conversions when writing configuration files. Instead I'm doing Unicode=>IDNA before email addresses get into the users/aliases table. Now we assume the database uses IDNA-encoded ASCII domain names. When adding/removing aliases, addresses are converted to ASCII (w/ IDNA). User accounts must be ASCII-only anyway because of Dovecot's auth limitations, so we don't do any IDNA conversion (don't want to change the user's login info behind their back!). The aliases control panel page converts domains back to Unicode for display to be nice. The status checks converts the domains to Unicode just for the output headings.
      
      A migration is added to convert existing aliases with Unicode domains into IDNA. Any custom DNS or web settings with Unicode may need to be changed.
      
      Future support for SMTPUTF8 will probably need to add columns in the users/aliases table so that it lists both IDNA and Unicode forms.
      322a5779
  17. 22 Mar, 2015 3 commits
  18. 31 Jan, 2015 1 commit
  19. 19 Jan, 2015 2 commits
    • Joshua Tauberer's avatar
      catch-all aiases and domain aliases should not require postmaster@ and admin@... · 85a40da8
      Joshua Tauberer authored
      catch-all aiases and domain aliases should not require postmaster@ and admin@ aliases because they'll forward anyway
      85a40da8
    • Joshua Tauberer's avatar
      internationalized domain names (DNS, web, CSRs, normalize to Unicode in... · 1bf8f199
      Joshua Tauberer authored
      internationalized domain names (DNS, web, CSRs, normalize to Unicode in database, prohibit non-ASCII characters in user account names)
      
      * For non-ASCII domain names, we will keep the Unicode encoding in our users/aliases table. This is nice for the user and also simplifies things like sorting domain names (using Unicode lexicographic order is good, using ASCII lexicogrpahic order on IDNA is confusing).
      * Write nsd config, nsd zone files, nginx config, and SSL CSRs with domains in IDNA-encoded ASCII.
      * When checking SSL certificates, treat the CN and SANs as IDNA.
      * Since Chrome has an interesting feature of converting Unicode to IDNA in <input type="email"> form fields, we'll also forcibly convert IDNA to Unicode in the domain part of email addresses before saving email addresses in the users/aliases tables so that the table is normalized to Unicode.
      * Don't allow non-ASCII characters in user account email addresses. Dovecot gets confused when querying the Sqlite database (which we observed even for non-word ASCII characters too, so it may not be related to the character encoding).
      1bf8f199
  20. 14 Nov, 2014 1 commit
    • Joshua Tauberer's avatar
      support "domain aliases" (@domain => @domain aliases) · 7e7abf3b
      Joshua Tauberer authored
      This seemed to already be technically supported but the validation is now stricter and the admin is more helpful:
      
      * Postfix seems to allow @domain.tld as an alias destination address but only if it is the only destination address (see the virtual man page).
       * Allow @domain.tld if it is the whole destination address string.
       * Otherwise, do not allow email addresses without local parts in the destination.
      * In the admin, add a third tab for making it clear how to add a domain alias.
      
      closes #265
      7e7abf3b
  21. 07 Oct, 2014 3 commits
  22. 21 Sep, 2014 1 commit
  23. 09 Sep, 2014 1 commit
  24. 17 Aug, 2014 1 commit
  25. 09 Aug, 2014 1 commit
  26. 08 Aug, 2014 1 commit
  27. 13 Jul, 2014 1 commit
  28. 12 Jul, 2014 2 commits
  29. 10 Jul, 2014 1 commit
    • Joshua Tauberer's avatar
      use the Dovecot managesieve service to manage sieve scripts · 85bd2c88
      Joshua Tauberer authored
      This lets roundcube's manageseive plugin do cool things like vacation responses.
      
      Also:
      
      * Run the spam filtering sieve script out of a global sieve file that we'll place in /etc/dovecot. It is no longer necessary to create per-user sieve files for this. Remove them with a new migration. Remove the code that created them.
      
      * Corrects the spam script. Backslashes were double-escaped probably because this script started embedded within the bash script. Not sure how this was working until now.
      
      this adapts work by @h8h in #103
      85bd2c88