Qmail akzeptiert leere From und To Felder...

triumvirat

Registered User
Hallo zusammen,

Hab da mal ne Frage:

Wenn ich eine Telnet Verbindung von localhost aufbaue auf den Mailserver:
Code:
server# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 server.de ESMTP

Soweit sogut, dann....
Code:
helo test.de
250 server.de

und....
Code:
mail from:<>
250 ok

Bekomme ich einen Code 250 zurück....
HÄ? Wieso akzeptiert der Qmail Server das man keine E-Mailadresse eingeben darf ? Und wie stelle ich das ab ? Die gleiche Bestätigung "250" erhalte ich auch wenn ich das rcpt to:<> leer lasse. Die Mail wird in die Queue eingestellt, kann aber natürlich nie zugestellt werden und frisst meine Ressourcen.

Vielleicht bekomme ich hier den richtigen denkanstoß......hat ja schon öfter geklappt.

Vorab Dankeschön

LG
Ekki
 
Bekomme ich einen Code 250 zurück....
HÄ? Wieso akzeptiert der Qmail Server das man keine E-Mailadresse eingeben darf ?
Siehe RFC 2821, z. B. Abschnitt 6.1.

Und wie stelle ich das ab ?
Gar nicht, weil es von RFC 2821 gefordert wird.

Die gleiche Bestätigung "250" erhalte ich auch wenn ich das rcpt to:<> leer lasse.
Das wiederum ist dämlich und sollte eigentlich nicht möglich sein. Aber war es nicht so, dass qmail erstmal jede Mail annimmt und erst danach überprüft, ob sie überhaupt zugestellt werden kann?
 
Siehe RFC 2821, z. B. Abschnitt 6.1.
Ich lese dort:
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
message in response to DATA), it is accepting responsibility for
delivering or relaying the message.

Was bedeutet, dass man die Mail zustellen muss, wenn man auf DATA mit 250 geantwortet hat. (Annahme der Mail für die Zustellung) Dass der Sender explizit leer sein darf, habe ich da nicht gelesen.

Man darf aber den Dialog vorher mit einem Fehler abbrechen. (z.B. wenn eine From-Adresse mit nicht-existenter Domain angegeben wurde.)

Bei Postfix: reject_unknown_sender_domain, reject_non_fqdn_sender

Für Qmail sollte es doch entsprechungen geben, oder nicht?

Edit: Ok, scheint doch leer sein zu dürfen:
4.1.1.2 said:
[...] In some types of
reporting messages for which a reply is likely to cause a mail loop
(for example, mail delivery and nondelivery notifications), the
reverse-path may be null (see section 3.7).
In dem Fall muss ich mich der Aussage von Roger Wilco anschließen.
 
Last edited by a moderator:
Dass der Sender explizit leer sein darf, habe ich da nicht gelesen.
Bei Bounce-Meldungen muss er sogar leer sein.
RFC 2821 said:
6.1 Reliable Delivery and Replies by Email
[...]
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse path in the
envelope.

Darüber hinaus aus der ABNF-Notation für MAIL FROM (4.1.1.2):
[...] In some types of
reporting messages for which a reply is likely to cause a mail loop
(for example, mail delivery and nondelivery notifications), the
reverse-path may be null (see section 3.7).
[...]
Syntax:

"MAIL FROM:" ("<>" / Reverse-Path)
[SP Mail-parameters] CRLF

Man darf aber den Dialog vorher mit einem Fehler abbrechen. (z.B. wenn eine From-Adresse mit nicht-existenter Domain angegeben wurde.)
Ja, aber nicht wenn sie leer ist.
 
Darüber hinaus aus der ABNF-Notation für MAIL FROM (4.1.1.2):
Japp. Habs dann auch gefunden. Musste das Ding dann doch gleich mal intensiver studieren.
Danke für den Hinweis auf die RFC.
 
Last edited by a moderator:
Hallo zusammen,

also das macht Sinn, und ich verstehe das auch, allerdings wundert mich die die Möglichkeit, dass man auch im rcpt to Kommando <> schreiben darf und einen Code 250 zurück bekommt. Sicherlich sind die Restriktivierungen nicht so hoch, wenn man von Localhost aus zugreift, allerdings möchte ich gerne, das man auch als Webseitenbesitzer mit PHP nicht einfach mail(.....) schreibt und die Mail wir auch noch zugestellt. Egal welcher Absender und welcher Empfänger angegeben ist.

Es scheint mir nämlich so, das eines der Mail Formulare nicht vernünftig aufgesetzt ist und deswegen mein Server als Spam Relay mißbraucht werden kann. Ich würde gerne einen Hinweis darauf erhalten, das man eben auch nicht von localhost aus, einfach ohne Authentifizierung Mails von und an wen auch immer schreiben kann. Dann ist mir die verwendung von eigenen WebFormularen nämlich egal.

Vielen Dank
Ekki
 
wundert mich die die Möglichkeit, dass man auch im rcpt to Kommando <> schreiben darf
Das ist für den Fall, dass eine Mail mit <> im Mail-From bounced - also obligatorisch.

Es scheint mir nämlich so, das eines der Mail Formulare nicht vernünftig aufgesetzt ist und deswegen mein Server als Spam Relay mißbraucht werden kann.
Diese Exploits benutzen die Tatsache, dass das Script beliebige Header einschleusen lässt.
Du willst dich über den Unterschied zwischen Header und Envelope informieren.
 
Back
Top