Mail pipen via script of pop3 leegtrekken met script ?

[Verwijderd]

Voor ticketsupport wordt vaak gebruikt gemaakt van scripts om inkomende emails te porten naar je ticketsysteem.

Er zijn voor zever mij bekend eigenlijk 2 varianten:

1. Email piping: je port een mailadres/alias naar een script, dit script runt en je plaats je email in een database.

2. POP3 storage: Je maakt een mailbox aan welke je via pop3 kunt benaderen en laar via een cronjob de mailbox leegtrekken en alle emails in een database zetten.

Nu ben ik me gaan afvragen wat het makkelijkste en bedrijfszekerste is.

Piping is opzich een mooie en snelle manier omdat het zeer realtime is en je dus heel snel een autoreply kunt terug sturen, als je een cron hebt voor een pop3 zit hier altijd een delay tussen.

Piping zal mijn inziens ook de load verlagen op een server aangezien je met pop3 bijvoorbeeld in een keer 100 mails kunt wegtrekken, waar piping dit direct doet wanneer de mail binnen komt. Opzich met een cron iedere minuut zou dat moeten werken want 100 tickets per minuut, dan is er wat mis

Opzich is die load nog niet zo'n onoverkomelijke ramp, wat wel een ramp is als je je mails kwijt bent en ze niet opgeslagen worden in de database.

Voor pop3 doe je gewoon een check en kun je aan de hand daar van beslissen of je verder wil gaan met het storen, bij piping kun je dat ook wel doen, maar ligt de database-server plat moet je een extra tussenlaag hebben, een extra database op een andere server dus... extra script welke er na runnen, etc.

Een pop-box zal niet snel vollopen, je checkt je crons en deze zal dus niet vol raken door niet runnende scripts.

Zijn er mensen welke hier ook een mening over hebben ?

[DiedX]

Ik zit me even af te vragen welk probleem je op wil lossen:

* Piping is over het algemeen wat lastiger, en vaak MTA-Afhankelijk;
* Fetchmail werkt goed;
* De vertraging van een minuut of wat merk je echt niet...

Gewoon doen wat het makkelijkst is?

[Verwijderd]

DiedX schreef op zondag 06 december 2009 @ 18:11:
Ik zit me even af te vragen welk probleem je op wil lossen:

Probleem oplossen is niet zo de issue, ik wil meer eventuele problemen voorkomen.

* Piping is over het algemeen wat lastiger, en vaak MTA-Afhankelijk;

Ja dit is waar, qmail is vrij makkelijk hierin en Postfix ook wel te doen. Dus opzich... zou het een optie zijn.

* Fetchmail werkt goed;

Nog niet over nagedacht, meteen even bekijken !

* De vertraging van een minuut of wat merk je echt niet...

Dat is waar, realtime staat alle zo lekker profi vind ik

Gewoon doen wat het makkelijkst is?

Ja dit is eigenlijk wel de gedachte, maar het moet wel een decent oplossing zijn. Juist door die gedachte kun je mijn inziens toch altijd weer nat gaan... dat wil je niet met IT aangezien het niet hoeft

[DiedX]

Ben ik zeker met je eens. Zelf heb ik RT draaien met fetchmail. Die gooit het naar het perl-script wat meegelevert wordt door RT zelf. Werkt als een trein. Eens in de minuut poppen, fini

Het voordeel is dat je heel snel fetchmail stop kan zetten, en daarmee ook even NIET op kan halen. /etc/init.d/fetchmail stop

[Verwijderd]

Ja RT is een vreselijk goed script, alle grote bedrijven gebruiken dit wel.

Ik wil het graag zelf schrijven, mede omdat ik dat ook wel weer leuk vindt, maar RT is oh zo mooi eigenlijk !

Je hebt natuurlijk het bekende OStickets wat 10x geforked is welke en allemaal overleden zijn omdat het wiel opnieuw uitgevonden werd over code welke niet optimaal en veilig was. Ik wil het alleen integreren, dus ik zit er gewoon aan vast.

OStickets heeft opzich wel een mooi script voor dat pipen en fetchen, een een pop3 cron kun je natuurlijk altijd ook stoppen

Maar fetch... ben lezende...

[sanzut]

RT = Request Tracker, zo leert google mij.

Je kan eventueel als tussen-laag een file gebruiken, dat je de mail daar gewoon tijdelijk heen schrijft als je db plat is. Piping is het snelste, en bedrijfszekerste. Stel je cron wordt per ongeluk gewijzigd, het IP van je mailserver veranderd, het password van de box wordt perongeluk aangepast, of vanwege company policy..

[Verwijderd]

