A NetBSD eltávolította a Sendmail-t a forrásfából

Címkék

Christos Zoulas bejelentette, hogy eltávolította a Sendmail-t a NetBSD forrásfájából. Ezt a core@ és a security-officer@ beleegyezésével tette. Az ok: a Sendmail negatív biztonsági rekorjai.

Ezzel a NetBSD az korai BSD-k közül elsőként döntött úgy, hogy megválik az ősidők óta alapértelmezett Sendmail MTA-tól. Jelenleg a FreeBSD-ben is, és az OpenBSD-ben is a Sendmail az alapértelmezett MTA. A NetBSD-hez a Sendmail továbbra is elérhető lesz a pkgsrc-ből.

A bejelentés itt.

Hozzászólások

És mit mondtanak erre az _igazi_ BSD-sek? :-) Azt, hogy a Sendmail az egyetlen megfelelő licenc alatt terjesztett MTA. Míg a Postfix a licencének negyedik pontja miatt nem az. Ezért kizárt, hogy pl. az OpenBSD-be bevegyék.

Theo de Raadt:

"So, postfix is not free. It will never go into OpenBSD. As far as I
know, at this time there is only one acceptably free mail server that
we can use (and even with sendmail we have had a bit of a battle
keeping it freeish), and we will continue to use sendmail for the
forseeable future."

A teljes thread itt kezdődik.

--
trey @ gépház

Jol tette. Mar csak a bind-et kell kivennie. En igy tettem egy regi BSD gepen: sendmail -> postfix, bind -> djbdns, es voila, maris jobban alszom....

ASK Me No Questions, I'll Tell You No Lies

Nem értem a kérdést. Arra gondolsz, hogy a webmail beállításokat szeretnéd valahol tárolni? Ennek mi köze a postfixhez? Valamilyen kézbesítéssel kapcsolatos infót is betennél oda?

Nyilván ez is megoldható, az LDAP nem csak olvasható, de írható is... :)

Túl fáradt vagyok most ehhez, de a postfixszel hogy oldod meg azt, hogy ha bejön egy levél, nézze meg a domain MX-ét és ha az egy megadott IP cím, csak akkor csináljon LDAP lookupot, egyébként pedig mondjuk relayezzen arra a címre, vagy dobja el, stb?

Hogy csinálsz benne feltételkezelést úgy egyáltalán? Illetve vannak olyan dolgok, amelyek megoldhatók sendmailben, eximben (monolitikus), de sosem fogod tudni megoldani a postfixben (moduláris).

Policy szerver a te baratod. Ez egy olyan keret, amivel meg az altalad emlitett, gyorsan mondjunk mar par buzzword-ot is meg lehet oldani.

A feltetelkezelesre meg ott van az after queue content-filter, amikor a postfix atadja neked a levelet, aztan azt csinalsz vele, amit akarsz...

ASK Me No Questions, I'll Tell You No Lies

Oszinten!!! A legtobb esetben mindegy, hogy postfix, exim vagy sendmail-t hasznalsz MTA-nak, mert alkalmas arra amit meg szeretnel csinalni.
Ha egy kozosseg ugy dont, hogy sendmail-t nem telepiti alapertelmezett MTA-nak, mert nem eleg biztonsagos az a szive joga.
Ettol meg nem valotzik meg az MTA tudasa, es ha olyan speci eset van, hogy csak sendmail hasznalhato akkor a rendszergazdi fogja es hasznalja.
Es ugyanez igaz DNS-re is. Mindent arra kell hasznalni amire valo.

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

Nézd, DoS-olni mindent lehet, a DNS-t meg az UDP miatt még egyszerűbb is.
Biztonsági oldalról pedig azt mondom, hogy engem egy remote lyuk a bindban kevésbé érdekel. Olyan helyen, ahol erre szükség van, eleve feltételezem, hogy az adott alkalmazás hibás, így a környezetét olyanra alakítom, hogy ezt a hibát kihasználva minél kisebb kár történjen.

Latatlanban mondom, ez a gyerek se fut 100-al..

