Dovecot és Maildir

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

Sziasztok!

Debian Etch alatt farigcsálnám a levelezést. Szeretném ha minden felhasználó a saját /home/user/Maildir/ könyvtárába kapná a leveleit. Olvasgattam utána és átállítottam a Postfixet, hogy oda pakolja, Dovecot-ot meg, hogy onnan olvassa. Na mármost, ha lekérem a leveleim le is tölti szépen a /home/usr/Maildir/new helyről (/var/mail/user fájlt átkonvertáltam maildir formátumba és azokat másoltam be). De levélküldés után nem tudja átmásolni sehova, közli, hogy nem létezik a hely. A log fájlokat pedig ilyenekkel köhögi teli:

mail.info
Feb 7 11:57:16 zeus dovecot: IMAP(user): stat() failed with index file /home/user/Maildir/dovecot.index: No such file or directory
Feb 7 11:57:16 zeus dovecot: IMAP(user): Disconnected: Mailbox is in inconsistent state, please relogin.


mail.warn
Feb 7 11:51:34 zeus dovecot: IMAP(user): stat(/home/user/Maildir/new) failed: No such file or directory
Feb 7 11:51:34 zeus dovecot: IMAP(user): open(/home/user/Maildir/new) for dnotify failed: No such file or directory
Feb 7 11:51:34 zeus dovecot: IMAP(user): open(/home/user/Maildir/cur) for dnotify failed: No such file or directory
Feb 7 11:51:34 zeus dovecot: IMAP(user): stat(/home/user/Maildir/new) failed: No such file or directory
Feb 7 11:51:53 zeus dovecot: IMAP(user): stat() failed with index file /home/user/Maildir/dovecot.index: No such file or directory

A Maildir könyvtárat maildirmake.dovecot paranccsal hoztam létre. És természetesen léteznek a könyvtárak:

user@zeus:~$ ls ~/Maildir
cur dovecot.index dovecot.index.cache dovecot.index.log dovecot-uidlist new tmp

Valakinek van bármilyen ötlete hol szúrtam el?

  • 1787 megtekintés

Alapból a user azt csinál vele amit akar. Ha barbárul áttolom 777-re akkor is panaszkodik kliens, hogy nem található. Ellenben nem logolja, hogy nem található. Kinek a kezében kéne lenni a Maildir-nek? Dovecot?

@@
"You can hide a semi truck in 300 lines of C."
OpenSolaris 2008.11
Debian Lenny 2.6.27.6

Én szoktam egy mailuser usert létrehozni és nálam az szokta pakolni, de nem a home-okba, mivel én virtuális user-eket szoktam használni (pont az ilyen szarakodások miatt), aztán ez a mailuser a /home/mailuser/ < username > /Maildir-be tolja ki a leveleket a postfix által, és innen a dovecot a mailuser segítségével veszi el.
Pont a jogosultásgok furcsa kezelése miatt nem szoktam rendes userek-nek kézbesíteni levelet. Mondjuk megoldás lehet még az acl. Fogod és azt mondod, hogy a unix alap jogosultságokon kívül a dovecot userének és a postfix userének is rwx a jogosultsága a könyvtárakra a /home-ban. Bár én ezt sem tartom szerencsésnek biztonsági megfontolásokból.

( mrev | 2009. 02. 07., szo – 16:07 )

Szerintem az a problémád, hogy nem világos, melyik program, honnan hová teszi a levelet.

A postfix (smtp) átveszi a levelet és berakja /var/mail/user-ba. Te ezt megváltoztattad, nem sok értelme volt.

Most egy helyi user a mutt-tal (vagy mail-lel, ilyesmivel) le tudja kérni a leveleit, és egyúttal átrakhatja /home/user/mbox-ba. Ehhez nem kell dovecot.

Vagy egy távoli user az otthoni gépén beállíthatja az evolutiont (ilyesmit), hogy a pop3 szervertől kérje el a levelet. Ekkor kap szerepet a dovecot (a pop3 szerver). Az evolution elkéri a dovecot-tól a levelet, áthozza a hálózaton, és berakja a user otthoni gépére /home/user/.evolution/mail-be.

Ez az egyszerű levelezés, amikor a levelezőszerveren accounttal rendelkező userek leveleit kell kezelni.

--
CCC3

