test(GODT-1602): run integration tests against black 🖤

go.mod

@@ -7,7 +7,7 @@ require (
 	github.com/Masterminds/semver/v3 v3.2.0
 	github.com/ProtonMail/gluon v0.17.1-0.20240102132144-89b40fb6fe7e
 	github.com/ProtonMail/go-autostart v0.0.0-20210130080809-00ed301c8e9a
-	github.com/ProtonMail/go-proton-api v0.4.1-0.20231130083229-e8aa47d7a366
+	github.com/ProtonMail/go-proton-api v0.4.1-0.20240209095006-01f781177113
 	github.com/ProtonMail/gopenpgp/v2 v2.7.4-proton
 	github.com/PuerkitoBio/goquery v1.8.1
 	github.com/abiosoft/ishell v2.0.0+incompatible

go.sum

@@ -38,8 +38,8 @@ github.com/ProtonMail/go-message v0.13.1-0.20230526094639-b62c999c85b7 h1:+j+Kd/
 github.com/ProtonMail/go-message v0.13.1-0.20230526094639-b62c999c85b7/go.mod h1:NBAn21zgCJ/52WLDyed18YvYFm5tEoeDauubFqLokM4=
 github.com/ProtonMail/go-mime v0.0.0-20230322103455-7d82a3887f2f h1:tCbYj7/299ekTTXpdwKYF8eBlsYsDVoggDAuAjoK66k=
 github.com/ProtonMail/go-mime v0.0.0-20230322103455-7d82a3887f2f/go.mod h1:gcr0kNtGBqin9zDW9GOHcVntrwnjrK+qdJ06mWYBybw=
-github.com/ProtonMail/go-proton-api v0.4.1-0.20231130083229-e8aa47d7a366 h1:W9P5GdDnuGkB3tbzKnXmUrTjIs6zk/K+4lpPTWzsoRE=
+github.com/ProtonMail/go-proton-api v0.4.1-0.20240209095006-01f781177113 h1:1VRTJonug9tjHGkBbOYuHzXYsAz76F2GYpPbXVb2er4=
-github.com/ProtonMail/go-proton-api v0.4.1-0.20231130083229-e8aa47d7a366/go.mod h1:t+hb0BfkmZ9fpvzVRpHC7limoowym6ln/j0XL9a8DDw=
+github.com/ProtonMail/go-proton-api v0.4.1-0.20240209095006-01f781177113/go.mod h1:t+hb0BfkmZ9fpvzVRpHC7limoowym6ln/j0XL9a8DDw=
 github.com/ProtonMail/go-smtp v0.0.0-20231109081432-2b3d50599865 h1:EP1gnxLL5Z7xBSymE9nSTM27nRYINuvssAtDmG0suD8=
 github.com/ProtonMail/go-smtp v0.0.0-20231109081432-2b3d50599865/go.mod h1:qm27SGYgoIPRot6ubfQ/GpiPy/g3PaZAVRxiO/sDUgQ=
 github.com/ProtonMail/go-srp v0.0.7 h1:Sos3Qk+th4tQR64vsxGIxYpN3rdnG9Wf9K4ZloC1JrI=

internal/dialer/dialer_basic.go

@@ -29,27 +29,34 @@ type TLSDialer interface {
 	DialTLSContext(ctx context.Context, network, address string) (conn net.Conn, err error)
 }
 
+func SetBasicTransportTimeouts(t *http.Transport) {
+	t.MaxIdleConns = 100
+	t.MaxIdleConnsPerHost = 100
+	t.IdleConnTimeout = 5 * time.Minute
+
+	t.ExpectContinueTimeout = 500 * time.Millisecond
+
+	// GODT-126: this was initially 10s but logs from users showed a significant number
+	// were hitting this timeout, possibly due to flaky wifi taking >10s to reconnect.
+	// Bumping to 30s for now to avoid this problem.
+	t.ResponseHeaderTimeout = 30 * time.Second
+
+	// If we allow up to 30 seconds for response headers, it is reasonable to allow up
+	// to 30 seconds for the TLS handshake to take place.
+	t.TLSHandshakeTimeout = 30 * time.Second
+}
+
 // CreateTransportWithDialer creates an http.Transport that uses the given dialer to make TLS connections.
 func CreateTransportWithDialer(dialer TLSDialer) *http.Transport {
-	return &http.Transport{
+	t := &http.Transport{
 		DialTLSContext: dialer.DialTLSContext,
 
-		Proxy:               http.ProxyFromEnvironment,
+		Proxy: http.ProxyFromEnvironment,
-		MaxIdleConns:        100,
-		MaxIdleConnsPerHost: 100,
-		IdleConnTimeout:     5 * time.Minute,
-
-		ExpectContinueTimeout: 500 * time.Millisecond,
-
-		// GODT-126: this was initially 10s but logs from users showed a significant number
-		// were hitting this timeout, possibly due to flaky wifi taking >10s to reconnect.
-		// Bumping to 30s for now to avoid this problem.
-		ResponseHeaderTimeout: 30 * time.Second,
-
-		// If we allow up to 30 seconds for response headers, it is reasonable to allow up
-		// to 30 seconds for the TLS handshake to take place.
-		TLSHandshakeTimeout: 30 * time.Second,
 	}
+
+	SetBasicTransportTimeouts(t)
+
+	return t
 }
 
 // BasicTLSDialer implements TLSDialer.

tests/README.md

@@ -0,0 +1,67 @@
+# Bridge Integration tests
+
+Tests defined in this folder are using `github.com/cucumber/godog` library to
+define scenarios.
+
+The scenarios are defined in `./features/` folder.
+The step definition can be found in `./steps_test.go`.
+
+
+# How to run
+All features are run as sub-test of `TestFeatures` in `./bdd_test.go`.
+The most simple way to execute is `make test-integration` from project source directory.
+
+
+There are several environment variables which can be used to control the tests:
+
+
+* `FEATURES` sets the path to folder / file / line in file to select which
+  scenarios to run.
+
+        FEATURES=${PWD}/tests/features/user/addressmode.feature:162
+
+* `FEATURE_TEST_LOG_LEVEL` the logrus level for tests (affects also testing
+  bridge instance)
+
+        FEATURE_TEST_LOG_LEVEL=trace
+
+* `BRIDGE_API_DEBUG` when enabled
+  [GPA](https://github.com/ProtonMail/go-proton-api/)
+  client used in testing bridge instance will log http communication and logrus
+  is automatically set to `trace`
+
+        BRIDGE_API_DEBUG=1
+
+* `GO_PROTON_API_SERVER_LOGGER_ENABLED` GPA mock server will print log line per
+  each request to stdout (not logrus)
+
+        GO_PROTON_API_SERVER_LOGGER_ENABLED=1
+
+* `FEATURE_API_DEBUG` when enabled GPA client for preparation of test
+  condiditions (see `./ctx_helper_test.go`) will dump http communication to
+  stdoout.
+
+        FEATURE_API_DEBUG=1
+
+* `FEATURE_TEST_LOG_IMAP` when enabled
+  bridge will dump all (client and server) IMAP communication to logs
+  and logrus is automatically set to `trace`
+
+        FEATURE_TEST_LOG_IMAP=1
+
+* `GLUON_LOG_IMAP_LINE_LIMIT` controls maximal number of lines (by default 1)
+  which are printed into imap trace log (logrus).
+  Needs `FEATURE_TEST_LOG_IMAP` enabled to take effect.
+
+        GLUON_LOG_IMAP_LINE_LIMIT=1048576
+
+
+* `FEATURE_TEST_LOG_SMTP` when enabled
+  bridge will dump all SMTP communication to logs
+  and logrus is automatically set to `trace`
+
+        FEATURE_TEST_LOG_SMTP=1
+
+
+
+

tests/api_test.go

@@ -18,7 +18,6 @@
 package tests
 
 import (
-	"crypto/tls"
 	"net/http"
 	"net/url"
 	"os"
@@ -26,6 +25,7 @@ import (
 	"github.com/Masterminds/semver/v3"
 	"github.com/ProtonMail/go-proton-api"
 	"github.com/ProtonMail/go-proton-api/server"
+	"github.com/ProtonMail/proton-bridge/v3/internal/dialer"
 )
 
 type API interface {
@@ -73,13 +73,14 @@ func newLiveAPI(hostURL string) API {
 		panic(err)
 	}
 
+	tr := proton.InsecureTransport()
+	dialer.SetBasicTransportTimeouts(tr)
+	tr.Proxy = http.ProxyFromEnvironment
+
 	return &liveAPI{
 		Server: server.New(
 			server.WithProxyOrigin(hostURL),
-			server.WithProxyTransport(&http.Transport{
+			server.WithProxyTransport(tr),
-				TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
-				Proxy:           http.ProxyFromEnvironment,
-			}),
 		),
 		domain: url.Hostname(),
 	}

tests/bdd_test.go

@@ -132,9 +132,19 @@ func getFeatureTags() string {
 		tags = ""
 	case "smoke": // Currently this is just a placeholder, as there are no scenarios tagged with @smoke
 		tags = "@smoke"
+	case "black": // Currently this is just a placeholder, as there are no scenarios tagged with @smoke
+		tags = "~@skip-black"
 	default:
 		tags = "~@regression && ~@smoke" // To exclude more add `&& ~@tag`
 	}
 
 	return tags
 }
+
+func isBlack() bool {
+	if len(os.Args) == 0 {
+		return false
+	}
+
+	return os.Args[len(os.Args)-1] == "black"
+}

tests/bridge_test.go

@@ -168,7 +168,7 @@ func newTestBugReport(br *bridge.Bridge) *testBugReport {
 		Title:       "title",
 		Description: "description",
 		Username:    "username",
-		Email:       "email",
+		Email:       "email@pm.me",
 		EmailClient: "client",
 		IncludeLogs: false,
 	}

tests/ctx_bridge_test.go

@@ -23,6 +23,7 @@ import (
 	"crypto/x509"
 	"encoding/json"
 	"fmt"
+	"net/http"
 	"net/http/cookiejar"
 	"os"
 	"path/filepath"
@@ -34,6 +35,7 @@ import (
 	"github.com/ProtonMail/proton-bridge/v3/internal/bridge"
 	"github.com/ProtonMail/proton-bridge/v3/internal/constants"
 	"github.com/ProtonMail/proton-bridge/v3/internal/cookies"
+	"github.com/ProtonMail/proton-bridge/v3/internal/dialer"
 	"github.com/ProtonMail/proton-bridge/v3/internal/events"
 	frontend "github.com/ProtonMail/proton-bridge/v3/internal/frontend/grpc"
 	"github.com/ProtonMail/proton-bridge/v3/internal/service"
@@ -146,6 +148,16 @@ func (t *testCtx) initBridge() (<-chan events.Event, error) {
 		logrus.SetLevel(logrus.TraceLevel)
 	}
 
+	rt := t.netCtl.NewRoundTripper(&tls.Config{InsecureSkipVerify: true})
+	if isBlack() {
+		// GODT-1602 make sure we don't time out test server
+		t, ok := rt.(*http.Transport)
+		if !ok {
+			panic("expecting http.Transport")
+		}
+		dialer.SetBasicTransportTimeouts(t)
+	}
+
 	// Create the bridge.
 	bridge, eventCh, err := bridge.New(
 		// App stuff
@@ -161,7 +173,7 @@ func (t *testCtx) initBridge() (<-chan events.Event, error) {
 		persister,
 		useragent.New(),
 		t.mocks.TLSReporter,
-		t.netCtl.NewRoundTripper(&tls.Config{InsecureSkipVerify: true}),
+		rt,
 		t.mocks.ProxyCtl,
 		t.mocks.CrashHandler,
 		t.reporter,

tests/ctx_helper_test.go

@@ -26,14 +26,20 @@ import (
 	"github.com/ProtonMail/gluon/async"
 	"github.com/ProtonMail/go-proton-api"
 	"github.com/ProtonMail/gopenpgp/v2/crypto"
+	"github.com/ProtonMail/proton-bridge/v3/internal/dialer"
 	"github.com/bradenaw/juniper/stream"
 )
 
 // withProton executes the given function with a proton manager configured to use the test API.
 func (t *testCtx) withProton(fn func(*proton.Manager) error) error {
+	tr := proton.InsecureTransport()
+	if isBlack() {
+		dialer.SetBasicTransportTimeouts(tr)
+	}
+
 	m := proton.New(
 		proton.WithHostURL(t.api.GetHostURL()),
-		proton.WithTransport(proton.InsecureTransport()),
+		proton.WithTransport(tr),
 		proton.WithAppVersion(t.api.GetAppVersion()),
 		proton.WithDebug(os.Getenv("FEATURE_API_DEBUG") != ""),
 	)
@@ -88,6 +94,15 @@ func (t *testCtx) runQuarkCmd(ctx context.Context, command string, args ...strin
 	return out, nil
 }
 
+func (t *testCtx) decryptID(id string) ([]byte, error) {
+	return t.runQuarkCmd(context.Background(),
+		"encryption:id",
+		"--decrypt",
+		"--",
+		id,
+	)
+}
+
 func (t *testCtx) withAddrKR(
 	ctx context.Context,
 	c *proton.Client,

tests/ctx_test.go

@@ -223,7 +223,13 @@ func (t *testCtx) replace(value string) string {
 
 		// Create a new user if it doesn't exist yet.
 		if _, ok := t.userUUIDByName[name]; !ok {
-			t.userUUIDByName[name] = uuid.NewString()
+			val := uuid.NewString()
+
+			if name != strings.ToLower(name) {
+				val = "Mixed-Caps-" + val
+			}
+
+			t.userUUIDByName[name] = val
 		}
 
 		return t.userUUIDByName[name]

tests/features/bridge/config_status.feature

@@ -33,7 +33,6 @@ Feature: Configuration Status Telemetry
     And config status event "bridge_config_success" is eventually send 1 time
 
 
-  @long-black
   Scenario: Config Status Success send only once
     Then bridge telemetry feature is enabled
     When the user logs in with username "[user:user]" and password "password"
@@ -77,4 +76,4 @@ Feature: Configuration Status Telemetry
     And bridge stops
     And force config status progress to be sent for user"[user:user]"
     And bridge starts
-    Then config status event "bridge_config_progress" is eventually send 1 time
+    Then config status event "bridge_config_progress" is eventually send 1 time

tests/features/bridge/updates.feature

@@ -21,9 +21,9 @@ Feature: Bridge checks for updates
     Then bridge sends a manual update event for version "2.4.0"
 
   Scenario: Update is required to continue using bridge
-    Given there exists an account with username "user" and password "password"
+    Given there exists an account with username "[user:user]" and password "password"
     And bridge is version "2.3.0" and the latest available version is "2.3.0" reachable from "2.3.0"
     And the API requires bridge version at least "2.4.0"
     When bridge starts
-    And the user logs in with username "user" and password "password"
+    And the user logs in with username "[user:user]" and password "password"
-    Then bridge sends a forced update event
+    Then bridge sends a forced update event

tests/features/imap/auth.feature

@@ -3,7 +3,6 @@ Feature: A user can authenticate an IMAP client
     Given there exists an account with username "[user:user]" and password "password"
     And there exists an account with username "[user:user2]" and password "password2"
     And the account "[user:user]" has additional address "[alias:alias]@[domain]"
-    And the account "[user:user2]" has additional disabled address "[alias:alias2]@[domain]"
     Then it succeeds
     When bridge starts
     And the user logs in with username "[user:user]" and password "password"
@@ -21,8 +20,12 @@ Feature: A user can authenticate an IMAP client
   Scenario: IMAP client can authenticate successfully with secondary address
     Given user "[user:user]" connects and authenticates IMAP client "1" with address "[alias:alias]@[domain]"
 
+  # Need to find  way to setup disabled address on black
+  @skip-black
   Scenario: IMAP client can not authenticate successfully with disable address
-    Given user "[user:user2]" connects and can not authenticate IMAP client "1" with address "[alias:alias2]@[domain]"
+    Given the account "[user:user2]" has additional disabled address "[alias:disabled]@[domain]"
+    And it succeeds
+    Then user "[user:user2]" connects and can not authenticate IMAP client "1" with address "[alias:disabled]@[domain]"
 
   Scenario: IMAP client can authenticate successfully
     When user "[user:user]" connects IMAP client "1"

tests/features/imap/mailbox/list.feature

@@ -40,6 +40,8 @@ Feature: IMAP list mailboxes
     Then IMAP client "2" counts 20 mailboxes under "Folders"
     And  IMAP client "2" counts 60 mailboxes under "Labels"
 
+  # need to implement _schedule message_ test step for black
+  @skip-black
   Scenario: List with scheduled mail
     Given there exists an account with username "[user:user]" and password "password"
     And the address "[user:user]@[domain]" of account "[user:user]" has the following messages in "Scheduled":

tests/features/imap/mailbox/rename_hiearchy.feature

@@ -12,6 +12,8 @@ Feature: IMAP get mailbox info
     And user "[user:user]" connects and authenticates IMAP client "1"
     Then it succeeds
 
+  # with black subfolder is not renamed (maybe missing event?)
+  @skip-black
   Scenario: Rename folder with subfolders
     When IMAP client "1" renames "Folders/f1" to "Folders/f3"
     And it succeeds

tests/features/imap/message/delete.feature

@@ -6,7 +6,6 @@ Feature: IMAP remove messages from mailbox
       | mbox  | folder |
       | label | label  |
     And the address "[user:user]@[domain]" of account "[user:user]" has 10 messages in "Folders/mbox"
-    And the address "[user:user]@[domain]" of account "[user:user]" has 1 messages in "Scheduled"
     Then it succeeds
     When bridge starts
     And the user logs in with username "[user:user]" and password "password"
@@ -48,10 +47,3 @@ Feature: IMAP remove messages from mailbox
     And it succeeds
     And IMAP client "1" expunges
     Then it fails
-
-  Scenario: Not possible to delete from Scheduled and expunge does nothing
-    When IMAP client "1" selects "Scheduled"
-    And IMAP client "1" marks message 1 as deleted
-    Then it succeeds
-    And IMAP client "1" expunges
-    Then it fails

tests/features/imap/message/drafts.feature

@@ -42,6 +42,8 @@ Feature: IMAP Draft messages
     And IMAP client "1" eventually sees 1 messages in "Drafts"
     And IMAP client "1" does not see header "Reply-To" in message with subject "Basic Draft" in "Drafts"
 
+  # The draft event is received from black but it's not processed to IMAP
+  @skip-black
   Scenario: Draft edited remotely
     When the following fields were changed in draft 1 for address "[user:user]@[domain]" of account "[user:user]":
       | to                  | subject     | body                             |
@@ -52,6 +54,8 @@ Feature: IMAP Draft messages
     And IMAP client "1" eventually sees 1 messages in "Drafts"
     And IMAP client "1" does not see header "Reply-To" in message with subject "Basic Draft" in "Drafts"
   
+  # The draft event is received from black but it's not processed to IMAP
+  @skip-black
   @regression
   Scenario: Draft edited remotely and sent from client
     When IMAP client "1" selects "Drafts"
@@ -103,6 +107,8 @@ Feature: IMAP Draft messages
     And IMAP client "1" eventually sees 0 messages in "Drafts"
 
 
+  # The draft event is received from black but it's not processed to IMAP
+  @skip-black
   Scenario: Draft moved to trash remotely
     When draft 1 for address "[user:user]@[domain]" of account "[user:user]" was moved to trash
     Then IMAP client "1" eventually sees the following messages in "Trash":

tests/features/imap/message/fetch.feature

@@ -15,6 +15,8 @@ Feature: IMAP Fetch
     And user "[user:user]" connects and authenticates IMAP client "1"
     Then it succeeds
 
+  # The date returned from black is server time.. Black is probably correct we need to fix GPA server
+  @skip-black
   Scenario: Fetch very old message
     Given IMAP client "1" eventually sees the following messages in "INBOX":
       | from              | to                   | subject | date                  |
@@ -22,6 +24,8 @@ Feature: IMAP Fetch
     Then IMAP client "1" sees header "X-Original-Date: Sun, 13 Jul 1969 00:00:00 +0000" in message with subject "foo" in "INBOX"
 
 
+  # The date returned from black is server time.. Black is probably correct we need to fix GPA server
+  @skip-black
   Scenario: Fetch from deleted cache
     When the user deletes the gluon cache
     Then IMAP client "1" eventually sees the following messages in "INBOX":

tests/features/imap/message/import.feature

@@ -274,6 +274,8 @@ Feature: IMAP import messages
       | Archive |
       | Sent    |
 
+  # The date returned from black is server time.. Black is probably correct we need to fix GPA server
+  @skip-black
   Scenario: Import message without sender to Drafts
     When IMAP client "1" appends the following message to "Drafts":
       """
@@ -648,4 +650,4 @@ Feature: IMAP import messages
           ]
         }
       }
-      """
+      """

tests/features/imap/message/move.feature

@@ -16,9 +16,6 @@ Feature: IMAP move messages
     And the address "[user:user]@[domain]" of account "[user:user]" has the following messages in "Sent":
       | from              | to                   | subject | unread |
       | john.doe@mail.com | [user:user]@[domain] | bax     | false  |
-    And the address "[user:user]@[domain]" of account "[user:user]" has the following messages in "Scheduled":
-      | from              | to                   | subject | unread |
-      | john.doe@mail.com | [user:user]@[domain] | sch     | false  |
     Then it succeeds
     When bridge starts
     And the user logs in with username "[user:user]" and password "password"
@@ -124,15 +121,7 @@ Feature: IMAP move messages
       | jane.doe@mail.com | name@[domain]        | bar     | true   |
       | john.doe@mail.com | [user:user]@[domain] | baz     | false  |
       | john.doe@mail.com | [user:user]@[domain] | bax     | false  |
-      | john.doe@mail.com | [user:user]@[domain] | sch     | false  |
 
-  Scenario: Move message from Scheduled is not possible
-    Given test skips reporter checks
-    When IMAP client "1" moves the message with subject "sch" from "Scheduled" to "Inbox"
-    Then it fails
-    And IMAP client "1" eventually sees the following messages in "Scheduled":
-      | from              | to                   | subject | unread |
-      | john.doe@mail.com | [user:user]@[domain] | sch     | false  |
 
   Scenario: Move message from Inbox to Sent is not possible
     Given test skips reporter checks

tests/features/imap/message/move_without_support.feature

@@ -60,9 +60,49 @@ Feature: IMAP move messages by append and delete (without MOVE support, e.g., Ou
       | INBOX      | Folders/mbox | DELETE APPEND EXPUNGE |
       | INBOX      | Spam         | DELETE APPEND EXPUNGE |
       | INBOX      | Trash        | DELETE APPEND EXPUNGE |
-      | Trash      | INBOX        | DELETE EXPUNGE APPEND |
       | Spam       | INBOX        | DELETE EXPUNGE APPEND |
       | INBOX      | Archive      | DELETE EXPUNGE APPEND |
       | INBOX      | Folders/mbox | DELETE EXPUNGE APPEND |
       | INBOX      | Spam         | DELETE EXPUNGE APPEND |
       | INBOX      | Trash        | DELETE EXPUNGE APPEND |
+
+  # black cannot pass this test, test timimng probably needs to be different. Once fixed it can be merged again
+  @skip-black
+  Scenario Outline: Move message from <srcMailbox> to <dstMailbox> by <order>, second batch
+    When IMAP client "source" appends the following message to "<srcMailbox>":
+      """
+      Received: by 2002:0:0:0:0:0:0:0 with SMTP id 0123456789abcdef; Wed, 30 Dec 2020 01:23:45 0000
+      From: sndr1@[domain]
+      Date: 01 Jan 1980 00:00:00 +0000
+      To: rcvr1@[domain]
+      Subject: subj1
+
+      body1
+      """
+    Then it succeeds
+    When IMAP client "source" appends the following message to "<srcMailbox>":
+      """
+      Received: by 2002:0:0:0:0:0:0:0 with SMTP id 0123456789abcdef; Wed, 30 Dec 2020 01:23:45 0000
+      From: sndr2@[domain]
+      Date: 01 Jan 1980 00:00:00 +0000
+      To: rcvr2@[domain]
+      Subject: subj2
+
+      body2
+      """
+    Then it succeeds
+    And IMAP client "source" selects "<srcMailbox>"
+    And IMAP client "target" selects "<dstMailbox>"
+    When IMAP clients "source" and "target" move message with subject "subj2" of "[user:user]" to "<dstMailbox>" by <order>
+    And IMAP client "source" eventually sees 1 messages in "<srcMailbox>"
+    And IMAP client "source" eventually sees the following messages in "<srcMailbox>":
+      | from           | to             | subject |
+      | sndr1@[domain] | rcvr1@[domain] | subj1   |
+    And IMAP client "target" eventually sees 1 messages in "<dstMailbox>"
+    And IMAP client "target" eventually sees the following messages in "<dstMailbox>":
+      | from           | to             | subject |
+      | sndr2@[domain] | rcvr2@[domain] | subj2   |
+    Examples:
+      | srcMailbox | dstMailbox   | order                 |
+      | Trash      | INBOX        | DELETE EXPUNGE APPEND |
+

tests/features/imap/message/scheduled.feature

@@ -0,0 +1,56 @@
+# need to implement _schedule message_ test step for black
+@skip-black
+Feature: IMAP interaction with scheduled
+
+  Scenario: Not possible to delete from Scheduled and expunge does nothing
+    Given there exists an account with username "[user:user]" and password "password"
+    And the account "[user:user]" has the following custom mailboxes:
+      | name  | type   |
+      | mbox  | folder |
+      | label | label  |
+    And the address "[user:user]@[domain]" of account "[user:user]" has 10 messages in "Folders/mbox"
+    And the address "[user:user]@[domain]" of account "[user:user]" has 1 messages in "Scheduled"
+    Then it succeeds
+    When bridge starts
+    And the user logs in with username "[user:user]" and password "password"
+    And user "[user:user]" finishes syncing
+    And user "[user:user]" connects and authenticates IMAP client "1"
+    Then it succeeds
+    When IMAP client "1" selects "Scheduled"
+    And IMAP client "1" marks message 1 as deleted
+    Then it succeeds
+    And IMAP client "1" expunges
+    Then it fails
+
+  Scenario: Move message from Scheduled is not possible
+    Given there exists an account with username "[user:user]" and password "password"
+    And the account "[user:user]" has the following custom mailboxes:
+      | name   | type   |
+      | mbox   | folder |
+      | label  | label  |
+      | label2 | label  |
+    And the address "[user:user]@[domain]" of account "[user:user]" has the following messages in "Inbox":
+      | from              | to                   | subject | unread |
+      | john.doe@mail.com | [user:user]@[domain] | foo     | false  |
+      | jane.doe@mail.com | name@[domain]        | bar     | true   |
+    And the address "[user:user]@[domain]" of account "[user:user]" has the following messages in "Labels/label2":
+      | from              | to                   | subject | unread |
+      | john.doe@mail.com | [user:user]@[domain] | baz     | false  |
+    And the address "[user:user]@[domain]" of account "[user:user]" has the following messages in "Sent":
+      | from              | to                   | subject | unread |
+      | john.doe@mail.com | [user:user]@[domain] | bax     | false  |
+    And the address "[user:user]@[domain]" of account "[user:user]" has the following messages in "Scheduled":
+      | from              | to                   | subject | unread |
+      | john.doe@mail.com | [user:user]@[domain] | sch     | false  |
+    Then it succeeds
+    When bridge starts
+    And the user logs in with username "[user:user]" and password "password"
+    And user "[user:user]" finishes syncing
+    And user "[user:user]" connects and authenticates IMAP client "1"
+    Then it succeeds
+    Given test skips reporter checks
+    When IMAP client "1" moves the message with subject "sch" from "Scheduled" to "Inbox"
+    Then it fails
+    And IMAP client "1" eventually sees the following messages in "Scheduled":
+      | from              | to                   | subject | unread |
+      | john.doe@mail.com | [user:user]@[domain] | sch     | false  |

tests/features/imap/message/state.feature

@@ -6,7 +6,7 @@ Feature: IMAP change state of message in mailbox
       | one  | folder |
       | two  | folder |
     And the address "[user:user]@[domain]" of account "[user:user]" has 5 messages in "Folders/one"
-    And the address "[user:user]@[domain]" of account "[user:user]" has 150 messages in "Folders/two"
+    And the address "[user:user]@[domain]" of account "[user:user]" has 5 messages in "Folders/two"
     And the address "[user:user]@[domain]" of account "[user:user]" has the following messages in "Inbox":
       | from          | to            | subject | unread |
       | a@example.com | b@example.com | one     | true   |

tests/features/smtp/auth.feature

@@ -2,15 +2,11 @@ Feature: A user can authenticate an SMTP client
   Background:
     Given there exists an account with username "[user:user]" and password "password"
     And there exists an account with username "[user:user2]" and password "password2"
-    And there exists a disabled account with username "[user:user3]" and password "password3"
     And the account "[user:user]" has additional address "[alias:alias]@[domain]"
-    And the account "[user:user2]" has additional disabled address "[alias:alias2]@[domain]"
-    And the account "[user:user3]" has additional address "[alias:alias3]@[domain]"
     Then it succeeds
     When bridge starts
     And the user logs in with username "[user:user]" and password "password"
     And the user logs in with username "[user:user2]" and password "password2"
-    And the user logs in with username "[user:user3]" and password "password3"
     Then it succeeds
 
   Scenario: SMTP client can authenticate successfully
@@ -40,8 +36,12 @@ Feature: A user can authenticate an SMTP client
     When user "[user:user]" connects and authenticates SMTP client "1" with address "[alias:alias]@[domain]"
     Then it succeeds
 
+  # Need to find  way to setup disabled address on black
+  @skip-black
   Scenario: SMTP client can not authenticate with disabled address
-    When user "[user:user2]" connects and authenticates SMTP client "1" with address "[alias:alias2]@[domain]"
+    Given the account "[user:user2]" has additional disabled address "[alias:disabled]@[domain]"
+    And it succeeds
+    When user "[user:user2]" connects and authenticates SMTP client "1" with address "[alias:disabled]@[domain]"
     Then it fails
 
   Scenario: SMTP Logs out user
@@ -55,7 +55,13 @@ Feature: A user can authenticate an SMTP client
     When user "[user:user2]" connects SMTP client "2"
     Then SMTP client "2" can authenticate
 
-  @ignore-live
+  # Need to find  way to setup disabled address on black
+  @skip-black
   Scenario: SMTP Authenticates with secondary address of account with disabled primary address
+    Given there exists a disabled account with username "[user:user3]" and password "password3"
+    And the account "[user:user3]" has additional address "[alias:alias3]@[domain]"
+    And it succeeds
+    And the user logs in with username "[user:user3]" and password "password3"
+    And it succeeds
     When user "[user:user3]" connects and authenticates SMTP client "1" with address "[alias:alias3]@[domain]"
     Then it succeeds

tests/features/smtp/send/attachment.feature

@@ -11,7 +11,8 @@ Feature: SMTP sending with attachment
     And user "[user:user1]" connects and authenticates IMAP client "1"
     Then it succeeds
 
-  @long-black
+  # black has issues with cyrilic char
+  @skip-black
   Scenario: Sending with cyrillic PDF attachment
     When SMTP client "1" sends the following message from "[user:user1]@[domain]" to "[user:user2]@[domain]":
       """
@@ -77,7 +78,8 @@ Feature: SMTP sending with attachment
       """
 
 
-  @long-black
+  # black has issues with cyrilic char
+  @skip-black
   Scenario: Sending with cyrillic docx attachment
     When SMTP client "1" sends the following message from "[user:user1]@[domain]" to "[user:user2]@[domain]":
       """

tests/features/smtp/send/bcc.feature

@@ -48,8 +48,6 @@ Feature: SMTP with bcc
       }
       """
 
-
-  @long-black
   Scenario: Send message only to bcc
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:bcc]@[domain]":
       """

tests/features/smtp/send/embedded_message.feature

@@ -9,7 +9,6 @@ Feature: SMTP sending embedded message
     And user "[user:user]" connects and authenticates SMTP client "1"
     Then it succeeds
 
-  @long-black
   Scenario: Send it
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:to]@[domain]":
       """
@@ -49,4 +48,4 @@ Feature: SMTP sending embedded message
     When user "[user:to]" connects and authenticates IMAP client "2"
     Then IMAP client "2" eventually sees the following messages in "Inbox":
       | from                 | to                 | subject          | attachments  | unread |
-      | [user:user]@[domain] | [user:to]@[domain] | Embedded message | embedded.eml | true   |
+      | [user:user]@[domain] | [user:to]@[domain] | Embedded message | embedded.eml | true   |

tests/features/smtp/send/failures.feature

@@ -1,7 +1,6 @@
 Feature: SMTP wrong messages
   Background:
     Given there exists an account with username "[user:user]" and password "password"
-    And the account "[user:user]" has additional disabled address "[user:disabled]@[domain]"
     And there exists an account with username "[user:to]" and password "password"
     Then it succeeds
     When bridge starts
@@ -48,13 +47,3 @@ Feature: SMTP wrong messages
 
       """
     Then it fails with error "invalid return path"
-
-Scenario: Send from a valid address that cannot send
-  When SMTP client "1" sends the following message from "[user:disabled]@[domain]" to "[user:to]@[domain]":
-    """
-    From: Bridge Test Disabled <[user:disabled]@[domain]>
-    To: Internal Bridge <[user:to]@[domain]>
-
-    Hello
-    """
-  And it fails with error "Error: can't send on address: [user:disabled]@[domain]"

tests/features/smtp/send/failures_disabled.feature

@@ -0,0 +1,24 @@
+Feature: SMTP wrong messages
+  Background:
+    Given there exists an account with username "[user:user]" and password "password"
+    And the account "[user:user]" has additional disabled address "[user:disabled]@[domain]"
+    And there exists an account with username "[user:to]" and password "password"
+    Then it succeeds
+    When bridge starts
+    And the user logs in with username "[user:user]" and password "password"
+    And user "[user:user]" connects and authenticates SMTP client "1"
+    Then it succeeds
+
+  # Need to find  way to setup disabled address on black
+  @skip-black
+  Scenario: Send from a valid address that cannot send
+    Given the account "[user:user]" has additional disabled address "[user:disabled]@[domain]"
+    When SMTP client "1" sends the following message from "[user:disabled]@[domain]" to "[user:to]@[domain]":
+      """
+      From: Bridge Test Disabled <[user:disabled]@[domain]>
+      To: Internal Bridge <[user:to]@[domain]>
+
+      Hello
+      """
+    And it fails with error "Error: can't send on address: [user:disabled]@[domain]"
+

tests/features/smtp/send/html.feature

@@ -9,6 +9,8 @@ Feature: SMTP sending of plain messages
     And user "[user:user]" connects and authenticates SMTP client "1"
     Then it succeeds
 
+  # black fails to get parent ID
+  @skip-black
   Scenario: HTML message to external account
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "pm.bridge.qa@gmail.com":
       """
@@ -49,6 +51,8 @@ Feature: SMTP sending of plain messages
       }
       """
 
+  # black is changing order of attachments
+  @skip-black
   Scenario: HTML message with inline image to external account
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "pm.bridge.qa@gmail.com":
       """
@@ -311,6 +315,8 @@ Feature: SMTP sending of plain messages
       }
       """
 
+  # black fails to get parent ID
+  @skip-black
   Scenario: HTML message with extremely long line (greater than default 2000 line limit) to external account
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "pm.bridge.qa@gmail.com":
       """
@@ -352,15 +358,13 @@ Feature: SMTP sending of plain messages
       """
 
   Scenario: HTML message with Foreign/Nonascii chars in Subject and Body to external
-    When there exists an account with username "bridgetest" and password "password"
+    When user "[user:user]" connects and authenticates SMTP client "1"
-    And the user logs in with username "bridgetest" and password "password"
+    And SMTP client "1" sends the following EML "html/foreign_ascii_subject_body.template.eml" from "[user:user]@[domain]" to "pm.bridge.qa@gmail.com"
-    And user "bridgetest" connects and authenticates SMTP client "1"
-    And SMTP client "1" sends the following EML "html/foreign_ascii_subject_body.eml" from "bridgetest@proton.local" to "pm.bridge.qa@gmail.com"
     Then it succeeds
-    When user "bridgetest" connects and authenticates IMAP client "1"
+    When user "[user:user]" connects and authenticates IMAP client "1"
     Then IMAP client "1" eventually sees the following messages in "Sent":
-      | from                    | to                     | subject        |
+      | from                     | to                     | subject        |
-      | bridgetest@proton.local | pm.bridge.qa@gmail.com | Subjεέςτ ¶ Ä È |
+      | [user:user]@[domain]     | pm.bridge.qa@gmail.com | Subjεέςτ ¶ Ä È |
     And the body in the "POST" request to "/mail/v4/messages" is:
       """
       {
@@ -384,11 +388,13 @@ Feature: SMTP sending of plain messages
 
   # It is expected for the structure check to look a bit different. More info on GODT-3011
   @regression
+  # Black changes order of attachments
+  @skip-black
   Scenario: HTML message with remote content in Body
-    When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:to]@[domain]":
+    When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:user2]@[domain]":
     """
     Date: 01 Jan 1980 00:00:00 +0000
-    To: Internal Bridge Test <[user:to]@[domain]>
+    To: Internal Bridge Test <[user:user2]@[domain]>
     From: Bridge Test <[user:user]@[domain]>
     Subject: MESSAGE WITH REMOTE CONTENT SENT
     Content-Type: multipart/alternative;
@@ -442,7 +448,7 @@ Feature: SMTP sending of plain messages
     """
     {
       "date": "01 Jan 01 00:00 +0000",      
-      "to": "Internal Bridge Test <[user:to]@[domain]>",
+      "to": "Internal Bridge Test <[user:user2]@[domain]>",
       "from": "Bridge Test <[user:user]@[domain]>",
       "subject": "MESSAGE WITH REMOTE CONTENT SENT",
       "content": {

tests/features/smtp/send/html_to_internal.feature

@@ -1,5 +1,5 @@
 @regression
-Feature: SMTP sending of HTMl messages to Internal recipient
+Feature: SMTP sending of HTML messages to Internal recipient
   Background:
     Given there exists an account with username "[user:user]" and password "password"
     And there exists an account with username "[user:to]" and password "password"
@@ -248,6 +248,8 @@ Feature: SMTP sending of HTMl messages to Internal recipient
       }
       """
 
+  # black is changing the order of attachments
+  @skip-black
   Scenario: HTML message with multiple attachments to Internal
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:to]@[domain]":
       """
@@ -754,6 +756,8 @@ Feature: SMTP sending of HTMl messages to Internal recipient
       }
       """
 
+  # black is changing order of attachments
+  @skip-black
   Scenario: HTML message with multiple inline images to Internal
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:to]@[domain]":
       """
@@ -1999,6 +2003,8 @@ Feature: SMTP sending of HTMl messages to Internal recipient
       }
       """
 
+  # black is changing order of attachments
+  @skip-black
   Scenario: HTML message with inline HTML and HTML attachment encoded in UTF-8
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:to]@[domain]":
       """
@@ -2071,6 +2077,8 @@ Feature: SMTP sending of HTMl messages to Internal recipient
       }
       """
 
+  # black is changing order of attachments
+  @skip-black
   Scenario: HTML msg with inline HTML and HTML attachment not encoded in UTF-8
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:to]@[domain]":
       """
@@ -2135,6 +2143,8 @@ Feature: SMTP sending of HTMl messages to Internal recipient
       }
       """
 
+  # black is changing order of attachments
+  @skip-black
   Scenario: HTML message and attachment not encoded in UTF-8 and without meta charset
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:to]@[domain]":
       """
@@ -2773,4 +2783,4 @@ Feature: SMTP sending of HTMl messages to Internal recipient
           ]
         }
       }
-      """
+      """

tests/features/smtp/send/one_account_to_another.feature

@@ -8,8 +8,6 @@ Feature: SMTP sending two messages
     And the user logs in with username "[user:recp]" and password "password"
     Then it succeeds
 
-
-  @long-black
   Scenario: Send from one account to the other
     When user "[user:user]" connects and authenticates SMTP client "1"
     And SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:recp]@[domain]":
@@ -64,8 +62,6 @@ Feature: SMTP sending two messages
       | from                 | to                   | subject                  | body  |
       | [user:user]@[domain] | [user:recp]@[domain] | One account to the other | hello |
 
-
-  @long-black
   Scenario: Send from one account to the other with attachments
     When user "[user:user]" connects and authenticates SMTP client "1"
     And SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:recp]@[domain]":
@@ -137,4 +133,4 @@ Feature: SMTP sending two messages
     When user "[user:recp]" connects and authenticates IMAP client "2"
     Then IMAP client "2" eventually sees the following messages in "Inbox":
       | from                 | to                   | subject                        | body             | attachments                    | unread |
-      | [user:user]@[domain] | [user:recp]@[domain] | Plain with attachment internal | This is the body | outline-light-instagram-48.png | true   |
+      | [user:user]@[domain] | [user:recp]@[domain] | Plain with attachment internal | This is the body | outline-light-instagram-48.png | true   |

tests/features/smtp/send/plain_att.feature

@@ -171,15 +171,13 @@ Feature: SMTP sending of plain messages
       """
 
   Scenario: Basic message with multiple different attachments to internal account
-    When there exists an account with username "bridgetest" and password "password"
+    When user "[user:user]" connects and authenticates SMTP client "1"
-    And the user logs in with username "bridgetest" and password "password"
+    And SMTP client "1" sends the following EML "plain/text_plain_multiple_attachments.template.eml" from "[user:user]@[domain]" to "[user:to]@[domain]"
-    And user "bridgetest" connects and authenticates SMTP client "1"
-    And SMTP client "1" sends the following EML "plain/text_plain_multiple_attachments.eml" from "bridgetest@proton.local" to "internalbridgetest@proton.local"
     Then it succeeds
-    When user "bridgetest" connects and authenticates IMAP client "1"
+    When user "[user:user]" connects and authenticates IMAP client "1"
     Then IMAP client "1" eventually sees the following messages in "Sent":
-      | from                    | to                              | subject                                   |
+      | from                     | to                 | subject                                   |
-      | bridgetest@proton.local | internalbridgetest@proton.local | Plain with multiple different attachments |
+      | [user:user]@[domain]     | [user:to]@[domain] | Plain with multiple different attachments |
     And the body in the "POST" request to "/mail/v4/messages" is:
       """
       {
@@ -190,7 +188,7 @@ Feature: SMTP sending of plain messages
           },
           "ToList": [
             {
-              "Address": "internalbridgetest@proton.local",
+              "Address": "[user:to]@[domain]",
               "Name": "Internal Bridge"
             }
           ],

tests/features/smtp/send/plain_to_internal.feature

@@ -164,6 +164,8 @@ Feature: SMTP sending of PLAIN messages to Internal recipient
       }
       """
 
+  # black changes order of attachments
+  @skip-black
   Scenario: Plain message with multiple attachments to Internal
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:to]@[domain]":
       """
@@ -660,6 +662,8 @@ Feature: SMTP sending of PLAIN messages to Internal recipient
       }
       """
 
+  # black is changing order of attachments
+  @skip-black
   Scenario: Forward a Plain message containing various attachments
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:to]@[domain]":
       """

tests/features/smtp/send/same_message.feature

@@ -17,7 +17,6 @@ Feature: SMTP sending the same message twice
       """
     And it succeeds
 
-  @long-black
   Scenario: The exact same message is not sent twice
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:to]@[domain]":
       """
@@ -37,8 +36,6 @@ Feature: SMTP sending the same message twice
       | from                 | to                 | subject | body  |
       | [user:user]@[domain] | [user:to]@[domain] | Hello   | World |
 
-
-  @long-black
   Scenario: Slight change means different message and is sent twice
     When SMTP client "1" sends the following message from "[user:user]@[domain]" to "[user:to]@[domain]":
       """
@@ -58,4 +55,4 @@ Feature: SMTP sending the same message twice
     Then IMAP client "2" eventually sees the following messages in "Inbox":
       | from                 | to                 | subject | body  |
       | [user:user]@[domain] | [user:to]@[domain] | Hello   | World |
-      | [user:user]@[domain] | [user:to]@[domain] | Hello.  | World |
+      | [user:user]@[domain] | [user:to]@[domain] | Hello.  | World |

tests/features/smtp/send/send_reply.feature

@@ -11,7 +11,6 @@ Feature: SMTP send reply
     And user "[user:user1]" connects and authenticates IMAP client "1"
     Then it succeeds
 
-  @long-black
   Scenario: Reply with In-Reply-To but no References
     # User1 send the initial message.
     When SMTP client "1" sends the following message from "[user:user1]@[domain]" to "[user:user2]@[domain]":
@@ -58,7 +57,6 @@ Feature: SMTP send reply
       | from                  | subject           | body  | in-reply-to               | references                |  reply-to             |
       | [user:user2]@[domain] | FW - Please Reply | Heya  | <something@protonmail.ch> | <something@protonmail.ch> | [user:user2]@[domain] |
 
-  @long-black
   Scenario: Reply with References but no In-Reply-To
     # User1 send the initial message.
     When SMTP client "1" sends the following message from "[user:user1]@[domain]" to "[user:user2]@[domain]":
@@ -106,7 +104,6 @@ Feature: SMTP send reply
       | [user:user2]@[domain] | FW - Please Reply | Heya  | <something@protonmail.ch> | <something@protonmail.ch> | [user:user2]@[domain] |
 
 
-  @long-black
   Scenario: Reply with both  References and In-Reply-To
     # User1 send the initial message.
     When SMTP client "1" sends the following message from "[user:user1]@[domain]" to "[user:user2]@[domain]":
@@ -155,7 +152,6 @@ Feature: SMTP send reply
       | [user:user2]@[domain] | FW - Please Reply | Heya  | <something@protonmail.ch> | <something@protonmail.ch> | [user:user2]@[domain] |
 
 
-  @long-black
   Scenario: Reply with In-Reply-To matching several received ExternalID
     # User1 send the initial message.
     When SMTP client "1" sends the following message from "[user:user1]@[domain]" to "[user:user2]@[domain]":
@@ -216,7 +212,6 @@ Feature: SMTP send reply
       | [user:user2]@[domain] | FW - Please Reply | Heya  |              |            |
 
 
-  @long-black
   Scenario: Reply with In-Reply-To matching several ExternalID but one sent by us
     # User1 send the initial message.
     When SMTP client "1" sends the following message from "[user:user1]@[domain]" to "[user:user2]@[domain]":
@@ -279,7 +274,6 @@ Feature: SMTP send reply
       | [user:user2]@[domain] | FW - Please Reply       | <something@external.com> | <something@external.com>  |
       | [user:user2]@[domain] | FW - Please Reply Again | <something@external.com> | <something@external.com>  |
 
-  @long-black
   Scenario: Reply with In-Reply-To and X-Forwarded-Message-Id sets forwarded flag
     # User1 send the initial message.
     When SMTP client "1" sends the following message from "[user:user1]@[domain]" to "[user:user2]@[domain]":
@@ -334,7 +328,8 @@ Feature: SMTP send reply
       | from                  | subject                 | in-reply-to              | references                |
       | [user:user2]@[domain] | FW - Please Reply       | <something@external.com> | <something@external.com>  |
 
-  @long-black
+  # black: missing answered flag
+  @skip-black
   Scenario: Reply with In-Reply-To sets answered flag
     # User1 send the initial message.
     When SMTP client "1" sends the following message from "[user:user1]@[domain]" to "[user:user2]@[domain]":
@@ -386,4 +381,4 @@ Feature: SMTP send reply
     # User1 receive the reply.|
     And IMAP client "1" eventually sees the following messages in "INBOX":
       | from                  | subject                 | in-reply-to              | references                |
-      | [user:user2]@[domain] | FW - Please Reply       | <something@external.com> | <something@external.com>  |
+      | [user:user2]@[domain] | FW - Please Reply       | <something@external.com> | <something@external.com>  |

tests/features/smtp/send/two_messages.feature

@@ -2,7 +2,7 @@ Feature: SMTP sending two messages
   Background:
     Given there exists an account with username "[user:user]" and password "password"
     And there exists an account with username "[user:multi]" and password "password"
-    And the account "[user:multi]" has additional address "[user:multi-alias]@[domain]"
+    And the account "[user:multi]" has additional address "[alias:multi]@[domain]"
     And there exists an account with username "[user:to]" and password "password"
     Then it succeeds
     When bridge starts
@@ -34,7 +34,7 @@ Feature: SMTP sending two messages
 
   Scenario: Send with two addresses of the same user in split mode
     When user "[user:multi]" connects and authenticates SMTP client "1" with address "[user:multi]@[domain]"
-    And user "[user:multi]" connects and authenticates SMTP client "2" with address "[user:multi-alias]@[domain]"
+    And user "[user:multi]" connects and authenticates SMTP client "2" with address "[alias:multi]@[domain]"
     And SMTP client "1" sends the following message from "[user:multi]@[domain]" to "[user:to]@[domain]>":
       """
       From: Bridge Test <[user:multi]@[domain]>

tests/features/user/addressmode.feature

@@ -111,9 +111,9 @@ Feature: Address mode
       | b@[domain] | b@[domain] | two     | false  |
       | c@[domain] | c@[domain] | three   | true   |
       | d@[domain] | d@[domain] | four    | false  |
-    Given the account "[user:user]" has additional address "other@[domain]"
+    Given the account "[user:user]" has additional address "[user:other]@[domain]"
     And bridge sends an address created event for user "[user:user]"
-    When user "[user:user]" connects and authenticates IMAP client "3" with address "other@[domain]"
+    When user "[user:user]" connects and authenticates IMAP client "3" with address "[user:other]@[domain]"
     Then IMAP client "3" eventually sees the following messages in "All Mail":
       | from       | to         | subject | unread |
       | a@[domain] | a@[domain] | one     | true   |
@@ -134,11 +134,13 @@ Feature: Address mode
       | from       | to         | subject | unread |
       | c@[domain] | c@[domain] | three   | true   |
       | d@[domain] | d@[domain] | four    | false  |
-    Given the account "[user:user]" has additional address "other@[domain]"
+    Given the account "[user:user]" has additional address "[user:other]@[domain]"
     And bridge sends an address created event for user "[user:user]"
-    When user "[user:user]" connects and authenticates IMAP client "3" with address "other@[domain]"
+    When user "[user:user]" connects and authenticates IMAP client "3" with address "[user:other]@[domain]"
     Then IMAP client "3" eventually sees 0 messages in "All Mail"
 
+  # Cannot delete primary address on black
+  @skip-black
   Scenario: The user deletes an address while in combined mode
     When user "[user:user]" connects and authenticates IMAP client "1" with address "[user:user]@[domain]"
     Then IMAP client "1" eventually sees the following messages in "All Mail":
@@ -159,6 +161,8 @@ Feature: Address mode
     When user "[user:user]" connects IMAP client "3"
     Then IMAP client "3" cannot authenticate with address "[alias:alias]@[domain]"
 
+  # Cannot delete primary address on black
+  @skip-black
   Scenario: The user deletes an address while in split mode
     Given the user sets the address mode of user "[user:user]" to "split"
     And user "[user:user]" finishes syncing
@@ -179,4 +183,4 @@ Feature: Address mode
 
   Scenario: The user makes an alias the primary address while in combined mode
 
-  Scenario: The user makes an alias the primary address while in split mode
+  Scenario: The user makes an alias the primary address while in split mode

tests/features/user/contact.feature

@@ -12,6 +12,8 @@ Feature: user's contact
     Then it succeeds
 
 
+  # Implement contacts on black
+  @skip-black
   Scenario: Playing with contact settings
     When the contact "SuperTester@proton.me" of user "[user:user]" has message format "plain"
     When the contact "SuperTester@proton.me" of user "[user:user]" has message format "HTML"

tests/features/user/login.feature

@@ -1,8 +1,6 @@
 Feature: A user can login
   Background:
     Given there exists an account with username "[user:user]" and password "password2"
-    And there exists an account with username "[user:MixedCaps]" and password "password3"
-    And there exists a disabled account with username "[user:disabled]" and password "password4"
     Then it succeeds
     And bridge starts
     Then it succeeds
@@ -24,11 +22,18 @@ Feature: A user can login
     When the user logs in with username "[user:user]" and password "password2"
     Then user "[user:user]" is not listed
 
+  # Mixed caps doesn't work on black
+  @skip-black
   Scenario: Login to account with caps
+    Given there exists an account with username "[user:MixedCaps]" and password "password3"
+    And it succeeds
     When the user logs in with username "[user:MixedCaps]" and password "password3"
     Then user "[user:MixedCaps]" is eventually listed and connected
 
+  # Mixed caps doesn't work on black
+  @skip-black
   Scenario: Login to account with disabled primary
+    Given there exists a disabled account with username "[user:disabled]" and password "password4"
     When the user logs in with username "[user:disabled]" and password "password4"
     Then user "[user:disabled]" is eventually listed and connected
 
@@ -51,5 +56,3 @@ Feature: A user can login
     Given the account "[user:user]" has additional address "[user:alias]@[domain]"
     When the user logs in with alias address "[user:alias]@[domain]" and password "password2"
     Then user "[user:user]" is eventually listed and connected
-    
-    

tests/features/user/relogin.feature

@@ -17,10 +17,10 @@ Feature: A logged out user can login again
     Then user "[user:user]" is not listed
 
   Scenario: Bridge password persists after logout/login
-    Given there exists an account with username "testUser" and password "password"
+    Given there exists an account with username "[user:test]" and password "password"
-    And the user logs in with username "testUser" and password "password"
+    And the user logs in with username "[user:test]" and password "password"
-    And the bridge password of user "testUser" is changed to "YnJpZGdlcGFzc3dvcmQK"
+    And the bridge password of user "[user:test]" is changed to "YnJpZGdlcGFzc3dvcmQK"
-    And user "testUser" is deleted
+    And user "[user:test]" is deleted
-    And the user logs in with username "testUser" and password "password"
+    And the user logs in with username "[user:test]" and password "password"
-    Then user "testUser" is eventually listed and connected
+    Then user "[user:test]" is eventually listed and connected
-    And the bridge password of user "testUser" is equal to "YnJpZGdlcGFzc3dvcmQK"
+    And the bridge password of user "[user:test]" is equal to "YnJpZGdlcGFzc3dvcmQK"

tests/features/user/report_problem.feature

@@ -6,7 +6,7 @@ Feature: The user reports a problem
     And the user logs in with username "[user:user]" and password "password"
     And user "[user:user]" finishes syncing
     Then it succeeds
-  
+
   Scenario: User sends a problem report without logs attached
     When the user reports a bug
     Then the header in the "POST" multipart request to "/core/v4/reports/bug" has "Title" set to "[Bridge] Bug - title"
@@ -22,7 +22,7 @@ Feature: The user reports a problem
     And the header in the "POST" multipart request to "/core/v4/reports/bug" has "Username" set to "[user:user]"
     And the header in the "POST" multipart request to "/core/v4/reports/bug" has file "logs.zip"
 
-  
+
   @regression
   Scenario: User sends a problem report while signed out of Bridge
     When user "[user:user]" logs out
@@ -30,7 +30,7 @@ Feature: The user reports a problem
     Then it succeeds
     And the header in the "POST" multipart request to "/core/v4/reports/bug" has "Username" set to "[user:user]"
     And the header in the "POST" multipart request to "/core/v4/reports/bug" has "Email" set to "[user:user]@[domain]"
-  
+
   @regression
   Scenario: User sends a problem report with changed Title
     When the user reports a bug with field "Title" set to "Testing title"
@@ -61,4 +61,4 @@ Feature: The user reports a problem
     And the header in the "POST" multipart request to "/core/v4/reports/bug" has "Username" set to "[user:user]"
     And the header in the "POST" multipart request to "/core/v4/reports/bug" has "Email" set to "[user:user]@[domain]"
     And the header in the "POST" multipart request to "/core/v4/reports/bug" has "Client" set to "Apple Mail"
-    And the header in the "POST" multipart request to "/core/v4/reports/bug" has file "logs.zip"
+    And the header in the "POST" multipart request to "/core/v4/reports/bug" has file "logs.zip"

tests/features/user/sync_high_number.feature

@@ -20,7 +20,9 @@ Feature: Bridge can fully synchronize an account with high number of messages, a
     Then it succeeds
     When bridge starts
     Then it succeeds
-  
+
+  # Too many messages need to use fixture on black
+  @skip-black
   Scenario: The account is synced when the user logs in and the number of messages is correct
     When the user logs in with username "[user:user]" and password "password"
     Then bridge sends sync started and finished events for user "[user:user]"

tests/imap_test.go

@@ -358,6 +358,24 @@ func (s *scenario) imapClientSeesMessageInMailboxWithStructure(clientID, mailbox
 			return err
 		}
 
+		debug := false
+		for iFetch := range fetch {
+			if !debug {
+				continue
+			}
+
+			fmt.Printf("\n\n\n fetch %d %#v\n evenlope %+v\n",
+				iFetch, fetch[iFetch],
+				fetch[iFetch].Envelope,
+			)
+
+			for _, v := range fetch[iFetch].Body {
+				fmt.Println("body literal", v)
+			}
+
+			fmt.Printf("\n\n\n")
+		}
+
 		haveMessages := xslices.Map(fetch, newMessageStructFromIMAP)
 
 		return matchStructure(haveMessages, msgStruct)

tests/init_test.go

@@ -1,40 +0,0 @@
-// Copyright (c) 2024 Proton AG
-//
-// This file is part of Proton Mail Bridge.Bridge.
-//
-// Proton Mail Bridge is free software: you can redistribute it and/or modify
-// it under the terms of the GNU General Public License as published by
-// the Free Software Foundation, either version 3 of the License, or
-// (at your option) any later version.
-//
-// Proton Mail Bridge is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-// GNU General Public License for more details.
-//
-// You should have received a copy of the GNU General Public License
-// along with Proton Mail Bridge. If not, see <https://www.gnu.org/licenses/>.
-
-package tests
-
-import (
-	"time"
-
-	"github.com/ProtonMail/go-proton-api/server/backend"
-	"github.com/ProtonMail/proton-bridge/v3/internal/certs"
-	"github.com/ProtonMail/proton-bridge/v3/internal/user"
-)
-
-func init() {
-	// Use the fast key generation for tests.
-	backend.GenerateKey = backend.FastGenerateKey
-
-	// Use the fast cert generation for tests.
-	certs.GenerateCert = FastGenerateCert
-
-	// Set the event period to 1 second for more responsive tests.
-	user.EventPeriod = time.Second
-
-	// Don't use jitter during tests.
-	user.EventJitter = 0
-}

tests/main_test.go

@@ -20,12 +20,29 @@ package tests
 import (
 	"os"
 	"testing"
+	"time"
 
+	"github.com/ProtonMail/go-proton-api/server/backend"
+	"github.com/ProtonMail/proton-bridge/v3/internal/certs"
+	"github.com/ProtonMail/proton-bridge/v3/internal/user"
 	"github.com/sirupsen/logrus"
 	"go.uber.org/goleak"
 )
 
 func TestMain(m *testing.M) {
+	// Use the fast key generation for tests.
+	backend.GenerateKey = backend.FastGenerateKey
+
+	// Use the fast cert generation for tests.
+	certs.GenerateCert = FastGenerateCert
+
+	if !isBlack() {
+		// Set the event period to 1 second for more responsive tests.
+		user.EventPeriod = time.Second
+		// Don't use jitter during tests.
+		user.EventJitter = 0
+	}
+
 	level := os.Getenv("FEATURE_TEST_LOG_LEVEL")
 
 	if os.Getenv("BRIDGE_API_DEBUG") != "" {

tests/smtp_test.go

@@ -150,7 +150,7 @@ func (s *scenario) smtpClientSendsTheFollowingEmlFromTo(clientID, file, from, to
 		return err
 	}
 
-	if err := clientSend(client, from, to, string(b)); err != nil {
+	if err := clientSend(client, from, to, s.t.replace(string(b))); err != nil {
 		s.t.pushError(err)
 	}
 

tests/testdata/html/foreign_ascii_subject_body.template.eml

@@ -1,15 +1,15 @@
-From: Bridge Test <bridgetest@proton.local>
+From: Bridge Test <[user:user]@[domain]>
-To: External Bridge <pm.bridge.qa@gmail.com>
+To: External Bridge <pm.bridge.qa@gmail.com>
-Subject: =?UTF-8?B?U3Vias61zq3Pgs+EIMK2IMOEIMOI?=
+Subject: =?UTF-8?B?U3Vias61zq3Pgs+EIMK2IMOEIMOI?=
-Content-Type: text/html; charset=UTF-8
+Content-Type: text/html; charset=UTF-8
-Content-Transfer-Encoding: 8bit
+Content-Transfer-Encoding: 8bit
-
+
-<html>
+<html>
-  <head>
+  <head>
-
+
-    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
+    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
-  </head>
+  </head>
-  <body>
+  <body>
-    Subjεέςτ ¶ Ä È
+    Subjεέςτ ¶ Ä È
-  </body>
+  </body>
-</html>
+</html>

tests/testdata/plain/text_plain_multiple_attachments.template.eml

@@ -1,69 +1,69 @@
-From: Bridge Test <bridgetest@proton.local>
+From: Bridge Test <[user:user]@[domain]>
-To: Internal Bridge <internalbridgetest@proton.local>
+To: Internal Bridge <[user:to]@[domain]>
-Subject: Plain with multiple different attachments
+Subject: Plain with multiple different attachments
-Content-Type: multipart/mixed; boundary="bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606"
+Content-Type: multipart/mixed; boundary="bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606"
-
+
---bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
+--bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
-Content-Type: text/plain; charset=UTF-8; format=flowed
+Content-Type: text/plain; charset=UTF-8; format=flowed
-Content-Transfer-Encoding: 7bit
+Content-Transfer-Encoding: 7bit
-
+
-Body of plain text message with multiple attachments
+Body of plain text message with multiple attachments
-
+
---bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
+--bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
-Content-Type: application/zip; name="PINProtected.zip"
+Content-Type: application/zip; name="PINProtected.zip"
-Content-Disposition: attachment; filename="PINProtected.zip"
+Content-Disposition: attachment; filename="PINProtected.zip"
-Content-Transfer-Encoding: base64
+Content-Transfer-Encoding: base64
-
+
-UEsDBBQACAAIAHhlwVYAAAAAAAAAABADAAAMACAAbWVzc2FnZTIudHh0VVQNAAdkdnhk7nZ4
+UEsDBBQACAAIAHhlwVYAAAAAAAAAABADAAAMACAAbWVzc2FnZTIudHh0VVQNAAdkdnhk7nZ4
-AABQSwUGAAAAAAIAAgC/AAAAewMAAAAA
+AABQSwUGAAAAAAIAAgC/AAAAewMAAAAA
-
+
---bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
+--bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
-Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="test.docx"
+Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="test.docx"
-Content-Disposition: attachment; filename="test.docx"
+Content-Disposition: attachment; filename="test.docx"
-Content-Transfer-Encoding: base64
+Content-Transfer-Encoding: base64
-
+
-UEsDBBQABgAIAAAAIQDfpNJsWgEAACAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo
+UEsDBBQABgAIAAAAIQDfpNJsWgEAACAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo
-AAAAgB4AAHdvcmQvc3R5bGVzLnhtbFBLBQYAAAAACwALAMECAADXKQAAAAA=
+AAAAgB4AAHdvcmQvc3R5bGVzLnhtbFBLBQYAAAAACwALAMECAADXKQAAAAA=
-
+
---bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
+--bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
-Content-Type: application/pdf; name="test.pdf"
+Content-Type: application/pdf; name="test.pdf"
-Content-Disposition: attachment; filename="test.pdf"
+Content-Disposition: attachment; filename="test.pdf"
-Content-Transfer-Encoding: base64
+Content-Transfer-Encoding: base64
-
+
-JVBERi0xLjUKJeLjz9MKNyAwIG9iago8PAovVHlwZSAvRm9udERlc2NyaXB0b3IKL0ZvbnRO
+JVBERi0xLjUKJeLjz9MKNyAwIG9iago8PAovVHlwZSAvRm9udERlc2NyaXB0b3IKL0ZvbnRO
-MjM0NAolJUVPRgo=
+MjM0NAolJUVPRgo=
-
+
---bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
+--bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
-Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="test.xlsx"
+Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="test.xlsx"
-Content-Disposition: attachment; filename="test.xlsx"
+Content-Disposition: attachment; filename="test.xlsx"
-Content-Transfer-Encoding: base64
+Content-Transfer-Encoding: base64
-
+
-UEsDBBQABgAIAAAAIQBi7p1oXgEAAJAEAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo
+UEsDBBQABgAIAAAAIQBi7p1oXgEAAJAEAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo
-AAoACgCAAgAAexwAAAAA
+AAoACgCAAgAAexwAAAAA
-
+
---bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
+--bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
-Content-Type: text/xml; charset=UTF-8; name="testxml.xml"
+Content-Type: text/xml; charset=UTF-8; name="testxml.xml"
-Content-Disposition: attachment; filename="testxml.xml"
+Content-Disposition: attachment; filename="testxml.xml"
-Content-Transfer-Encoding: base64
+Content-Transfer-Encoding: base64
-
+
-PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIHN1aXRl
+PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIHN1aXRl
-VUtUZXN0Ii8+CiAgICAgICAgPC9jbGFzc2VzPgogICAgPC90ZXN0PgoKPC9zdWl0ZT4=
+VUtUZXN0Ii8+CiAgICAgICAgPC9jbGFzc2VzPgogICAgPC90ZXN0PgoKPC9zdWl0ZT4=
-
+
---bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
+--bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
-Content-Type: text/plain; charset=UTF-8; name="update.txt"
+Content-Type: text/plain; charset=UTF-8; name="update.txt"
-Content-Disposition: attachment; filename="update.txt"
+Content-Disposition: attachment; filename="update.txt"
-Content-Transfer-Encoding: base64
+Content-Transfer-Encoding: base64
-
+
-DQpHb2NlQERFU0tUT1AtQ0dONkZENiBNSU5HVzY0IC9jL1Byb2dyYW0gRmlsZXMvUHJvdG9u
+DQpHb2NlQERFU0tUT1AtQ0dONkZENiBNSU5HVzY0IC9jL1Byb2dyYW0gRmlsZXMvUHJvdG9u
-NFdqRUw5WkplbnJZcUZucXVvSFBEa0w5VWZFeTA0VlBYRkViVERWLVlQaS1BSWc9PSINCg==
+NFdqRUw5WkplbnJZcUZucXVvSFBEa0w5VWZFeTA0VlBYRkViVERWLVlQaS1BSWc9PSINCg==
-
+
---bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
+--bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606
-Content-Type: text/calendar; charset=UTF-8; name="=?UTF-8?B?6YCZ5piv5ryi5a2X55qE5LiA5YCL5L6L5a2QLmljcw==?="
+Content-Type: text/calendar; charset=UTF-8; name="=?UTF-8?B?6YCZ5piv5ryi5a2X55qE5LiA5YCL5L6L5a2QLmljcw==?="
-Content-Disposition: attachment; filename*0*=UTF-8''%E9%80%99%E6%98%AF%E6%BC%A2%E5%AD%97%E7%9A%84%E4%B8%80; filename*1*=%E5%80%8B%E4%BE%8B%E5%AD%90%2E%69%63%73
+Content-Disposition: attachment; filename*0*=UTF-8''%E9%80%99%E6%98%AF%E6%BC%A2%E5%AD%97%E7%9A%84%E4%B8%80; filename*1*=%E5%80%8B%E4%BE%8B%E5%AD%90%2E%69%63%73
-Content-Transfer-Encoding: base64
+Content-Transfer-Encoding: base64
-
+
-QkVHSU46VkNBTEVOREFSCk1FVEhPRDpQVUJMSVNIClZFUlNJT046Mi4wClgtV1ItQ0FMTkFN
+QkVHSU46VkNBTEVOREFSCk1FVEhPRDpQVUJMSVNIClZFUlNJT046Mi4wClgtV1ItQ0FMTkFN
-RDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg==
+RDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg==
-
+
---bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606--
+--bc5bd30245232f31b6c976adcd59bb0069c9b13f986f9e40c2571bb80aa16606--
-
+

tests/types_test.go

@@ -448,19 +448,19 @@ func eventually(condition func() error) error {
 	var timerDuration = 30 * time.Second
 	// Extend to 5min for live API.
 	if hostURL := os.Getenv("FEATURE_TEST_HOST_URL"); hostURL != "" {
-		timerDuration = 600 * time.Second
+		timerDuration = 300 * time.Second
 	}
 
 	timer := time.NewTimer(timerDuration)
 	defer timer.Stop()
 
-	ticker := time.NewTicker(100 * time.Millisecond)
+	ticker := time.NewTicker(timerDuration / 300)
 	defer ticker.Stop()
 
 	for tick := ticker.C; ; {
 		select {
 		case <-timer.C:
-			return fmt.Errorf("timed out: %w", lastErr)
+			return fmt.Errorf("eventually timed out: %w", lastErr)
 
 		case <-tick:
 			tick = nil

tests/user_test.go

@@ -57,7 +57,7 @@ func (s *scenario) theAccountHasAdditionalAddressWithoutKeys(username, address s
 	userID := s.t.getUserByName(username).getUserID()
 
 	// Decrypt the user's encrypted ID for use with quark.
-	userDecID, err := s.t.runQuarkCmd(context.Background(), "encryption:id", "--decrypt", userID)
+	userDecID, err := s.t.decryptID(userID)
 	if err != nil {
 		return err
 	}
@@ -66,6 +66,7 @@ func (s *scenario) theAccountHasAdditionalAddressWithoutKeys(username, address s
 	if _, err := s.t.runQuarkCmd(
 		context.Background(),
 		"user:create:address",
+		"--",
 		string(userDecID),
 		s.t.getUserByID(userID).getUserPass(),
 
@@ -513,7 +514,7 @@ func (s *scenario) addAdditionalAddressToAccount(username, address string, disab
 	userID := s.t.getUserByName(username).getUserID()
 
 	// Decrypt the user's encrypted ID for use with quark.
-	userDecID, err := s.t.runQuarkCmd(context.Background(), "encryption:id", "--decrypt", userID)
+	userDecID, err := s.t.decryptID(userID)
 	if err != nil {
 		return err
 	}
@@ -527,6 +528,7 @@ func (s *scenario) addAdditionalAddressToAccount(username, address string, disab
 	}
 
 	args = append(args,
+		"--",
 		string(userDecID),
 		s.t.getUserByID(userID).getUserPass(),
 		address,
@@ -557,6 +559,14 @@ func (s *scenario) addAdditionalAddressToAccount(username, address string, disab
 func (s *scenario) createUserAccount(username, password string, disabled bool) error {
 	// Create the user and generate its default address (with keys).
 
+	if len(username) == 0 || username[0] == '-' {
+		panic("username must be non-empty and not start with minus")
+	}
+
+	if len(password) == 0 || password[0] == '-' {
+		panic("password must be non-empty and not start with minus")
+	}
+
 	args := []string{
 		"--name", username,
 		"--password", password,
@@ -582,7 +592,7 @@ func (s *scenario) createUserAccount(username, password string, disabled bool) e
 		}
 
 		// Decrypt the user's encrypted ID for use with quark.
-		userDecID, err := s.t.runQuarkCmd(context.Background(), "encryption:id", "--decrypt", user.ID)
+		userDecID, err := s.t.decryptID(user.ID)
 		if err != nil {
 			return err
 		}
@@ -592,6 +602,7 @@ func (s *scenario) createUserAccount(username, password string, disabled bool) e
 			context.Background(),
 			"user:create:subscription",
 			"--planID", "visionary2022",
+			"--",
 			string(userDecID),
 		); err != nil {
 			return err