[linux] Re: met enige ergernis

[Rob Sterenborg]

>> Als ik in RFC2822 zoek dan kan ik niets over HELO/EHLO vinden.
>> Je bedoelt vast RFC2821?
> 
> Je hebt gelijk. Sorry.

No sweat. Ik kan zelf ook zoeken; dat houdt me wakker.. :-)

> 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

Mja en een MDA is een Mail Delivery Agent, de applicatie die de email in
de mailbox van een user bezorgt; ik ben er wel een klein beetje bekend
mee. Ik beheer niet alleen m'n eigen mailserver op home (!= @home.nl).

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

Daarvoor heb je als het goed is in je MTA weer checks zoals SASL auth
en/of $mynetworks, die je voor de andere tests kan laten plaatsvinden
zodat die smtp clients niet onbedoeld worden geblokkeerd.
Wanneer $mynetworks goed is gevuld en alle smtp clients zich moeten
authentiseren dan ben ik er vrij zeker van dat dat degenen die "buiten"
moeten blijven ook buiten blijven en omgekeerd.

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

Zit wat in. Hoewel die natuurlijk via de smart host van hun provider
kunnen emailen: dan hebben ze, tenzij de ISP er op diverse fronten een
rommeltje van maakt, hier allemaal geen last van. De ISP kan het intern
zelf wel oplossen dat dit goed loopt. (Mag ik hopen, en zo niet dan
wordt het tijd om van ISP te switchen.)

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

Vooralsnog gaat dat bij XS4ALL goed. Ik heb tot nu toe nergens last van
en zou het erg jammer vinden wanneer dat voorbij is. De IP range waar ik
in zat en zit heeft zover ik heb controleren nog nooit op een RBL
gestaan en dat mag van mij zo blijven.

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

Ach, ik vind beide net zo erg, maar misschien kan ik het waarderen met
een 4xx ipv een 5xx error. Hahahaa..!

> 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.
...
> de gegevens omtrent de verbinding uitleest. Triviaal is dit
> zeker niet.

Dit is idd een situatie waarin je gelijk hebt. Maar dit kan je
natuurlijk, zoals je zelf ook zegt, naar "local policy" trekken (met het
risico mezelf nu in m'n voet te schieten): wil je wel email van een DSL
kant ontvangen? Ik bedoel: ik weet dat mijn MTA geen dingen doet waarvan
ik niet wil dat ze gebeuren, maar dat kan je niet overal zeggen.

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

En een spambot is welke zichzelf doorgaans ook niet aan een RFC houdt
als je ziet watvoor kansloze pogingen er voorbij komen.

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

Heheh.. Dat zou ik toch wel een beetje jammer voor mezelf vinden.. ;-)
Zolang als ik bij XS4ALL een abo heb hoop ik dat ze SMTP servers
toestaan. (Hoewel ik het van een aantal andere ISP's een goede stap vind
dat ze rechtstreeks smtp van clients blokkeren.) 

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

Ja. Nou ja, in zoverre, ik heb dat een jaar of wat geleden geprobeerd en
toen werd er al direct email geweigerd van mensen waarvan ik wel email
wilde ontvangen. Het opvoeden van de "beheerders" van die servers was
uh... kansloos: de reactie die ik kreeg grensde aan "So what?". Dus laat
ik bepaalde checks toch maar achterwege.

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

Yep. Maar je baas zal maar net die ene email niet krijgen. ;-)
Ik bedoel, ik probeer m'n setup toch wel zo dicht mogelijk te houden en
voor mezelf maakt het niet zoveel uit want als er iets mis gaat dan is
dat zo opgelost. Maar zakelijk liggen de dingen nou eenmaal wat anders
als er wat dure jongens in het spel zijn die het spam probleem niet zo
goed begrijpen.


Groeten,
Rob


-- 
Disclaimer: Any errors in spelling, tact, or fact are transmission
errors.