Add an endpoint to login.

As a owner of this program, in order to save on needlessly expended bandwidth and keep the cloud account in good standing, I want e-mail addresses disabled when their have been too many bounces.

Acceptance Criteria

• Mark a source e-mail as disabled after one bounce.
  • What if the verification e-mail bounces?
• Ability to mark an e-mail address as active after showing it can receive e-mails again by sending an e-mail similar to the ownership verification e-mail.
• Do not forward e-mails to a disabled e-mail address.

Ideas

Use AWS SES's notification functionality to send events to an AWS SNS topic. This is hooked up to a Lambda that is able to write to the actual e-mail entity in DynamoDB. It will write more attributes that it had a hard bounce or marked the message as spam.

In the forwarding usecase, it will also check these attributes and not forward the e-mail if it had a bounce or was marked as spam.

As a halprin, in order to add or delete e-mail mappings, I want a management application to add or delete mappings.

A local command-line program that takes in a URL, reads from that URL location as an e-mail, and forwards it to me via AWS SES.

This doesn't need an SES rule created, an S3 bucket, nor an SNS topic. No IaC is needed for this. This is just to test the SES API. Later on, we can add a story for SES receiving part that'll require SES rules, S3 bucket, SNS topic, etc. Even beyond that, we can add a story to Dockerize this application and put it in ECS.

• Can read from a local file:// URL
• I receive the e-mails
• All headers are preserved, even the To
  • Don't preserve the DKIM headers though. arithmetric/aws-lambda-ses-forwarder#8

As a user, in order for the application to work, I need to know whether I entered a valid e-mail address.

Use https://github.com/gin-gonic/gin.

Make sure to make things concurrency-safe while there being good performance. Case-in-point: the AWS session and service should be a singleton, but concurrency can make that hard.

POST /v1/forward

{
    "emailUrl": "s3://moof.dms"
}

As a halprin, in order to easily differentiate between multiple concealed e-mail addresses, I want to to assign descriptions to them.

Acceptance Criteria

• Ability to set an optional description on creation of a concealed e-mail address.
• Ability to add a description to a concealed e-mail address after creation.
• Ability to delete a description to a concealed e-mail address.
• Add this description to forwarded e-mails by including them in the custom e-mail address name.
• Limit the description to 50 unicode characters.

Use an e-mail as the username.

Update the existing endpoints to require that you are already logged in.
Update the existing endpoints to associate the user with the actual e-mails and conceal e-mails.
Update the existing endpoints to ensure you can only read/update/delete the actual e-mails and conceal e-mails that you created.

AWS SES only allows up to 10 MB e-mails (once it's been encoded Base64) to be sent. Allow e-mails over 10 MB to be received using this service.

Possible Solutions

• Put the output e-mail (not the input e-mail) into an S3 bucket and then send a simple e-mail out to the forwarded recipients with a S3 pre-signed link.

To prevent other people signing up e-mails they don't control, a newly added real e-mail address will expire after eight hours.

As halprin, in order to remain anonymous, I want to receive e-mail from a single anonymous e-mail address.

• Set-up a single e-mail address to be the anonymous e-mail that receives e-mail
• CI/CD process created
• Infrastructure as Code created (SES to receive and send e-mails, S3 bucket to receive e-mails, SQS to be notified of e-mails, something to run the forwarder (ECS?))

As a halprin, in order to receive concealed e-mails, I wan to be able to set-up multiple concealed e-mails address for myself.

As a person with an e-mail address, in order for my e-mail address to not be signed up for this service when I don't want it to be, I want e-mail addresses to be verified by the owner before forwarding begins.

Acceptance Criteria

• Valid owner of e-mail address has ability to verify ownership.
  • Send validation e-mail.
  • Validation link activates the actual e-mail.
• Owner of e-mail address has ability chose to not approve e-mail address (which could be through ignoring the verification method).
• Creating a conceal e-mail for a given actual e-mail is only allowed if that actual e-mail is verified.