Adding unique account ID to email may foil VARs/resellers

[Vermyndax]

In the case of some resellers or VARs, they have to pre-create a known email address inside the email system first. Having the code generate one that is dynamically generated to include the account ID foils that, unfortunately.

[afeld]

Responding to comments from #9 here.

I still do not understand the purpose behind generating a unique email address with arbitrary values outside of what is supplied by the user in the environment variable.

AWS requires a unique email per account. Since the broker can make many accounts, it can't simply use the one from the environment variable.

I would still like this to just use an actual usable email address given by the user.

We can accept a parameter for the email to be used with the account, but I suggest we keep it optional.

Just because [appending to addresses] works in public Gmail does not guarantee that it will work in GSA's GMail Suite

It works. You can test yourself! Send a message to name+something@gsa.gov.

[afeld]

I should elaborate: thinking about the DevSecOps use case, a given team will be creating an arbitrary number of accounts through this broker. As we know, each account will need a unique email address associated with it. There are two ways (I can think of) that the email can be specified:

• At start time - this is what BASE_EMAIL is doing, in order to generate the unique email using the + syntax (basically only supported by GMail)
• At provision time - this is where a parameter could be used for the user to specify the unique email

The latter would support the VAR use case, I think, though I'd argue that's out of scope for us. Thoughts?

[afeld]

Sorry, I should clarify again: I think this is less about VAR vs. non-VAR, and more about whether the email system supports + email aliases or not. Since our primary concern is GSA, I'd say supporting non-aliasable emails is out of scope. That being said, certainly open to pull requests to support them. That sound reasonable?