[linux] Re: met enige ergernis

Ma Feb 26 00:59:32 CET 2007

On Sun, 25 Feb 2007, Rob Sterenborg wrote:

>Kees Theunissen wrote:
>> Volgens RFC2822 moet een (smtp-server die een verbinding opent als)
>
>Als ik in RFC2822 zoek dan kan ik niets over HELO/EHLO vinden.
>Je bedoelt vast RFC2821?

Je hebt gelijk. Sorry.

>
>> 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.
>
>Owke, het zit dus iets anders, echter.. Het is over het algemeen
>mogelijk om in de configuratie de hostname op te geven waardoor de
>mailserver software altijd de correcte hostname zal opgeven bij een
>HELO/EHLO(*). Ik weet dat met Postfix mogelijk is, Sendmail zal er
>hoogst waarschijnlijk ook geen problemen hebben en zelfs op Exchange kan
>je dat doen (verder geen idee welke mailers het ook kunnen).
>
>Wat zie ik over het hoofd dat het excuus kan zijn dat een mailserver
>niet met een correcte *hostname* (FQDN) groet? (Dus, technisch gezien en
>de RFC buiten beschouwing gelaten.)
>
>(*) In het geval dat een client een dynamisch IP adres heeft en daardoor
>geen nuttige FQDN kan opgeven kan je je afvragen met watvoor MTA je
>"zaken" doet. Ik bedoel: ik het vreemd dat een mailserver een dynamisch
>IP adres zou hebben maar misschien is daar toch een goede reden voor.

Je ziet niets over het hoofd denk ik, voor zover het communicatie
betreft tussen smtp servers.
Een een organisatie die zelf een mailserver wil draaien moet (en zal
vast ook wel) een FQDN hebben en er voor zorgen dat DNS en reverse
DNS in orde zijn. En als de organisatie dat zelf niet kan of wil dan
zijn er genoeg hosting-providers die dat wel kunnen.

Maar RFC2821 beschrijft het smtp protocol, niet de communicatie
tussen mail servers. Het smtp protocol wordt ook gebruikt voor
voor communicatie tussen een bedrijfs-server en de MUA's (Mail User
Agents, zeg maar de mail clients van de eindgebruikers) van de
werknemers voor het versturen van mail. In plaats van "bedrijfs-server"
en "werknemers" mag je hier ook lezen "ISP's" en "(particuliere)
klanten". En dan krijg heb je wel te maken met clients die geen
flauwe notie hebben van hun eigen netwerkomgeving.
Het protocol voorziet daar in. En ook de implementatie van het protocol
moet daar in (kunnen) voorzien.

Bedenk ook dat RFC2821 al weer zes jaar geleden werd gepubliceerd en het
opstellen van de RFC zal ongetwijfeld ook enige tijd hebben gevergd.
Destijds was de spam-plaag een stuk minder. Toen was het ook
gebruikelijker dat een mailserver van kleine organisaties een paar
keer per dag naar buiten belde (met een gewoon modem) om zijn mail te
versturen en daarbij steeds een ander ip-nummer/hostnaam kreeg.
Er werd gewoon welwillender om gegaan met mailservers die hun eigen
FQDN niet kenden.

Tegenwoordig zeg je al snel dat die welwillendheid goed is voor
het intern verkeer in een bedrijf, of tussen ISP en klanten, maar
dat je daar geen boodschap aan hoeft te hebben wanneer je als
bedrijfs-server communiceert met externe servers. Dat is dan jammer
voor die particuliere eindgebruiker met linux die zijn eigen mail-
server wil runnen, maar het is niet anders.

>
>> 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,
>
>Dus ook localhost en zijn varianten.

Ja. Hij moet gewoon zijn eigen FQDN gebruiken. Punt.
Maar als hij MIJN FQDM gebruikt dan is dat regelrecht een poging
tot identiteitsfraude. Net een graadje erger.
Het gebruik van localhost in al zijn varianten is gewoon stomp-
zinnig, maar zou je met een hoop welwillendheid nog kunnen zien
al een configuratiefout.

