Re: Spam auf der Liste

["Guenther H. Merkens" <merkens@datenschutzserver.de>]

On Sun, 6 May 2001 09:41:30 +0200, Kristian Koehntopp wrote:

>On Sat, May 05, 2001 at 10:36:53PM +0200, Neko (Simone Demmel) wrote:
>> > behauptet, alle bei dem MTA abgelieferten Nachrichten würden den
>> > angegebenen Empfänger erreichen, dann ist ihm irgendwas nicht so
>> > ganz klar geworden, oder er will es nicht wahrhaben, was er denn
>> 
>> Du weisst, dass Du gerade Buchstaben und Gemeintes verdrehst. Kristian
>> hat nie behauptet, dass derjenige das tatsaechlich bei ihm auch
>> empfaengt.
>
>Kris sagte, dass der Envelope-To bestimmt, bei wem die Mail
>ankommt und der Header-To, fuer wen sie intendiert ist.

Eine Lektüre der einschlägigen technischen Spezifikationen (RFCs)
wird Kris eines besseren belehren, obwohl der Widerspruch schon
in seinem Satz offenbar wird: Der aus dem "RCPT TO"-Kommando
resultierende Envelope-To (die Information über den Empfänger für
den MTA) wird von der von Kris favorisierten Software und den
Filtermethoden aufgrund 'formaler' Kriterien im Nachrichteninhalt
ignoriert und die Nachricht wird nicht an den genannten Empfänger
befördert ("The first or only argument to this command includes a
forward-path [...] identifying one recipient. siehe RFC2821).

Dass "der Envelope-To bestimmt, bei wem die Mail ankommt", ist
also gerade bei Kristians favorisierter Implementation unrichtig,
weil die Beförderung von weiteren Bedingungen abhängig gemacht
wird.

>Kris
>sagte weiter, dass qmail und ezmlm keine Mail akzeptieren, die
>nicht fuer die Liste intendiert sind, also weder im Header-To
>noch im Header-Cc die Adresse der Liste stehen haben.

Ich glaube, dass Kristian sich auf ein schmales Brett begeben
hat, um die inhaltlich begründete Nichtauslieferung von
Nachrichten technisch zu rechtfertigen:

   "Server SMTP systems SHOULD NOT reject messages based on
    perceived defects in the RFC 822 or MIME [12] message
    header or message body." (FRC2821)

Welchen Fehlercode gibt der Mailer eigentlich zurück?

>Und Kris ist der festen Meinung und Ueberzeugung, dass dies ein
>Feature [tm] ist.

Derartige von Kristian in seinem Text konstruierte Vorwände sind
nicht erforderlich, wenn man in deutscher Sprache eine Policy
formuliert, anstatt 200 Zeilen Programmcode hier zu posten.

Die 'Features' einer Software können bei der Rechtfertigung einer
Praxis hinter sachlichen Argumenten zurücktreten. Nach Abschluss
der Diskussion wird technisches Personal mit einer getreuen
Implementation der beschlossenen Policy beauftragt.

Einen Vorschlag für eine Formulierung habe ich bereits gepostet
und würde die Bedrängung Kristians in einer zweifellos misslichen
Situation in diesem Teilthread gerne hiermit beenden.

Beste Grüsse,

-gm