E-Mail des Servers

WorkOffice Pro verschickt Mails auf zwei Wegen:

Weg	Was	Eingetragen
Konto des Servers	Systemmails: Passwort vergessen, Zwei-Faktor, Einladungen, Aufgaben-Erinnerungen, Bank-Freigabe, Nachrichten der Pendelakte, „Angebot angenommen“ aus dem Kundenportal, Meldungen der Archivprüfung	vom Betreiber in der `.env`
Mailserver des Betriebs	Rechnungen, Angebote, Lieferscheine, Mahnungen, Serienrechnungen an die Kunden des Betriebs	vom Betrieb unter Einstellungen → E-Mail-Versand

Dieser Artikel behandelt das Konto des Servers.

Die Einträge

SMTP_HOST=smtp.ihrbetrieb.de
SMTP_PORT=587
SMTP_USER=buero@ihrbetrieb.de
SMTP_PASSWORD=
SMTP_SECURE=false
MAIL_FROM=buero@ihrbetrieb.de

SMTP_SECURE: true für eine Verbindung, die von Anfang an verschlüsselt ist (üblich auf Port 465), false für Port 587, auf dem die Verschlüsselung nach dem Verbindungsaufbau ausgehandelt wird.
MAIL_FROM muss eine Adresse sein, unter der das Konto senden darf – sonst lehnt der Mailserver ab oder die Mail landet im Spam. In der Vorlage .env.example steht eine Adresse des Herstellers; auf dem eigenen Server gehört dort die eigene hin.
Danach docker compose -p workoffice -f docker-compose.selfhost.yml up -d.

Wie die Absender heißen

Jede Systemmail trägt einen Namen nach ihrer Art, mit der Adresse aus MAIL_FROM: „WorkOffice Pro - Support“ für Passwort und Zwei-Faktor, „WorkOffice Pro - Einladung“, „WorkOffice Pro - Erinnerung“, „WorkOffice Pro - Bank“ und so weiter. Steht in MAIL_FROM ein eigener Name, etwa Bergmann Elektrotechnik <buero@ihrbetrieb.de>, gilt dieser Name für alle Systemmails – solange MAIL_MARKE leer ist.

Anpassen lässt sich das in der .env:

MAIL_MARKE ersetzt „WorkOffice Pro“ vor dem Bindestrich, etwa MAIL_MARKE=Bergmann Elektrotechnik für „Bergmann Elektrotechnik - Support“.
MAIL_ABSENDER_<ART> gibt einer Art einen eigenen Namen, eine eigene Adresse oder beides – Arten: INFO, SUPPORT, EINLADUNG, ERINNERUNG, VERTRIEB, KUNDENPORTAL, STEUERBERATER, BANK, SYSTEM, PARTNER, ABRECHNUNG. Eine eigene Adresse muss das Konto als Alias kennen.

docker-compose.selfhost.yml reicht alle diese Einträge an die API weiter; nach docker compose -p workoffice -f docker-compose.selfhost.yml up -d gelten sie.

Ohne SMTP

Ist SMTP_HOST leer, verschickt der Server nichts – die Mails landen nur im Protokoll der API (docker compose … logs api). Für einen ersten Probelauf ist das bequem. Im Betrieb heißt es: „Passwort vergessen“ kommt nie an, Einladungen auch nicht.

Rechnungen der Betriebe

Jeder Betrieb kann unter Einstellungen → E-Mail-Versand seinen eigenen Mailserver eintragen; dann gehen seine Belege von seiner Adresse hinaus. Trägt er keinen ein, gehen sie auf einem Server beim Kunden über das Konto des Servers – mit dem Namen des Betriebs. Das ist der Unterschied zur Cloud, wo ohne eigenen Mailserver nichts an Kunden verschickt wird: Auf dem eigenen Server ist das Konto ohnehin das eigene.

Der Mailserver eines Betriebs muss von außen erreichbar sein und verschlüsselt sprechen; erlaubt sind die Ports 25, 465, 587 und 2525. Adressen im eigenen Netz sind gesperrt – den Mailserver gibt der Betrieb vor, und ohne diese Sperre könnte er den Server Verbindungen in das interne Netz aufbauen lassen. Die Meldung dazu:

Der Mailserver zeigt in ein internes Netz. Das ist nur beim Betrieb auf dem eigenen Server erlaubt (MAIL_INTERNE_SERVER=true).

Auf dem eigenen Server mit einem Mail-Relay im Haus schaltet MAIL_INTERNE_SERVER=true in der .env diese Sperre ab; docker-compose.selfhost.yml reicht den Eintrag an die API weiter (Vorgabe false, siehe Umgebungsvariablen). Ob Betriebe ohne eigenen Mailserver über das Konto des Servers senden, legt BETRIEB_MAIL_UEBER_SERVER ausdrücklich fest; leer gilt auf dem eigenen Server „ja“.

Belege per E-Mail empfangen

Das ist ein eigenes Thema mit eigenem Postfach (IMAP) und den Einträgen BELEGEMPFANG_ADRESSE und IMAP_*. Ohne BELEGEMPFANG_ADRESSE bleibt der Empfang abgeschaltet.