Emails auswerten

Wenn der TO Outlook benutzt, könnte er es in VBA programmieren. Die 
unpräzise Frage des TO lässt allerdings vermuten, dass keinerlei 
Programmiererfahrung vorhanden ist. Dann ist es leider schwierig bis 
unmöglich, es über das Forum zu lösen.

Jester schrieb:
> Nur_ein_typ schrieb:
>> Du kannst -- und es ist Deine Wahl, nicht meine -- in die wunderbare
>> Welt der Softwareentwicklung eintreten. Womit Du das machst, ist kein
>> Thema: Python,  Perl/Rake, Ruby, sprachen-technisch tun die sich alles
>> nichts. Python hätte Parser für E-Mails, CSV viele andere aber schon
>> standardmäßig dabei.
>
> Ich würde mich an AWK versuchen. Bei unixoiden OS ist es dabei, bei
> Windows kann man es nachrüsten.
>
> Kuck da: https://www.gnu.org/software/gawk/

Die verschiedenen Varianten von awk(1) sind mächtige Werkzeuge, aber 
letztlich liefe das hier auch auf eine Art von Programmierung hinaus -- 
und im hier vorliegenden Anwendungsfall würde ich, wenn ich schon alles 
selbst schreiben wollte, vermutlich eher in Richtung Perl gehen, das ja 
als mächtigerer Ersatz für die damals üblichen Shellwerkzeuge wie 
awk(1), sed(1), grep(1) und Co. gedacht war. Und natürlich gibt es auch 
für Perl ein paar passende, dort allerdings externe Werkzeuge zum Parsen 
von E-Mails, so daß man auch in Perl nicht alles selbst machen müßte...

Aber warum sollte jemand, der bei klarem Verstand ist, so etwas tun und 
eine Version von awk(1) oder Perl benutzen? Die Wahl einer modernen, 
typsicheren Skriptsprache, welche obendrein als besonders leicht zu 
erlernen gilt und obendrein schon fertige Module zum Parsen von E-Mails 
und verschiedenen anderen Datenformaten (JSON, YAML, XML, ...) bereits 
in der Standarddistribution an Bord hat, liegt da IMHO deutlich näher. 
Es sei denn, man wäre aus nostalgischen Gründen daran interessiert, sich 
in eher... klassische Methoden aus dem UNIX-Umfeld einzuarbeiten. ;-)

Was sonst würde Deiner Ansicht nach für [go]?awk(1) und gegen Python 
sprechen, vor allem, auch wenn man beides noch nicht kann und sich 
zunächst einarbeiten muß?

Da müßte mal zuerst geklärt werden, wie die Mails erhalten werden.
SleepWalker schreibt da was von "stündlich". Ich glaube kaum, daß er
da stündlich die Mails checkt. Oder macht er das einmal am Tag
und dann alle 24 Mails hintereinander ? Außerdem wäre es dann
hilfreich, wenn ein Mailprogramm schon vorab nach Absender entsprechend
filtern und automatisch abspeichern kann. Es kommen ja noch viel
mehr Mails, als die vom besagten WEB-Dienst an.

Das wäre da zuerst einmal vorab zu klären. Umsonst hat dér das
"stündlich" wohl nicht oben geschrieben.

Wenn das schon automatisiert werden sollte, stellt sich schon die
Frage, ob man einen PC permanent laufen läßt oder es besser wäre,
einen Rasperry Pi oder ein Smartphone zu nehmen. So ein Smartphone
z.B. haben ja viele permanent (Tag und Nacht) an. In JAVA geht z.B.
so ein Service oder Dienst fürs Phone. Zumindest mal für anrufende
Telefonnummern. Denke, daß es sowas für ankommende Mails auch gibt.
Da kenne ich mich aber leider nicht so aus. Das habe ich nur bei
B4X.com mal gesehen.

Aber warten wir mal ab, was SleepWalker eigentlich genau will.

Heinz B. schrieb:
> Da müßte mal zuerst geklärt werden, wie die Mails erhalten werden.

