Postfix + MySQL = rejtely

Web, mail, IRC, IM, hálózatok

Sziasztok,

Erdekes a problemam. Van egy mukodo rendszer, ami Debian Etch-en fut. Ennek a konfigjat masoltam be egy Mandriva 2009.1-et futtato gep ala, es valami nagyon furcsan nem mukodik. Egeszen konkretan az aliasokat nem tudja feloldani. Mielott valaki elkezdene mysql okossagokkal jonni, kerem mindenkepp nezze at az utolso kodot - az rejti a lenyeget.

Kodok:

main.cf idevago resze: 


virtual_alias_domains =  
virtual_mailbox_base = /srv/mail
virtual_uid_maps = static:501
virtual_gid_maps = static:501
virtual_alias_maps = mysql:/etc/postfix/mysql/forwardings.cf, mysql:/etc/postfix/mysql/email2email.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql/domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql/mailboxes.cf
virtual_transport_maps = proxy:mysql:/etc/postfix/mysql/transports.cf
virtual_create_maildirsize = yes
virtual_mailbox_extended = yes
virtual_mailbox_limit_override = yes
virtual_maildir_limit_message = "The user tried to reach over quota."
virtual_overquota_bounce = yes
virtual_mailbox_limit_maps = proxy:mysql:/etc/postfix/mysql/mbox_limit.cf
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps $virtual_transport_maps

mysql/forwardings.cf 


hosts = 127.0.0.1
user = railway
password = ******
dbname = adatbazis
query = SELECT destination FROM alias_list WHERE source='%s' AND active=1

A log: 


Jul 18 15:49:09 tim postfix/smtpd[24457]: connect from localhost[127.0.0.1]
Jul 18 15:49:57 tim postfix/smtpd[24457]: DA664144AE: client=localhost[127.0.0.1]
Jul 18 15:50:54 tim postfix/cleanup[24468]: DA664144AE: message-id=<20090718134957.DA664144AE@mail.egypt.local>
Jul 18 15:50:54 tim postfix/qmgr[24453]: DA664144AE: from=<hron@egypt.local>, size=409, nrcpt=1 (queue active)
Jul 18 15:50:54 tim postfix/virtual[24472]: DA664144AE: to=<backupadm@egypt.local>, relay=virtual, delay=80, delays=80/0.03/0/0.03, dsn=5.1.1, status=bounced (unknown user: "backupadm@egypt.local")
Jul 18 15:50:54 tim postfix/cleanup[24468]: 340CB144B0: message-id=<20090718135054.340CB144B0@mail.egypt.local>
Jul 18 15:50:54 tim postfix/qmgr[24453]: 340CB144B0: from=<>, size=2175, nrcpt=1 (queue active)
Jul 18 15:50:54 tim postfix/bounce[24474]: DA664144AE: sender non-delivery notification: 340CB144B0
Jul 18 15:50:54 tim postfix/qmgr[24453]: DA664144AE: removed
Jul 18 15:50:54 tim postfix/qmgr[24453]: 340CB144B0: removed
Jul 18 15:50:54 tim postfix/virtual[24472]: 340CB144B0: to=<hron@egypt.local>, relay=virtual, delay=0.05, delays=0.03/0/0/0.02, dsn=2.0.0, status=sent (delivered to maildir)

Es akkor a legfurab: egy postmap futasa. 


[root@tim hron]# postmap -q backupadm@egypt.local mysql:/etc/postfix/mysql/forwardings.cf 
backup@egypt.local
[root@tim hron]#

Ja, es a backup@ felhasznalo amugy letezik a rendszerben, altalaban NDR-ben kap levelet.

Tehat, osszefoglalva: a postmap megtalalja a keresett usert, am a postfix valamiert megis azt mondja, hogy ez a felhasznalo itt nem talalhato. Megegyszer: a fenti osszeallitas az eles rendszeren, ahonnet masoltam, mukodik.
Amit igy elso korben kizartam:
- mysql: a NDR kimegy a szinten virtualis hron@ -nak
- query hiba: a postmap biztosan sirna miatta
- mysql hozzaferesi hiba: detto, a postmap tuti ordibalna.
- permdenied a mysql-es konfigon: mar volt ilyen, es azt fixaltam is.