Nah várjunk csak. Azt tudom, hogy a postfix fogadja a leveleket. De én egyéni perverzió miatt szerettem volna a /home/user/Maildir-ben tárolni, mert számomra úgy szép és tiszta.
Ezért gondoltam a következőre:
Postfix megkapja, átrakja a /home/user/Maildirbe (kapásból menjen oda).
Dovecot Imap onnan olvassa rögtön.

"Most egy helyi user a mutt-tal (vagy mail-lel, ilyesmivel) le tudja kérni a leveleit, és egyúttal átrakhatja /home/user/mbox-ba."

Igen de minek? Miért nem egyszerűbb ha rögtön odamennek a levelek? Ráadásul általában a user nem jelentkezik be a távoli gépre. Vagy én értettem félre valamit?

@@
"You can hide a semi truck in 300 lines of C."
OpenSolaris 2008.11
Debian Lenny 2.6.27.6

Vegyünk egyelőre csak egy gépet, ezen fut a postfix, és vannak rajta userek. Defaultból a postfix a leveleket a /var/mail/user filébe teszi. Talán máshová is tudná tenni, de nem próbáltam. A /var/mail/user nagyon príma kis hely a leveleknek. A filék permission flagje 600, azaz mindenki csak a saját leveléhez fér hozzá. 1000 user alatt nem érdemes más megoldást keresni.

Ha most egy user be tud erre a (postfixes) gépre jelentkezni, akkor a muttal el is tudja olvasni a saját leveleit. A mutt ui. defaultból ott keresi őket, ahová a postfix defaultból teszi. A mutt kilépéskor felajánlja, hogy az elolvasott leveleket áthozza a /home/user/mbox filébe. Én nem szoktam áthozni. A muttot csak arra használom, hogy gyorsan töröljem a spameket (a /var/mail/user-ben).

Feltehető, hogy a userek zöme nem jelentkezik be a postfixes gépre. Az ilyeneknek a saját gépén fut valami levelező kliens, mondjuk az evolution. Az evolutiont bekonfigurálják, hogy az előző (postfixes) gépen futó dovecot (pop3) szervertől kérjék a leveleket. A levelező kliens elhozza a szerverről a levelet, és beteszi a user saját gépén a /home/user/.evolution-ba. Kész.

Ha már a levelező szerveren szét akarod rakni a leveleket a home-okba, akkor mit csinálsz az olyan userekkel, akiknek nincs is home-uk, mert mondjuk csak azért vetted fel őket usernek, hogy levelezni tudjanak?

--
CCC3

Csak egy internetes szervert 10 felhasználóval (a munkatársaimmal), plusz a itthon családomat.

Ha csak levelezést akarnék szolgáltatni usereimnek, akkor 1000-ig használhatónak gondolom a UNIX passwd/shadow adatbázist. Ui. ekkora méretben egy szöveges lista ugyanúgy megfelel, mint egy SQL adatbázis.

Persze nem akarok az adatbázisban tárolt címekre leveleket, hirdetéseket, számlákat küldeni. Nem vagyok ISP. Ha valaki ISP, az úgyis jobban ért nálam a levelezéshez. És nem itt fog érdeklődni.

Szerk: Érdekelne, mik az előnyök 10 felhasználónál.

--
CCC3

Alapvetően nem az a baj, hogy mennyi felhasználónál gyors-lassú a passwd (ami például FreeBSD alatt BDB alapon tárolódik, tehát adatbázis alapú :), hanem a kezelhetőség és a biztonság: miért kellene egy levelező szerverre login-t adni annak, aki csak levelezik? :)

Nincsenek olyan előnyök, amely miatt minden esetben jobb a virtualizált levelezés... de nagyjából annyi munka beállítani, mint a szoksásos módszer szerint...
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Nem szükséges mindenkinek logint és homeot adni.

A postfix és dovecot default configjától csak pár sorral térek el. Tehát lényegében magától ilyen egyszerűen működik a levelezés.

Ha én volnék az UPC, akkor persze másképp csinálnám.
--
CCC3

Szerk.

Ránéztem a BME ural2 szerverére, 14500 sor van a passwd-ben. Gondolom, ezek egy része be tud oda jelentkezni.

Az is igaz, hogy az spam továbbítás ellen levélküldéshez be-ssh-ztatom a usereimet.

A virtuális levelezés is csak pár sor... nagyjából öt sor. :)

A 14500 felhasználó passwd alapon kezelve? Ilyenkor a jobb helyeken már LDAP backend-et használnak, már csak a fába szervezettség miatt.

Az is igaz, hogy az spam továbbítás ellen levélküldéshez be-ssh-ztatom a usereimet.