Soweit ich sehe, lädt der TO die Mails per POP3 oder IMAP von einem 
Webmail-Anbieter herunter.

> SleepWalker schreibt da was von "stündlich". Ich glaube kaum, daß er
> da stündlich die Mails checkt. Oder macht er das einmal am Tag
> und dann alle 24 Mails hintereinander ? Außerdem wäre es dann
> hilfreich, wenn ein Mailprogramm schon vorab nach Absender entsprechend
> filtern und automatisch abspeichern kann. Es kommen ja noch viel
> mehr Mails, als die vom besagten WEB-Dienst an.

Das ist zwar möglich, aber das wissen wir ja alles (noch?) nicht.

> Wenn das schon automatisiert werden sollte, stellt sich schon die
> Frage, ob man einen PC permanent laufen läßt oder es besser wäre,
> einen Rasperry Pi oder ein Smartphone zu nehmen.

Nunja, etwas Linux-basiertes wie ein RasPi würde sich da schon anbieten. 
Die Mails ließen sich problemlos via fetchmail(1) abrufen und dann mit 
einem passenden Eintrag in /etc/aliases (nach Änderungen den Aufruf 
newaliases(1) nicht vergessen!) der Form

1

<localpart>: | <path to script>

also zum Beispiel

1

datacollector: | /usr/local/bin/mail_to_database.py

ganz einfach an das entsprechende Skript übergeben, das unterstützen 
alle mir erinnerlichen Local Delivery Agents. Ähnliches ginge übrigens 
auch über eine .forward (dot forward) Datei im Homeverzeichnis des 
Benutzers <localpart>, für dieses Beispiel also 
/home/datacollector/.forward.

Wenn eine E-Mail für den angegebenen localpart ankommt, wird sie mit 
allen Headern etc. über STDIN an das angegebene Skript übergeben. Wenn 
dieses Skript ein Python-Skript ist, kann es die E-Mail dann mit der 
Methode parse() der Klasse Parser aus dem Standardmodul email.parser 
direkt von sys.stdin lesen, und in eine email.message.Message parsen:

1

#!/usr/bin/env python3

2

import sys

3

from email.parser import Parser

4

5

if __name__ == '__main__':

6

    message = Parser().parse(sys.stdin)

Diese email.message.Message (in meinem Beispiel "message") bietet 
Zugriff auf die Header, Inhalte und Attachments der E-Mail, die dann 
weiterverarbeitet werden können. Für die meisten dieser Inhaltstypen 
gibt es auch bereits fertige Parser, einige -- wie csv, json und xml -- 
bereits als Standardmodule mit der Python-Distribution geliefert, andere 
wie BeautifulSoup oder PyYAML aus ganz schnell und einfach 
nachinstallierbar.

Wem das zuvor beschriebene zu viel Aufwand oder zu... "verteilt" auf 
verschiedene Dateien und Konfigurationen ist, kann die Mails vom 
Anbieter womöglich mit Scrapy via HTTP herunterladen und parsen, oder 
für POP3 oder IMAP4 natürlich die fertigen Standardmodule poplib oder 
imaplib benutzen und das Skript über Cron oder einen systemd-Timer 
periodisch starten.

Jester schrieb:
> Ich denke, eine weiterführende Antwort hat sich erledigt: SleepWalker
> scheint nicht wirklich um eine Lösung bemüht. Und wenn ich ehrlich bin,
> war mir das von Anfang an schon klar ...

Mir war das nicht so klar -- aber am Ende ist das IMHO auch egal. Denn 
irgendwann kommt einer mit einer ähnlichen Frage und liest die Antwort 
dann in diesem Thread, und dem hilfts dann womöglich...

> Bei meiner Erstantwort lag die Betonung auf "Ich", mit Zweitbetonung auf
> "unixoid". Gawk deshalb, weil ich es schon vielfach eingesetzt hatte,
> etwas anspruchsvollere Funktionalität (auch ohne große
> Installationsorgie) auf fremden Win-Dosen benutzen zu können.