sanzut schreef op zondag 06 december 2009 @ 19:10:
RT = Request Tracker, zo leert google mij.

Wat bedoel je hiermee ? Bedrijven als Ingram Micro gebruiken dit voor hun support-afhandeling bijvoorbeeld.

Je kan eventueel als tussen-laag een file gebruiken, dat je de mail daar gewoon tijdelijk heen schrijft als je db plat is. Piping is het snelste, en bedrijfszekerste. Stel je cron wordt per ongeluk gewijzigd, het IP van je mailserver veranderd, het password van de box wordt perongeluk aangepast, of vanwege company policy..

Je haalt wel hele goede punten aan, ik heb alleen nog niemand gezien welke tijdens een check in het script dat die pipe runt naar files gaat schrijven.

Je zal hier namelijk ook wel een check in moeten maken dat als hij weerk beschikbaar is hij al die files opnieuw gaat importeren. Opzich een mooie oplossing, alleen hoe ga je die mails weer in de DB zetten, door gewoon fopen files uit te gaan lezen ?

[Creepy]

Of je een mail nu leest via STDIN m.b.v. een pipe of zelf direct een bestand opent waar een mail in staat, dat maakt toch helemaal geen verschil?

Ik zit me eigenlijk af te vragen wat het nut van dit topic is. Een algemeen informatie topic over hoe mails naar een eigen gemaakt systeem door te zetten? Of loop je tegen een specifiek probleem aan? Je geeft zelf al de twee meest gangbare oplossingen: mail direct doorsturen naar een eigen gemaakt script/programma of eens in de zoveel tijd een pop of imap box uitlezen.

[Verwijderd]

Een van de problemen zoals DiedX ookal aangaf is of je kunt storen of niet, of dit wil doen ja of de nee, je kunt dus ook stoppen.

De manier van in een file wegschrijven is dan een optie bijvoorbeeld.

Dus door uit te benen hoe je de tussenlaag tussen mail en storage het beste op kunt lossen is dit topic ontstaan.

DiedX had ook een paar goede vragen welke punt van disucssie hoorden te zijn.

[Creepy]

Als je je app en/of database wilt kunnen stoppen dan gebruik je toch gewoon de POP3/imap optie? Dan lost je mailserver die problemen op No offence maar wat mij betreft hebben we het over een redelijk simpel iets en wil je een redelijk zware tussenlaag gaan maken voor eventuele problemen die je al wel en nog niet hebt voorzien. Wat let je om gewoon even wat te proberen en er zo zelf wat ervaring mee op te doen. Uiteindelijk wil je ergens in je ticketsysteem een mail zien te krijgen. Denk gewoon na hoe tickets nu worden opgeslagen. Maak dan vervolgens iets wat een mail omzet naar een ticket. Of je dat stukje code dan aanstuurt via code die een pop3/imap box uitleest, of code die via een pipe de mail opvangt of via 1 platte file (standaard pop3 opslag als je geen maildir gebruikt overigens) maakt dan echt niet uit. Je kan ook erg eenvoudig wisselen van techniek indien nodig.

[ Voor 3% gewijzigd door Creepy op 06-12-2009 19:57 ]

[Verwijderd]

He opslaan van een ticket opzich is niet moeilijk, je kunt alleen de laag er dus tussen zo fancy maken als je maar wil.

Een zeker overwogen vraag is of je het beste Perl of PHP op de commandline kunt gebruiken. Perl zou wellicht iets beter op performance kunnen zijn bij meerdere "pipes" denk ik ?

[Creepy]

Qua performance is er maar 1 zekerheid: testen Maar als jij 100 mails per minuut wilt verwerken dan maakt het echt niet uit of je nu perl of PHP pakt..... Dus nogmaals: wat let je om gewoon even wat te testen en spelen? Je kan wel blijven overleggen maar je zult toch echt zelf de knoop moeten doorhakken.

[Verwijderd]

Creepy schreef op maandag 07 december 2009 @ 15:28:
Qua performance is er maar 1 zekerheid: testen Maar als jij 100 mails per minuut wilt verwerken dan maakt het echt niet uit of je nu perl of PHP pakt..... Dus nogmaals: wat let je om gewoon even wat te testen en spelen? Je kan wel blijven overleggen maar je zult toch echt zelf de knoop moeten doorhakken.

Ik ga nu voor PHP omdat me dat beter ligt

[djluc]

Je kan ook een combinatie proberen. Laat de mail in een mailbox opslaan (inbox) en tegelijkertijd verwerk je deze (realtime). Als het realtime proces goed is verlopen verplaatst je de mail naar de archive map.