Re: "Offenes" SMTP-Relay mal anders

Andreas Beck <becka-news-nospam-2006-09@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Ansgar -59cobalt- Wiechers wrote:
Andreas Beck <becka-news-nospam-2006-09@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Weil das mögliche Mails unterdrückt. ggf. sogar ohne, daß man das an
der Reaktion sieht. Wenn ein Spammer auf diese Weise Mails
einliefert (per POST an vermutet kaputtes PHP-Script), müßte er bei
konsequenter Weiterverfolgung obigen Gedankens darauf pochen können,
daß das Zeug ankommt.

Das käme AFAICS auf die konkreten Umstände an. Mailskripte sind ja
zunächst mal regelmäßig als Backend für Webformulare gedacht, nicht
für die direkte Benutzung. Das unterscheidet sie schon mal von
SMTP-Servern.

SMTP-Server, die $Irgendwo laufen, sind nicht für die öffentliche
Benutzung gedacht.

Bullshit. Ein öffentlich erreichbarer, öffentlich nutzbarer Server in
einem öffentlichen Netz ist selbstverständlich offensichtlich für die
öffentliche Benutzung gedacht. Oder darf man IYHO auch nur auf HTTP-
Server zugreifen, die der Provider einem benennt? Das wäre dieselbe
alberne Argumentation.

Nichtmal SMTP-Server, die bei $Provider laufen sind in der Regel für
öffentliche Benutzung gedacht. Inzwischen setzen sogar die meisten
Provider _wirksame_ Techniken ein, um das zu verhindern.

*Damit* sind sie dann nicht mehr für die öffentliche Benutzung gedacht.
Vorher sind sie es.

Dann hängt es davon ab, was sie annehmen, auf welche Art das erfolgt,
und was sie zurückmelden. Ein Mailskript, das ohne Rückmeldung Mail
für beliebige Adressen annimmt, könnte IMHO in der Tat ähnlich wie
ein SMTP-Server zu bewerten sein. Mal ganz davon abgesehen, dass
Leute, die sowas auf ihren Servern laufen haben, dringend
LART-bedürftig sind.

Und nu findet jemand den Fehler und fixt ihn.

Was für einen Fehler?

Ohne in der Rückmeldung drauf einzugehen. Und jetzt ist er der
Nachrichtenunterdrückung schuldig? Das bezweifele ich.

Wenn Nachrichten ohne Rückmeldung unterdrückt werden? Warum nicht?

Ein gängiger Fix wäre z.B. die Zieladresse einfach nochmal zu
überschreiben, auch wenn die per POST/GET-Variable schon reinkommt.

Wer macht denn sowas kaputtes? Das ist ja völlig krank.

Verletzt man damit nun das Briefgeheimnis? Ach nein, geht ja nicht,
weil Mail=Postkarte. Aber zum Ziel kommt die Mail auch nicht. Man kann
selbst beim Empfänger nicht mehr feststellen, wohin die gehen sollte
...

Andreas, es geht und ging hier nie um das Briefgeheimnis, sondern um
Nachrichtenunterdrückung gemäß § 206 (2) StGB.

Ömm - also ich kenne diverse solcher Kästen, bei denen ich das
niemals annehmen würde. Einige dienen in Privathäusern als Bar oder
Hundehütte, ein weiterer befindet sich in einem alten Gasometer als
Attraktion unter Wasser, andere liegen in Seen.

Sind sie öffentlich aufgestellt?

Definiere öffentlich. Einige davon sind in etwa so öffentlich, wie ein
Server, der irgendwo rumsteht und auf Port 25 Verbindungen annimmt.

Also "theoretisch für jedermann erreichbar".

Sind sie praktisch für jedermann erreichbar? Wie in "steht auf dem
Marktplatz". Ich sehe nicht, warum ich bei einem Briefkasten, der auf
einem öffentlichen Platz aufgestellt ist, etwas anderes annehmen sollte,
als dass es tatsächlich ein Briefkasten ist. Und dasselbe gilt halt
nunmal auch für SMTP-Server in öffentlichen Netzen, die meine Mail
*annehmen*.

