Ralf Mueller <[EMAIL PROTECTED]> wrote on 09.05.04:
> Michael Heydekamp <[EMAIL PROTECTED]> schrieb am 09.05.04
> zum Thema: Re: E-UUZ und -graberec tut's nicht mehr ...
>> Da ich bei der Gelegenheit auch noch "X-Original-To:" (ist wohl ein
>> Postfix-spezischer Header) einbauen will und keinen Bock auf
> BTW, X-Original-To setzt auch UKA_PPP in Zusammmenhang mit dem
> redirect-Hack.
Ach ja, stimmt... Hmm, Vorschlag?
Vielleicht einfach, den redirect-Hack nicht zu verwenden, der sowieso
keine gute Idee ist.
Auch der wird durch das Add-On BTW obsolet.
>> �berm��ige Pr�fungen habe, werde ich wohl "Envelope-To:", "X-
>> Original-To:" und "Original-Recipient:" gleichbehandeln, der letzte
>> gewinnt dann halt ("Delivered-To:" durchl�uft eh eine
>> Sonderbehandlung und h�tte nach wie vor niedrigere Priorit�t).
> Die Frage dahinter lautet wohl, warum k�nnten mehrere davon
> auftauchen und was sollte das aussagen?
Keine Ahnung, aber ich habe lieber ein kontrolliertes bzw. wenigstens
klar definiertes Verhalten als da� ich es dem Zufall �berlasse.
Wobei "der letzte gewinnt" letztlich nat�rlich zu einem zuf�lligen -
n�mlich von der Reihenfolge abh�ngigen - Ergebnis f�hren kann.
>>> Aha, danke. Ich hoffe es l��t sich dann auch nicht durch ein:
>>> 'MailMonitor for SMTP' in einer 'Received: ...'-Zeile aus der Ruhe
>>> bringen, da es 'SMTP' in diesem Beispiel als *Nicht-Adresse*
>>> erkennt und daher ignoriert.
>> In dem von Dir angesprochenen Fall ist es ohnehin kein Problem, weil
>> "for SMTP" in einem Kommentar steht, der �berlesen wird.
>> Auf die G�ltigkeit einer Adresse wird an der Stelle noch nicht
>> gepr�ft, sp�ter aber schon und eine ung�ltige Adresse ggf. entsorgt.
> Wird in diesem Falle, also wenn eine vermeintliche Adressse verworfen
> wird, der ganze Vorgang abgebrochen, oder wird dann mit der Suche nach
> einer echten Adresse in dem n�chsten Received-Header fortgefahren?
Ausprobieren. ;)
In fr�heren Versionen w�re, sobald die Variable *irgendeinen* Inhalt
hat, nicht mehr weiter nach einer Adresse in den folgenden Headern
gesucht worden. Wurde sp�ter festgestellt, da� es gar keine Adresse
ist, wurde die Variable verworfen (also eigentlich ein Bug).
Jetzt (auch bereits in der Dir vorliegenden Fassung) pr�fe ich
zumindest, ob der String nach dem "for " ein "@" enth�lt, und wenn das
nicht der Fall ist, verwerfe ich den Inhalt sofort. Das f�hrt dann
automatisch dazu, da� in den folgenden Headern weiter nach einer Adresse
gesucht w�rde.
Enth�lt der String ein "@", wird er derselben Behandlung unterzogen wie
auch alle �brigen Header, die Adressen enthalten k�nnen.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
