Es gibt zwei Arten der Übermittlung von Mails per SMTP: Mails an Empfänger, für die der annehmende Server sich selbst zuständig fühlt, und solche, die er weitergeben muss.

Für Ersteres ist keine Authentifizierung notwendig; wenn ich eine E-Mail an beispiel@gmx.de direkt beim SMTP-Server von GMX einliefere, brauche ich dazu kein Passwort, keine spezielle Software, keinen speziellen Server.

Du benötigst dazu einen SMTP-Client, der das SMTP-Protokoll mit dem Server sprechen kann. Selbstverständlich kann der Server das Relaying auch ablehnen. Selbstverständlich kann er es auch abhängig von Authorisierungen machen. Du kannst ohne SMTP keine eMail bei GMX-Mail "einliefern"

Ich schrieb von "zwei Arten der Übermittlung von Mails per SMTP". Von "ohne SMTP" war nirgends die Rede.

Ich beschränke mich zudem eben gerade _nicht_ auf das Relaying. Das Relaying ist vielmehr eine der beiden genannten Arten, nämliche die zweite, die Weitergabe.

Ein SMTP-Client ist darüber hinaus auch keine spezielle Software im Sinne der ursprünglichen Frage: Das kann auch ein selbstgestricktes PHP-Skript aus kayas Ausgangsfrage sein.
Es gibt aus Protokollsicht wirklich nichts, was gegen ein selbstgestricktes Skript spricht; es stehen einzig praktische Überlegungen, beinahe schon Fragen der Bequemlichkeit gegen kayas Vorhaben.

E-Mail-Versand wäre auch überhaupt nicht möglich, wenn man für jede Domain Anmeldedaten bräuchte

Das habe ich auch gar nicht behauptet. Du hast nur nicht genau gelesen

Habe ich? Dies habe ich gelesen:

Da der SMTP-Server gegen Missbrauch intern aber noch einige Dinge prüft vor dem Annehmen des Auftrages (SASL) und sich beim SMTP-Partner im Netz (der dann Client spielt) authentifiziert, kann man das heute nicht mehr so einfach mit einem eigenen SMTP-Script nachbilden.

Zwei SMTP-Server, der übermittelnde soll sich beim empfangenden authentifizieren. Das ist so nicht richtig, genauso wenig wie die Behauptung, dass ginge nicht mit einem eigenen "SMTP-Skript", also mit dem selbstgestrickten PHP-Skript aus kayas Ausgangsfrage.

Zwischen Mailservern findet im Allgemeinen keine Authentifizierung statt. Punkt. Mailserver sind die Systeme, die dauerhaft im Netz erreichbar sind und Mails annehmen. Falls du mit dem "SMTP-Server" und seinem "SMTP-Partner im Netz" etwas anderes als solche Mailserver meinst, müsstest du dich genauer ausdrücken; mir fällt da jedenfalls nichts anderes zu ein, egal wie ich es drehe und wende.

Es ist zudem auch schon allgemein eher unüblich, dass ein Server, egal ob SMTP oder sonstwas, sich bei einem Client authentifiziert (selbst, wenn's ein Server ist, "der dann Client spielt"). Im Sprachgebrauch läuft es normalerweise andersrum: Der Client ist der, der etwas will und sich ausweisen muss.

Bis hierhin habe ich den Eindruck, bei dir gingen die Begrifflichkeiten etwas verquer. Die falsche Zuordnung von Client- und Serverrolle bei der Authentifizierung, vielleicht auch das Missverständnis, was im jeweiligen Zusammenhang mit Mail- bzw. SMTP-Server gemeint ist.
Es ist in der Tat so, dass ein Mailserver aus Protokollsicht mal Server und mal Client ist. Genau aus diesem Grunde, um solche Verwirrung zu vermeiden, habe ich die Nutzung von SMTP eingangs auf die Empfängerrolle beschränkt, auf die Rolle als Ziel- oder als weiterleitendes System – denn das ist das Einzige, was für kayas Frage von Belang ist.

Dass du in dem Absatz SASL falsch eingeordnet hast, lassen wir jetzt mal beiseite (SASL ist nicht "noch einige Dinge", SASL ist nur eines dieser Dinge; SASL ist IMHO nicht einmal der Nennung per se wert, es handelt sich schlicht um die Authentifizierung).

Ich kann's auch noch ein fünftes, sechstes und siebtes Mal durchlesen, mitsamt deines hier nicht zitierten restlichen Beitrags – du hast das meiner Meinung nach nicht richtig dargestellt. Und es ist leider auch nicht besser, oder sagen wir mal: verständlicher geworden, du hast dich nur in noch mehr Details verstrickt, die für kaya noch nicht einmal von Interesse sind.