Einrichtung

Im AWS-Konto

Nicht gebraucht werden Lambda, EC2, VPC oder eine WorkMail-Organisation.

Der kurze Weg: CloudFormation

Bucket, Bucket-Policy, IAM-Benutzer samt Policy, die Geräte-Boundary und die SES-Empfangsregel legt eine Vorlage an (deploy/README.md im Repository sagt, wofür jede Ressource da ist):

aws cloudformation create-stack \
  --stack-name s3mail \
  --template-body file://deploy/s3mail.json \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameters \
      ParameterKey=MailDomain,ParameterValue=firma.de \
      ParameterKey=MailboxLocalPart,ParameterValue=info \
      ParameterKey=MailBucket,ParameterValue=mein-eindeutiger-bucket

Die Domain muss vorher in SES verifiziert sein; dafür braucht es DNS-Einträge, die nur du setzen kannst. Zwei Schritte kann die Vorlage nicht abschließen, und beide sind ein Befehl: das Rule-Set aktivieren (dafür gibt es keine CloudFormation-Ressource) und einen Zugangsschlüssel erzeugen. Die Vorlage legt bewusst keinen an: ein Schlüssel in einem Stack-Output ist für jeden lesbar, der den Stack lesen kann, und bleibt es.

aws ses set-active-receipt-rule-set --rule-set-name s3mail-info
aws iam create-access-key --user-name s3mail-info

IAM-Policy

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::MEIN-BUCKET",
      "Condition": {"StringLike": {"s3:prefix": ["mail/*"]}} },
    { "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::MEIN-BUCKET/mail/*" },
    { "Effect": "Allow", "Action": "ses:SendRawEmail", "Resource": "*" },
    { "Effect": "Allow", "Action": ["sqs:ReceiveMessage", "sqs:DeleteMessage"],
      "Resource": "arn:aws:sqs:REGION:KONTO:MEINE-QUEUE" },
    { "Effect": "Allow", "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
      "Resource": "arn:aws:kms:REGION:KONTO:key/DEIN-SCHLUESSEL" }
  ]
}

Der KMS-Teil entfällt, wenn weder der Bucket noch die SES-Regel verschlüsselt. Der SQS-Teil entfällt, wenn es keine Klingel gibt; dann läuft der Abgleich im Takt. sqs:GetQueueUrl steht bewusst nicht dabei: s3mail baut die URL aus dem ARN, den es ohnehin in der Policy liest.

Bucket, Ordner, Absenderadresse und Queue stehen bereits in der Policy, als genau die Angabe, an der AWS den Zugriff später misst. Darf der Zugang seine eigene Policy lesen (iam:ListUserPolicies, iam:GetUserPolicy auf user/${aws:username}), holt s3mail sie sich von dort, statt danach zu fragen: eintragen musst du dann nur noch Access Key und Secret. Gelesen werden nur eingebettete Policies. Die Region nennt S3 selbst im Kopf seiner Antwort.

Optional, nur für die Bequemlichkeit des Assistenten: s3:ListAllMyBuckets (Bucket-Auswahlliste; bewusst nicht in der Policy oben, weil es jeden Bucket des Kontos zeigt), ses:ListIdentities und ses:GetIdentityVerificationAttributes (Absender-Auswahl), s3:GetLifecycleConfiguration und s3:PutLifecycleConfiguration (Papierkorb-Automatik).

Erster Start

./s3mail

Beim Start schreibt s3mail eine Adresse ins Terminal, die ein Token enthält: s3mail laeuft auf 127.0.0.1.. Der Browser öffnet sich damit von selbst. Ohne dieses Token antwortet der Server nicht.

Beim ersten Mal öffnet sich der Einrichtungs-Assistent statt des Postfachs, in drei Schritten: AWS-Zugang (Profil wählen oder Access Key ID + Secret eintragen, dazu die Region), Postfach (Bucket, Prefix aus der SES-Regel, Absenderadresse für Antworten, optional Signatur und ein Name für den Umschalter), Prüfen (legt kurz ein Testobjekt an und löscht es wieder; Ergebnis ist eine Checkliste, und was fehlt, steht im Klartext dabei). Danach lässt sich optional eine Lifecycle-Regel setzen, die den Papierkorb nach 7/30/90 Tagen leert.

„Speichern und starten“ schreibt ~/.config/s3mail/config.json (chmod 600) und lädt direkt das Postfach. Ab dann genügt ./s3mail. Über Einstellungen oben rechts kommst du jederzeit zurück in den Assistenten, auch für ein zweites Postfach.

Optionen