3
SMTP-Dialog: MAIL FROM leere Zeichenkette
Normalerweise sieht ein Teil des SMTP-Dialogs so aus:
MAIL FROM:<absender@beispiel1.tld>
RCPT TO:<empfänger@beispiel2.tld>
Bei automatischen Abwesenheitsbenachrichtigungen sehen diese Zeile etwas anders aus:
MAIL FROM:<>
RCPT TO:<empfänger@beispiel2.tld>
Also, "MAIL FROM" übergibt eine leere Zeichenkette.
Bisher machte dies nie Probleme, aber neuerdings werden solche E-Mails von einem (einzigen) SMTP-Server nicht akzeptiert. Der Provider meint, das sei eine Sicherheitsmaßnahme gegen Spam und er denke nicht daran, etwas daran zu ändern.
Meine Fragen:
In wie weit hat der Provider Recht mit seiner Behauptung? Könnte mich jemand darüber aufklären?
In Voraus herzlichen Dank!
temuco
MAIL FROM:<absender@beispiel1.tld>
RCPT TO:<empfänger@beispiel2.tld>
Bei automatischen Abwesenheitsbenachrichtigungen sehen diese Zeile etwas anders aus:
MAIL FROM:<>
RCPT TO:<empfänger@beispiel2.tld>
Also, "MAIL FROM" übergibt eine leere Zeichenkette.
Bisher machte dies nie Probleme, aber neuerdings werden solche E-Mails von einem (einzigen) SMTP-Server nicht akzeptiert. Der Provider meint, das sei eine Sicherheitsmaßnahme gegen Spam und er denke nicht daran, etwas daran zu ändern.
Meine Fragen:
- Ist es erlaubt, eine leere Zeichenkette zu übergeben? Ich bin bisher immer davon ausgegangen, dass dies OK und Teil der Spezifikation des SMTP-Dialogs ist. Schließlich will man gerade bei automatisch generierten E-Mails (in diesem Fall Abwesenheitsbenachrichtigungen) keine Endlosschleife hervorrufen.
- Wie kann das ein Sicherheitsrisiko sein, wenn man nur und ausschließlich nach erfolgreicher Anmeldung am SMTP-Server die Einlieferung von E-Mails möglich ist?
In wie weit hat der Provider Recht mit seiner Behauptung? Könnte mich jemand darüber aufklären?
In Voraus herzlichen Dank!
temuco
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 237838
Url: https://administrator.de/contentid/237838
Ausgedruckt am: 24.11.2024 um 04:11 Uhr
3 Kommentare
Neuester Kommentar
Moin
Nun irgendwie muss der ja auch eine Antwortmail machen können.
Und Anonym werden E-Mail eh bei vielen abgelehnt.
Es ist ja kein Problem bei Auto-Scripten anzugeben welchen Absender diese nehmen sollen.
Bei uns würde die Mail auch abgelehnt werden.
Nun irgendwie muss der ja auch eine Antwortmail machen können.
Und Anonym werden E-Mail eh bei vielen abgelehnt.
Es ist ja kein Problem bei Auto-Scripten anzugeben welchen Absender diese nehmen sollen.
Bei uns würde die Mail auch abgelehnt werden.
Ich bin bisher immer davon ausgegangen, dass dafür die Infos im Header vollkommen ausreichend sind. Dieser ist nämlich vollständig. Hier handelt es sich um den SMTP-Dialog zwischen Client und Server und nicht um die E-Mail selbst.
Ich habe versucht, Infos darüber zu finden, allerdings finde ich bisher nichts über die Übergabe einer leeren Zeichenkette bei "MAIL FROM" während des SMTP-Dialogs.
Gleich noch eine Frage:
Was heißt hier anonym? Im E-Mail-Header ist die ganze Info enthalten – so gesehen ist die E-Mail selbst nicht anonym. Nur der Client teilt dem Server während des SMTP-Dialogs keine Absenderadresse mit. Aber das ist m. E. auch gewollt und richtig, denn bei einem Zustellfehler würde der Server eine Mitteilung an den Sender zurückschicken und dieser würde wiederum eine erneute Abwesenheitsbenachrichtigung schicken usw.
Fragen über Fragen...
Herzlichen Dank!
temuco
Ich habe versucht, Infos darüber zu finden, allerdings finde ich bisher nichts über die Übergabe einer leeren Zeichenkette bei "MAIL FROM" während des SMTP-Dialogs.
Gleich noch eine Frage:
Was heißt hier anonym? Im E-Mail-Header ist die ganze Info enthalten – so gesehen ist die E-Mail selbst nicht anonym. Nur der Client teilt dem Server während des SMTP-Dialogs keine Absenderadresse mit. Aber das ist m. E. auch gewollt und richtig, denn bei einem Zustellfehler würde der Server eine Mitteilung an den Sender zurückschicken und dieser würde wiederum eine erneute Abwesenheitsbenachrichtigung schicken usw.
Fragen über Fragen...
Herzlichen Dank!
temuco
Nun habe ich nach langem Suchen doch die RFC gefunden, die das Beschreibt. In meinem Fall ist die leere Zeichenkette erlaubt und im Standard vorgesehen. Daher handelt es sich hierbei um ein Fehlverhalten seitens des Providers:
RFC 5321, Oktober 2008
3.6.3. Message Submission Servers as Relays
http://www.ietf.org/rfc/rfc5321.txt
3.6.3. Message Submission Servers as Relays
Many mail-sending clients exist, especially in conjunction with
facilities that receive mail via POP3 or IMAP, that have limited
capability to support some of the requirements of this specification,
such as the ability to queue messages for subsequent delivery
attempts. For these clients, it is common practice to make private
arrangements to send all messages to a single server for processing
and subsequent distribution. SMTP, as specified here, is not ideally
suited for this role. A standardized mail submission protocol has
been developed that is gradually superseding practices based on SMTP
(see RFC 4409 [18]). In any event, because these arrangements are
private and fall outside the scope of this specification, they are
not described here.
It is important to note that MX records can point to SMTP servers
that act as gateways into other environments, not just SMTP relays
and final delivery systems; see Sections 3.7 and 5.
If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-
path). Formats specified for non-delivery reports by other standards
(see, for example, RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if
possible.
This notification message must be from the SMTP server at the relay
host or the host that first determines that delivery cannot be
accomplished. Of course, SMTP servers MUST NOT send notification
messages about problems transporting notification messages. One way
to prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a message
is transmitted, the reverse-path MUST be set to null (see
Section 4.5.5 for additional discussion). A MAIL command with a null
reverse-path appears as follows:
MAIL FROM:<>
As discussed in Section 6.4, a relay SMTP has no need to inspect or
act upon the header section or body of the message data and MUST NOT
do so except to add its own "Received:" header field (Section 4.4)
and, optionally, to attempt to detect looping in the mail system (see
Section 6.3). Of course, this prohibition also applies to any
modifications of these header fields or text (see also Section 7.9).
RFC 5321, Oktober 2008
3.6.3. Message Submission Servers as Relays
http://www.ietf.org/rfc/rfc5321.txt
3.6.3. Message Submission Servers as Relays
Many mail-sending clients exist, especially in conjunction with
facilities that receive mail via POP3 or IMAP, that have limited
capability to support some of the requirements of this specification,
such as the ability to queue messages for subsequent delivery
attempts. For these clients, it is common practice to make private
arrangements to send all messages to a single server for processing
and subsequent distribution. SMTP, as specified here, is not ideally
suited for this role. A standardized mail submission protocol has
been developed that is gradually superseding practices based on SMTP
(see RFC 4409 [18]). In any event, because these arrangements are
private and fall outside the scope of this specification, they are
not described here.
It is important to note that MX records can point to SMTP servers
that act as gateways into other environments, not just SMTP relays
and final delivery systems; see Sections 3.7 and 5.
If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-
path). Formats specified for non-delivery reports by other standards
(see, for example, RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if
possible.
This notification message must be from the SMTP server at the relay
host or the host that first determines that delivery cannot be
accomplished. Of course, SMTP servers MUST NOT send notification
messages about problems transporting notification messages. One way
to prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a message
is transmitted, the reverse-path MUST be set to null (see
Section 4.5.5 for additional discussion). A MAIL command with a null
reverse-path appears as follows:
MAIL FROM:<>
As discussed in Section 6.4, a relay SMTP has no need to inspect or
act upon the header section or body of the message data and MUST NOT
do so except to add its own "Received:" header field (Section 4.4)
and, optionally, to attempt to detect looping in the mail system (see
Section 6.3). Of course, this prohibition also applies to any
modifications of these header fields or text (see also Section 7.9).
