pop3 to maildir

Fórumok

Na szóval, az a kérdésem, hogy milyen lehetőségek vannak arra, hogy külső pop3 szerverről levelet letöltve betegyem azt egy helyi virtuális usernek?
Pop3 to IMAP toolt ismerek, azzal az a baj, hogy ugye tudni kell a user jelszavát, másrészt meg ott a gond, ha a user jelszót cserél. Tehát valami olyasmi kellene, hogy a távoli pop3 user+passt, meg egy könyvtárat kap meg, így mondjuk cronból a megfelelő uid-del indítva beteszi a megadott maildirbe a levelet.

Hozzászólások

Fetchmail / Procmail...

Maga a maildirben a levelek fileokkent vannak tarolva. Igythat, vag procmail feladja a local userednek, vagy egyszeruen beteszed a leelet egy filekent a maldir new konyvtaraba.

Egy jegyet kėrek a Magratheara.

Talán hülyeséget írok, de nekem ez így működött:

poll mail.x.hu proto POP3 user "user0@x.hu" pass akarmiislehetne is "user0@domain0.hu" here
poll mail.x.hu proto POP3 user "user1@x.hu" pass akarmiislehetne is "user1@domain1.hu" here

'user0@domain0.hu', és 'user1@domain1.hu' is sqlben tárolt user.

Amit te szeretnél az 2 dolog.
1, letölteni távoli kiszolgálóról
2, helyben kézbesíteni
Erre a fetchmailt találták ki.
Mivel azonban "rejtélyes" a helyi konfig annyit tudunk virtuális, nos nekem tök mindegy milyen virtuális, valaki csak csinált rá MDA-t, vagy most nincs is mail kezelés a helyi hoszton. Ha meg van, akkor az MDA-nak kell odaadni hogy tessék itt vannak a levelek ennek a címzettnek.
Erre jött pár javaslat, persze ettől sem lesz haladó a kérdés...

Userek sql-ben vannak, postfix+dovecot, a dovecot deliver teszi be a levelet a maildirbe.
Fetchmailt már próbáltam régen, és nem működött virtuális userrel, hiába indítottam a usernek megfelelő uid-vel, asszem az volt a hiba, hogy ilyen usert ő nem talál a rendszerben.
Milyen infót szeretnél még tudni?
--
Discover It - Have a lot of fun!

Na, most jutottam ide. Úgy néz ki jó lesz. Annyi kéne még, hogy paraméterként át kéne adni a delivernek az email címet (login username)... Ezt hogy lehet megtenni?
[szerk]
Minden userhez 'and wants mda "/usr/lib/dovecot/deliver -d aktualisuser@domain.hu"' megoldotta éppen, de jó lenne, ha nem kéne mindenkihez megadni az MDA-t... Bár nem katasztrófa.
--
Discover It - Have a lot of fun!

Az rendben van, csak úgy a virtuális címekkel van gond.
Külső szerveren van xy@domain.hu virtuális cím, ami user@domain.hu-ra lett kézbesítve. Tehát ebben az emailben mint címzett xy@domain.hu szerepel. Azt ha poppal leszedi fetchmail, mondjuk sendmaillel beküldi a levelet a helyi smtp-nek, az meg bounce lesz, és megy a postmasternek, mert xy@domain.hu emailcím nem létezik.
--
Discover It - Have a lot of fun!

Miért kéne tudnia minden címre érkező levélről? Amilyen cím nincs, arra levél reject.
Ha arra gondolsz, hogy a mail szerver is tudjon az alias címekről ugyanúgy, akkor szintén fail.
Pl: info@domain.hu -> user1@domain.hu, user2@domain.hu, user3@domain.hu. Külső MX szétszórja a levelet a 3 usernek, ok, benne lesz az inboxukban. De címzett attől még marad az info. Jön a kicsi fetchmail, letölti user1 új leveleit, átadja az smtp-nek, aki ugye a levélben szereplő címzettnek fogja kézbesíteni, látja hogy info@ alias cím, feloldja, beteszi a 3 usernek. Fethcmail megy user2, levél letölt, smtp alias, beteszi mindháromnak megint...
Tehát az SMTP-s kézbesítés eléggé halott dolog így. Arról nem is beszélve, hogy akármilyen domain lehet. Szóval mondjuk user2@domain.eu simán lehet kézbesítve user2@domain.hu-nak már a külső mail szerveren...
--
Discover It - Have a lot of fun!

Miért kéne tudnia minden címre érkező levélről? Amilyen cím nincs, arra levél reject.

Nade ha reject, akkor az a cím nincs. Márpedig ha nincs, akkor egyetlen egy külső MX se érezze úgy, hogy neki szabad "szértszórnia" az arra a címre érkező leveleket. Mert akkor az a cím nincs, tehát vagy a külső is rejecteljen, vagy ha nem tudja, hogy van-e (mert nincs authentikus listája arról, hogy mi létezik és mi nem), akkor továbbítsa egy olyannak, akinek van ilyen listája.

Az a baj, hogy a külső MX is azt képzeli, hogy tudja, melyik localpart@domain.hu létezik, és melyik nem, meg a belső szervered is pont ugyanezt képzeli magáról, de minő fájdalom, a két szerver elképzelése eltér a @domain.hu alatt létező mailcímekről.

Jön a kicsi fetchmail, letölti user1 új leveleit, átadja az smtp-nek, aki ugye a levélben szereplő címzettnek fogja kézbesíteni

Na, megvan, hol cseszted el.

Nem. Az smtp nem a levélben szereplő címzettnek fogja kézbesíteni, hanem a borítékon levő címzettnek. Az smtp nem olvassa a levél belsejét, az ugyanis nem neki szól. A borítékra van ráírva, hogy kinek kell a levelet berakni. A borítékot a fetchmail írja, mégpedig a neki megadott módon.
Történetesen ha az xy@domain.hu mailboxát szeded le, akkor arra kell megkérni a fetchmailt, hogy az xy@domain.hu igazi mailboxának a neve legyen a borítékon (ami lehet akár xy@domain.hu is, de lehet más is).

Hint:
--smtpname < user@domain >
(Keyword: smtpname)
Specify the domain and user to be put in RCPT TO lines shipped
to SMTP. The default user is the current local user.

Igen, és akkor eljutottunk ugyanahhoz a problémához, mint a dovecot delivernél... Hogy adod meg globálisan paraméternek valami változóval a user@domaint, hogy ne kelljen az mda-hoz hasonlóan minden usernél a fetchmailrc-ben megadni az smtpname-t?
--
Discover It - Have a lot of fun!

Elolvasom én a manualt, ha megmondod mit nézzek...
Nos, már találtam egy működő megoldást: http://hup.hu/node/99746#comment-1235380
Működik, csak mondjuk szebb/kicsit egyszerűbb lenne, ha nem kéne minden userhez megadni az mda-t, hanem lehetne globálisan mondjuk 'mda "/usr/lib/dovecot/deliver -d %U', ahol %U helyére betenné a login usernevet. Na ilyet nem találtam...
--
Discover It - Have a lot of fun!