[linux] Re: met enige ergernis

[Kees Theunissen]

On Sat, 24 Feb 2007, Rob Sterenborg wrote:

>> IK beweer niet dat deze mogelijkheid niet gebruikt moet worden
>> om spammers buiten de deur te houden.
>
>Vlgs RFC zou helo/ehlo de hostname (FQDN) van je server moeten geven.

Volgens RFC2822 moet een (smtp-server die een verbinding opent als)
smtp-client zijn _eigen_ FQDN opgeven. Als hij zijn eigen FQDN
niet kent dan mag hij zijn ip-nummer geven tussen vierkante haken.
En zelfs dat zal niet altijd mogelijk zijn voor een computer op
een NATted netwerk. De RFC stelt dan ook dat een foute hostname
in de helo/ehlo begroeting geen reden mag zijn om de connectie
te weigeren. ISP's zullen voor hun eigen klanten (herkenbaar aan
het ip-nummer van de remote host) zeker niet moeilijk doen
over een foute naam.

Maar het feit dat je een connectie niet mag weigeren puur vanwege een
foute naam, wil zeker niet zeggen dat je elke verbinding maar moet
accepteren. Je mag een verbinding weigeren vanwege 'local policies'.
In de ehlo/helo fase zou dat dan kunnen als:
-- een externe client mijn eigen host name gebruikt,
   (Reden: client probeert zijn eigen identiteit te verbergen,
   waarschijnlijk om spam filters te misleiden. Het is in ieder
   geval malafide gedrag.)
-- een externe client mijn eigen ip-nummer (al dan niet tussen
   vierkante haken) gebruikt als host name,
   (Reden: zie hierboven.)
-- een externe client een host name gebruikt die bij een lookup
   niet resolved tot het ip-nummer waarmee de verbinding is
   gemaakt,
   (Reden: mogelijk probeert de client zijn eigen identiteit te
   verbergen, anders is het een slecht beheerd/geconfigureerd
   systeem en daar hoef ik ook geen mail van omdat de kans te groot
   is dat ik daar later geen bounce messages kwijt kan mocht dat
   nodig zijn.)
-- een reverse lookup van het ip-nummer faalt,
   (Reden: een slecht beheerd/geconfigureerd systeem en daar hoef
   ik nog steeds geen mail van.)
-- een reverse lookup van het ip-nummer een host name geeft welke
   bij een forward lookup resolved tot een _ander_ ip-nummer.
   (Reden: alweer een bewuste poging tot identitieitsfraude, of op
   zijn minst weer een slecht beheerd/geconfigureerd systeem.)

Dit zijn allemaal 'local policies' die in de praktijk gebruikt
worden. Als particuliere eindgebruiker zal je vaak geen controle
hebben over de (reverse) DNS van je systeem. En dat kan je dwingen
tot het gebruik van de mailserver van je ISP voor uitgaande mail.

En als dan alles in orde is -je gebruikt de goede host name,
DNS lookups zijn ok, reverse lookups idem, je staat niet op een
blacklist- zelfs dan loop je nog het risico dat je soms wordt
geblokkeerd als je host name iets is als:
181-30.bbned.dsl.internl.net [82.215.30.181]
Ik heb spamfilters gezien van organisties die absoluut geen
prijs stellen op rechtstreekse verbindingen met particuliere
eindgebruikers (want dat zijn waarschijnlijk toch spam zombies).
De bovenstaande host name zou daar worden beblokkeerd alleen al
vanwege de 'dsl' naam (adsl, dyn, dhcp zouden ook raak geweest
zijn) en ook vanwege de twee bytes (30, 181) van het ip-nummer die
in de host name terug komen (decimaal of hexadecimaal weergegeven).

Al die 'local policies' zijn niet in strijd met de RFC's. Of je
er blij mee moet zijn is iets anders. Maar in een tijd dat het
normale email volume meer dan tienvoudig overtroffen wordt in
de vorm van SPAM verzonden door de georganiseerde misdaad, kan
je op zijn minst begrip hebben voor zulke policies.

De bruikbaarheid van email als _betrouwbaar_ communicatiemiddel
neemt helaas zeker niet toe door al deze filters.

>Vaak wordt er iets als localhost, een IP adres, jouw eigen hostname of
>een niet bestaande hostname opgegeven. Je kan daar op filteren maar het
>zal hoogstwaarschijnlijk ook false positives op geven. Niet echt een
>excuus om het niet te doen, maar dan zal je wel je poot stijf moeten
>zien te houden wanneer het management een email niet krijgt omdat de
>"tegenpartij" zijn mailserver verkeerd heeft geconfigureerd...

Je kan heel ver gaan in het blokkeren, maar je zult altijd een balans
moeten zoeken tussen mogelijk spam doorlaten en false positives
riskeren.
Overigens, als een externe partij jouw host name of jouw ip-nummer
gebruikt bij de ehlo/helo begroeting dan is dat echt geen verkeerde
configuratie maar een regelrechte poging tot identiteitsfraude.
Het risico op false positives is niet groot in dat geval.

En naar aanleiding van je opmerking over je poot stijf houden als
het management een mailtje mis loopt: onderstaande URL wijst naar
een goed verhaal over spam fighting dat is gericht op managers.

http://www.cio.com/technology/infrastructure/security/spam/
                  five_things_about_fighting_spam.html?CID=28830

[url wrapped]

Groeten,

Kees.

-- 
Kees Theunissen
F.O.M.-Instituut voor Plasmafysica Rijnhuizen, Nieuwegein
E-mail: theuniss op rijnh.nl,     Tel: 030-6096724,     Fax: 030-6031204