Ezt nem értem igazán.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

A 14500 felhasználóhoz semmi közöm, csak éppen megnéztem, ha már ilyesmiről volt szó. Ehhez képest 1000 az elég szerény.

ssh portforwardingal az otthoni user a localhost:25000-et átirányítja a levelezőszerver:25-re. Ha az evolutiont úgy konfigurálja, hogy a localhost:25000-on van az smtp szerver, akkor a postfix úgy látja, hogy a levél helyben lett feladva, azaz továbbítható. Nem helyben feladott levelet nem továbbít. Biztonságos, mert csak az tud levelet küldeni, aki be tud ssh-zni. De ehhez kell a login.

A "pop before smtp"-hez viszont nem kell sem login sem home. Azt nézem éppen, hogy a postfix-hez van-e "pop before smtp" bővítmény. Ennek lényege, hogy az küldhet levelet, akit korábban elfogadott a pop3 szerver, ami mehet mondjuk CRAM-MD5-tel. Nem látom túl nehéznek egy ilyen bővítmény készítését (ha nem találnék).
--
CCC3

Hát ez így eléggé érdekes fusimegoldás... három sornyi postfix konfiggal megoldható, hogy csak azokat engedje levelet küldeni, akik felhasználók a gépen (vagy LDAP-ban benne vannak). És akkor nem kell szórakozni ilyen hülyeségekel, másrészt akárhonnan műküdik... :)

Írtam egy linket, ahol ezek részletesen le vannak írva, és negyed óra alatt megszabadíthatod magad az ilyen felesleges kanyaroktól. Persze mindenki azzal szivatja magát és a kollégáit, amivel akarja... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Nem mondanám sem fusinak sem hülyeségnek. A postfix configban ez egyetlen sor, ssh és portforwarding pedig ettől függetlenül is kell. Az ssh-zás ennyi: ssh host. RSA azonosítás van, jelszó nem kell. A port forwarding automatikus. Nyelvtanárnő elboldogul vele. Biztonságos. Ettől még lehet egyszerűbb megoldás, érdekelne is, de nem látok linket a postodban. Negyedóra az sok.
--
CCC3

Nézem a dokumentációidat, szép munka. Látom, mire gondoltál, de a megértéshez több idő kell. A lényeg: Minden bejövő levelet legalábbis meg kell vizsgálni. Kimenő levelet csak saját usertől szabad elfogadni.

Szerintem inkább irigyelnéd őket. Most viszont aludni megyek.
--
CCC3

spam továbbítás ellen besshzni az miért jó?

Nekem úgy van, hogy van mondjuk 30 levelező felhasználó, ebből kb. 10-nek van shell hozzáférése is a géphez.
Akinek van shell, az ssh-n be tud lépni.
Akinek nincs, csak levelezik, az nem tud belépni. Levelet csak smtp auth után tudnak küldeni (authentikálni csak TLS titkosított kapcsolaton lehet)

G

Kicsit feljebb leírtam, miért jó az ssh port forwarding. Távolról is lehet úgy levelet feladni, hogy az smtp szerver lokális eredetűnek lássa a levelet.

Még egy dolog. Az ISP-k egy része, az enyém is, szűri az smtp forgalmat, ezért itthonról nem tudom elérni az smtp szerveremet. Az ssh ezt is megoldja. De azért most megnézem, hogyan megy az smtp auth.
--
CCC3

Távolról is lehet úgy levelet feladni, hogy az smtp szerver lokális eredetűnek lássa a levelet.

Kíváncsi lennék arra, hogy miképpen tudsz levelezni mobiltelefonról a saját szervereden át? :)

Az ISP-k egy része, az enyém is, szűri az smtp forgalmat, ezért itthonról nem tudom elérni az smtp szerveremet.

Noigen, az SMTP/25 portot tiltják, de az SMTPS/465 portot nem, amelyen a TLS/SSL over STMP van általában. És persze itt csak azt engedi be az MTA, aki azonosítja magát.

Ezek teljesen egyszerű, szabványos és szokványos megoldások. Minden valamirevaló MUA ismeri ezeket, még a mobiltelefonok is képesek TLS-t és SMTP auth megoldásokat használni. Ez annyit jelent, hogy az SMTP szerver megadásánál meg kell adni, hogy ez SMTPS lesz a 465-ös porton, és megadni a levelek letöltésénél is használt nevet és jelszót. Teljesen biztonságos, mert kódolt a csatorna, teljesen egyszerű, mert nem kell megelőző tevékenységeket végezni és teljesen szabványos, ezért olyan eszközről is működik, ahol nincs SSH.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

