Sziasztok, nekem is ugyanez a problémám (annyiszor jön meg egy levél az adott félnek, ahány címzettnek szól). Fedora 8 szerveren fetchmail+postfix párossal használom, és szintén csoportos fiókról van szó. Próbáltam a "Delivered-To:" és "X-Envelope-To:" párost, de nem hat. Mit javasoltok? Előre is köszönöm.
Fetchmail konf:
set daemon 30 set logfile "/var/log/fetchmail.log" set no bouncemail
poll mail.szolgaltato.hu proto pop3 aka domain.hu envelope 'Delivered-To' no dns user "valami" pass "valaki" to 'pista.kiss' = 'pista-kiss'
A segitsegeteket szeretnem kerni SMTP szerver konfiguralasaban!
Nekem CSAK es kizarolag SMTP szerver kell. A lenyeg hogy akinek jogosultsagot adok azok hasznalhassak a szervert level kuldesre.Viszont a szolgaltatom SMTP szervere is felhasznaloi azonositassal enged kuldeni levelet. Ehhez kernek segitseget, hogy hogyan lehet beallitani.
Postfix (spamassassin) hogyan beállítandó, hogy azokat a spamaket megfogja, ahol a FROM és a TO mezők azonosak?
Mintha magamnak küldenék spamet :(
----------------------
I was hoping someone could help me figure out a way to block incoming email within either postfix or spamassassin when the sender equals the recipient.
Az alábbi, szerintem postfix imap problémára próbálok megoldást találni.
Egy Ubuntu 8.04 Server-en fut a postfix. Többféle levelező kliens (Outlook, Outlook Expressz, Thunderbird) alatt is jelentkeznek rendszeresen ipam lekérdezési problémák. Outlook Expressznél, nem tudja lekérdezni a különféle imap szerveren található mappákat (sent,inbox,stb), hálózat vagy tevékenység hiány miatt, Outlook esetében a nem tudta letölteni a NULL mappát, vagy Beérkezett üzenetek mappát hibaüzenet fogad, Thunderbird használatakor, pedig a nem sikerült kapcsolódni az IMAP kiszolgálóhoz. Lehet, hogy túllépte a kapcsolatok maximális számát hiba, jelentkezik. Próbálkoztam már a levelező kliensek ellenőrzésével is, az IMAP szerveren a mappák ellenőrzésével is. A hiba rendszeresen elhárul, ha újra indítom a courier imap szolgáltatását. Amennyiben valaki már találkozott hasonló hibával, vagy van tippje, annak megköszönném a hozzászólását. Már keresem egy ideje a megoldást, de eddig sikertelenül, ezért is kérném a közönség segítségét.
Nos itt vagyok megint :-) A postxix+fetchmail duó ismét a kérdés tárgya: szépen válogat a cucc, de ha valakinek úgy küldenek levelet, hogy van egy másik címzett aki cc-t kap, mindenki kétszer kapja meg ugyanazt a levelet. Bele se gondolok mi lenne egy sok tagú levelező lista esetén :-)
Mit lehet tenni ez ellen? Illetve a postfix vagy a fetchmail a hunyó?
És persze fordítva is:-) Mostanában futottam bele abba, hogy lenny kernel downgrade után (2.6.22.19) nem bootolt a nyomorult. De csak a 32 bites verzió, az AMD64 megette.
A múltkor kipróbáltam abban a környezetben ahova készült a cucc, és minden levél a fetchmail postmasterének megy. Igaz, ez egy etch, az otthoni, ahol teszteltem meg lenny. Lehet a két rendszer között ekkora különbség? (lehet, nyilván mert nem ment, de vajh miért?) Mindegy holnap felhúzok rá egy lenny-t, remélem az otthoni 64bites és a leendő 32bites között nem lesz ekkora különbség :-)
A link tényleg nagyon jó, köszönöm :-) A levelezés egy elég misztikus világ, elég jó kihívás... Anno belefogtam egy sendmail.conf feltérképezésébe, na az nem semmi egy cucc :-) A procmail maidir utálatáról nem tudtam, de szerencsére végül nem szorultam rá. Mert akkor kezdődött volna egy újabb etap a courier-pop mailbox-hoz szoktatásával...
Vagyis ez az arpipc.ceg.hu ez tulajdonképp mit csinál?
Semmit.:-) Csak hát a fechmail tud olyan nagyon érdekes fejléceket produkálni, amit a postfixet részletes logolásra állítva derült ki ( a mastercf-be az smtp inet n - - - - smtpd -v sort szükséges módosítani ehhez) számomra. Ezért ez a keverés a hostnevekkel, bár a fetchmailrc-be a set invisible megakadályozza ezt, de ha ez elmarad, akkor előfordulhat fura címzés.
A fetchmailrc-ben a is * here minden lokál usernek küldené?
Igen, a csillag itt is mindent jelöl. Az van, hogy itt egy helyi usernév állna a csillag helyén, ha nem közös mailboxot használnátok, hanem minden userhez egyet-egyet, itt lehetne közölni, hogy melyik helyi usernek címezze a levelet.
Az envelop (azon túl, hogy boríték) mit is csinál?
Ez a sor hülyeség tőlem, és még sokszorosítottam is:-) Szolgaian másoltam egy régi, működő konfigomat a hibájával együtt, csak a hostokat, meg az userneveket, passwordoket írtam át. De működik így is:-) Szóval, az envelope azt szabja meg, hogy a fetchmail a headerben kutakodva milyen mezőből szedje ki a címzettet. Régen X-Envelope-To -t használt defaultban, de azt sok mail szerver hanyagolta, ezért a mostani alapértelmezés a Received.
Linket nem tudok ütőseket, én a gugli meg a fetchmail man lapja alapján lőttem be (http://fetchmail.berlios.de/fetchmail-man.html).* A postfix viszont egészen bő és informatív honlappal rendelkezik (http://www.postfix.org/) Amit igen jónak találtam, ráadásul magyar is: Postfix UCE HOWTO
*bár egészen csudálatos dolgokra képes a fetchmail, nekem a timeout a fetchmailrc-ben nem működött, csak parancssorból veszi figyelembe az új értéket.
Nem akarom elkiabálni, de úgy nézki nálam is :-) Az akarmi@ceg.hu-ra jövő levél szépen landol az akarmi lokál user fiókjában. És ez volt amit szerettem volna. Ami lokálisan nem létezik, az úgytűnik megy a postmasternek ami teljesen logikus döntés.
És most jön a neheze: a feladat megoldva, hála neked, de engem a miértek is érdekelnek. Vagyis ez az arpipc.ceg.hu ez tulajdonképp mit csinál? A fetchmailrc-ben a is * here minden lokál usernek küldené? Az envelop (azon túl, hogy boríték) mit is csinál?
Nagyon köszönöm a segítségedet és a türelmedet, ha a kérdésekre akadna a tarsolyodban pár link, meg köszönném. Angol is lehet, bár magyarul kétségtelen produktívabb vagyok :-) Az is igaz, hogy amikor a linux felszinénél mélyebbre ások, már nemigen akad jó magyar irodalom róla, ezt bizonyítja ez a feladat is.
A teljes levelezésünket természetesen archiválom, sose tudni mikor kell még...
:-) Nem baj, mert nem hagyott nyugodni a dolog, kipróbáltam. Működik.
A postfix beállításainál felesleges a canonical és a virtual táblákat létrehozni, nem kellenek. Tehát amit alant írtam ezekről, azt figyelmen kívül lehet hagyni. Még sarge-val csináltam ilyet, működik is, de túlcifráztam szvsz.
Az egyszerű és jó config a 298-as hsz.-emben van leírva. Ez így a ceg.hu domaint helyben kezeli, el is fogadja az ilyen címzést, de a server nem használja az ISP mail szerverét, mindenhova maga akarja küldeni a leveleket. Ezt megelőzendő:
Okay, akkor először a postfix konfigja, hogy a ceg.hu leveleit helyben kézbesítse (az általad említett változók közé még egyet felveszünk, a helyi szubnet IP tartománya 172.16.168.0/24, és az arpipc host a 172.16.168.1-es címen csücsül.).:
Kipróbáltam a saját -desktop- gépemen (Debian lenny, IA32; postfix 2.5.5-1.1), ez így nekem megy, helyben kézbesíti a ceg.hu -nak címzett leveleket, már ha létező unix userről van szó.
pl egy kézbesített levél a zoli usertől a dds-nek.: From zoli@ceg.hu Wed Jul 22 09:06:24 2009 Return-Path: <zoli@ceg.hu> X-Original-To: dds@ceg.hu Delivered-To: dds@ceg.hu Received: from [172.16.168.1] (dadus [172.16.168.1]) by ceg.hu (Postfix) with ESMTP id 4816C5C598 for <dds@ceg.hu>; Wed, 22 Jul 2009 09:06:24 +0200 (CEST) Message-ID: <4A66BA6B.4080108@ceg.hu> Date: Wed, 22 Jul 2009 09:06:19 +0200 From: zoli <zoli@ceg.hu> User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: dds@ceg.hu Subject: proba01 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit
Á, annyira nem voltam fáradt, csak rohadt zörgős a billentyűzetem és már jelentőségteljes sóhajtozást hallottam :-). Ha benne vagyok egy ilyen érdekes témában akkor no álmosság (amúgy sem tudtam még elaludni egy darabig)...
Én így nem, hanem úgy jártam, hogy ssh-val ki tűzfalszabályoztam magam alól a gépet. Ott szerencsére volt aki újraindítsa, a szabályok meg nem voltak mentve...
Szóval némi átbeszélést igényel a jelrendszer is, mert már ott is voltak bizonytalanságok:
van a cég, akinek van egy külső domain neve, nevezzük ceg.hu-nak. van a gépem, amin a kísérletezés folyik, ennek a neve arpipc. és van a mailszerver, legyen mail.isp.hu Náluk van az a fiók amire beesnek a levelek, ezt hívjuk info@ceg.hu-nak. Ráadásul érzésem szerint úgy esnek be, hogy bármi ami a @ceg.hu-ra jön, bejön. Már csak emiatt is kell a szűrés, hogy a sok szemét ne terhelje őket.
Persze, ha nagyon fáradt vagy, akkor jobb is, mert most inkább csak rombolnánk a rendszert:-)*
Jóccakát neked is.
* Én már már jártam úgy éjjel kettőkor, hogy a saját gépem helyett egy szervernek adtam ki a halt parancsot. Mit tudtam csinálni, fogtam a kocsikulcsot, oszt hajrá. Visszafele a zsaruk megszondáztak, úgy meg voltam már reccsenve, hogy a sötétben, hat méterről csak rámnéztek, és már kapták is elő:-)
Szerintem is ez lenne a legjárhatóbb, már elvesztem... Ha megengeded holnap keresnélek ezzel, kezdve egy postfix conf. kifaragásával. Addig is köszönöm a türelmet, jó pihenést Neked...
Szvsz kettéválaszthatnánk a problémát. Ha a postfix helyben már tud küldeni a cegnev.hu-ra, akkor legalább már az kilőve. Vagyis ha az user1@cegnev.hu helyben képes levelet küldeni az user2@cegnev.hu-ra, akkor a postfix többé-kevésbé jól be van lőve.
A localhost és a cegdomain.hu után whitespace, a kettőspont után nincs. A csillag után szintén whitespace, de a kettőspont után nincs tehát egybe: smtp:isp-mailserver.hu.
Nah, most annyi változott, hogy megint írogatja a postmasternek a "user@cegnev.hu" nincs a rendszeremen üzeneteket. Virtual, canonical kitöltve, postmap futtatva rájuk és mégis... Kezdem elveszíteni a fonalat. A transport fordításakor pedig warningol, mondván, hogy név whitespace érték párokat szeretne. Sajna egy transport example sem akadt a kezembe... De az, hogy Te gyártottál ilyet, optimizmusra ad okot, miszerint meg lehet ezt csinálni :-) A küldés annyira nem dráma, az ISP SMTP-t gondoltam használni hozzá. Csak ez a szétszedés lenne fontos, mert az outlook nem tud pop3 szűrést sajna.
A disable_dns_lookups meredeknek tűnik, de ugye nem igazi mail szerver, gondolom te is az ISP mail serverén keresztül küldöd a leveleidet. Az /etc/hosts file-ba társítottam a cegdomain.hu-t az eth0-ás IP címre, és így ragyogóan kézbesít helyben is, hisz nem vizsgálja a postfix az MX rekordot.
Ha jól sejtem enélkül a helyben egymásnak küldött cegdomain.hu-nak címzett leveleket kiküldené az ISP mail serverének. Bár elvileg a transport file-ba helyire van állítva a cegdomain.hu, de kérdés, hogy mitet művelne egy névfeloldás után.
Köszi a leírásokat, megcsináltam. Ám minden a fetchmail@localhost usernek megy. Igazából nem tudom, hogy ki a ludas: postfix, vagy fetchmail?
postfix/local[13330]: AA2A42B8581: to=<fetchmail@localhost>, Ilyenek vannak a logban...
Ez pedig a fetchmailrc:
set daemon 90 set syslog set postmaster arpi
poll mail.server.hu proto pop3 envelope "X-Original-To:" user felhasznalo pass jelszo keep
Itt lehet rossz valami, de a neten egy érthető fetchmailrc leírást nem leltem. Nyilván egy mda "mda" sor kéne, de az mda "postfix"-től hidegrázást kapott...
