Über SMTP senden
Derselbe Versand wie POST /emails, für Software, die SMTP spricht.
Verbinden
Alles, was Mail über einen SMTP-Server sendet, kann über OpenEmail senden: der Mailer eines Frameworks, ein CMS, ein Monitoring-Tool, ein Drucker. Melden Sie sich mit dem Benutzernamen openemail und einem API-Schlüssel als Passwort an. Der Schlüssel braucht den Scope emails:send, und eine Nachricht, die er übergibt, ist derselbe Versand wie POST /emails mit diesem Schlüssel.
| Einstellung | Wert |
|---|---|
| Host | smtp.openemail.uk |
| Port | 465 mit SSL/TLS oder 587 mit STARTTLS |
| Benutzername | openemail |
| Passwort | Ein API-Schlüssel mit dem Scope emails:send |
| Anmeldung | PLAIN oder LOGIN, was die meiste Software ein normales Passwort nennt |
Unverschlüsselt wird nichts angenommen, und auf Port 587 öffnet sich die Anmeldung erst nach STARTTLS. Ein API-Schlüssel meldet sich nur zum Senden an. Das Lesen eines Postfachs über IMAP oder POP3 erfordert ein App-Passwort.
Eine Testnachricht senden
Speichern Sie eine Nachricht als message.eml und übergeben Sie sie mit curl. From muss eine Adresse sein, als die der Schlüssel senden darf.
From: Acme <[email protected]>To: [email protected]Subject: Hello over SMTPMessage-ID: <[email protected]> It works.curl --url "smtps://smtp.openemail.uk:465" \ --user "openemail:$OPENEMAIL_API_KEY" \ --mail-from "[email protected]" \ --mail-rcpt "[email protected]" \ --upload-file message.eml --crlfcurl --ssl-reqd --url "smtp://smtp.openemail.uk:587" \ --user "openemail:$OPENEMAIL_API_KEY" \ --mail-from "[email protected]" \ --mail-rcpt "[email protected]" \ --upload-file message.eml --crlfDie Antwort auf eine angenommene Nachricht ist 250 2.0.0 OK queued as, gefolgt von ihrer ID. Diese ID ist die, die GET /emails/{id} annimmt. Die Nachricht, ihre Ereignisse und ihr Tracking lassen sich also wie bei jedem anderen Versand lesen.
Wie aus einer Nachricht ein Versand wird
Die Nachricht wird gelesen und über denselben Weg gesendet wie ein REST-Versand, sie wird also aus ihren Teilen neu aufgebaut und nicht Byte für Byte weitergereicht.
| In der Nachricht | Im Versand |
|---|---|
| From | from. Die Angabe ist Pflicht, und sie ist der Absender, gegen den der Schlüssel geprüft wird. Die Adresse in MAIL FROM muss nur vorhanden sein. |
| RCPT TO | Wem die Nachricht zugestellt wird, höchstens 50. Ein in To genannter Empfänger ist ein to, ein in Cc genannter ein cc, und einer, der in keinem von beiden steht, ein bcc. Mindestens einer muss in To stehen. |
| Reply-To | replyTo, die erste Adresse. |
| Subject | subject. |
| Die Text- und HTML-Teile | text und html. Ein Bild, das das HTML als cid: verwendet, wird an seiner Stelle eingebettet. |
| Anhänge | attachments: höchstens 20 Dateien und zusammen 5 MB. |
| Weitere Header | X-*, List-*, Precedence, Auto-Submitted, Importance, Priority und Feedback-ID bleiben erhalten. Jeder andere Header wird weggelassen. |
| X-OpenEmail-Stream | stream: transactional oder broadcast. Der Header wird entfernt, bevor die Nachricht hinausgeht. |
Was gilt
Alles, was für einen REST-Versand gilt, gilt auch hier, denn es ist ein und derselbe Weg.
- Die Scopes des Schlüssels sowie die Adressen und Domains, auf die er beschränkt ist.
- Die Absenderprüfung:
Fromist eine Adresse auf einer Domain, die senden kann, und eine, als die der Schlüssel senden darf. - Das Versandkontingent des Workspace und seine Sperrliste.
- Die Signatur und das Öffnungs- und Klick-Tracking der Adresse, von der gesendet wird, wie bei einem REST-Versand, der weder
signaturenochtrackingsetzt. - Die Spur: Solange die Broadcast-Spur pausiert ist, wird eine Nachricht mit
X-OpenEmail-Stream: broadcastabgelehnt. - Webhooks und Zustellereignisse, die die Nachricht mit der ID aus der
250-Antwort benennen.
Wiederholungen
Eine Nachricht mit einer Message-ID wird einmal gesendet. Wird dieselbe Message-ID für dieselben Empfänger erneut übergeben, kommt als Antwort die ID der ersten Nachricht, und es wird nichts gesendet. Software, die es nach einer abgebrochenen Verbindung erneut versucht, kann sie also nicht doppelt senden. Dieselbe Nachricht für andere Empfänger ist ein weiterer Versand. Siehe Idempotenz.
Antworten und Limits
| Antwort | Wann |
|---|---|
| 250 2.0.0 | Die Nachricht steht in der Warteschlange, und ihre ID folgt. |
| 535 5.7.8 | Die Anmeldung ist fehlgeschlagen: ein falscher, widerrufener oder abgelaufener Schlüssel, ein Schlüssel ohne emails:send oder ein API-Schlüssel unter einem anderen Benutzernamen. |
| 452 4.5.3 | Mehr als 50 Empfänger in einer Nachricht. Mail-Software sendet den Rest von selbst in einer weiteren. |
| 552 5.3.4 | Die Nachricht ist größer als 25 MB. |
| 550 5.6.0 | Die Nachricht kann so, wie sie geschrieben ist, nicht gesendet werden: kein From, niemand in To, zu viele oder zu große Anhänge, eine unbekannte Spur. Der Text sagt, was zutrifft. |
| 550 5.7.1 | Der Versand wurde abgelehnt: Der Schlüssel darf nicht als diese Adresse senden, die Domain kann noch nicht senden, oder die Broadcast-Spur ist pausiert. |
| 452 4.7.0 | Das Versandkontingent des Workspace ist aufgebraucht. |
| 451 4.7.1 | Mehr als 300 Nachrichten von einem Schlüssel in einer Minute. Mail-Software wartet und versucht es erneut. |
| 451 4.3.0 | Ein Fehler auf unserer Seite. Versuchen Sie es in Kürze erneut. |
Eine Verbindung, über die nichts gesendet wird, schließt sich nach fünf Minuten. Eine Verbindung kann beliebig viele Nachrichten tragen, eine nach der anderen.
Im Anfrageprotokoll
Jede Nachricht, die ein Schlüssel übergibt, ist eine Zeile in seinem Anfrageprotokoll, mit der Methode SMTP, dem Pfad /emails und dem Status, den ein REST-Versand gehabt hätte: 202, wenn sie in die Warteschlange kam, und 403, 422 oder 429 mit demselben code des Fehlers, wenn sie abgelehnt wurde. GET /keys/{id}/requests?path=/emails listet sie neben den REST-Versänden auf. Eine Anmeldung, die mit einem echten Schlüssel fehlschlägt, erscheint in der Aktivität dieses Schlüssels.