( gee v | 2009. 02. 07., szo – 17:09 )

Ezen a gépen postfix van, /home/gee/Maildir/-be jönnek a leveleim.

Így néz ki a könyvtáram:
moto:/home/gee/Maildir# l
total 5.3M
drwxr-xr-x 2 gee gee 340K 2009-02-07 16:04 cur/
-rw------- 1 gee gee 55K 2009-02-07 16:04 dovecot.index
-rw------- 1 gee gee 4.4M 2009-02-07 16:04 dovecot.index.cache
-rw------- 1 gee gee 153K 2009-02-07 16:04 dovecot.index.log
-rw------- 1 gee gee 152K 2009-02-07 15:56 dovecot.index.log.2
-rw------- 1 gee gee 32 2008-06-19 00:51 dovecot-keywords
-rw------- 1 gee gee 153K 2009-02-07 16:03 dovecot-uidlist
drwxr-xr-x 2 gee gee 24K 2009-02-07 16:19 new/
-rw------- 1 gee gee 641 2009-01-10 00:22 subscriptions
drwxr-xr-x 2 gee gee 4.0K 2009-02-07 16:19 tmp/

Fogalmam sincs, hogy hoztam létre magát a maildirt, régen volt.

Csak mutatni akartam, nálam mi van benne, és mondani, hogy így működik jól.

main.cf:
-smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
+smtpd_banner = $myhostname ESMTP
-myorigin = /etc/mailname
+myorigin = $mydomain
-mynetworks = 127.0.0.0/8
+mynetworks_style = host
+mailbox_command = procmail -a "$EXTENSION"
+smtpd_sasl_auth_enable = yes
+smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
+smtpd_sasl_type = dovecot
+smtpd_sasl_path = private/auth
+smtpd_tls_auth_only = yes

Ennyi az eredetihez képest a változás.
A gépen nem minden felhasználónak van maildirben a mailboxa, az enyémet a .forward-ból teszem /home/gee/Maildir/ alá.

Hogy a dovecot honnan tudja, hogy az enyémet a Maildirben keresse, pistiét meg mondjuk a /var/mail/pisti alatt, azt nem tudom fejből.

Van egy másik gép, azon is postfix pakolja maildirbe a leveleket (mindenkinek), de azon nem dovecot van. Ezen a gépen a main.cf-ben van egy ilyen:
mail_spool_directory = /var/spool/mail/

Ettől teszi maildirbe a leveleket.
A felhasználóknak (mindenkinek) van egy symlink a home-ban, pl. nekem:
spark:/home/gee# ls -l Maildir
lrwxrwxrwx 1 gee gee 13 2006-01-24 22:50 Maildir -> /var/mail/gee

Itt a jogosultságok (csak hogy lásd, hová tud a postfix sikeresen kézbesíteni):
spark:/var/mail/gee# l
total 132
drwxrwxr-x 2 gee mail 4016 2008-12-18 01:17 courierimapkeywords
-rw-r--r-- 1 gee mail 36 2008-12-08 00:30 courierimapsubscribed
-rw-r--r-- 1 gee mail 2677 2008-12-18 01:15 courierimapuiddb
drwx--S--- 2 gee mail 3536 2008-12-18 01:17 cur
drwx--S--- 2 gee mail 120776 2009-02-07 21:42 new
drwx--S--- 2 gee mail 48 2009-02-07 21:42 tmp

G

( gyunix | 2009. 02. 08., v – 08:37 )

Lehet, hogy ez segít.
http://www.sulinet.hu/tart/fcikk/Kaaae/0/21476/1
Itt a .forward rész a fontos. Nálam ez úgy néz ki, hogy a .forward fájl a user-ek home könyvtárában van és ez a tartalma.
/home/user/mail
A dovecot alapból azt hiszem mail könyvtárat készít. De ha lekérdezed a leveleket egy kliensről és még nincs ilyen könyvtár akkor alapból létre kell hoznia a dovecot-nak. Ugyan így ha levelet küldesz ennek a user-nek pl. a mail paranccsal akkor létre fog jönni az imap könyvtár szerkezet.

( sany | 2009. 02. 08., v – 16:44 )

"ezért itthonról nem tudom elérni az smtp szerveremet. Az ssh ezt is megoldja."

A http is tiltott?

Egy webmail nem felel meg?