[PHP] Webmail integreren in je eigen applicatie, welke ?

[Verwijderd]

Ik wil graag webmail in een eigen applicatie integreren maar dit is lastiger dan je denkt.

Er zijn legio webmail clients welke voldoen aan mijn eisen, twee van de eisen zijn open source en gratis. Alle betaalde versies hebben vaak een community editie en dat is prima voor wat simpel mail werk.

De integratie gaat wat verder dan even de mailclient laden in je eigen app want je moet je verifiëren met je DB-backend en dat uiteraard graag zonder 2e login voor je mailbox.

Ik zie dat veel php-imap-clients hier wel scripts voor hebben maar dan verstuur je het WW in plain text en dat is niet netjes natuurlijk. Zelfs het WW in MD5 hash opslaan in een Sessie-variabele is dirty, mocht je dat willen zou ik een 2e WW alleen geschikt voor die imapclient auth hashen, salten en dat opslaan maar dat zint me nog niet zoals jullie zullen begrijpen.

Ik ben er vrij zeker dat Horde met (d)imp de beste tools aan boord heeft om dit wel goed te doen, echter ik vind die client wat te "zwaar" voor deze simpele mailhandelingen welke ik nodig heb.

Nu is mijn vraag of mensen (goede) ervaring met de bekende imapclients, integratie hiervan in hun eigen app en authenticatie zonder 2x in te loggen.

Iemand ?

[Gomez12]

Wat wil je precies gaan aanbieden in je eigen app?

Waar ik in het verleden wel eens voor gekozen heb was gewoon simpele imap-functies integratie in mijn eigen app ( gewoon headers / messages tonen etc ) en dan een doorkoppeling naar een volledige OWA voor de mensen die het echt wilden ( was wel intranet dus ietwat anders qua policies etc)...

Maar als ik je verhaal zo lees vraag ik me ook af wat je eigenlijk wilt met een eigen imap mailserver? Het voorkomt inderdaad plain ( of via SSL ) doorsturen van wachtwoorden.
Maar als gebruiker heb ik zoiets van : ik heb al een email account, die heb ik ingericht zoals ik wil. Ik zit niet echt te wachten op een extra email-account. Oftewel weet je heel zeker dat je gebruiker niet zijn eigen email wil gebruiken ( want dan tuig je een heel circus voor niets op )

Ik heb er eigenlijk nooit naar gekeken, maar zou je niet iets van openid authentication en headers / mails uitlezen mogelijkheden hebben voor hotmail / gmail etc? Persoonlijk zie ik niet direct het nut in van weer een webmail optuigen als iedereen dit al heeft.

[Verwijderd]

Gomez12 schreef op woensdag 23 juni 2010 @ 00:10:
Wat wil je precies gaan aanbieden in je eigen app?

Waar ik in het verleden wel eens voor gekozen heb was gewoon simpele imap-functies integratie in mijn eigen app ( gewoon headers / messages tonen etc ) en dan een doorkoppeling naar een volledige OWA voor de mensen die het echt wilden ( was wel intranet dus ietwat anders qua policies etc)...

Zoiets zou ook goed kunnen, maar deed jij dan nog een extra auth bij de doorlink ?

Maar als ik je verhaal zo lees vraag ik me ook af wat je eigenlijk wilt met een eigen imap mailserver? Het voorkomt inderdaad plain ( of via SSL ) doorsturen van wachtwoorden.
Maar als gebruiker heb ik zoiets van : ik heb al een email account, die heb ik ingericht zoals ik wil. Ik zit niet echt te wachten op een extra email-account. Oftewel weet je heel zeker dat je gebruiker niet zijn eigen email wil gebruiken ( want dan tuig je een heel circus voor niets op )

Het is gewoon voor de interne mail. Er zitten wat handige tools in de applicatie en ik wil dat de user makkelijk zijn mail kan lezen, beantwoorden en verplaatsen... de mailclients als atmail en roundcube zijn super nette ajax versies welke dan echt heel handy zijn... en tja, opnieuw inrichten ? Daar is imap voor toch ?

Aangezien ik horde gebruik denk ik er over dat te integreren zodat de user gewoon alles binnen trekt via SQL en dus geen wijziging nodig is.

Ik heb er eigenlijk nooit naar gekeken, maar zou je niet iets van openid authentication en headers / mails uitlezen mogelijkheden hebben voor hotmail / gmail etc? Persoonlijk zie ik niet direct het nut in van weer een webmail optuigen als iedereen dit al heeft.

Mhh, bovenstaand is dus niet echt optie aangezien het intern is.

[Gomez12]

Verwijderd schreef op woensdag 23 juni 2010 @ 00:15:
[...]
Zoiets zou ook goed kunnen, maar deed jij dan nog een extra auth bij de doorlink ?

Nope gewoon intranet met windows credentials en dan tegen een exchange server aanpraten met dezelfde credentials...
Op linux zou ik zo snel geen oplossing weten, maar afhankelijk van bedrijfspolicy zou ik overwegen of ik niet naast de backup-account een extra mail-admin account zou kunnen aanmaken die bij alle mailboxen kan. Policy op papier laten zetten door directie, deze verspreiden door organisatie en dan password van dit account naast het password van de backup-account leggen. Lijkt me wettelijk op zich wel toegestaan ( mits je het goed afdicht )