Ahogy eddig olvastam a hozzaszolasokat bra-n es trey-n kivul nem nagyon ert itt senki a dolgokhoz. Mindenki csak magyaraz hogy postfix meg djbdns de epeszu magyarazatot meg senki nem adott bra-n kivul :)
Nem veletlenul hasznalnak meg nagyon sok helyen sendmailt es bindot.
Teszem ezt hozza hogy en is. Es olyan redszereken ahol nem a sendmail a default ott azonnal rakom fel az OpenBSD -s sendmailt.
Igy vagyok az apacheal is. Az OpenBSD-s httpd -t hasznalom ahol csak tudom. Mert tudom, hogy igy egy *jol tesztelt* es *kiforrot* programot hasznalhatok. Es akkor meg jon ehhez hozza a licence. Ahogy trey idezte Theo-t. Vannak emberek akik kiallnak az elveikert es nem dobjak el azokat.

Még ti se tudtok a sendmail-ből csodát csinálni.

Egy kérdés: ha BSD license -ű lenne a postfix bekerülne?
vagy csak "nem BSD" = szar ?

Tisztelem azt, ha valaki kiáll az elvei mellett, de egy kicsit savanyú a szőlő érzésem van.
(Technikai jellegű érveket hozzál fel. A "Nem veletlenul hasznalnak meg nagyon sok helyen sendmailt es bindot." nem technikai.)

A Bind -nak és a Sendmail -nek rosszabb a security recordja mint a ntp-nek volt. Mellesleg mindenhol openntpd -t használok, bár elismerem, hogy annak is vannak hibái, de azt mondom, hogy az elveim-nek megfelel a program és együtt élek velük (pl. frekvencia szinkronizálás hiánya).

Aki pedig akarja szívassa magát sendmail-lel.

De itt most nem a konfigurálásról, annak mikéntjéről van szó, hanem arról, hogy egy fejlesztői közösség szerint (?) túl sok hiba van benne, és szerintük nem érdemes tovább szenvedni vele. (*)

Szép dolog az elvhűség, de egy átlagos felhasználót bazira nem érdekel, hogy milyen rendszer fut az asztal alatt a gépen, ami a levelezést bonyolítja, a DNS említésekor valószínüleg nem arra asszociál, amire itt a többség (:)). Neki egy a lényeg (és neked is :)): m ű k ö d j ö n, a lehető legkevesebb idő és energia ráfordítással.

(És itt kapcsolódik be az eredeti cikkcím: egy hibával teli, sebezhető alkalmazásnál ez vélhetően jóval nehezebb).

*: a sok hulye baromallat lehet, hogy nekiállt doksit olvasni, csak netán felmerült benne a kérdés: miért tanuljak meg egy plusz makró nyelvet, amire máshol sehol nem lesz szükségem, vagy hogy nahát, megint egy bugreport, és esetleg emiatt állt tovább...

Szerintem elvannak a sendmaillel. Ha meg majd kijön az X és az nem tetszik nekik, akkor marad a 8-as, ahogy az apache esetében is.
Technikai jellegű érveléshez nézd meg a postfix big picture-t, majd képzelj el valami olyat a végén, amit csak az elején tudsz megcsinálni, de te mégsem ott akarod. :)

Aktívan használok postfix-et.

(fentebb válaszoltam a kérdéseidre)

Ha konkrét példákat hozol mint fent, akkor megpróbálok válaszolni.

BTW. Biztos van amit sendmail-lel lehet csak megcsinálni, vagy csak postfix-szel ebben nem kételkedek. A kérdés az, hogy tényleg szükség van-e rá, és hogy megelégszel-e azzal a workaround-dal ami postfix-ben működik.

pl. mindenképp be kell, hogy kerüljön egy levél a queue -ba.

Nem igazán postfixeztem mostanában, de megpróbálok összehozni egy életszerű példát (persze lehet, hogy ez csak nekem az, neked nem):
LDAP szerverben vannak az adatok, relayezni kell az MTA-val. Az LDAP entryk tartalmazzák azt, hogy mi a user e-mail címe és hogy mi az a relayhost, ahová tovább kell küldeni.
A feladat: ha bejön egy levél, amelynek címzettje @valami.hu, akkor próbáljuk meg feloldani a valami.hu A-t és MX-et. Ha ennek az eredménye 1.1.1.1 (amely nem egyezik meg a szerverünk IP címével), akkor menjünk tovább LDAP-ot lookupolni, ha nem, akkor szimplán tegyük a queue-ba és továbbítsuk annak az MX-nek, amit kiadott a DNS.
Ha a miénk, csináljuk vele a következőt:
ha a címzett @domain1.hu, akkor írjuk át @domain2.hu-ra (esetleg ezt az átírást kössük feltételhez, mondjuk a createtimestamp értékétől függővé, vagy valami egyéb attribútum meglétéhez, akár ez is jó lehet)és nézzük meg az LDAP-ban, hogy létezik-e. Ha nem létezik, utasítsuk el.
Ha létezik, továbbítsuk a levelet az LDAP entryben megadott relayhostra.

