[SOLVED] Postfix --- transport_maps + procmail

Fórumok

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.

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

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.

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

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.

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.

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.

Ü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

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! :)