Skip to main content
Hallo an alle Mitleser,
wie bringen ich postfix dazu ein Log zu schreiben - insbesondere
darüber, was mit Mail passiert, die nicht an einen MDA weitergegeben
werden. (warum das nicht passiert ist dann eine andere Baustelle)
Wenn es so etwas schon gibt, wo muß ich das/die Log(s) suchen. Unterhalb
von /var/log finde ich nichts.
Ich bin es gewohnt, daß in oben beschriebenen Fall die Mail zumindest
nach
/var/spool/mail/$USER
gelangen. Das ist aber nicht der Fall. Sie sind fort und wo könnten die
nun abgeblieben sein?
Bei Mageia gibt es ein unterhalb von
/var/spool/postfix
eine umfangreiche Verzeichnisstruktur, in die allerdings noch nie
reingeschaut habe, weil es dort einfach immer funktioniert. Dort würde ich
ein Cache am ehesten vermuten. Ich habe hier z.Z. aber keinen Rechner mit
Mageia laufen.
Im konkreten Fall fehlt das allerdings alles komplett.
Da ich das zu sehen bekomme
andreas@linux-1uge:~> ps aux | grep postfix
root 654 0.0 0.0 5072 1272 ? Ss 16:08 0:00
/usr/lib/postfix/master
postfix 662 0.0 0.0 4880 1128 ? S 16:08 0:00 pickup -l -t
fifo -u
postfix 663 0.0 0.0 4924 1140 ? S 16:08 0:00 qmgr -l -t fifo
-u
andreas 1639 0.0 0.0 4160 880 pts/0 S+ 18:00 0:00 grep --
color=auto postfix
nehme ich mal an, daß postfix zumindest zu laufen scheint?
--
Gruß Stefan
Die e-Mail-Adresse nimmt grundsätzlich keine privaten Nachrichten entgegen.
Solche bitte an
hsn.neumeyer[dot]arcor.de
senden.
GnuPG-Schluesselkennung für diese Adresse: 7C9AB525
Bei mir logt postfix ganz einfach nach /var/log/mail.*
Das ist wohl auch Standard, jedenfalls kann ich mich nicht erinnern,
das irgendwo eingestellt zu haben.
grep postfix /var/log/mail.*
sollte einiges ausgeben.
Hermann
Am 31.08.2013 18:27, schrieb H.-Stefan Neumeyer:
> Hallo an alle Mitleser,
>
> wie bringen ich postfix dazu ein Log zu schreiben - insbesondere
> darüber, was mit Mail passiert, die nicht an einen MDA
> weitergegeben werden. (warum das nicht passiert ist dann eine
> andere Baustelle) Wenn es so etwas schon gibt, wo muß ich das/die
> Log(s) suchen. Unterhalb von /var/log finde ich nichts.
> Ich bin es gewohnt, daß in oben beschriebenen Fall die Mail
> zumindest nach
> /var/spool/mail/$USER
> gelangen. Das ist aber nicht der Fall. Sie sind fort und wo könnten
> die nun abgeblieben sein? Bei Mageia gibt es ein unterhalb von
> /var/spool/postfix
> eine umfangreiche Verzeichnisstruktur, in die allerdings noch nie
> reingeschaut habe, weil es dort einfach immer funktioniert. Dort
> würde ich ein Cache am ehesten vermuten. Ich habe hier z.Z. aber
> keinen Rechner mit Mageia laufen. Im konkreten Fall fehlt das
> allerdings alles komplett.
> Da ich das zu sehen bekomme
> andreas@linux-1uge:~> ps aux | grep postfix root 654 0.0
> 0.0 5072 1272 ? Ss 16:08 0:00
> /usr/lib/postfix/master postfix 662 0.0 0.0 4880 1128 ?
> S 16:08 0:00 pickup -l -t fifo -u postfix 663 0.0 0.0
> 4924 1140 ? S 16:08 0:00 qmgr -l -t fifo -u andreas
> 1639 0.0 0.0 4160 880 pts/0 S+ 18:00 0:00 grep --
> color=auto postfix
> nehme ich mal an, daß postfix zumindest zu laufen scheint?
> _______________________________________________ Ubuntu mailing
> list Ubuntu@easylinux.de
> http://www.easylinux.de/Kontakt/Mailinglisten/listinfo/ubuntu
_______________________________________________
Ubuntu mailing list
Ubuntu@easylinux.de
http://www.easylinux.de/Kontakt/Mailinglisten/listinfo/ubuntu
Am Samstag, den 31.08.2013, 18:54 +0200 schrieb Hermann:
Hallo Hermann
> grep postfix /var/log/mail.*
> sollte einiges ausgeben.
Es gibt keine /var/log/mail und auch sonst nichts, was auf die Arbeit
von postfix hindeutet - außer, daß die von fetchmail geholten Mail weg
sind.
Ist denn der rsyslogd installiert und gestartet?
Am 31.08.2013 19:37, schrieb H.-Stefan Neumeyer:
> Am Samstag, den 31.08.2013, 18:54 +0200 schrieb Hermann:
> Hallo Hermann
>>
>> grep postfix /var/log/mail.*
>> sollte einiges ausgeben.
> Es gibt keine /var/log/mail und auch sonst nichts, was auf die
> Arbeit von postfix hindeutet - außer, daß die von fetchmail
> geholten Mail weg sind.
Am Samstag, den 31.08.2013, 20:06 +0200 schrieb Hermann:
> Ist denn der rsyslogd installiert und gestartet?
andreas@linux-1uge:~> ps aux | grep rsyslog
root 389 0.0 0.0 39312 3548 ? Ssl 16:08 0:00
/usr/sbin/rsyslogd -n
andreas 1181 0.0 0.0 4160 880 pts/1 S+ 20:24 0:00 grep --
color=auto rsyslog
Ich habe heute Nachmittag alle in Frage kommenden logs durchgeschaut.
Ohne Ergebnis. Das einzige was auf die Arbeit von "Mail" im allgemeinen
hindeutet ist die $USER/home/.fetchids, die beim manuellen
fetchmail-Aufruf angelegt wird.
Das manuell zu machen ist im Moment das einzige was funktioniert. Aber
die abgerufenen Mail verschwinden eben irgendwo...
Gibt es denn die /var/log/syslog? Dann schreib doch mal in deine
/etc/fetchmailrc " set syslog".
Außerdem kennt fetchmailrc eine Option "set logfile".
Vielleicht hift das ja weiter.
Am 31.08.2013 20:36, schrieb H.-Stefan Neumeyer:
> Am Samstag, den 31.08.2013, 20:06 +0200 schrieb Hermann:
>> Ist denn der rsyslogd installiert und gestartet?
> andreas@linux-1uge:~> ps aux | grep rsyslog root 389 0.0
> 0.0 39312 3548 ? Ssl 16:08 0:00 /usr/sbin/rsyslogd -n
> andreas 1181 0.0 0.0 4160 880 pts/1 S+ 20:24 0:00
> grep -- color=auto rsyslog
> Ich habe heute Nachmittag alle in Frage kommenden logs
> durchgeschaut. Ohne Ergebnis. Das einzige was auf die Arbeit von
> "Mail" im allgemeinen hindeutet ist die $USER/home/.fetchids, die
> beim manuellen fetchmail-Aufruf angelegt wird. Das manuell zu
> machen ist im Moment das einzige was funktioniert. Aber die
> abgerufenen Mail verschwinden eben irgendwo...
Am Samstag, den 31.08.2013, 20:58 +0200 schrieb Hermann:
> Vielleicht hift das ja weiter.
Der Rechner steht zwar nur 1 1/2 Straßen weiter, aber ich komme trotzdem
erst Ende der Woche wieder dran.
Hallo Stefan,
H.-Stefan Neumeyer schrieb am 31.08.2013 um 18:27:
>wie bringen ich postfix dazu ein Log zu schreiben
Das musst Du postfix nicht extra beibringen.
Wenn postfix läuft, loggt es nach /var/log/mail.log, Fehler
nach /var/log/mail.err, Warnungen nach /var/log/mail.warn
> - insbesondere
>darüber, was mit Mail passiert, die nicht an einen MDA weitergegeben
>werden. (warum das nicht passiert ist dann eine andere Baustelle)
Mails, die nicht ausgeliefert werden können - egal aus welchem Grund -
wandern in Unterverzeichnisse von /var/spool/postfix. Wie lange sie dort
verbleiben, respektive wie viele Zustellversuche unternommen werden,
bis die Mail endgültig verworfen wird, wird in der Konfiguration
festgelegt.
>Wenn es so etwas schon gibt, wo muß ich das/die Log(s) suchen. Unterhalb
>von /var/log finde ich nichts.
Dann würde ich mal testen, ob postfix überhaupt läuft.
root@einstein:/home/uwe# /etc/init.d/postfix status
[ ok ] postfix is running.
snip
>Da ich das zu sehen bekomme
>andreas@linux-1uge:~> ps aux | grep postfix
>root 654 0.0 0.0 5072 1272 ? Ss 16:08 0:00
>/usr/lib/postfix/master
>postfix 662 0.0 0.0 4880 1128 ? S 16:08 0:00 pickup -l -t
>fifo -u
>postfix 663 0.0 0.0 4924 1140 ? S 16:08 0:00 qmgr -l -t fifo
>-u
>andreas 1639 0.0 0.0 4160 880 pts/0 S+ 18:00 0:00 grep --
>color=auto postfix
>nehme ich mal an, daß postfix zumindest zu laufen scheint?
Ich würde sagen der Schein trügt. Sieht mir eher danach aus, als ob die
Konfiguration nicht abgeschlossen ist und/oder Fehler aufweist.
Da Du etwas später im Thread fetchmail erwähnst, würde ich erst mal in
Abhängigkeit von dessen Einstellung, die Mails die eventuell unterhalb
von /var/spool/postfix liegen sichern. Wenn fechtmail nicht im
keep-Modus läuft, sind die Mails sowohl vom Server als auch irgendwann
aus der Queue von Postfix weg.
Dann würde ich alle Postfix-Prozesse killen und versuchen ihn
über
/etc/init.d/postfix start
zu starten. Ist die Konfiguration verbogen kommen dabei in der Regel
recht aussagekräftige Meldungen und der postfix-Start wird
abgebrochen. Da kann man dann ansetzen.
Viele Grüße
Uwe
Debian GNU/Linux 7 Kernel 3.2.0-4-686-pae Xfce 4.8
Sag NEIN zu globalen Spionageprogrammen!
Am Sonntag, den 01.09.2013, 03:16 +0200 schrieb Uwe Herrmuth:
Hallo Uwe
Ich hole mal etwas weiter aus:
SuSE 12.3, an der sich vor mir schon zwei andere mit den
unterschiedlichsten Ansätzen zu schaffen gemacht haben. Dabei ist u.a.
ein Courier aufgesetzt worden, der aber vor einiger Zeit an irgend einem
Detail die Mitarbeit eingestellt hat. Der Besitzer hat's an der falschen
Stelle bereinigen wollen und auf KDE 4.11.x ge-updatet.
> Das musst Du postfix nicht extra beibringen.
> Wenn postfix läuft, loggt es nach /var/log/mail.log, Fehler
> nach /var/log/mail.err, Warnungen nach /var/log/mail.warn
Das dachte ich in meinem jugendlichen Leichtsinn bisher auch, aber es
gibt kein Log dafür. Es gibt auch keine archivierten älteren.
Inzwischen habe ich in meinen Aufzeichnungen aber eine Notiz gefunden,
daß man bei SuSE 9.x logrotate nachrüsten mußte, weil das nicht zur
Standard-Installation zählte.
Evtl. ist das heute (SuSE 12.3) auch noch so. Kann ich aber erst gegen
Ende der Woche prüfen.
> Mails, die nicht ausgeliefert werden können - egal aus welchem Grund -
> wandern in Unterverzeichnisse von /var/spool/postfix. Wie lange sie dort
> verbleiben, respektive wie viele Zustellversuche unternommen werden,
> bis die Mail endgültig verworfen wird, wird in der Konfiguration
> festgelegt.
Hatte ich ja schon gesagt:
Dies gesamte Struktur fehlt.
> root@einstein:/home/uwe# /etc/init.d/postfix status
> [ ok ] postfix is running.
SuSE hat ja inzwischen systemd - lt. Runleveleditor (der in 12.3 aber
offenbar einen weg hat) laufen die Dienste. Der sytemctl-Aufruf liefert
allerdings immer wieder unklare Werte (failed). Beim zweiten oder
dritten Versuch dann aber OK
> Dann würde ich alle Postfix-Prozesse killen und versuchen ihn
> über
> /etc/init.d/postfix start
s.o.
> zu starten. Ist die Konfiguration verbogen kommen dabei in der Regel
> recht aussagekräftige Meldungen und der postfix-Start wird
> abgebrochen. Da kann man dann ansetzen.
Ich hatte den Courier runtergenommen, weil das in meinen Augen in etwa
so ist, wie wenn die "Pierre Guillaumat" ein Glas Bier
transportiert... :-) Ganz davon abgesehen, daß ich mich damit bisher
überhaupt noch nie beschäftigt habe.
Ich wollte das dann in etwa so wieder hochziehen, wie es mit Mageia bzw.
Sid einigermaßen brauchbar funktioniert (Zustellung direkt in ein
Maildir-Verzeichis im $USER/home), aber die gesamte Basis dafür spielt
irgendwie verrückt.
Am Sonntag, 1. September 2013, 09:58:32 schrieb H.-Stefan Neumeyer:
> Hallo Uwe
> Ich hole mal etwas weiter aus:
> SuSE 12.3, an der sich vor mir schon zwei andere mit den
> unterschiedlichsten Ansätzen zu schaffen gemacht haben. Dabei ist u.a.
> ein Courier aufgesetzt worden, der aber vor einiger Zeit an irgend einem
> Detail die Mitarbeit eingestellt hat. Der Besitzer hat's an der falschen
> Stelle bereinigen wollen und auf KDE 4.11.x ge-updatet.
wenn das vielleicht nur verkofiguriert ist, würde da nicht Dein alter Trick,
einen neuen User anzulegen, helfen.
Liebe Grüße
Willi
Am Sonntag, den 01.09.2013, 11:13 +0200 schrieb Willi Zelinka:
Hallo Willi
> wenn das vielleicht nur verkofiguriert ist, würde da nicht Dein alter Trick,
> einen neuen User anzulegen, helfen.
Ich habe auf der Maschine die ganze Zeit mit einem extra für mich
angelegten Account gearbeitet.
Die gesamte Problematik spielt sich aber eindeutig auf der
Systemebene ab und da bringt das nix.
Debian GNU/Linux testing ("Jessie") x86_64
Xfce 4.10.1
Evolution PIM 3.4.4
Diese e-Mail-Adresse nimmt ausschließlich Nachrichten für
Mailinglisten entgegen.
Für private Nachrichten bitte die Adresse
hsn.neumeyer[at]arcor dot de benutzen.
Dort eingehende Nachrichten, die nicht unter Nutzung von
GnuPG verschlüsselt sind, werde ich grundsätzlich nicht mehr
beachten.
H.-Stefan Neumeyer schrieb am 01.09.2013 um 09:58:
>> Das musst Du postfix nicht extra beibringen.
>> Wenn postfix läuft, loggt es nach /var/log/mail.log, Fehler
>> nach /var/log/mail.err, Warnungen nach /var/log/mail.warn
>Das dachte ich in meinem jugendlichen Leichtsinn bisher auch, aber es
>gibt kein Log dafür.
Auch das spricht dafür, dass Postfix nie wirklich lief.
>Es gibt auch keine archivierten älteren.
>Inzwischen habe ich in meinen Aufzeichnungen aber eine Notiz gefunden,
>daß man bei SuSE 9.x logrotate nachrüsten mußte, weil das nicht zur
>Standard-Installation zählte.
>Evtl. ist das heute (SuSE 12.3) auch noch so. Kann ich aber erst gegen
>Ende der Woche prüfen.
logrotate dürfte darauf keinen Einfluß haben. Das ist ja nur für das
Rotieren der Logfiles zuständig, nicht für deren Erstellung. Ohne
Logrotate wachsen die Logfiles dann halt ins Unendliche an.
>> Mails, die nicht ausgeliefert werden können - egal aus welchem Grund -
>> wandern in Unterverzeichnisse von /var/spool/postfix. Wie lange sie dort
>> verbleiben, respektive wie viele Zustellversuche unternommen werden,
>> bis die Mail endgültig verworfen wird, wird in der Konfiguration
>> festgelegt.
>Hatte ich ja schon gesagt:
>Dies gesamte Struktur fehlt.
Was steht denn in der main.cf unter queue_directory?
>Ich wollte das dann in etwa so wieder hochziehen, wie es mit Mageia bzw.
>Sid einigermaßen brauchbar funktioniert (Zustellung direkt in ein
>Maildir-Verzeichis im $USER/home), aber die gesamte Basis dafür spielt
>irgendwie verrückt.
Normalerweise liefert Postfix ja nach /var/mail/username aus und ich
glaube mich zu erinnern, dass die entsprechende Datei username erst
einmal angelegt werden muss, weil Postfix die nicht selbst anlegt.
Kannm ich aber auch täuschen. Wie man das auf das Home-Verzeichnis
verbiegt, bin ich im Moment überfragt. Müßte ich erst das dicke Postfix
Buch wälzen.
Vielleicht läßt Du Dir mittels
postconf -n
erst mal alle Parameter der main.cf auflisten, die nicht den
Default-Werten entsprechen. Eventuell ist ja da schon was zu sehen.
Mit
postconf -d
kannst Du Dir auch die Default-Werte ansehen, also so wie sie ohne die
main.cf voreingestellt wären.
Du kannst natürlich versuchen mittels strace den ganzen Postfix-Start
und die Arbeit des Daemons zu protokollieren und an Hand dessen
herausfinden wo es hakt. Da laufen aber jede Menge Daten auf und es
wird eine Zeit dauern sich da durch zu wühlen. Das wäre für mich
also die letzte Option, wenn ich mit allen anderen Versuchen der
Fehlersuche nicht weiter komme. Aber um so was zu debuggen ist strace
wirklich eine Allzweckwaffe, wenn man das Protokoll mit den
verschiedensten Parametern dann auch noch einschränken kann, siehe man
strace.
Am Sonntag, den 01.09.2013, 12:17 +0200 schrieb Uwe Herrmuth:
> Auch das spricht dafür, dass Postfix nie wirklich lief.
Das gesamte Konstrukt hat es zumindest bis zum 22.07. getan. Dann hat es
keine Mail von GMX (ProMail) und t-online (Premium) mehr abholen können
oder wollen. Zeitgleich ist auf dem Rechner auch nur noch sporadischer
Zugriff auf den IMAP möglich gewesen - und wenn, dann nur nach
unendlicher Ladezeit und die meisten Mails waren leer. Letzteres ist
IMHO ein extra Problem.
> logrotate dürfte darauf keinen Einfluß haben. Das ist ja nur für das
> Rotieren der Logfiles zuständig, nicht für deren Erstellung. Ohne
> Logrotate wachsen die Logfiles dann halt ins Unendliche an.
Einfluß nicht, aber ich dachte, daß man wenigstens ein paar archivierte
Sachen finden kann.
> Was steht denn in der main.cf unter queue_directory?
Ich versuche gerade eine SuSE 12.3 in die VirtualBox zu installieren,
scheitere aber bei der netinstall schon zum zweiten mal bei der
Installation des Kernels.
Wenn ich es doch schaffe, habe ich wenigstens erst mal eine unverhunzte
Installation.
> Normalerweise liefert Postfix ja nach /var/mail/username aus und ich
> glaube mich zu erinnern, dass die entsprechende Datei username erst
> einmal angelegt werden muss, weil Postfix die nicht selbst anlegt.
Doch, sollte angelegt werden, wenn die erste Mail aufschlägt. Passiert
jedenfalls bei Mageia, wenn ich nach der Einrichtung die erste Mail mit
dem mail-Befehl absetze um zu sehen ob der Kram läuft.
> Kannm ich aber auch täuschen. Wie man das auf das Home-Verzeichnis
> verbiegt, bin ich im Moment überfragt. Müßte ich erst das dicke Postfix
> Buch wälzen.
Bei exim kannst Du IMHO sogar in der Konfiguration ein Maildir in
$USER/home selber angeben. Habe ich aber noch nie versucht.
Ansonsten will ich einen MDA laufen lassen. Das funktioniert, mit
einigen Einschränkungen mit fetchmail - exim - procmail auf der
Sid-Kiste sogar mit KDE.
> Du kannst natürlich versuchen mittels strace den ganzen Postfix-Start
> und die Arbeit des Daemons zu protokollieren und an Hand dessen
> herausfinden wo es hakt. Da laufen aber jede Menge Daten auf und es
> wird eine Zeit dauern sich da durch zu wühlen. Das wäre für mich
> also die letzte Option, wenn ich mit allen anderen Versuchen der
> Fehlersuche nicht weiter komme. Aber um so was zu debuggen ist strace
> wirklich eine Allzweckwaffe, wenn man das Protokoll mit den
> verschiedensten Parametern dann auch noch einschränken kann, siehe man
> strace.
Wie schon gesagt - der Bekannte ist nächste Woche unterwegs - und wir
kommen vor Freitag nicht wieder zusammen.
Ich tendiere im Moment sowieso zu einer Neuinstallation, denn da scheint
viel mehr durcheinander geraten zu sein, als man als Laie wieder
sortieren kann.
Am Sonntag, 1. September 2013 schrieb Uwe Herrmuth:
> Wenn postfix läuft, loggt es nach /var/log/mail.log,
so ist es auch bei mir (zusammen mit fetchmail)
Joachim Puttkammer
http://www.puttkammer.de
Siduction - KDE 4.11.0 (mit KMail 1.13.7)
Am Samstag, den 31.08.2013, 18:27 +0200 schrieb H.-Stefan Neumeyer:
ich schleiße das nach mehreren Wochen mal ab - ohne insgesamt eine
wirkliche Lösung zu habe.
Nach der Neuinstallation auf eine leere Platte hatten wir zwar auch Logs
von postfix. Allerdings war das Verhalten dort immer wieder reichlich
merkwürdig. Einzige Veränderung am default-Setup war die die Ergänzung
in der /etc/postfix/aliases in der Zeile "Account of a human".
Zur Laufzeit kam es immer wieder vor, daß sich postfix wohl nach
kürzester Zeit von selbst beende hat. Jedenfalls deute ich so etwas
2013-09-11T20:09:18.637519+02:00 linux postfix/postfix-script[3629]:
fatal: the Postfix mail system is not running
2013-09-11T20:09:19.630037+02:00 linux-vtk7
postfix/postfix-script[2598]: starting the Postfix mail system
2013-09-11T20:09:19.850699+02:00 linux-vtk7 postfix/master[2599]: daemon
started -- version 2.9.6, configuration /etc/postfix
2013-09-11T20:09:24.876417+02:00 linux-vtk7
postfix/postfix-script[4511]: refreshing the Postfix mail system
2013-09-11T20:09:24.915300+02:00 linux-vtk7 postfix/master[2599]: reload
-- version 2.9.6, configuration /etc/postfix
2013-09-11T20:09:24.921252+02:00 linux-vtk7 postfix/master[2599]:
warning: ignoring inet_protocols parameter value change
2013-09-11T20:09:24.926251+02:00 linux-vtk7 postfix/master[2599]:
warning: old value: "all", new value: "ipv4"
2013-09-11T20:09:24.928541+02:00 linux-vtk7 postfix/master[2599]:
warning: to change inet_protocols, stop and start Postfix
2013-09-11T20:09:30.928689+02:00 linux postfix/postfix-script[3629]:
den Logs in dieser Richtung.
Ein anschließendes prüfen per systemctl-Befehl ergab dann immer ein "not
running"
Dann kommt dazu, daß es mir nicht möglich war/ist, dort bestimmte
Dienste automatisch oder per Befehl zu starten.
Der fetchmail-Daemon z.B. lief nur über die Einrichtung per Yast - und
dann lediglich für eine Adresse in der globalen fetchmailrc. Sobald ich
die editiert und um weitere Einträge ergänzt habe, wollte fetchmail
weder automatisch noch per Befehl mehr starten. dto. bei einer händisch
angelegten fetchmailrc und Startversuchen unter Umgehung der
"Mailserver-Einrichtung" in Yast.
spamd ist der nächste Kandidat. Einzige Änderung am default-Setup ist
die user_prefs in .spamassassin im §HOME.
spamassassin läßt sich aber weder im Runlevelditor (gibt unbekannten
Fehler zurück) noch per Befehl zum laufen überreden
linux-vtk7:~ # /bin/systemctl start spamd.service
Failed to issue method call: Unit spamd.service failed to load: No such
file or directory. See system logs and 'systemctl status spamd.service'
for details
Die Details, die man sich ansehen soll, sagen mir aber garnichts und ich
kann mich erinnern, daß ich im Frühjahr schon mal an dieser Stelle stand
und nicht weiter gekommen bin...
Also haben wir inzwischen beschlossen, das aufzugeben.
Die Fragen, die sich aus dem Neuanfang ergeben, stellen ich dann an
anderer Stelle.
[Impressum] [Fragen zur Web-Seite] [Fragen zu Stories] [Mission] Datenschutzerklärung | © 2014 Medialinx AG