Wie gesagt, [go]awk(1) ist sehr leistungsfähig, allerdings... der Code 
ist IMHO etwa  so übersichtlich und wartbar wie Perl. Bitte, versteh' 
mich nicht falsch: Perl war über 13 Jahre lang meine primäre 
Skriptsprache, und ich kann damit tatsächlich auch les- und wartbaren 
Code schreiben, aber das braucht viel Disziplin und Erfahrung -- und in 
den awk(1)-Dialekten, die ich kenne, ist das sogar noch schlimmer. 
Deshalb habe ich awk(1) schon vor Ewigkeiten durch Perl abgelöst, und 
dieses wiederum vor ungefähr 12 Jahren durch Python. Da ist es genau 
andersherum: ich brauche meine Disziplin und Erfahrung, wenn ich 
unlesbaren Code schreiben möchte. Und, naja, egal ob awk(1) oder Perl 
oder auch Ruby -- Reguläre Ausdrücke sind eben leider immer ein 
Alptraum, was ihre Les- und Wartbarkeit angeht.

Zudem, wie gesagt, liefert Python all das, was Du in [go]awk(1) manuell 
schreiben, debuggen, und ggf. pflegen und warten mußt, bereits fertig 
mit. Die oben genannten Module zum Parsen von E-Mails, CSV, JSON etc. 
sind hingegen schon fertig, vielfach genutzt, getestet und 
produktionsstabil in der Standarddistribution vorhanden, und können zum 
Beispiel auch MIME-Attachments sauber händeln. Du siehst ja oben an den 
paar Zeilen Code, wie einfach das ist: im Prinzip sind das ja nur zwei 
Importe und eine Zeile "richtiger" Code, schon hat man ein fertiges, 
geparstes Nachricht-Objekt und kann die Header, Inhalte und Attachments 
daraus lesen -- oder die E-Mail auch manipulieren, wenn man das möchte, 
alles ohne eine einzige Regular Expression, in gut strukturiertem, les- 
und wartbaren Code, performant, stabil...

> Dein Ein- und Ansatz (mit raspi) in Ehren, aber traust du dir wirklich
> zu, dies fernschriftlich oder auch -mündlich -- denn selbst kann es der
> TO ja offensichtlich nicht -- im dessen EDV-Umfeld zum Laufen zu
> bringen?

Ich kenne die Infrastruktur des TO nicht, aber Python läuft so ziemlich 
überall -- auch auf dem vom TO erwähnten Windows, für das es sogar 
mehrere Python-Interpreter und -Distributionen gibt. Der Trick mit 
Fetchmail und /etc/aliases muß ja nicht sein, selbstverständlich 
enthalten alle Standarddistributionen von Python nicht nur die von mir 
verwendeten Module sys und email, sondern auch Libraries für POP3, IMAP 
und SMTP, ganz nach Pythons Motto "Batteries Included". Man kann also 
mein kleines "Skript" auch so umschreiben, daß es selbst die Mails 
abruft, und gegebenenfalls auch gleich den Scheduler (mit dem 
Standardmodul "sched") beinhaltet, damit wären  dann fetchmail und Cron 
oder der systemd-Timer aus dem Spiel und das Programm läßt sich unter 
Windows (mit was auch immer Windows dafür vorsieht) als Daemon (sicher 
gibt es dafür unter Windows einen eigenen Namen, "Dienst"?) starten.

Ich... glaube auch, daß das Parsen von E-Mails nicht ganz einfach ist, 
denn dabei geht es schließlich um eine kontext-sensitive Grammatik, die 
wissen muß: bin ich gerade in den Headern, im Body oder in einem 
Attachment? Ich denke, daß das mit [go]awk(1) nicht ganz einfach 
abzubilden ist. Aber im Endeffekt kommt es sicher darauf an, was der 
Betreffende bereits kann: wer fit ist in RegEx und eventuell sogar schon 
in [go]awk(1), der ist damit womöglich ganz gut bedient, aber ohne 
Vorkenntnisse ist vermutlich eine Lösung sinnvoller, die bereits 
möglichst viel benötigte Funktionalität fertig an Bord hat.