[linux] Re: met enige ergernis

[Rob Sterenborg]

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?

> 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.

> 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.

>    (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.

> -- 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.

>> 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.

> 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