Wenn nein: warum hältst Du diese Beispiele für relevant? Oder anders
gefragt: würdest Du bei einem öffentlich aufgestellten Kasten, der
genau wie ein Briefkasten aussieht, tatsächlich unterstellen, dass
das kein Briefkasten ist? Echt?

Nein. Denn es ist Verkehrssitte, daß diese Dinger, die in einer
bestimmten Optik an der Straße stehen, Briefkästen sind, und mit den
entsprechenden Beförderungsbedingungen verknüpft mir ermöglichen, den
Beförderungsvertrag durch schlüssiges Handeln (Brief reinwerfen)
einzugehen.

Genau das sage ich ja.

[...]
Und im Fall der EMail ist Verkehrssitte, daß man seine Mails entweder
Richtung MX des Empfängers schiebt oder jemandem übergibt, der Kraft
eines Vertrages für die Weiterleitung sorgt. (Smarthost des Providers)

Die Nutzung von Diensten, die zwar öffentlich _erreichbar_, aber eben
nicht offensichtlich öffentlich _angeboten_ sind, könnte viel eher
eine Erschleichung von Leistungen begründen als eine
Beförderungspflicht.

Das sehe ich anders. Ein Dienst, der öffentlich erreichbar UND
öffentlich nutzbar ist, wird IMnsHO auch öffentlich angeboten.

Schließlich kann man aus dem puren Vorhandensein eines SMTP-Servers
auch nicht auf die Vertragsbedingungen schließen.

*seufz*

Zum wiederholten Mal: aus dem Vorhandensein nicht, aus dem Annehmen von
Mail zur Beförderung hingegen schon.

Sonst könnte man ja mal versuchen, Spammern mit einem tatsächlich
funktionierenden Relay 5 EUR/Mail abzuknöpfen ... wär doch mal was.

Wie soll das IYHO rechtlich funktionieren? Dazu müsstest Du dem Absender
ein Angebot machen, dass dieser dann annehmen müsste. Das ist eine
andere rechtliche Situation. Ein offenes Relay stellt kein Angebot dar,
sondern eine Aufforderung zur Angebotsabgabe (ähnlich der Warenauslage
in einem Geschäft). Das Einliefern einer Mail durch den Absender ist das
eigentliche Angebot, das der Server durch Annehmen der Mail akzeptiert
bzw. durch Rejecten der Mail ablehnt.

Weil irgendwo ein Dienst auf Port 25 mit
220 Affen schreiben vielleicht Shakespeares Werke
antwortet?

Nein, sondern weil dieser Dienst auf dem Default-Port für SMTP auf
genau die Art antwortet, wie es für SMTP spezifiziert ist.

Das ist IMHO wumpe, weil es nicht verkehrsüblich ist, seine Mail
einfach an irgendeinen beliebigen SMTP-Server, der einem gerade vor
die Füße springt zu übergeben.

Das sehe ich wie gesagt grundlegend anders.

Zumindest wir Techniker sollten mal die Kirche im Dorf lassen und
das konkludente Handeln auf vernünftige Varianten beschränken.

Was genau ist IYHO daran unvernünftig, wenn ich als Techniker von
etwas, das sich nach außen wie ein SMTP-Server verhält, erwarte, dass
es sich auch ansonsten wie ein SMTP-Server verhält?

Die Tatsache, daß der Server Dir keinerlei Versprechen gemacht hat,
was er mit der Mail tun wird.

Bitte? Aber selbstverständlich hat mir der Server mit einem "250 OK"
nach dem DATA-Kommando ein Versprechen gemacht, was er mit der Mail tun
wird.

Vielleicht bildet er ja ein Gateway in ein Netz mit parallelem
Namensraum? Die wird dann sogar korrekt zugestellt. Nur nicht an den,
den Du gedacht hast.

Darum geht es hier nicht.

Man muss und soll als SMTP-Server keine Mails annehmen, die man nicht
relayen will.

*Schulterzuck* Man muß keine Mails an Server übergeben, für die man
nicht entweder per Vertrag zugesichert hat, daß sie diese relayen oder
den MX des Empfängers darstellen.

Stimmt, man muss nicht. Aber man darf. Mails, die man zur Beförderung
angenommen hat, darf man hingegen *nicht* einfach wegschmeissen. Feiner
Unterschied.