[...]
Het is gewoon voor de interne mail. Er zitten wat handige tools in de applicatie en ik wil dat de user makkelijk zijn mail kan lezen, beantwoorden en verplaatsen... de mailclients als atmail en roundcube zijn super nette ajax versies welke dan echt heel handy zijn... en tja, opnieuw inrichten ? Daar is imap voor toch ?

Beantwoorden zou ik persoonlijk al nooit aan beginnen, daarvoor krijgen mensen 1 mail-programma. Meerdere mail-programma's betekent ook meerdere keren de handtekening etc regelen.
Dat is imho ook gelijk het grootste nadeel van full blown webmail progs, je krijgt er een extra beheer stuk bij...

[...]
Mhh, bovenstaand is dus niet echt optie aangezien het intern is.

Wat is dan het probleem met plain-text auth / md5-auth? Het is niet helemaal ideaal, maar als je dit soort dingen netjes wilt regelen moet je het hele traject netjes hebben. Als je een simpele linux-imap server hebt omdat die gratis was en goed genoeg, dan ga je gewoon tegen beperkingen aanlopen, die kan je oplossen door zelf extreem veel tijd erin te steken, maar als het enkel intern is en je de authenticatie van je app goed hebt geregeld dan heb je enkel kan dat iemand die in je app komt ook bij iemands mail komt, MitM attacks intern lijken me niet echt van toepassing ( of je hebt het al grotendeels opgevangen op andere gebieden )

[Verwijderd]

Gomez12 schreef op woensdag 23 juni 2010 @ 00:40:
[...]

Nope gewoon intranet met windows credentials en dan tegen een exchange server aanpraten met dezelfde credentials...
Op linux zou ik zo snel geen oplossing weten, maar afhankelijk van bedrijfspolicy zou ik overwegen of ik niet naast de backup-account een extra mail-admin account zou kunnen aanmaken die bij alle mailboxen kan. Policy op papier laten zetten door directie, deze verspreiden door organisatie en dan password van dit account naast het password van de backup-account leggen. Lijkt me wettelijk op zich wel toegestaan ( mits je het goed afdicht )

Tja, die second login is alleen voor auth, dus applicatie wise... dit hoef je niet af te bakenen mijn inziens.

[...]

Beantwoorden zou ik persoonlijk al nooit aan beginnen, daarvoor krijgen mensen 1 mail-programma. Meerdere mail-programma's betekent ook meerdere keren de handtekening etc regelen.
Dat is imho ook gelijk het grootste nadeel van full blown webmail progs, je krijgt er een extra beheer stuk bij...

Dit hoeft geen probleem te zijn als je bijvoorbeeld horde IMP gebruikt, je kunt dan dezelfde DB gebruiken voor je user-settings.

[...]

Wat is dan het probleem met plain-text auth / md5-auth? Het is niet helemaal ideaal, maar als je dit soort dingen netjes wilt regelen moet je het hele traject netjes hebben. Als je een simpele linux-imap server hebt omdat die gratis was en goed genoeg, dan ga je gewoon tegen beperkingen aanlopen, die kan je oplossen door zelf extreem veel tijd erin te steken, maar als het enkel intern is en je de authenticatie van je app goed hebt geregeld dan heb je enkel kan dat iemand die in je app komt ook bij iemands mail komt, MitM attacks intern lijken me niet echt van toepassing ( of je hebt het al grotendeels opgevangen op andere gebieden )

Je hebt een punt maar ik sluit het liever uit als het kan

[AtleX]

Let er ook op of het licentie-technisch wel toegestaan is om de boel te integreren in je applicatie?

[Verwijderd]

AtleX schreef op woensdag 23 juni 2010 @ 14:05:
Let er ook op of het licentie-technisch wel toegestaan is om de boel te integreren in je applicatie?

Tuurlijk, zonder verkoop lijkt me dit geen probleem met GPL...

In andere gevallen kun je gewoon het als addon laten installeren door een "afnemer"...

[ Voor 13% gewijzigd door Verwijderd op 23-06-2010 14:26 ]

[AtleX]

Nou, GPL mag je ook niet zomaar integreren. Ik denk dat je applicatie dan afgeleid werk wordt en dus moet het dan ook onder een GPL licentie verspreid worden.

[Verwijderd]

AtleX schreef op woensdag 23 juni 2010 @ 14:29:
Nou, GPL mag je ook niet zomaar integreren. Ik denk dat je applicatie dan afgeleid werk wordt en dus moet het dan ook onder een GPL licentie verspreid worden.

Dat hoeft helemaal niet zolang je het maar niet verkoopt als product.

Voor intern mag je er mee doen wat je wil!

[Creepy]

Iets wat intern draait, wordt niet verspreid door het bedrijf naar derden Dus dat scheelt licentie technisch, in elk geval voor GPLv2. Voor V3 gelden iets andere regels voor het verspeiden van code via de webbrowser, dus dan zul je nog steeds uit moeten kijken.

edit:[/laat]

[ Voor 3% gewijzigd door Creepy op 23-06-2010 14:39 ]