[LUGA] Mit freundlicher Unterstützung von:
Linux New Media AG

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [luga] Greylisting



On 2007-03-30 18:10:10 +0200, Andreas Haumer wrote:
> Peter J. Holzer schrieb:
> > On 2007-03-30 14:31:28 +0200, Michael Demelbauer wrote:
> >> Was hält man hier eigentlich von der Idee eines Greylistings, das alle
> >> Absenderadressen nicht checkt, die eine Antwort auf eine von innerhalb der
> >> Domain verschickte Mail sind, dh. wenn zB michael@wsr.ac.at an
> >> office@luga.at schickt, wird auch die andere Richtung office@luga.at an
> >> michael@wsr.ac.at automatisch whitegelistet (dh. die Mail geht dann schon
> >> beim ersten Mal durch)?
> >> Hätte so etwas schlimme Mißbrauchsmöglichkeiten? Würde es den
> >> Implementierungsaufwand lohnen?
[...]
> > Das größte Problem, das ich bei dem Ansatz sehe, ist, dass man nicht
> > weiß, woher die Antwort kommen wird, wenn man eine Mail an eine Adresse
> > schickt. Wenn Du eine Mail an <office@luga.at> schickst, kommt die
> > Antwort wahrscheinlich von <hjp-luga@hjp.at> oder <bernd@luga.at> o.ä.
> > Das kannst Du nicht im vorhinein erraten und whitelisten. Selbst wenn
> > die Antwort von <office@luga.at>, kommt kannst Du aus der Mail-Adresse
> > im Allgemeinen nicht erkennen, von welcher IP-Adresse sie kommen kann
> > (im Fall von luga.at wegen SPF schon), d.h., Du gibst damit die Bindung
> > zwischen IP-Adresse und Absenderdomain, die Greylisting erzwingt, auf.
> > Das ist insbesondere bei Viren/Würmern, die häufig Absenderadressen aus
> > Adressbüchern verwenden, ein Nachteil.
> > 
> Die Idee ist witzig, aber ich denke, der Key dürfte nicht die Mailadresse
> sondern sollte eher die Message-Id sein. Damit könnte man dann eine Art
> "Stateful-Inspection-Greylisting" machen:
>
> 1) Der Mailserver merkt sich die Message-Id's von allen abgehenden Mails
>    in einer internen Tabelle (mit einer bestimmten Ablaufzeit)
> 2) Bei ankommenden Mails wird der "In-Reply-To" Header (eventuell auch andere)
>    gecheckt, wobei es zwei Möglichkeiten gibt:
>    a) Message-Id steht in der internen Tabelle -> Mail geht sofort durch
>    b) Message-Id steht nicht in der internen Tabelle -> übliche Greylisting Rules usw.

Das hat den Nachteil, dass die Message-Id erst mit DATA übermittelt
wird, man Greylisting aber bei RCPT machen möchte. Der Sender muss also
die gesamte Message übertragen (außer Server und Client beherrschen
beide die CHUNKING Extension) nur um dann mitgeteilt zu bekommen, er
möge es später noch einmal probieren. Das will man normalerweise nicht.

Außerdem muss eine Antwort nicht unbedingt einen In-Reply-To Header
enthalten. Es kann sein, jemand nicht auf Reply klickt, sondern eine
neue Mail schreibt, die aber eigentlich eine Antwort ist (ja, ich mag
das auch nicht). Oder eine Mail kann eine Antwort auf eine Nicht-Mail
(z.B. einen Telefonanruf) sein.  (Letzteres ist vermutlich die
Situation, in der Greylisting am lästigsten ist: Man ruft jemanden an,
um schnell eine bestimmte Information zu bekommen, derjenige schickt das
per Mail - und dann wartet man darauf, dass die Mail durchs Greylisting
durchkommt).

Ich könnte mir aber vorstellen, dass man das Schema im Spamassassin
verwenden könnte: Mails, die eine Reply auf eine selbst verschickte
Message-Id sind, bekommen einen großen negativen Score.

	hp

-- 
   _  | Peter J. Holzer    | Ich sehe nun ein, dass Computer wenig
|_|_) | Sysadmin WSR       | geeignet sind, um sich was zu merken.
| |   | hjp@hjp.at         |
__/   | http://www.hjp.at/ |	-- Holger Lembke in dan-am

Attachment: signature.asc
Description: Digital signature



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010