Abartige Interpretationen müssen wir den Juristen bitte nicht auch
noch vorschlagen.

Abartig ist hächstens, SMTP pervertieren zu wollen. Erklär' mir doch
mal bitte, wie Du (remote) Mailprobleme noch halbwegs sinnvoll
untersuchen willst, wenn Mailserver anfangen, einfach jede
eingelieferte Mail mit 250 zu quittieren.

Ich debugge keine Mailprobleme auf Servern, die weder Upstream-Relay
sind, noch der Ziel-MX.

Selbst wenn mal weitere in der Kette sind, komme ich an die in der
Regel sowieso nicht ran, weil mein Host i.a. dann nicht zum Relayen
zugelassen ist. Es ist also völlig sinnlos.

Du hattest noch nie User, die einen Buchstabendreher oder sonstigen
Fipptehler beispielsweise im Localpart einer Mailadresse hatten und dann
von Dir wissen wollten, warum ihre Mail nicht ankommt? Ich schon. Und
ich hätte gerne weiterhin, dass in solchen Fällen ein NDR zurückkommt
anstatt dass die Mail einfach im Nirvana verschwindet.

Und was Deine Behauptung angeht, es sei "gegen den Standard, Mails
woanders als bei einem zuständigen MX oder einem Smarthost einzuwerfen":
RFC821 teilt Deine Ansicht nicht.
| 2. THE SMTP MODEL
| The SMTP provides mechanisms for the transmission of mail; directly
| from the sending user's host to the receiving user's host when the
| two host are connected to the same transport service, or via one or
| more relay SMTP-servers when the source and destination hosts are
| not connected to the same transport service.

Wo genau siehst Du da einen Widerspruch? SMTP hat also Mechanismen zum
Relayen. Ach.

Dort steht nichts davon, dass nur der Empfänger-MX oder ein Smarthost
Relay sein dürfen. Ergo ist Deine Behauptung nicht durch den Standard
gedeckt.

Das sagt genau gar nichts darüber aus, wie diese Relaykette aufgebaut
wird.

Exakt. Du hingegen behauptetest, der Aufbau der Relaykette sei
vorgeschrieben. Was nicht der Fall ist.

cu
59cobalt
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html
.

Relevant Pages

  • Re: Exchange 2003 - externe E-Mails verschwinden...
    ... Outgoing ist z.Zt eh alles erlaubt, reingehend nur SMTP ... "zu Fuß" kann ich eine Mail loswerden (an einem anderen Exchange 2003 ... >> Aber dennoch bleibt das Problem, dass die Verbindung der SMTP Server ... > Steht dazwischen denn eventuell irgendeine Firewall die als SMTP Proxy ...
    (microsoft.public.de.german.exchange2000.general)
  • Re: Exchange2000, Sperren des Mail-Versands für bestimmte benutzer
    ... Wie kann ich pro benutzer angeben wer welchen SMTP verwendend darf? ... > Wir verwenden bei eine Firma einen Exchange2000 Server mit ca. 100 ... > internes Mail funktioniert. ...
    (microsoft.public.de.exchange)
  • Re: E-Mail mit leerem Betreff
    ... Streng genommen sind die Zeilen im "DATA"-Teil nur Datensosse für den SMTP ... daß diese EMail unerwünscht ist. ... Also wenn der empfangende Server ein 5xx ausgibt, ... SMTP-Client soll sich dann gefälligst darum kümmern, was er mit der Mail ...
    (microsoft.public.de.german.exchange2000.general)
  • Re: "Offenes" SMTP-Relay mal anders
    ... Ein "Hier ist kein SMTP" im Banner ist nicht spezifiziert, ... auch beim OE den Transfer protokollieren lassen. ... Zumal immer noch nicht ganz klar ist, welche Daten der *Betreiber* nun ... eine Willenserklärung zur Beförderung der Mail ableiten lassen. ...
    (de.comp.security.misc)
  • MX-Record einrichten
    ... Wir setzen den Exchange2003 Standard mit SP2 ein. ... Als Backup setzen wir den Server von Schlund ein. ... Im DNS Server habe ich folgendes gemacht: ... Betreff: Mail delivery failed: returning message to sender ...
    (microsoft.public.de.exchange)