Lehetne még ragozni...

Megtanulhatod a sendmail avagy exim configurációs lehetőségeit (nyelvét) vagy felhasználhatod meglevő perl tudásodat ;-)

A munin scriptek után ha ez nem triviális feladat akkor csalódtam benned :)
Amit írsz kb. 2 oldalban meg lehet oldani (perl).
(Elég triviális policy servert írni a doksi és a példa alapján.)

LDAP szerverben vannak az adatok, relayezni kell az MTA-val. Az LDAP entryk tartalmazzák azt, hogy mi a user e-mail címe és hogy mi az a relayhost, ahová tovább kell küldeni.
A feladat: ha bejön egy levél, amelynek címzettje @valami.hu, akkor próbáljuk meg feloldani a valami.hu A-t és MX-et.
Ha ennek az eredménye 1.1.1.1 (amely nem egyezik meg a szerverünk IP címével), akkor menjünk tovább LDAP-ot lookupolni, ha nem, akkor szimplán tegyük a queue-ba és továbbítsuk annak az MX-nek, amit kiadott a DNS.

Ha így építed fel a szerveredet, akkor open relay vagy. Ha kihagyod az MX lookup-ot (amitől open relay vagy), akkor a feladat postfix-szel megoldható.

A createtimestamp értékétől függő címzett átírásra tudsz mondani egy gyakorlati, élő alkalmazást, ahol ez kell?

Miért lennék open relay? Ha az adott domain MX-e az általam meghatározott cím *és* ez a cím létezik az LDAP-ban, akkor helyileg kézbesítem valamelyik backend szervernek, amelyet az LDAP-ból nyerek. Ha az LDAP-ban nem létezik ez a cím, elutasítom, mint nem létezőt.

Ha a domain nem rám mutat, akkor elfogadom és továbbküldöm a megfelelő MX-nek *de* csak akkor, ha a feladó IP címe szerepel az engedélyezettek között.
Szerencsétlen keveréke egy mx-nek és smarthostnak, ez igaz.

Gyakorlati élő alkalmazás: egy cégnél, ahol régebben kellett pár dolgot hegesztenem volt olyan feladat, hogy megváltoztak e-mail címek, amelyeket át kellett írni, de nem akarták, hogy az újonnan létrehozott címeknél is működjön ez az átírás (rövidebb volt a régi cím, mint az új, -domain.hu-ból lett valami.domain.hu- így fennállt a veszélye, hogy az újak is a régit használnák :).
Nyilván lehet csinálni egy statikus táblát, viszont ha már sok százezer címed van, szebbnek tűnik úgy átírást csinálni, hogy a createtimestampet veszed figyelembe és akinek ez egy dátumnál magasabb, annál nem írsz át, a régi formájú címet nemlétezőnek veszed.

Egy kérdesem még lenne, te úgyis fényévekkel jobb vagy postfixben, biztos tudod a választ. :)

Ha kihagyjuk az MX lookupot és csak az átírásra koncentrálunk: hogy oldod meg, hogy megtörténjen az átírás, és emellett címzett ellenőrzés is legyen? Legyen csak egy egyszerű domain1.hu->domain2.hu átírás, az LDAP-ban csak domain2.hu-s címek vannak, vannak viszont más domainek is, tehát LDAP filterből keresni uid@domain2.hu-t nem célszerű.
Esetleg bonyolíthatjuk azzal (de ezt kezeld külön a fenti problémától), hogy az LDAP-ban domain1.hu-s címek is maradtak, így először domain1.hu-ra kell keresni, ha az nincs, át kell írni domain2.hu-ra és ellenőrizni, hogy az létezik-e. :)

"Ha kihagyjuk az MX lookupot és csak az átírásra koncentrálunk"
Mi köze az mx-nek ehhez? Mi van akkor ha ugyan azzal a prioritással van 8 db MX-e, és a lista mondjuk havonta változik, totózol?

