Mail bounces when using recvmail and sendmail addons simultaneously

[jimcavoli]

I first noticed this issue while packaging Loomio and ended up right back here again when I started working on OneDev as well.

So, as first described in January and confirmed as recently as last week and yesterday, this issue is still going on. Let's say we have a cloudron app called example which gets the email address example.app@example.com assigned from the Cloudron for it to use. When both sendmail and recvmail addons are enabled for it, I would expect that the behavior would be:

1. Both SMTP and IMAP credentials populate into the environment
2. The app can connect to both SMTP and IMAP servers
3. Once connected with the app's credentials, it is possible to send mail via SMTP and receive mail via IMAP

However, the observed behavior is:

1. Both SMTP and IMAP credentials populate into the environment
2. The app can connect to both SMTP and IMAP servers
3. Once connected with the app's credentials, it is possible to send mail via SMTP, but all mail sent to example.app@example.com (and any example.app+foo@example.com-style subaddresses) is hard bounced smtp;550 5.1.1

This is a surprising behavior anyway, but particularly tough for the common use case both these apps have, whereby they send email notifications which users can reply to via email as a way to interact with the service. Loomio does this for discussion threads, OneDev does it for issue and PR notifications, and there are many useful cases in which this sort of feature is useful. However, it is not possible to enable it "automatically" at least with a Cloudron app presently, using the managed addons' capabilities. This could all of course be manually wired up, but that's a clunky workaround that's blocking the process of at least these two apps toward general availability, but has also impacted my designs on two other custom apps I've been working on to run on Cloudron.

I've got no solutions or ideas on what is causing this under the hood presently (it's been a pretty busy year), but I wanted to make sure this post gets out there to identify the issue as known, and maybe some greater minds with more time can get it resolved eventually!

[robi]

@jimcavoli Can you grab the mail log snippets and post them here?

Sounds like something is either being malformed during the send, and/or the SMTP receive requirements went through an upgrade & are now rejecting something.

[jimcavoli]

These are the log messages when executing a test (which exercises both sending and receiving) through OneDev. Taken from the Cloudron-side email logs, with expanded details, domain name redacted, and chronology flipped (oldest message first):

Queued mail for delivery to onedev.app+test-sub-addressing@example.com from onedev.app@example.com

{
  "ts": 1629216044183,
  "type": "queued",
  "direction": "outbound",
  "uuid": "22C112A7-5AA8-4685-8D85-11BBE6DC4C28.1",
  "remote": {
    "ip": "172.18.16.253",
    "port": 48192,
    "host": "05b821f7-a64e-40c0-8296-451deb089e0c.cloudron",
    "info": "05b821f7-a64e-40c0-8296-451deb089e0c.cloudron",
    "closed": false,
    "is_private": true,
    "is_local": false
  },
  "authUser": "onedev.app@example.com",
  "mailFrom": "<onedev.app@example.com>",
  "rcptTo": [
    "<onedev.app+test-sub-addressing@example.com>"
  ],
  "details": {
    "spamStatus": "",
    "message": "Message Queued (22C112A7-5AA8-4685-8D85-11BBE6DC4C28.1)"
  }
}

Sent bounce to onedev.app@example.com for mail sent to onedev.app+test-sub-addressing@example.com. Some recipients failed: <onedev.app+test-sub-addressing@example.com>

{
  "ts": 1629216044307,
  "type": "bounce",
  "direction": "outbound",
  "uuid": "22C112A7-5AA8-4685-8D85-11BBE6DC4C28.1.1",
  "mailFrom": "<onedev.app@example.com>",
  "rcptTo": [
    "<onedev.app+test-sub-addressing@example.com>"
  ],
  "details": {
    "message": "Some recipients failed: <onedev.app+test-sub-addressing@example.com>",
    "mx": {
      "priority": 0,
      "exchange": "127.0.0.1",
      "port": 2424,
      "using_lmtp": true,
      "family": "A",
      "bind_helo": "mail.example.com"
    },
    "bounced_rcpt": [
      {
        "original": "<onedev.app+test-sub-addressing@example.com>",
        "original_host": "example.com",
        "host": "example.com",
        "user": "onedev.app+test-sub-addressing",
        "reason": "550 5.1.1 <onedev.app+test-sub-addressing@example.com> User doesn't exist: onedev.app@example.com",
        "dsn_action": "failed",
        "dsn_smtp_code": "550",
        "dsn_smtp_extc": "5.1.1",
        "dsn_status": "5.1.1",
        "dsn_smtp_response": "<onedev.app+test-sub-addressing@example.com> User doesn't exist: onedev.app@example.com",
        "dsn_remote_mta": "127.0.0.1"
      }
    ]
  }
}

Sent bounce to <> for mail sent to onedev.app@example.com. Some recipients failed: <onedev.app@example.com>

{
  "ts": 1629216044342,
  "type": "bounce",
  "direction": "outbound",
  "uuid": "D47C41D3-83FB-49F0-A709-5162706B0A72.1",
  "mailFrom": "<>",
  "rcptTo": [
    "<onedev.app@example.com>"
  ],
  "details": {
    "message": "Some recipients failed: <onedev.app@example.com>",
    "mx": {
      "priority": 0,
      "exchange": "127.0.0.1",
      "port": 2424,
      "using_lmtp": true,
      "family": "A",
      "bind_helo": "mail.example.com"
    },
    "bounced_rcpt": [
      {
        "original": "onedev.app@example.com",
        "user": "onedev.app",
        "original_host": "example.com",
        "host": "example.com",
        "reason": "550 5.1.1 <onedev.app@example.com> User doesn't exist: onedev.app@example.com",
        "dsn_action": "failed",
        "dsn_smtp_code": "550",
        "dsn_smtp_extc": "5.1.1",
        "dsn_status": "5.1.1",
        "dsn_smtp_response": "<onedev.app@example.com> User doesn't exist: onedev.app@example.com",
        "dsn_remote_mta": "127.0.0.1"
      }
    ]
  }
}

[girish]

@jimcavoli With regards to recvmail, this is mostly deprecated. The initial idea was similar to sendmail where we will preconfigure a mailbox and let a user choose a mailbox. But with recvmail, it's often the case that the mail server is external and not on Cloudron. So, for the moment, maybe it's a good idea to not use recvmail and let the user configure the mailbox after installation. What do you think?

(we still have the code for recvmail but it's not tested since I don't think any package uses it. maybe the meemo app).

[jimcavoli]

@girish All else held equal, I'd probably take this compromise. However, the apps in question where I have run into this issue have the email interface as core features and it can't really be turned off. Installing a somewhat handicapped version of these apps which would require further manual configuration, in some cases through the terminal, is a really poor experience.

I think the case that the mail server is external to the Cloudron should be a well-accounted for exception, but not the expectation of packaged apps. My "perfect" reimagined recvmail would be that by default it works as you've described, but there would be new options on the app configuration page for "Email" that would allow switching the CLOUDRON_MAIL_IMAP_* details over to a manually-entered set of values if desired. That would keep things automatic for the all-in users and allow flexibility for the split-server case, all without requiring complex configuration changes to files and/or the apps' packaging.

[girish]

@jimcavoli I think that makes sense. Let me see if I can get the recvmail addon working again, should be straightforward. For your suggestion of having a "selector" in the email UI, we did exactly that for sendmail addon in the previous release. So, we can do the same for recvmail as well I guess. Let me investigate.