Was ist denn da los: Postfix 3.0 Release; Spamassassin mit Montags-Fehler

Tux

Ein guter Montag fängt mit einem fehlerhaften SA-Update an:

Feb 9 11:29:25 linsrv02 spamd[55034]: )
Feb 9 11:29:25 linsrv02 spamd[55034]: (Can't locate object method "check_for_spf_temperror" via package "Mail: [...]:SpamAssassin::PerMsgStatus" at (eval 1186) line 2292, line 43.
Feb 9 11:29:25 linsrv02 spamd[55034]: rules: failed to run T_SPF_TEMPERROR test, skipping:
Feb 9 11:29:25 linsrv02 spamd[55034]: )
Feb 9 11:29:25 linsrv02 spamd[55034]: (Can't locate object method "check_for_spf_helo_temperror" via package "Mail: [...]:SpamAssassin::PerMsgStatus" at (eval 1186) line 997, line 43.
Feb 9 11:29:25 linsrv02 spamd[55034]: rules: failed to run T_SPF_HELO_TEMPERROR test, skipping:
Feb 9 11:29:25 linsrv02 spamd[55034]: )
Feb 9 11:29:25 linsrv02 spamd[55034]: (Can't locate object method "check_for_spf_permerror" via package "Mail: [...]:SpamAssassin::PerMsgStatus" at (eval 1186) line 274, line 43.
Feb 9 11:29:25 linsrv02 spamd[55034]: rules: failed to run T_SPF_PERMERROR test, skipping:
Feb 9 11:29:25 linsrv02 spamd[55034]: )
Feb 9 11:29:25 linsrv02 spamd[55034]: (Can't locate object method "check_for_spf_helo_permerror" via package "Mail: [...]:SpamAssassin::PerMsgStatus" at (eval 1186) line 45, line 43.
Feb 9 11:29:25 linsrv02 spamd[55034]: rules: failed to run T_SPF_HELO_PERMERROR test, skipping:

Ein Update der SA-Regeln hat Schuld. Nicht wundern, nicht ärgern, einfach abwarten.
Das kam schon einmal vor und wird mit Sicherheit sehr schnell behoben.
Stackexchange war mal wieder schneller.

Aber viel wichtiger ist wohl das Release des Postfix Mailservers in Version 3.0.

Zitat (aus obigem Link) von Wietse Venema:

The main changes in no particular order are:

– SMTPUTF8 support for internationalized domain names and address localparts as defined in RFC 6530 and related documents. The implementation is based on code contributed by Arnt Gulbrandsen and sponsored by CNNIC. SMTPUTF8 support is a work in progress; it is expected to be completed during the Postfix 3.1 development cycle. See SMTPUTF8_README for a summary of limitations.
 
– Support for Postfix dynamically-linked libraries and database plugins. The implementation is based on code by LaMont Jones for Debian Linux. See INSTALL for detailed descriptions of the available options.
 
– An OPT-IN safety net for the selective adoption of new Postfix default settings. If you do nothing, the old Postfix default settings *should* remain in effect (complain to your downstream maintainer if that is not the case). See COMPATIBILITY_README for detailed descriptions of Postfix logfile messages.
 
– Support for operations on multiple lookup tables. The pipemap:{map1,map2…} database type implements a pipeline of lookup tables where the result from one lookup table becomes a query for the next table; the unionmap:{map1,map2,…} database type sends the same query to multiple lookup tables and concatenates their results.
 
– Support for pseudo-tables that make simple things easy to implement. The inline:{key1=value1,key2=value2,…} table avoids the need to create an external file for just a few items; and the randmap{value1,value2,…} table implements random selection from the specified values.
 
– Table-driven transformation of DNS lookup results and of delivery agent status codes and messages. Typically, one would use a PCRE table to fix problematic DNS responses or to fix the handling of delivery errors. See smtp_dns_reply_filter, smtp_delivery_status_filter, and similarly-named parameters for other Postfix daemons.
 
– Improved configuration file syntax with support for the ternary operator such as ${name?{iftrue}:{iffalse}}, comparison operators such as ${{expr1}==${expr2}?{iftrue}:{iffalse}}, per-Milter and per-policy server timeout and other settings, master.cf parameters that contain whitespace, import/export_environment settings that contain whitespace, and „static“ table lookup results that contain whitespace. Support for multiple lookup results in access(5) and header/body_checks(5) tables is expected to be completed in the Postfix 3.1 development cycle.
 
– Per-session command profiles, logged at the end of each inbound SMTP session. For example, a password-guessing bot is logged as „disconnect from name[addr] ehlo=1 auth=0/1 commands=1/2“, meaning that the client sent one EHLO command that worked, one AUTH command that failed, and hung up without sending a QUIT command. This information is always logged, and can help to solve puzzles without verbose logging or network sniffers.

Eine Antwort auf “Was ist denn da los: Postfix 3.0 Release; Spamassassin mit Montags-Fehler

  1. Anon

    Hab heute Morgen auch nicht schlecht geschaut als ich aufgewacht bin und die Mails vom cron im Postfach waren.
    Über den Tag verteilt habe ich dann auch mehrere solcher Mails erhalten aber auch auf stackoverflow schon gelesen, dass man um das Problem weiß und daran arbeitet. ;)
    Es jetzt hier bei dir nochmal zu lesen beruhigt mich ein Stück weit mehr.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.