Postfix, amavis und uucp
Hallo. Ich habe ein Problem mit einem Mailserver: Ich empfange und versende E-Mails auf einer SUSE 10.2 mit 'postfix' und _uucp_ und möchte sie mit 'amavisd' auf Viren prüfen. Ausgehende E-Mails, die per smtp von den MUAs eingeliefert werden, werden problemlos auf Viren geprüft. Eingehende Mails, bei denen mir die Virenprüfung wichtiger wäre, gehen aber ungeprüft in die lokalen Mailboxen, da das 'rmail' aus dem uucp-Paket die eingehenden Mails nicht an postfix-smtpd gibt. Gibt es eine Möglichkeit, den 'amavisd' (oder ein ähnliches Programm) irgendwie über postfix-local zu erreichen? Oder auch eine ganz andere Lösung? Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andreas Koenecke wrote:
Hallo.
Ich habe ein Problem mit einem Mailserver: Ich empfange und versende E-Mails auf einer SUSE 10.2 mit 'postfix' und _uucp_ und möchte sie mit 'amavisd' auf Viren prüfen. Ausgehende E-Mails, die per smtp von den MUAs eingeliefert werden, werden problemlos auf Viren geprüft. Eingehende Mails, bei denen mir die Virenprüfung wichtiger wäre, gehen aber ungeprüft in die lokalen Mailboxen, da das 'rmail' aus dem uucp-Paket die eingehenden Mails nicht an postfix-smtpd gibt.
Gibt es eine Möglichkeit, den 'amavisd' (oder ein ähnliches Programm) irgendwie über postfix-local zu erreichen? Oder auch eine ganz andere Lösung?
Bisher habe ich noch keine UUCP-Lösung aufgesetzt. Wenn die Mails Postfix gar nicht erst erreichen, kann Postfix/Amavisd-new natürlich nichts mehr machen. Wie sieht denn der Aufruf von rmail aus? -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Sandy, Am Dienstag, 24. April 2007 schrieb Sandy Drobic:
Andreas Koenecke wrote:
Ich habe ein Problem mit einem Mailserver: Ich empfange und versende E-Mails auf einer SUSE 10.2 mit 'postfix' und _uucp_ und möchte sie mit 'amavisd' auf Viren prüfen. Ausgehende E-Mails, die per smtp von den MUAs eingeliefert werden, werden problemlos auf Viren geprüft. Eingehende Mails, bei denen mir die Virenprüfung wichtiger wäre, gehen aber ungeprüft in die lokalen Mailboxen, da das 'rmail' aus dem uucp-Paket die eingehenden Mails nicht an postfix-smtpd gibt.
Gibt es eine Möglichkeit, den 'amavisd' (oder ein ähnliches Programm) irgendwie über postfix-local zu erreichen? Oder auch eine ganz andere Lösung?
Bisher habe ich noch keine UUCP-Lösung aufgesetzt. Wenn die Mails Postfix gar nicht erst erreichen, kann Postfix/Amavisd-new natürlich nichts mehr machen.
Wie sieht denn der Aufruf von rmail aus?
Sie erreichen Postfix schon, nur wenn du die innere Warteschlange mit dem amavis beglückst wird der Kram schlimmstenfalls ewig im Kreis gescannt. Weil nach dem wiedereinliefern durch amavis würde das spiel mglw. von vorne beginnen. ich hab das jedenfalls nie hinbekommen das ich dem rmail vom uucp irgendwie eine content_filter Bedingung mitgeben konnte. Die einfachste und konfigurationstechnisch übersichtlichste Lösung ist das abholende uucp auf einer anderen kiste laufen zu lassen oder notfalls gegen eine separate Postfix instanz auf der gleichen kiste die es dann per smtp weiter gibt. Das hat außerdem den vorteil das man saubere smtp Kanäle haben kann mit unterschiedlichen content_filtern die internen und externen Traffic getrennt handeln. Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo. * Dienstag, 24. April 2007 um 13:25 (+0200) schrieb Falk Sauer:
Die einfachste und konfigurationstechnisch übersichtlichste Lösung ist das abholende uucp auf einer anderen kiste laufen zu lassen oder notfalls gegen eine separate Postfix instanz auf der gleichen kiste die es dann per smtp weiter gibt. Das hat außerdem den vorteil das man saubere smtp Kanäle haben kann mit unterschiedlichen content_filtern die internen und externen Traffic getrennt handeln.
Das hört sich gut an, obwohl ich befürchte, daß "einfach" in diesem Fall relativ ist... ;-) Wie müsste denn die existierende Postfix-Konfiguration abgeändert werden und wie sähe denn die Konfiguration einer zweiten Postfix-Instanz aus. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Andreas, Am Dienstag, 24. April 2007 schrieb Andreas Koenecke:
Das hört sich gut an, obwohl ich befürchte, daß "einfach" in diesem Fall relativ ist... ;-)
Wie müsste denn die existierende Postfix-Konfiguration abgeändert werden
ganz einfach, dein lokaler DNS hat einen MX für dein lokales Netz, deinen neuen uucp kasten nimmst du da raus - sprich er kriegt einen eigenen MX der auf sich selber zeigt. Dann konfigurierst du ihm einen smart host mit der entsprechenden smtp queue auf der Empfängerseite. Und dann legst du noch das uucp auf den kasten und gut. Wenn das zu schnell/kurz war such ich dir die wesentlichen Teile raus, kann aber dauern.
und wie sähe denn die Konfiguration einer zweiten Postfix-Instanz aus.
hab ich mir bisher erfolgreich gekniffen, läuft aber auf ein chroot jail hinaus. Macht mit Sicherheit viel mehr Arbeit als die andere Lösung. Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Falk. * Dienstag, 24. April 2007 um 14:54 (+0200) schrieb Falk Sauer:
Am Dienstag, 24. April 2007 schrieb Andreas Koenecke:
Das hört sich gut an, obwohl ich befürchte, daß "einfach" in diesem Fall relativ ist... ;-)
ganz einfach,
Ich habe gewusst, dass du das schreiben würdest... ;-)
dein lokaler DNS hat einen MX für dein lokales Netz, deinen neuen uucp kasten nimmst du da raus - sprich er kriegt einen eigenen MX der auf sich selber zeigt. Dann konfigurierst du ihm einen smart host mit der entsprechenden smtp queue auf der Empfängerseite. Und dann legst du noch das uucp auf den kasten und gut. Wenn das zu schnell/kurz war such ich dir die wesentlichen Teile raus, kann aber dauern.
Warte erst einmal, wenn Sandys Lösung funktioniert, dann wäre das IMO am einfachsten. Trotzdem schon mal vielen Dank für den Lösungsvorschlag.
und wie sähe denn die Konfiguration einer zweiten Postfix-Instanz aus.
hab ich mir bisher erfolgreich gekniffen, läuft aber auf ein chroot jail hinaus. Macht mit Sicherheit viel mehr Arbeit als die andere Lösung.
Dann ist das gestorben. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andreas Koenecke wrote:
Hallo Falk.
* Dienstag, 24. April 2007 um 14:54 (+0200) schrieb Falk Sauer:
Am Dienstag, 24. April 2007 schrieb Andreas Koenecke:
Das hört sich gut an, obwohl ich befürchte, daß "einfach" in diesem Fall relativ ist... ;-)
ganz einfach,
Ich habe gewusst, dass du das schreiben würdest... ;-)
Okay, einfach ist in diesem Fall wirklich relativ. Es ist sehr selten, dass man pickup mit einem content_filter verziert. Dass dies überhaupt möglich ist, wissen die meisten gar nicht. Von da her ist das nicht unbedingt eine Standard-Lösung für ein Standard-Problem. (^-^)
dein lokaler DNS hat einen MX für dein lokales Netz, deinen neuen uucp kasten nimmst du da raus - sprich er kriegt einen eigenen MX der auf sich selber zeigt. Dann konfigurierst du ihm einen smart host mit der entsprechenden smtp queue auf der Empfängerseite. Und dann legst du noch das uucp auf den kasten und gut. Wenn das zu schnell/kurz war such ich dir die wesentlichen Teile raus, kann aber dauern.
Warte erst einmal, wenn Sandys Lösung funktioniert, dann wäre das IMO am einfachsten. Trotzdem schon mal vielen Dank für den Lösungsvorschlag.
und wie sähe denn die Konfiguration einer zweiten Postfix-Instanz aus. hab ich mir bisher erfolgreich gekniffen, läuft aber auf ein chroot jail hinaus. Macht mit Sicherheit viel mehr Arbeit als die andere Lösung.
Eine zweite Postfix-Instanz kann manchmal sehr interessant sein, vor allem, wenn man die Mail sehr differenziert je nach Domain/Client usw. behandeln möchte. Aber der Aufwand, das KORREKT aufzusetzen, sollte wirklich nicht unterschätzt werden. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo. * Dienstag, 24. April 2007 um 13:03 (+0200) schrieb Sandy Drobic:
Ich empfange und versende E-Mails auf einer SUSE 10.2 mit 'postfix' und _uucp_ und möchte sie mit 'amavisd' auf Viren prüfen. Ausgehende E-Mails, die per smtp von den MUAs eingeliefert werden, werden problemlos auf Viren geprüft. Eingehende Mails, bei denen mir die Virenprüfung wichtiger wäre, gehen aber ungeprüft in die lokalen Mailboxen, da das 'rmail' aus dem uucp-Paket die eingehenden Mails nicht an postfix-smtpd gibt.
Gibt es eine Möglichkeit, den 'amavisd' (oder ein ähnliches Programm) irgendwie über postfix-local zu erreichen? Oder auch eine ganz andere Lösung?
Bisher habe ich noch keine UUCP-Lösung aufgesetzt. Wenn die Mails Postfix gar nicht erst erreichen, kann Postfix/Amavisd-new natürlich nichts mehr machen.
Wie sieht denn der Aufruf von rmail aus?
Hm, die Frage ist nicht einfach zu beantworten, da ich das selbst nicht
durchschaue.
Hier mal ein Auszug aus der man-page von rmail:
------------------------------------------------------------------------
NAME
rmail - handle remote mail received via uucp
SYNOPSIS
rmail [-D domain] [-T] user ...
DESCRIPTION
Rmail interprets incoming mail received via uucp(1), collapsing
``From'' lines in the form generated by mail.local(8) into a single
line of the form
``return-path!sender'', and passing the processed mail on to
sendmail(8).
Rmail is explicitly designed for use with uucp and sendmail.
Flags
-D Use the specified domain instead of the default domain of
``UUCP''.
-T Turn on debugging.
-------------------------------------------------------------------------
Und noch ein "Durchlauf" einer eingehenden Mail aus "/var/log/mail:
-------------------------------------------------------------------------
Apr 24 14:00:22 PinguinII postfix/pickup[24687]: E524521956A: uid=10
from=<MAILER-DAEMON>
Apr 24 14:00:22 PinguinII postfix/cleanup[24819]: E524521956A:
message-id=<200704241150.l3O9U6dK010092@server20.firstfind.nl>
Apr 24 14:00:23 PinguinII postfix/qmgr[14492]: E524521956A: from=<>,
size=3873, nrcpt=1 (queue active)
Apr 24 14:00:23 PinguinII postfix/local[24825]: E524521956A:
to=
Andreas Koenecke wrote:
Hallo.
* Dienstag, 24. April 2007 um 13:03 (+0200) schrieb Sandy Drobic:
Ich empfange und versende E-Mails auf einer SUSE 10.2 mit 'postfix' und _uucp_ und möchte sie mit 'amavisd' auf Viren prüfen. Ausgehende E-Mails, die per smtp von den MUAs eingeliefert werden, werden problemlos auf Viren geprüft. Eingehende Mails, bei denen mir die Virenprüfung wichtiger wäre, gehen aber ungeprüft in die lokalen Mailboxen, da das 'rmail' aus dem uucp-Paket die eingehenden Mails nicht an postfix-smtpd gibt.
Gibt es eine Möglichkeit, den 'amavisd' (oder ein ähnliches Programm) irgendwie über postfix-local zu erreichen? Oder auch eine ganz andere Lösung? Bisher habe ich noch keine UUCP-Lösung aufgesetzt. Wenn die Mails Postfix gar nicht erst erreichen, kann Postfix/Amavisd-new natürlich nichts mehr machen.
Wie sieht denn der Aufruf von rmail aus?
Hm, die Frage ist nicht einfach zu beantworten, da ich das selbst nicht durchschaue. Hier mal ein Auszug aus der man-page von rmail:
------------------------------------------------------------------------ NAME rmail - handle remote mail received via uucp
SYNOPSIS rmail [-D domain] [-T] user ...
DESCRIPTION Rmail interprets incoming mail received via uucp(1), collapsing ``From'' lines in the form generated by mail.local(8) into a single line of the form ``return-path!sender'', and passing the processed mail on to sendmail(8).
Rmail is explicitly designed for use with uucp and sendmail.
Flags -D Use the specified domain instead of the default domain of ``UUCP''.
-T Turn on debugging. -------------------------------------------------------------------------
Und noch ein "Durchlauf" einer eingehenden Mail aus "/var/log/mail:
------------------------------------------------------------------------- Apr 24 14:00:22 PinguinII postfix/pickup[24687]: E524521956A: uid=10 from=<MAILER-DAEMON>
Okay, alles klar. rmail liefert die Mail über das Kommandozeilen-Binary /usr/sbin/sendmail ein. Das zeigt die Zeile mit "pickup". Die Lösung ist damit recht einfach: Ändere in /etc/postfix/master.cf folgende Zeile ab: #von: pickup fifo n - n 60 1 pickup #nach: pickup fifo n - n 60 1 pickup -o content_filter=smtp-amavis:[127.0.0.1]:10024 Beachte bitte das die Einrückung mit Tab oder Leerzeichen am Anfang der content_filter-Zeile. Führe danach ein "postfix reload" aus und schaue ins Log, ob es Meldungen bezüglich Schreibfehler gibt. Wenn nicht, werden künftig die Mails über Amavis gescannt. Dabei dürfte es auch nicht zu einer Mailschleife kommen, da die Rücksendung normalerweise auf einen Port von Postfix geschieht, der den content_filter explizit abgeschaltet hat. Poste doch sicherheitshalber mal die /etc/postfix/master.cf. Poste bitte auch mal die Ausgabe von "postconf -n", dort können auch globale Filter angegeben werden. Caveat: Damit werden alle Mails gescannt, die über die Kommandozeile gehen, also auch die von cron und Konsorten geschickten. Dies lässt sich leider nicht auseinandertrennen. Wenn du andere Filter hast, welche die Mails über /usr/sbin/sendmail einliefern, könnte es passieren, dass sie durch den Filter von amavis gekapert werden. Ein Blick in die master.cf sollte das klären. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Sandy. * Dienstag, 24. April 2007 um 19:17 (+0200) schrieb Sandy Drobic:
Andreas Koenecke wrote:
-------------------------------------------------------------------------
Und noch ein "Durchlauf" einer eingehenden Mail aus "/var/log/mail:
------------------------------------------------------------------------- Apr 24 14:00:22 PinguinII postfix/pickup[24687]: E524521956A: uid=10 from=<MAILER-DAEMON>
Okay, alles klar. rmail liefert die Mail über das Kommandozeilen-Binary /usr/sbin/sendmail ein. Das zeigt die Zeile mit "pickup".
Die Lösung ist damit recht einfach:
Ändere in /etc/postfix/master.cf folgende Zeile ab:
#von: pickup fifo n - n 60 1 pickup
#nach: pickup fifo n - n 60 1 pickup -o content_filter=smtp-amavis:[127.0.0.1]:10024
Beachte bitte das die Einrückung mit Tab oder Leerzeichen am Anfang der content_filter-Zeile.
Führe danach ein "postfix reload" aus und schaue ins Log, ob es Meldungen bezüglich Schreibfehler gibt. Wenn nicht, werden künftig die Mails über Amavis gescannt.
OK, das wäre eine Lösung, die ich auch als "einfach" bezeichnen würde. Wenn es funktioniert, haben Falk und du ein Getränk bei mir frei...
Dabei dürfte es auch nicht zu einer Mailschleife kommen, da die Rücksendung normalerweise auf einen Port von Postfix geschieht, der den content_filter explizit abgeschaltet hat.
Poste doch sicherheitshalber mal die /etc/postfix/master.cf. Poste bitte auch mal die Ausgabe von "postconf -n", dort können auch globale Filter angegeben werden.
Siehe unten.
Caveat: Damit werden alle Mails gescannt, die über die Kommandozeile gehen, also auch die von cron und Konsorten geschickten. Dies lässt sich leider nicht auseinandertrennen.
Das wäre kein Problem.
Wenn du andere Filter hast, welche die Mails über /usr/sbin/sendmail einliefern, könnte es passieren, dass sie durch den Filter von amavis gekapert werden. Ein Blick in die master.cf sollte das klären.
OK, hier die master.cf: ------------------------------------------------------------------------ # # Postfix master process configuration file. For details on the format # of the file, see the Postfix master(5) manual page. # # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n - n - 10 smtpd -o content_filter=smtp:[127.0.0.1]:10024 #submission inet n - n - - smtpd # -o smtpd_etrn_restrictions=reject # -o smtpd_client_restrictions=permit_sasl_authenticated,reject #smtps inet n - n - 2 smtpd -o smtpd_tls_wrappermode=yes -o content_filter=smtp:[127.0.0.1]:10024 # -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes #submission inet n - n - - smtpd # -o smtpd_etrn_restrictions=reject # -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes #628 inet n - n - - qmqpd pickup fifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr #qmgr fifo n - n 300 1 oqmgr #tlsmgr unix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap smtp unix - - n - - smtp # When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix - - n - - smtp -o fallback_relay= # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n - n - - showq error unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil localhost:10025 inet n - n - - smtpd -o content_filter= -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks scache unix - - n - 1 scache # # ==================================================================== # Interfaces to non-Postfix software. Be sure to examine the manual # pages of the non-Postfix software to find out what options it wants. # # Many of the following services use the Postfix pipe(8) delivery # agent. See the pipe(8) man page for information about ${recipient} # and other message envelope options. # ==================================================================== # # maildrop. See the Postfix MAILDROP_README file for details. # Also specify in main.cf: maildrop_destination_recipient_limit=1 # maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient} cyrus unix - n n - - pipe user=cyrus argv=/usr/lib/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user} uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient) ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix - n n - - pipe flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient procmail unix - n n - - pipe flags=R user=nobody argv=/usr/bin/procmail -t -m /etc/procmailrc ${sender} ${recipient} ------------------------------------------------------------------------------ und die Ausgabe von 'postconf -n': ------------------------------------------------------------------------------ alias_maps = hash:/etc/aliases biff = no canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix debug_peer_level = 2 default_transport = uucp:shuttle defer_transports = disable_dns_lookups = no disable_mime_output_conversion = no html_directory = /usr/share/doc/packages/postfix/html inet_interfaces = 127.0.0.1 192.168.100.200 192.168.0.101 inet_protocols = all mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = (BTW: Bei meiner 10.0 steht hier "mailbox_command=/usr/bin/procmail" Bedeutet das leere "mailbox_command", dass 'procmail' nicht benutzt wird?) mailbox_size_limit = 0 mailbox_transport = mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = meine.mail.domain masquerade_exceptions = root message_size_limit = 10240000 mydestination = $myhostname,$mydomain,localhost.$mydomain,meine.mail.domain myhostname = pinguinii.meine-interne.domain mynetworks_style = subnet newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix/README_FILES relocated_maps = hash:/etc/postfix/relocated sample_directory = /usr/share/doc/packages/postfix/samples sender_canonical_maps = ldap:/etc/postfix/ldap-sender_canonical.cf sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_sasl_auth_enable = no smtp_use_tls = no smtpd_client_restrictions = smtpd_helo_required = no smtpd_helo_restrictions = smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination smtpd_sasl_auth_enable = no smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_use_tls = no strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_domains = hash:/etc/postfix/virtual virtual_alias_maps = hash:/etc/postfix/virtual ----------------------------------------------------------------------- Bevor ich deinen Vorschlag am "lebenden" System ausprobiere, wäre es gut, wenn du mal einen Blick auf die Ausgaben werfen würdest... Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andreas Koenecke wrote:
Hallo Sandy.
* Dienstag, 24. April 2007 um 19:17 (+0200) schrieb Sandy Drobic:
Andreas Koenecke wrote:
-------------------------------------------------------------------------
Und noch ein "Durchlauf" einer eingehenden Mail aus "/var/log/mail:
------------------------------------------------------------------------- Apr 24 14:00:22 PinguinII postfix/pickup[24687]: E524521956A: uid=10 from=<MAILER-DAEMON> Okay, alles klar. rmail liefert die Mail über das Kommandozeilen-Binary /usr/sbin/sendmail ein. Das zeigt die Zeile mit "pickup".
Die Lösung ist damit recht einfach:
Ändere in /etc/postfix/master.cf folgende Zeile ab:
#von: pickup fifo n - n 60 1 pickup
#nach: pickup fifo n - n 60 1 pickup -o content_filter=smtp-amavis:[127.0.0.1]:10024
Beachte bitte das die Einrückung mit Tab oder Leerzeichen am Anfang der content_filter-Zeile.
Führe danach ein "postfix reload" aus und schaue ins Log, ob es Meldungen bezüglich Schreibfehler gibt. Wenn nicht, werden künftig die Mails über Amavis gescannt.
OK, das wäre eine Lösung, die ich auch als "einfach" bezeichnen würde. Wenn es funktioniert, haben Falk und du ein Getränk bei mir frei...
Sollte funktionieren. Ich habe es gerade bei mir noch einmal getestet. Du kannst als Test einfach eine Mail von der Kommandozeile schicken. echo "test"|mail user@deine-domain.de Dann siehst du in /var/log/mail, wie die Mail durch Amavis wandert. Wie gesagt, auch alle anderen Mails von der Kommandozeile wandern dann durch Amavis. Gerade, wenn das von Cron generierte Berichte über Spams sind, können diese dann auch als Spam klassifiziert werden. Das sind dann die Nebenwirkungen. (^-°)
Dabei dürfte es auch nicht zu einer Mailschleife kommen, da die Rücksendung normalerweise auf einen Port von Postfix geschieht, der den content_filter explizit abgeschaltet hat.
Poste doch sicherheitshalber mal die /etc/postfix/master.cf. Poste bitte auch mal die Ausgabe von "postconf -n", dort können auch globale Filter angegeben werden.
Siehe unten.
Caveat: Damit werden alle Mails gescannt, die über die Kommandozeile gehen, also auch die von cron und Konsorten geschickten. Dies lässt sich leider nicht auseinandertrennen.
Das wäre kein Problem.
Dann kannst du das testen wie oben erwähnt.
Wenn du andere Filter hast, welche die Mails über /usr/sbin/sendmail einliefern, könnte es passieren, dass sie durch den Filter von amavis gekapert werden. Ein Blick in die master.cf sollte das klären.
OK, hier die master.cf: ------------------------------------------------------------------------ # # Postfix master process configuration file. For details on the format # of the file, see the Postfix master(5) manual page. # # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n - n - 10 smtpd -o content_filter=smtp:[127.0.0.1]:10024 #submission inet n - n - - smtpd # -o smtpd_etrn_restrictions=reject # -o smtpd_client_restrictions=permit_sasl_authenticated,reject #smtps inet n - n - 2 smtpd -o smtpd_tls_wrappermode=yes -o content_filter=smtp:[127.0.0.1]:10024
Das hier ist nur der Umbruch durch die Mail, nicht wahr? diese Zeile sollte auskommentiert sein.
#submission inet n - n - - smtpd # -o smtpd_etrn_restrictions=reject # -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes #628 inet n - n - - qmqpd pickup fifo n - n 60 1 pickup -o content_filter=smtp:[127.0.0.1]:10024
Hier gehört dann die Ergänzung rein.
cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr #qmgr fifo n - n 300 1 oqmgr #tlsmgr unix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap smtp unix - - n - - smtp # When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix - - n - - smtp -o fallback_relay= # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n - n - - showq error unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil localhost:10025 inet n - n - - smtpd -o content_filter= -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
Sehr schön, dann sollte es keine Probleme geben.
und die Ausgabe von 'postconf -n': ------------------------------------------------------------------------------ alias_maps = hash:/etc/aliases biff = no canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix debug_peer_level = 2 default_transport = uucp:shuttle defer_transports = disable_dns_lookups = no disable_mime_output_conversion = no html_directory = /usr/share/doc/packages/postfix/html inet_interfaces = 127.0.0.1 192.168.100.200 192.168.0.101
Das sind die (lokalen) IP-Adressen, auf denen Postfix lauscht. Am einfachsten ist es, hier zu setzen: inet_interfaces = all Dies ist auch Default. Dies sind nicht die IP-Adressen, welche berechtigt sind, Mails einzuliefern. Dies wird in mynetworks festgelegt.
inet_protocols = all mail_owner = postfix mail_spool_directory = /var/mail mailbox_command =
(BTW: Bei meiner 10.0 steht hier "mailbox_command=/usr/bin/procmail" Bedeutet das leere "mailbox_command", dass 'procmail' nicht benutzt wird?)
So ist es. Als Default wird die Mail dann von dem Local Delivery Agent (LDA) "local" abgelegt. Dieser legt sie dann ab unter /var/spool/mail/username.
mailbox_size_limit = 0 mailbox_transport = mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = meine.mail.domain masquerade_exceptions = root message_size_limit = 10240000 mydestination = $myhostname,$mydomain,localhost.$mydomain,meine.mail.domain myhostname = pinguinii.meine-interne.domain mynetworks_style = subnet
Okay, das gibt dem lokalen Netzwerk das Recht, den Server zum Relayen zu verwenden. Ich nehme an, du hast ein lokales Netzwerk?
newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix/README_FILES relocated_maps = hash:/etc/postfix/relocated sample_directory = /usr/share/doc/packages/postfix/samples sender_canonical_maps = ldap:/etc/postfix/ldap-sender_canonical.cf sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_sasl_auth_enable = no smtp_use_tls = no smtpd_client_restrictions = smtpd_helo_required = no smtpd_helo_restrictions = smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination smtpd_sasl_auth_enable = no smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_use_tls = no strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_domains = hash:/etc/postfix/virtual virtual_alias_maps = hash:/etc/postfix/virtual -----------------------------------------------------------------------
Bevor ich deinen Vorschlag am "lebenden" System ausprobiere, wäre es gut, wenn du mal einen Blick auf die Ausgaben werfen würdest...
Sieht gut aus. Teste es mal. Ändere die master.cf und führe "postfix reload" aus wie beschrieben. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Sandy. * Dienstag, 24. April 2007 um 20:13 (+0200) schrieb Sandy Drobic:
Andreas Koenecke wrote:
OK, das wäre eine Lösung, die ich auch als "einfach" bezeichnen würde. Wenn es funktioniert, haben Falk und du ein Getränk bei mir frei...
Sollte funktionieren. Ich habe es gerade bei mir noch einmal getestet. Du kannst als Test einfach eine Mail von der Kommandozeile schicken.
echo "test"|mail user@deine-domain.de
Dann siehst du in /var/log/mail, wie die Mail durch Amavis wandert.
Ich habe es gerade ausprobiert und es funktioniert! Danke. Das hat mir seit gestern nachmittag keine Ruhe gelassen...
Wie gesagt, auch alle anderen Mails von der Kommandozeile wandern dann durch Amavis. Gerade, wenn das von Cron generierte Berichte über Spams sind, können diese dann auch als Spam klassifiziert werden.
Das sollte eigentlich nicht vorkommen.
Das sind dann die Nebenwirkungen. (^-°)
Ich weiß ja, wo ich "Arzt oder Apotheker" finde. ;-)
smtpd_tls_wrappermode=yes -o content_filter=smtp:[127.0.0.1]:10024
Das hier ist nur der Umbruch durch die Mail, nicht wahr? diese Zeile sollte auskommentiert sein.
Ja, nur ein Zeilenumbruch in der Mail.
inet_interfaces = 127.0.0.1 192.168.100.200 192.168.0.101
Das sind die (lokalen) IP-Adressen, auf denen Postfix lauscht. Am einfachsten ist es, hier zu setzen:
inet_interfaces = all
Der Rechner hat auch noch einen DSL-Zugang (Ja, ich weiss, soll man nicht machen, aber...) und an dem soll der 'postfix' nicht lauschen.
mailbox_command =
(BTW: Bei meiner 10.0 steht hier "mailbox_command=/usr/bin/procmail" Bedeutet das leere "mailbox_command", dass 'procmail' nicht benutzt wird?)
So ist es. Als Default wird die Mail dann von dem Local Delivery Agent (LDA) "local" abgelegt. Dieser legt sie dann ab unter /var/spool/mail/username.
Ich habe jetzt 'procmail' eingesetzt. Ich benuzte 'procmail' aber nur zum Sortieren.
mynetworks_style = subnet
Okay, das gibt dem lokalen Netzwerk das Recht, den Server zum Relayen zu verwenden. Ich nehme an, du hast ein lokales Netzwerk?
Ja. Nochmal vielen Dank. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Andreas Am Dienstag, 24. April 2007 schrieb Andreas Koenecke:
* Dienstag, 24. April 2007 um 19:17 (+0200) schrieb Sandy Drobic:
Wenn du andere Filter hast, welche die Mails über /usr/sbin/sendmail einliefern, könnte es passieren, dass sie durch den Filter von amavis gekapert werden. Ein Blick in die master.cf sollte das klären.
Das war immer mein Problem, wenn man es schon dem rmail mitgeben könnte wäre es eine saubere Sache, aber so bleibt die Gefahr das man sich später ungewollt ins knie schiesst wenn man vergessen hat was man warum genau so gemacht hat.
OK, hier die master.cf: ------------------------------------------------------------------------
localhost:10025 inet n - n - - smtpd -o content_filter= -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks scache unix - - n - 1 scache
hier ist afaik nix dabei was über pickup zurück kommt.
---
und die Ausgabe von 'postconf -n': mailbox_command =
(BTW: Bei meiner 10.0 steht hier "mailbox_command=/usr/bin/procmail" Bedeutet das leere "mailbox_command", dass 'procmail' nicht benutzt wird?)
imho ja
Bevor ich deinen Vorschlag am "lebenden" System ausprobiere, wäre es gut, wenn du mal einen Blick auf die Ausgaben werfen würdest...
bei dir könnte sandys Lösung funktionieren, es sei denn du baust noch ein paar wilde procmail Sachen ein die per sendmail zurück kommen. procmail habe ich als content_filter drin, bei ganz bestimmten smtp Kanälen, die andere Möglichkeit ist, es dem deliver vorzuschalten, dann kannst du den local-deliver aufruf direkt ins procmailrc rein packen, spart einmal hin und zurück. Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Falk Sauer wrote:
Hi Andreas
Am Dienstag, 24. April 2007 schrieb Andreas Koenecke:
* Dienstag, 24. April 2007 um 19:17 (+0200) schrieb Sandy Drobic:
Wenn du andere Filter hast, welche die Mails über /usr/sbin/sendmail einliefern, könnte es passieren, dass sie durch den Filter von amavis gekapert werden. Ein Blick in die master.cf sollte das klären.
Das war immer mein Problem, wenn man es schon dem rmail mitgeben könnte wäre es eine saubere Sache, aber so bleibt die Gefahr das man sich später ungewollt ins knie schiesst wenn man vergessen hat was man warum genau so gemacht hat.
OK, hier die master.cf: ------------------------------------------------------------------------
localhost:10025 inet n - n - - smtpd -o content_filter= -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks scache unix - - n - 1 scache
hier ist afaik nix dabei was über pickup zurück kommt.
So ist es, in der Regel verwenden nur die Pipe-Transporte /usr/sbin/sendmail für den Rücktransport nach Postfix.
---
und die Ausgabe von 'postconf -n': mailbox_command =
(BTW: Bei meiner 10.0 steht hier "mailbox_command=/usr/bin/procmail" Bedeutet das leere "mailbox_command", dass 'procmail' nicht benutzt wird?)
imho ja
Bevor ich deinen Vorschlag am "lebenden" System ausprobiere, wäre es gut, wenn du mal einen Blick auf die Ausgaben werfen würdest...
bei dir könnte sandys Lösung funktionieren, es sei denn du baust noch ein paar wilde procmail Sachen ein die per sendmail zurück kommen.
procmail habe ich als content_filter drin, bei ganz bestimmten smtp Kanälen, die andere Möglichkeit ist, es dem deliver vorzuschalten, dann kannst du den local-deliver aufruf direkt ins procmailrc rein packen, spart einmal hin und zurück.
Hast du Procmail wirklich als content_filter drin oder nur als Local Delivery Agent? Letzteres wäre dann über mailbox_transport oder mailbox_command. Der content_filter wäre dann in der master.cf gesetzt oder global als content_filter in main.cf. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Sandy Am Dienstag, 24. April 2007 schrieb Sandy Drobic:
Hast du Procmail wirklich als content_filter drin oder nur als Local Delivery Agent?
sowohl als auch, es ist mehr als eine Kiste die ich streicheln muß.
Letzteres wäre dann über mailbox_transport oder mailbox_command. Der content_filter wäre dann in der master.cf gesetzt oder global als content_filter in main.cf.
das ist einer davon, der kommt nach einem virenscanner .. localhost:smtp-backdoor inet n - y - - smtpd -o content_filter=procmail:filter # einwurfschlitz fuer virenscanner procmail unix - n n - - pipe flags=R user=nobody argv=/usr/bin/procmail -t -m /etc/procmailrc-v1 ${sender} ${recipient} is ne schlimme Konfig, aber geht prima, die wird auch schon seit Jahren immer wieder hingedreht. ;-) Damit werden bestimmte Sachen sofort nach dem scanner behandelt, spart Aufwand. Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Falk. * Dienstag, 24. April 2007 um 20:21 (+0200) schrieb Falk Sauer:
bei dir könnte sandys Lösung funktionieren, es sei denn du baust noch ein paar wilde procmail Sachen ein die per sendmail zurück kommen.
Nein, das mache ich mit ziemlicher Sicherheit nicht, bestenfall ein bisschen sortieren.
procmail habe ich als content_filter drin, bei ganz bestimmten smtp Kanälen, die andere Möglichkeit ist, es dem deliver vorzuschalten, dann kannst du den local-deliver aufruf direkt ins procmailrc rein packen, spart einmal hin und zurück.
Äh, "einfach"? :-) Vielen Dank für die Hilfe. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo. (Ich erweitere mal den alten Thread, weil es sich um den gleichen Rechner mit dem im alten Thread genannten (Postfix-)Setup handelt.) Für die, die den Thread (verständlicherweise) nicht mehr "auf dem Schirm haben": Ich habe einen Mail-Server (Opensuse 10.2), der die Mails per UUCP von einem Provider abholt und mit Postfix an die lokalen Benutzer verteilt. UUCP benutzt ein Programm 'rmail', welches wiederum über das (Postfix-)sendmail-Binary die Mails an Postfix übergibt, wo sie dann "weiterverarbeitet" werden. So weit, so gut, es funktioniert im Allgemeinen... Das Problem sind per UUCP eingehende Mails, die das "message_size_limit" (und vermutlich das "mailbox_size_limit") überschreiten: Für diese nicht zustellbaren Mails werden keine "Nicht zustellbar"-Mails (Bounces?) an den Sender erzeugt. In "/var/log/mail" erscheinen lediglich die Meldungen Jul 22 11:02:10 PinguinII postfix/postdrop[2460]: warning: uid=10: File too large Jul 22 13:02:10 PinguinII postfix/sendmail[2459]: fatal: sender@sender.domain(10): message file too big (uid 10 ist uucp). UUCP versucht anschließend die Mail mit folgender Meldung immer wieder an Postfix zu übergeben: uuxqt shuttle uucp (2007-07-22 13:02:10.58 2571) Executing X.shuttleC41DH (rmail empfänger@empfänger.domain) uuxqt shuttle uucp (2007-07-22 13:02:10.99 2571) ERROR: Execution: Exit status 75 uuxqt shuttle uucp (2007-07-22 13:02:10.99 2571) Will retry later (X.shuttleC41DH) Wie kann ich Postfix konfigurieren, dass die Mails erst einmal angenommen werden und dann mit einer "Nicht zustellbar"-Mail an den Sender verworfen werden? Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andreas Koenecke wrote:
Hallo.
(Ich erweitere mal den alten Thread, weil es sich um den gleichen Rechner mit dem im alten Thread genannten (Postfix-)Setup handelt.)
Für die, die den Thread (verständlicherweise) nicht mehr "auf dem Schirm haben": Ich habe einen Mail-Server (Opensuse 10.2), der die Mails per UUCP von einem Provider abholt und mit Postfix an die lokalen Benutzer verteilt. UUCP benutzt ein Programm 'rmail', welches wiederum über das (Postfix-)sendmail-Binary die Mails an Postfix übergibt, wo sie dann "weiterverarbeitet" werden. So weit, so gut, es funktioniert im Allgemeinen...
Das Problem sind per UUCP eingehende Mails, die das "message_size_limit" (und vermutlich das "mailbox_size_limit") überschreiten: Für diese nicht zustellbaren Mails werden keine "Nicht zustellbar"-Mails (Bounces?) an den Sender erzeugt. In "/var/log/mail" erscheinen lediglich die Meldungen Jul 22 11:02:10 PinguinII postfix/postdrop[2460]: warning: uid=10: File too large Jul 22 13:02:10 PinguinII postfix/sendmail[2459]: fatal: sender@sender.domain(10): message file too big
(uid 10 ist uucp).
UUCP versucht anschließend die Mail mit folgender Meldung immer wieder an Postfix zu übergeben: uuxqt shuttle uucp (2007-07-22 13:02:10.58 2571) Executing X.shuttleC41DH (rmail empfänger@empfänger.domain) uuxqt shuttle uucp (2007-07-22 13:02:10.99 2571) ERROR: Execution: Exit status 75 uuxqt shuttle uucp (2007-07-22 13:02:10.99 2571) Will retry later (X.shuttleC41DH)
Wie kann ich Postfix konfigurieren, dass die Mails erst einmal angenommen werden und dann mit einer "Nicht zustellbar"-Mail an den Sender verworfen werden?
Gibt es eine Möglichkeit, dieses anachronistische Modell mit UUCP in Rente zu schicken? Das würde eine Menge Probleme lösen. IIRC ist UUCP auch kein Postfix-Paket, sondern 3rd-Party-Software. Deshalb wird es schwierig, dafür eine Lösung zu finden. Postfix ist auf SMTP abgestimmt. In deinem Fall ist die Mail bereits auf dem System, wird jedoch von Postfix abgewiesen und UUCP bleibt stur dabei, die Mail weiterhin nach Postfix einzuliefern. Mit einfachen Mitteln sehe ich keine Lösung. Sorry. :-( -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hall Sandy. * Sonntag, 22. Juli 2007 um 15:43 (+0200) schrieb Sandy Drobic:
Andreas Koenecke wrote:
Gibt es eine Möglichkeit, dieses anachronistische Modell mit UUCP in Rente zu schicken? Das würde eine Menge Probleme lösen.
Naja, die Alternative wäre eine Multidrop-POP3-Mailbox. IMHO noch mehr Probleme. Und sofern z.B. 'fetchmail' keine Bounce-Mails erzeugt, dieses Problem ebenfalls. Selbst die fetchmail-man-page empfiehlt UUCP statt Multidrop-POP3.
IIRC ist UUCP auch kein Postfix-Paket, sondern 3rd-Party-Software. Deshalb wird es schwierig, dafür eine Lösung zu finden. Postfix ist auf SMTP abgestimmt. In deinem Fall ist die Mail bereits auf dem System, wird jedoch von Postfix abgewiesen und UUCP bleibt stur dabei, die Mail weiterhin nach Postfix einzuliefern.
Aber warum verhält sich Postfix unterschiedlich: Mails an nichtexistente Mailboxen werden angenommen und ein Bounce erzeugt, die Annahme zu großer Mails wird aber verweigert?
Mit einfachen Mitteln sehe ich keine Lösung. Sorry. :-(
Schade. Trotzdem Danke. Hm, also bleibt nur anderer MTA oder eine Zwei-Server-Lösung... Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andreas Koenecke wrote:
Hall Sandy.
* Sonntag, 22. Juli 2007 um 15:43 (+0200) schrieb Sandy Drobic:
Andreas Koenecke wrote:
Gibt es eine Möglichkeit, dieses anachronistische Modell mit UUCP in Rente zu schicken? Das würde eine Menge Probleme lösen.
Naja, die Alternative wäre eine Multidrop-POP3-Mailbox. IMHO noch mehr Probleme. Und sofern z.B. 'fetchmail' keine Bounce-Mails erzeugt, dieses Problem ebenfalls. Selbst die fetchmail-man-page empfiehlt UUCP statt Multidrop-POP3.
Uh, gibt es denn keine Möglichkeit einfach SMTP einzusetzen? Mit mini_sendmail etwa kann man direkt von der Kommandozeile zu einem entfernten Server senden. Wieso muss es unbedingt ein asynchrones Verfahren sein?
IIRC ist UUCP auch kein Postfix-Paket, sondern 3rd-Party-Software. Deshalb wird es schwierig, dafür eine Lösung zu finden. Postfix ist auf SMTP abgestimmt. In deinem Fall ist die Mail bereits auf dem System, wird jedoch von Postfix abgewiesen und UUCP bleibt stur dabei, die Mail weiterhin nach Postfix einzuliefern.
Aber warum verhält sich Postfix unterschiedlich: Mails an nichtexistente Mailboxen werden angenommen und ein Bounce erzeugt, die Annahme zu großer Mails wird aber verweigert?
Gibt es nicht die Möglichkeit, diese Checks (Gültiger Empfänger + Mailgröße) auf den einliefernden Rechner zu verlagern? Grundsätzlich sollte die Zustellbarkeit einer Mail vor der Annahme geprüft werden. Dies wird mit UUCP, Fetchmail etc. für die Backend-Server gründlich unterlaufen. All das wäre mit SMTP kein Problem. Welche Version von Postfix verwendest du? postconf mail_version
Mit einfachen Mitteln sehe ich keine Lösung. Sorry. :-(
Schade. Trotzdem Danke.
Hm, also bleibt nur anderer MTA oder eine Zwei-Server-Lösung...
Wer weiss, vielleicht gibt es ja jemanden, der sich besser mit UUCP auskennt, meine Kenntnisse von UUCP sind recht gering. Die einzige Möglichkeit, die ich sonst sehe, ist message_size_limit auf einen hohen Wert zu setzen und einen Policydaemon wie policyd diese Mails dann bouncen zu lassen, eventuell abhängig von Domain oder Empfänger. Mailtechnisch macht das natürlich wenig Sinn, eine Mail erst komplett anzunehmen und dann wegen der Größe zu bouncen. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Sunday 22 July 2007 17:08, Sandy Drobic wrote:
Andreas Koenecke wrote: <quotings komplett entsorgt>
ich benutze UUCP in Teilen meiner Anlagen seit Jahren. Ich schätze dasss Postfix Dein Problem ist. Postfix kam auf als UUCP als Mail-Transportsystem schon längst aus der Mode war. Ich benutze UUCP/sendmail/fetchmail -- Regards, Walter Ulmke Ulmke Machine Tools, 48496 Hopsten, Germany Tel. ++49/5458/93345-0 Fax. ++49/5458/93345-45 Mobile: ++49/172/5357999 eMail: ulw@ulmke.com Dipl.-Ing. Walter Ulmke e.K. AG Steinfurt HRA 4384 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Walter Ulmke wrote:
On Sunday 22 July 2007 17:08, Sandy Drobic wrote:
Andreas Koenecke wrote: <quotings komplett entsorgt>
ich benutze UUCP in Teilen meiner Anlagen seit Jahren.
Ich schätze dasss Postfix Dein Problem ist. Postfix kam auf als UUCP als Mail-Transportsystem schon längst aus der Mode war.
Grins! Hört sich irgendwie an wie "Die Antwort ist 42." Aber korrekt ist definitiv, dass Postfix für SMTP optimiert ist.
Ich benutze UUCP/sendmail/fetchmail
Wie regelt Sendmail das, wenn eine zu große Mail per UUCP eingeht? -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo. * Sonntag, 22. Juli 2007 um 19:16 (+0200) schrieb Walter Ulmke:
ich benutze UUCP in Teilen meiner Anlagen seit Jahren.
Der Vorgänger des jetzigen Mail-Servers lief ziemlich genau 10 Jahre mit UUCP und sendmail. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andreas Koenecke wrote:
Hallo.
* Sonntag, 22. Juli 2007 um 19:16 (+0200) schrieb Walter Ulmke:
ich benutze UUCP in Teilen meiner Anlagen seit Jahren.
Der Vorgänger des jetzigen Mail-Servers lief ziemlich genau 10 Jahre mit UUCP und sendmail.
Was war denn der Grund für den Wechsel? -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
* Dienstag, 24. Juli 2007 um 19:02 (+0200) schrieb Sandy Drobic:
Andreas Koenecke wrote:
Der Vorgänger des jetzigen Mail-Servers lief ziemlich genau 10 Jahre mit UUCP und sendmail.
Was war denn der Grund für den Wechsel?
Pentiun (I) mit 133 MHz und SuSE 5.0: Die Hardware wurde zickig und die Software nur noch schwer zu pflegen. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andreas Koenecke wrote:
* Dienstag, 24. Juli 2007 um 19:02 (+0200) schrieb Sandy Drobic:
Andreas Koenecke wrote:
Der Vorgänger des jetzigen Mail-Servers lief ziemlich genau 10 Jahre mit UUCP und sendmail. Was war denn der Grund für den Wechsel?
Pentiun (I) mit 133 MHz und SuSE 5.0: Die Hardware wurde zickig und die Software nur noch schwer zu pflegen.
Wow, ich habe hier noch einen P2-350 als Firewall, und in der Firma kämpft noch ein kleiner P2-233 tapfer als Netzwerküberwachung unter Redhat 9.0. Mit Suse 5.0 kann ich nicht mithalten. (^-^) -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Sandy. * Sonntag, 22. Juli 2007 um 17:08 (+0200) schrieb Sandy Drobic:
Andreas Koenecke wrote:
Naja, die Alternative wäre eine Multidrop-POP3-Mailbox. IMHO noch mehr Probleme. Und sofern z.B. 'fetchmail' keine Bounce-Mails erzeugt, dieses Problem ebenfalls. Selbst die fetchmail-man-page empfiehlt UUCP statt Multidrop-POP3.
Uh, gibt es denn keine Möglichkeit einfach SMTP einzusetzen? Mit mini_sendmail etwa kann man direkt von der Kommandozeile zu einem entfernten Server senden.
Das Senden wäre IMHO kein Problem, aber das Empfangen von Mails...
Wieso muss es unbedingt ein asynchrones Verfahren sein?
Es handelt sich um eine Schule mit einem Dial-Up-Netzwerk und dynamischer IP.
Aber warum verhält sich Postfix unterschiedlich: Mails an nichtexistente Mailboxen werden angenommen und ein Bounce erzeugt, die Annahme zu großer Mails wird aber verweigert?
Gibt es nicht die Möglichkeit, diese Checks (Gültiger Empfänger + Mailgröße) auf den einliefernden Rechner zu verlagern?
Nicht so richtig: Für die Mailgröße gibt es keine Einstellmöglichkeit, die gültigen Empfänger könnte man über ein Webinterface eingeben, aber es geht hier um gut 2500 Mailboxen (aber mit geringem Mailaufkommen), die dazu noch halbjährlich/jährlich fluktuieren...
Grundsätzlich sollte die Zustellbarkeit einer Mail vor der Annahme geprüft werden. Dies wird mit UUCP, Fetchmail etc. für die Backend-Server gründlich unterlaufen.
All das wäre mit SMTP kein Problem.
Ja, aber das ist halt nicht so einfach mit einem Dial-Up-Netzwerk.
Welche Version von Postfix verwendest du? postconf mail_version
mail_version = 2.3.11
Wer weiss, vielleicht gibt es ja jemanden, der sich besser mit UUCP auskennt, meine Kenntnisse von UUCP sind recht gering.
Per UUCP ist da nicht viel zu machen: Die Mails werden vom Provider auf den Server gepusht, danach werden die Mails mit 'rmail' an den MTA übergeben. 'rmail' gehört eigentlich schon nicht mehr zu UUCP, sondern zum MTA. Auch Postfix bringt in seinem "auxiliary"-Verzeichnis ein (recht minimalistisches) 'rmail' mit. Wenn der MTA die Annahme der Mails von 'rmail' verweigert, dann müsste 'rmail' ggfs. Bounces generieren. Das macht aber kein mir bekanntes 'rmail', auch nicht das Postfix-rmail...
Die einzige Möglichkeit, die ich sonst sehe, ist message_size_limit auf einen hohen Wert zu setzen und einen Policydaemon wie policyd diese Mails dann bouncen zu lassen, eventuell abhängig von Domain oder Empfänger.
Das hört sich interessant an. Ich frage mich aber, unter welchen Umständen Postfix außerdem die Annahme von Mails verweigert und ob man alle diese Fälle mit einer Policy abfangen kann?
Mailtechnisch macht das natürlich wenig Sinn, eine Mail erst komplett anzunehmen und dann wegen der Größe zu bouncen.
Ja klar, aber unter den gegebenen Umständen sehe ich keine andere Möglichkeit. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andreas Koenecke wrote:
Hallo Sandy.
* Sonntag, 22. Juli 2007 um 17:08 (+0200) schrieb Sandy Drobic:
Andreas Koenecke wrote:
Naja, die Alternative wäre eine Multidrop-POP3-Mailbox. IMHO noch mehr Probleme. Und sofern z.B. 'fetchmail' keine Bounce-Mails erzeugt, dieses Problem ebenfalls. Selbst die fetchmail-man-page empfiehlt UUCP statt Multidrop-POP3. Uh, gibt es denn keine Möglichkeit einfach SMTP einzusetzen? Mit mini_sendmail etwa kann man direkt von der Kommandozeile zu einem entfernten Server senden.
Das Senden wäre IMHO kein Problem, aber das Empfangen von Mails...
Wieso muss es unbedingt ein asynchrones Verfahren sein?
Es handelt sich um eine Schule mit einem Dial-Up-Netzwerk und dynamischer IP.
Seufz. Na ja, zumindest für die T-Geschichten gibt es die Möglichkeit, für ein paar Euro Aufpreis pro Monat eine feste IP zu erwerben. Ansonsten ist genau für diesen Zweck smtp auth gedacht. Der Server an der Schule muss sich also nur mit Benutzername/Passwort authentifizieren und kann seine Mails absetzen. Für's Abholen würde ja Fetchmail reichen. Beides erfordert keine Feste IP. Was für ein Mailserver/OS wird denn in der Schule eingesetzt?
Welche Version von Postfix verwendest du? postconf mail_version
mail_version = 2.3.11
Ich schaue mal, ob sich mit DSN etwas machen lässt. Dies behebt aber nicht das Problem mit UUCP, dass es immer wieder versucht.
Wer weiss, vielleicht gibt es ja jemanden, der sich besser mit UUCP auskennt, meine Kenntnisse von UUCP sind recht gering.
Per UUCP ist da nicht viel zu machen: Die Mails werden vom Provider auf den Server gepusht, danach werden die Mails mit 'rmail' an den MTA übergeben. 'rmail' gehört eigentlich schon nicht mehr zu UUCP, sondern zum MTA. Auch Postfix bringt in seinem "auxiliary"-Verzeichnis ein (recht minimalistisches) 'rmail' mit. Wenn der MTA die Annahme der Mails von 'rmail' verweigert, dann müsste 'rmail' ggfs. Bounces generieren. Das macht aber kein mir bekanntes 'rmail', auch nicht das Postfix-rmail...
Das ist genau das Problem, was mit den 3rd-Party-Modulen gerne auftaucht. Sie reagieren nicht in allen Situationen korrekt.
Die einzige Möglichkeit, die ich sonst sehe, ist message_size_limit auf einen hohen Wert zu setzen und einen Policydaemon wie policyd diese Mails dann bouncen zu lassen, eventuell abhängig von Domain oder Empfänger.
Das hört sich interessant an. Ich frage mich aber, unter welchen Umständen Postfix außerdem die Annahme von Mails verweigert und ob man alle diese Fälle mit einer Policy abfangen kann?
Ein Policyserver arbeitet nur auf der SMTP Protokoll-Ebene. Erst, wenn die Mail an smtpd übergeben wird, greifen Policy-Eingaben. Deshalb kann nicht alles durch Policyserver abgefangen werden. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Sandy. * Sonntag, 22. Juli 2007 um 20:40 (+0200) schrieb Sandy Drobic:
Andreas Koenecke wrote:
Es handelt sich um eine Schule mit einem Dial-Up-Netzwerk und dynamischer IP.
Seufz. Na ja, zumindest für die T-Geschichten gibt es die Möglichkeit, für ein paar Euro Aufpreis pro Monat eine feste IP zu erwerben. Ansonsten ist genau für diesen Zweck smtp auth gedacht. Der Server an der Schule muss sich also nur mit Benutzername/Passwort authentifizieren und kann seine Mails absetzen.
Wie schon geschrieben, mit dem Mailversenden gibt es kein Problem.
Für's Abholen würde ja Fetchmail reichen. Beides erfordert keine Feste IP.
Aber 'fetchmail' und Multidrop-POP3 hat noch viel mehr Probleme...
Was für ein Mailserver/OS wird denn in der Schule eingesetzt?
Der Rechner, den wir hier im Thread besprechen, ist der Mailserver!
Ich schaue mal, ob sich mit DSN etwas machen lässt. Dies behebt aber nicht das Problem mit UUCP, dass es immer wieder versucht.
Wenn 'rmail' seine Mail ohne Fehler loswird, dann ist es auch zufrieden...
Per UUCP ist da nicht viel zu machen: Die Mails werden vom Provider auf den Server gepusht, danach werden die Mails mit 'rmail' an den MTA übergeben. 'rmail' gehört eigentlich schon nicht mehr zu UUCP, sondern zum MTA. Auch Postfix bringt in seinem "auxiliary"-Verzeichnis ein (recht minimalistisches) 'rmail' mit. Wenn der MTA die Annahme der Mails von 'rmail' verweigert, dann müsste 'rmail' ggfs. Bounces generieren. Das macht aber kein mir bekanntes 'rmail', auch nicht das Postfix-rmail...
Das ist genau das Problem, was mit den 3rd-Party-Modulen gerne auftaucht. Sie reagieren nicht in allen Situationen korrekt.
Na ja, das postfix-rmail ist doch aber kein 3rd-Party-Modul, oder?
Ich frage mich aber, unter welchen Umständen Postfix außerdem die Annahme von Mails verweigert und ob man alle diese Fälle mit einer Policy abfangen kann?
Ein Policyserver arbeitet nur auf der SMTP Protokoll-Ebene. Erst, wenn die Mail an smtpd übergeben wird, greifen Policy-Eingaben. Deshalb kann nicht alles durch Policyserver abgefangen werden.
Es gibt auch ein 'rmail', welches die Mail per SMTP übergeben kann. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andreas Koenecke wrote:
Hallo Sandy.
* Sonntag, 22. Juli 2007 um 20:40 (+0200) schrieb Sandy Drobic:
Andreas Koenecke wrote:
Es handelt sich um eine Schule mit einem Dial-Up-Netzwerk und dynamischer IP.
Seufz. Na ja, zumindest für die T-Geschichten gibt es die Möglichkeit, für ein paar Euro Aufpreis pro Monat eine feste IP zu erwerben. Ansonsten ist genau für diesen Zweck smtp auth gedacht. Der Server an der Schule muss sich also nur mit Benutzername/Passwort authentifizieren und kann seine Mails absetzen.
Wie schon geschrieben, mit dem Mailversenden gibt es kein Problem.
Für's Abholen würde ja Fetchmail reichen. Beides erfordert keine Feste IP.
Aber 'fetchmail' und Multidrop-POP3 hat noch viel mehr Probleme...
Was für ein Mailserver/OS wird denn in der Schule eingesetzt?
Der Rechner, den wir hier im Thread besprechen, ist der Mailserver!
Okay, so langsam sehe ich klarer. Wie sieht es mit dem Upstreamserver aus, ist der unter deiner Kontrolle oder ist das ein nicht von dir konfigurierbarer ISP-Server? Das Problem mit der Größe der Mail ist übel, da ich keine Möglichkeit sehe, aufgrund der Größe bestimmte Handlungen außer dem REJECT vorzunehmen.
Ich schaue mal, ob sich mit DSN etwas machen lässt. Dies behebt aber nicht das Problem mit UUCP, dass es immer wieder versucht.
Wenn 'rmail' seine Mail ohne Fehler loswird, dann ist es auch zufrieden...
Per UUCP ist da nicht viel zu machen: Die Mails werden vom Provider auf den Server gepusht, danach werden die Mails mit 'rmail' an den MTA übergeben. 'rmail' gehört eigentlich schon nicht mehr zu UUCP, sondern zum MTA. Auch Postfix bringt in seinem "auxiliary"-Verzeichnis ein (recht minimalistisches) 'rmail' mit. Wenn der MTA die Annahme der Mails von 'rmail' verweigert, dann müsste 'rmail' ggfs. Bounces generieren. Das macht aber kein mir bekanntes 'rmail', auch nicht das Postfix-rmail... Das ist genau das Problem, was mit den 3rd-Party-Modulen gerne auftaucht. Sie reagieren nicht in allen Situationen korrekt.
Na ja, das postfix-rmail ist doch aber kein 3rd-Party-Modul, oder?
Ich staune und lerne. Es ist ein kleines Shellscript und in der Tat in
Postfix enthalten:
------------------------------
#!/bin/sh
# Dummy UUCP rmail command for postfix/qmail systems
SENDMAIL="/usr/sbin/sendmail"
IFS=" " read junk from junk junk junk junk junk junk junk relay
case "$from" in
*[@!]*) ;;
*) from="$from@$relay";;
esac
exec $SENDMAIL -i -f "$from" -- "$@"
------------------------------
In diesen Script ist keinerlei Fehlerbehandlung, deshalb ist es kein
Wunder, wenn es immer wieder seine Routine versucht.
Das müsste dan ergänzt werden durch die entsprechende Behandlung von
reject codes. In deinem Fall möchtest du die Mail wahrscheinlich löschen
und eine Mail zurück an den Absender schicken.
Du könntest das vermutlich ergänzen und abfragen, ob die Größe
überschritten ist.
Hier ungetestet ein Beispiel, abgeleitet vom Filter-Beispiel:
#!/bin/sh
IFS=" " read junk from junk junk junk junk junk junk junk relay
SENDMAIL="/usr/sbin/sendmail -G -i"
INSPECT_DIR=/var/spool/uucp
# Exit codes from Ich frage mich aber, unter welchen Umständen Postfix außerdem die Annahme von
Mails verweigert und ob man alle diese Fälle mit einer Policy abfangen kann? Ein Policyserver arbeitet nur auf der SMTP Protokoll-Ebene. Erst, wenn die
Mail an smtpd übergeben wird, greifen Policy-Eingaben. Deshalb kann nicht
alles durch Policyserver abgefangen werden. Es gibt auch ein 'rmail', welches die Mail per SMTP übergeben kann. Das wäre nur eine Hilfe, wenn es abgewiesene Mails korrekt bouncen würde
und allgemein SMTP sprechen würde mit den entsprechenden Reaktionen.
Selbst wenn du hier /usr/sbin/sendmail durch mini_sendmail ersetzen
würdest, fehlt immer noch das Auswerten der returncodes und die
entsprechende Handlung danach.
Vielleicht komme ich am Wochenende mal dazu, etwas zu testen.
--
Sandy
Antworten bitte nur in die Mailingliste!
PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+unsubscribe@opensuse.org
Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken
Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Sandy. * Dienstag, 24. Juli 2007 um 19:20 (+0200) schrieb Sandy Drobic:
Andreas Koenecke wrote:
Der Rechner, den wir hier im Thread besprechen, ist der Mailserver!
Okay, so langsam sehe ich klarer. Wie sieht es mit dem Upstreamserver aus, ist der unter deiner Kontrolle oder ist das ein nicht von dir konfigurierbarer ISP-Server?
Das ist ein Server unseres Mail-Provider, keine Chance, da was zu drehen...
Hier ungetestet ein Beispiel, abgeleitet vom Filter-Beispiel:
#!/bin/sh IFS=" " read junk from junk junk junk junk junk junk junk relay SENDMAIL="/usr/sbin/sendmail -G -i" [ ... ]
Ich schau mir das Mal in Ruhe an. Danke erstmal.
Es gibt auch ein 'rmail', welches die Mail per SMTP übergeben kann.
Das wäre nur eine Hilfe, wenn es abgewiesene Mails korrekt bouncen würde und allgemein SMTP sprechen würde mit den entsprechenden Reaktionen.
Nein, das macht es leider auch nicht und fühlt sich dafür auch nicht zuständig. Hier ein Auszug aus dem Programm: -------------------------------------------------------------------- # Exit codes compatible to sendmails's rmail # We use only these exit values. # All other exit values may cause the UUCP system to send bounces back to the sender. # To send bounces (or not) is the job of our MTA. # my $EX_OK = 0; # Everything is OK my $EX_USAGE = 64; # Missing or bad arrguments on the commanline my $EX_TEMPFAIL = 75; # Give UUCP another chance to try it again. ----------------------------------------------------------------------
Vielleicht komme ich am Wochenende mal dazu, etwas zu testen.
Danke! Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andreas Koenecke, Dienstag, 24. Juli 2007 19:58:
XMMS spielt gerade nichts...
Wie bekommst Du denn per Skript raus, was xmms grad spielt? xmms --help gibt mir da irgendwie keine Option, die mir den aktuellen Song mitteilen würde. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
* Dienstag, 24. Juli 2007 um 20:05 (+0200) schrieb Andre Tann:
Andreas Koenecke, Dienstag, 24. Juli 2007 19:58:
XMMS spielt gerade nichts...
Wie bekommst Du denn per Skript raus, was xmms grad spielt? xmms --help gibt mir da irgendwie keine Option, die mir den aktuellen Song mitteilen würde.
Ich habe da ein Perl-Skript namens "ctrlxmms" (ist z.B bei "freshmeat" gelistet), mit dem man 'xmms' von der Konsole bedienen kann. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (5)
-
Andre Tann -
Andreas Koenecke -
Falk Sauer -
Sandy Drobic -
Walter Ulmke