"címzett ellenőrzés is legyen"

http://www.postfix.org/RESTRICTION_CLASS_README.html

http://www.postfix.org/access.5.html

"így először domain1.hu-ra kell keresni, ha az nincs, át kell írni domain2.hu-ra és ellenőrizni, hogy az létezik-e."

http://www.postfix.org/transport.5.html
Még az sem biztos kell hozzá egy másik postfix folyamat. :)

Az eredeti leírásból hiányzott a következő:

Ha a domain nem rám mutat, akkor elfogadom és továbbküldöm a megfelelő MX-nek *de* csak akkor, ha a feladó IP címe szerepel az engedélyezettek között.

E nélkül open relay lett volna a setup.

De látható, hogy ebben az esetben is fölösleges az MX lookup, mert így is, úgy is az LDAP lookup dönti el a levél sorsát.

Szerintem a kérdéses feladatot anélkül nem lehet jól (szépen/átláthatóan/stb.) megoldani, hogy valahol tárolod azokat a domain-eket, amelyek számára relay-ezel (és melyik backend kezeli a levelet), valamint ettől függetlenül a cím átírásokat. (Utóbbi persze használható a létező címek ellenőrzésére is.)

Konkrétan LDAP-ra nem tudom a megoldást (soha nem használtam), nálunk SQL alapon megy az egész. Kb 70 E-mail címtér, az összes backend szerverekre megy, közben részben cím átírással, részben anélkül. Persze az igazsághoz hozzátartozik, hogy saját policy daemon fut, de az nem a föntieket kezeli, hanem tisztán spamszűrést végez.

Tényleg, sendmail-el lehet csinálni regexp alapú átirányítást? Régebben MX voltunk a netfilter.org-ra is, és a következőt használtuk a levelek továbbítására:

/@(netfilter|iptables|gnumonks).org$/ smtp:[coruscant.$1.org]

:-)

Igen, nyilván kimaradt, de itt nem egy teljes funkcionális specifikációról volt szó, hanem arról, hogy mit nem lehet postfixszel megoldani. Ezt meg lehet, tehát felesleges volt beleírni.

Az SQL-es megoldásnál hogy ellenőrzöd a címzettet a címátírásos esetekben?

sendmaillel mindent lehet, csak akarni kell. :)

Az SQL-es megoldásnál hogy ellenőrzöd a címzettet a címátírásos esetekben?

OK, nézzünk egy konkrét példát. Legyen ez az SQL tábla definíció:

CREATE TABLE addresses (
address CHAR(64) NOT NULL DEFAULT '',
rewrite CHAR(64) NOT NULL DEFAULT '',
relay CHAR(64) NOT NULL DEFAULT '',
UNIQUE KEY (address),
);

Postfix-ben a külső SQL konfig file-okat preferálom, mert így az SQL jelszavak védettek. Ezért csak a file-okban levő query-t és a main.cf-beli bejegyzéseket írom le.

1. Címzettek ellenőrzése, azaz csak létező címre fogadunk el levelet:

relay_recipient_maps = proxy:mysql:/etc/postfix/mysql/relay.mysql

ahol a relay.mysql-ben a következő szerepel

query = SELECT address from addresses where address = '%s'

2. Cím átírás (kézbesítés másik címre, fejléc érintetlen marad - persze azt is át lehetne írni):

virtual_alias_maps = proxy:mysql:/etc/postfix/mysql/alias.mysql

query = SELECT rewrite from addresses where address = '%s' and rewrite != ''

3. Ha akarod, egyenként más és más backend gépre továbbítod a leveleket a transport_maps segítségével, az átírás mintájára.

Az addresses tábla az összes, átírás előtti és utáni címet tartalmazza. Nyilván ez most végletekig leegyszerűsített: ha akarod, plusz mezőkkel és módosított query-vel szabályozod, hogy pl. az átírt címekre nem fogadsz közvetlenül levelet, azaz kívülről nem látszanak, stb. Vagy ha a táblád tartalmaz egy timestamp mezőt, akkor akár annak az értékétől függően átírsz/átirányítasz/kapcsolsz be szűrést :-). Innentől már csak adatbázis kérdés az egész.

Postfix-szel minden lehet, csak akarni kell :-))