>
>>    (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.)
>
>Dus ook 127.0.0.1.

Zie hierboven.

>
>> -- een reverse lookup van het ip-nummer faalt,
>>    (Reden: een slecht beheerd/geconfigureerd systeem en daar hoef
>>    ik nog steeds geen mail van.)
>
>De RFC zegt idd dat je een IP adres mag opgeven, maar jah...
>
>Omdat dat de gemiddelde MTA's met een correcte hostname kunnen worden
>geconfigureerd zie ik gewoon geen reden dat een MTA een IP adres bij
>HELO zou moeten gebruiken (klanten van ISP's etc. kunnen worden
>afgevangen door smtp-auth en/of $mynetworks oid) en weet ik niet of ik
>wel email wil hebben van een MTA die een IP adres opgeeft.
>Echt, IMHO, wanneer een MTA niet op die manier kan worden geconfigureerd
>dan moet die optie er in komen of moet de admin aan een andere MTA gaan
>denken (en implementeren: er alleen aan denken is niet voldoende ;^)).
>
>Misschien kan je me een situatie opgeven waaruit blijkt dat ik geen
>gelijk heb.

Het is makkelijk om een situatie te beschrijven waarin een computer
(je mag dat een mailserver noemen als er een MTA draait) geen
correcte host name kan vinden.
Denk aan een PC achter een NAT-ing adsl modem. Er zijn genoeg
providers die minstens om de 24 uur de verbinding er uit gooien en
een ander ip-nummer uitdelen als de verbinding weer gemaakt wordt.
Een server configureren met de juiste host name is hierbij uitgesloten.
Een machine zijn externe ip-nummer/host name laten opzoeken zou in
principe kunnen met een script dat het externe ip-nummer opvraagt van
het adsl-modem, of dat verbinding maakt met een externe computer en daar
de gegevens omtrent de verbinding uitleest. Triviaal is dit zeker niet.
Daarmee heb ik nog geen situatie beschreven waaruit blijkt dat jij
geen gelijk hebt. De beschreven situatie is typisch voor een goedkoop
particulier kabel- of adsl-abbonnement. Het is alleszins verklaarbaar
als zo'n machine zijn eigen FQDN niet kent.
Maar je hebt volkomen gelijk als je zegt dat je geen mail wilt
ontvangen rechtstreeks van dat soort 'servers'. Practisch alle mail
van dit soort machines zal spam zijn, verzonden door gekraakte
systemen. Een particulier met zo'n abbonnement moet zijn mail maar
versturen via de server van zijn ISP, een bedrijf dat zelf zijn server
wil runnen moet maar investeren in een verbinding die aan de normen
voldoet.

>
>>> 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.
>
>Sorry, er staat niet wat ik bedoelde te zeggen.
>Het blokkeren van localhost en varianten, 127.0.0.1, $myhostname,
>$mydomain, $myipaddress zal geen problemen geven. Andere HELO checks
>die het leven (en een configuratie) makkelijker kunnen maken zoals in
>Postfix reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname en
>reject_unknown_helo_hostname, kunnen dat wel doen.
>

Deze laatste categorie checks hebben zeker een grotere kans op
false positeves. Maar heb je ooit een analyse gedaan op deze punten
van je non-spam mail die afkomstig was van externe bronnen?
Je mail logs moeten je een heel eind kunnen helpen met die
analyse. Ik vermoed dat het aantal false postives wel mee zal vallen.
De meeste legitieme afzenders hebben hun configuratie echt wel op
orde.

>> 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
>
>Een mooi artikel om eens verder te sturen als de tijd daar is, hopend
>dat de betreffende manager (of een klant..) het wil lezen.
>
>
>Groet,
>Rob
>
>

Groeten,

Kees.

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