Legyszi, help me..

  • 1010 megtekintés

( hrgy84 | 2009. 07. 19., v – 14:42 )

Csak hogy meg jobban elkepesszelek titeket, itt van, hogy mit kerdez a MySQL-tol a postfix: 


4 Connect    railway@localhost on railway
4 Query     SELECT dns AS virtual FROM domains WHERE dns='egypt.local' AND active=1
4 Query     SELECT dns AS virtual FROM domains WHERE dns='egypt.local' AND active=1
5 Connect   railway@localhost on railway
5 Query     SELECT destination FROM alias_list WHERE source='backupadm@egypt.local' AND active=1
4 Query     SELECT dns AS virtual FROM domains WHERE dns='egypt.local' AND active=1
6 Connect   railway@localhost on railway
6 Query     SELECT CONCAT(domain, '/', username, '/') FROM mailbox_list WHERE email = 'backupadm@egypt.local' AND active = 1
6 Query     SELECT CONCAT(domain, '/', username, '/') FROM mailbox_list WHERE email = '@egypt.local' AND active = 1
5 Query     SELECT destination FROM alias_list WHERE source='hron@egypt.local' AND active=1
7 Connect   railway@localhost on railway
7 Query     SELECT email FROM mailbox_list WHERE email='hron@egypt.local' AND active=1
4 Query     SELECT dns AS virtual FROM domains WHERE dns='egypt.local' AND active=1
6 Query     SELECT CONCAT(domain, '/', username, '/') FROM mailbox_list WHERE email = 'hron@egypt.local' AND active = 1

Szavakban:
1) Eloszor is, tiszteletteljesen erdeklodik az irant, hogy o felelos-e a cimzettbeli domainert. Felelos.
2) Ezutan utananez, hogy a cimzett az alias-e. Itt kezd furcsa lenni a dolog.
3) Megnezi, hogy felelos-e ezert a domainert - igen.
4) Itt jon a tenlyeg furcsa dolog: maildir-t probal szamolni az _alias_ cimhez.
5) Mivel ez termeszetesen nem jon ossze neki, valamiert egy ures useru domainnel is megprobalkozik
6) Ezek a probalkozasok elegge halva szuletett otletek, igy atmegyunk az NDR kezbesitesebe.

Ami az egeszben a legfurabb: az a query, amit o az alias feloldasara probal el, LEFUT, es raadasul jo erteket is ad vissza (egy maildirrel rendelkezo virtualis user cimet adja vissza). Adodik a kerdes: WTF?

-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( hrgy84 | 2009. 07. 19., v – 15:27 )

Rejtely megoldva.

Abba nem gondolkodtam bele, hogy mi a teszt es az eles rendszer kozt a kulonbseg (mar azon felul, hogy nem tomegek leveleznek rajta keresztul).

A kulonbseg ugyanis az, hogy mig az eles rendszeren van egy amavis a hatterben, addig a teszt rendszer itt meg nem tart, ki van kapcsolva a content filtering. Ahogy IroNiQ erre ramutatott, ha a receive_override_options erteke no_address_mappings, a postfix nem probal meg aliasokat feloldani (mi tobb, fel sem olvassa az illeto konfigot). Ez jo akkor, ha van egy content filterunk, es nagyjabol minden loszart atveszunk a kapcsolodas es a bemutatkozas koruli akadalyokat sikeresen vevo szerverektol, es atadjuk a szamara. Ekkor arra az smtpd-re, amin a content filter visszafele levelezik, ezt a beallitast felulvagjuk, meghozza ugy, hogy csak azok az ellenorzesek ne tortenjenek meg, amiken a level mar egyszer atment.

Igy eloallt a fenti hiba: a levelezo kapott egy levelet, amit viszont nem adott at senkinek, es hirtelen szembe talalta magat egy kezbesitetlen/kezbesithetetlen levellel, amit aztan nagy lelkesen vissza is iranyitott a feladonak.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.