Hali,
az tortent, hogy csinaltam egy mail gateway-t, ami egy Exchange szerver elott Postfix + Amavis + Spamassassin + Clamav komboval megszuri a leveleket.
Eddig ugy ment, hogy bedobalta egy fiokba a teljes forgalamt es az Exchange onnan szopta le egy POP3 konnektor segitsegevel.
Na ezt most atalakitottam, mivel ez igy takolmany volt, hogy hasznaljon transport_maps-ot:
transport_maps = hash:/etc/postfix/transport
igy serobol tovabbitja is a megszurt mail-t az Exchange-nek, cak igy nem mukodik a mailbox command, ertheto okokbol:
mailbox_command = /usr/bin/procmail
A subject-et (header-t) eppenseggel atirja a Spamassssin, de eddig a procmail kukazta az igy megjelolt hulladekot.
Szoval akkor hogyan tudnam ebben az esetben a detektalt spamot kukazni?
Koszi!
e
Megoldas, lasd lenn: Header and Body Restrictions kellett a postfix-be, procmail-re innentol nincs is szukseg.
- 1459 megtekintés
Hozzászólások
mi is hasonló okok miatt használunk ilyen szűrést az exchange előtt, de annyi különbséggel, hogy az exchange szerver tölti le a leveleket egy wines fetchmaillel...
--
by Mikul@s
- A hozzászóláshoz be kell jelentkezni
Eddig en is ugy hasznaltam, de ez hordozott magaban annyi hibalehetoseget, hogy mi van ha nem fut a fetchmail valamiert + igy lassabban jutott el a cimzetthez a level, mert eloszor megallt a linux-on, aztan atkerult az Exchange-be es csak onnan jutott el a user levelezo kliensebe.
Eredetileg ezt akartam volna elerni, hogy ne szurjon a linux esz nelkul mindent, mert igy azokat is siman vegignyalta, amik nem letezo user-hez cimzodtek, de az adott domain ala.
Hat sajnos ugy latom ez erre nem megoldas, de mindenkeppen gyorsabb es biztonsagosabb.
Bar ha a fenti probelamra tud valaki valamit az se lenne rossz.
Vegulis minek processalja az akarmi@mydomain.com -ra erkezo leveleket, ha nincs akarmi nevu user?
Jelen allapotban ugyanis ezt mar az exchange mondja meg tovabbitas utan es hat ez tok felesleges overhead, amivel csak noveljuk a termikus hot.
- A hozzászóláshoz be kell jelentkezni
Hat, favagas helyett neha nem art, ha az ember doksit olvas, szoval RTFM. Kis segitseg: elso korben relay_recipient_maps kornyeken keresgelj. A subject atirasa helyett ertelmesebb, ha plusz header-eket rak be a spamassassin, ha pedig mar content filter-kent van beuzemelve, akkor amikor a postfix visszakapja a levelet, akar el is dobhatja a fejlecek alapjan - bar a levelek eldobalasaval azert ovatosan bannek...
- A hozzászóláshoz be kell jelentkezni
gondolom sejted, hogy az eddig elert megoldast is kisujjambol szoptam ki, sot kifejezetten kihivas a szamomra doksi nelkul farigcsalni, mert elvezetet okoz, ha en talalhatom ki, amit mar masok amugy regen megvalositottak.
Pl. remelem az X-Spam-Flag: YES vagy X-Spam-Level: ****** vagy X-Spam-Status: YES, score .... megteszi
a level eldobasa meg szerintem teljesen normalis, ha pont az a cel, hogy el akarom dobni. :)
relay_recipient_maps (default: empty)
Optional lookup tables with all valid addresses in the domains that match $relay_domains.
ez okes, csak hat a user-ek az AD-ban vannak ugyebar...
valami olyasmi kene, ami az AD-t kerdezgeti meg az egyeb processalasok elott.
- A hozzászóláshoz be kell jelentkezni
AD-bol winbind-el tudsz authentikalni, krb-vel vagy nelkul.
Ezt olvasd el: http://hu.samba.org/samba/docs/man/Samba-Guide/DomApps.html
Az AD-bol kapott usernevek alapjan pedig mar tudsz szurni a postfixban a smtpd_recipient_restrictions-ban.
- A hozzászóláshoz be kell jelentkezni
koszi!
ezkell
- A hozzászóláshoz be kell jelentkezni
na igen, mondjuk ez jo, de kicsit sokat kell heggeszteni.
nincs valami elegantosabb, ahogy ezt a postfix magatol is tudna? Mar hogy kit kerdezzen es hogyan es mirol.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
ha az elmeletet kihagyod az elejerol kb 7 parancs begepeleset plusz 3 fajl szerkeszteset jelenti a konfig es megvan az elonye, hogy serverwide, egyeb alkalmazasok is authetikalhatnak ADbe. Ha erre nincs szukseged, akkor a direkt LDAP lekerdezes sem rossz, de akkor neked kell megirnod a query filtereket.
- A hozzászóláshoz be kell jelentkezni
és a te AD-d nem kérdezhető le ldap-al pl? :-)
- A hozzászóláshoz be kell jelentkezni
Sooooooot!
Most ugy latom sikerult azt a helyzetet elodiznem, hogy csak azokat levelekt tomi bele az Exchange-be, amikhez tartozik a Linux-on is lokalis mailbox.
Na remek....
Akkor valahogy mindenkeppen meg kene magyarazni a Postfix-nek, hogy milyen mailbox-ok letezenek a Windows-on, kulonben agyhalal az egesz igy.
- A hozzászóláshoz be kell jelentkezni
A megoldas:
local_recipient_maps =
;)
- A hozzászóláshoz be kell jelentkezni
ezt mashol szoktak ugy is hivni, hogy:
local_transport = error:no local mail delivery
- A hozzászóláshoz be kell jelentkezni
vegulis
- A hozzászóláshoz be kell jelentkezni
Üdv!
Nem egyértelmű, de van valami hasonló nálunk is.
Egy perl-script csinál transport map -et, és az exchange -en lévő fiókokat felépíti belőle. Szerintem már nagyon át lett tákolva, de működik. Sajnos ebben az esetben is kell a linux-on felhasználó.
Nálam annyiban bővült a dolog, hogy egy új domain került be a szórásba, ami idáig csak exchange-en volt. Valahogy szeretném megoldani hogy az új exdomain.hu összes levele bekerüljön az exchange -re, a többiből meg csak az aminek van a domain -jához tartozó exchange címe. (ezek le vannak válogatva.)
Sajnos hiába írtam be a transport-ba
exdomain.hu smtp:xchsrv.belso.cim
Valahogy nem akarja az igazságot.
A dolog szépsége és ami miatt az egész történt, hogy egy baraccuda szűri a spam -et ez előtt és a fentiek miatt is ennek a domain -nek a leveleit jobbnak találtuk átfolyatni a baraccuda -n és a linux mail server -en is. Most már csak azt szeretném elérni, hogy ami erre a domain -ra érkezik a mailsrv -en mind menjen a belső exchange -re.
(btw - Jó sok kis Perl scriptek találhatók pl itt:
http://www.opensourcehowto.org/how-to/postfix/dovecot-imap--squirrel-ma…
is.)
De ezek közül az a pár amit próbáltam sem teljesen az elvártaknak megfelelően működött,
és ha nem felhasználóhoz hanem mappához van e-mail cím rendelve, akkor sehogysem.
(Remélem a fenti példákból lehet pár jó ötletet meríteni, illetve lesz valaki aki nekem is tud valami segítő választ adni.)
R
- A hozzászóláshoz be kell jelentkezni
Ehun talaltam egy tokeletes megoldast a kerdesre: http://www.securityfocus.com/infocus/1598
A lenyeg:
1. fel kellett dobni a postfix-pcre csomagot
2. csinalni kellett file-t, /etc/postfix/header_checks neven, a kov. tartalommal:
/^X-Spam-Flag: YES/ REJECT
3. a /etc/postfix/main.cf -be fel kellett venni egy sort, ugy mint:
header_checks = pcre:/etc/postfix/header_checks
4. aztan postfix reload, hogy modositasok eletbe lepjenek
Ezaltal a postfix reject-eli azokat a leveleket, amiket a spamassasin X-Spam-Flag: YES header-rel latott el.
Az eredmeny a syslog-ban szepen nyomonkovetheto.
Es mindez ezert jo:
This method is useful because the client machine will think your address is invalid, which may get you taken off their spam list. It also means that you haven't sent the message along to your local delivery agent. However, you are receiving the e-mail over the network, so your bandwidth has not been spared.
Szerintem [SOLVED]
Koszi/szivesen mindenkinek! :)
- A hozzászóláshoz be kell jelentkezni