Postscreen - Schutz vor Überbelastung und SPAM-Abwehr

Postfix-Logo Die Grundidee hinter Wietse Venema's postscreen Daemon, ist der Schutz des Mailservers vor Überlastung. Ein postscreen Prozess lässt dabei nur noch diejenigen Verbindungen zum SMTP-Daemon durch, die die Eingangstest nicht überlebt haben. Typischer Weise sind gekaperte Rechner (Zombies) und andere SPAM-Bots für etwa 90% aller Spam-Mails verantwortlich. Durch das Elimimieren dieser unerwünschten Verbindungsanfragen, stehen die SMTP-Serverprozesse mehr den legitimen MTAs1) zur Verfügung und entlastet so den kompletten Server.

Damit der erwünschte MTA zu MTA Verkehr bestmöglichst nicht eingeschränkt wird, pflegt der postscreen Daemon eine eigene temporäre Whitelist, in die er alle Clients einträgt, die die postscreen Prüfungen bereits bestanden haben.

Die Hauptaufgabe, bzw. wie Wietse es sagt „..die größte Herausforderung“ von postscreen ist es mit nur einer Bewertung herauszufinden, ob es sich um einen SPAMer handelt oder nicht. Dies ist vorallem dadurch notwendig, da viele Zombiesysteme versuchen, möglichst unerkannt SPAM zu versenden und dadurch vermeiden große Mengen an einem Host einzuliefern. Bewertet postscreen den Zustellversuch als HAM, also als erwünschten Verkehr, so merkt er sich diesen Host in seiner temporären Whitelist und vermeidet so weitere Verzögerungen bei legitimen Verkehr. Eine weitere Herausforderung von SPAM versendenden Systemen ist die begrenzte Zeit, bevor die betroffenen IP-Adressen auf Blacklisten erscheinen, die zur Verfügung steht um SPAM zu verschicken. Daher sind viele SPAM-clients daruaf getrimmt, möglichst schnell ihre Post loszuwerden. Sie ignorieren daher sehr oft richtige SMTP-Implementierungen, legen mit der Übertragung sofort nach dem Connect los oder ignorieren Rückmeldungen des Empfangssystems. All dies macht sich postscreen zu nutze!

Zur Erkennung von Zombies nutzt der Postscreen Daemon verschiedene Techniken. So prüft der Daemon erst mal, ob der Client auf einer Blacklist gelistet ist. Dabei kann er verschiedene Listen befragen und entsprechend deren Gewichtung eine Entscheidung treffen. Desweiteren prüft postscreen, ob der Client RFC-konform arbeitet, oder ob der Client ungefragt loslegt bevor der SMTP-Daemon sich richtig gemeldet hat. Bereits diese beiden Prüfungen reichen aus, um eine erste Entscheidung auf HAM oder SPAM zu treffen.

Viele wertvolle Konfigurationshinweise findet man in der Manpage von postscreen.

 # man 8 postscreen
POSTSCREEN(8)                                                    POSTSCREEN(8)

NAME
       postscreen - Postfix zombie blocker

SYNOPSIS
       postscreen [generic Postfix daemon options]

DESCRIPTION
       The Postfix postscreen(8) server provides additional protection against
       mail  server  overload.  One  postscreen(8)  process  handles  multiple
       inbound SMTP connections, and decides which clients may talk to a Post-
       fix SMTP server  process.   By  keeping  spambots  away,  postscreen(8)
       leaves more SMTP server processes available for legitimate clients, and
       delays the onset of server overload conditions.

       This program should not be used on SMTP ports that  receive  mail  from
       end-user clients (MUAs). In a typical deployment, postscreen(8) handles
       the MX service on TCP port 25, while MUA clients submit  mail  via  the
       submission  service  on  TCP port 587 which requires client authentica-
       tion.  Alternatively, a site could set up a dedicated,  non-postscreen,
       "port  25" server that provides submission service and client authenti-
       cation, but no MX service.

       postscreen(8) maintains a temporary whitelist  for  clients  that  have
       passed  a  number  of  tests.   When  an  SMTP  client  IP  address  is
       whitelisted, postscreen(8) hands off the connection  immediately  to  a
       Postfix SMTP server process. This minimizes the overhead for legitimate
       mail.

       By default, postscreen(8) logs statistics and hands off  every  connec-
       tion  to  a  Postfix  SMTP  server  process, while excluding clients in
       mynetworks from all tests (primarily, to avoid problems with  non-stan-
       dard  SMTP implementations in network appliances).  This mode is useful
       for non-destructive testing.

       In a typical production setting, postscreen(8) is configured to  reject
       mail  from  clients  that  fail  one  or more tests. postscreen(8) logs
       rejected mail with the  client  address,  helo,  sender  and  recipient
       information.

       postscreen(8)  is  not an SMTP proxy; this is intentional.  The purpose
       is to keep spambots away from Postfix SMTP server processes, while min-
       imizing overhead for legitimate traffic.

SECURITY
       The postscreen(8) server is moderately security-sensitive.  It talks to
       untrusted clients on the network. The process can be  run  chrooted  at
       fixed low privilege.

STANDARDS
       RFC 821 (SMTP protocol)
       RFC 1123 (Host requirements)
       RFC 1652 (8bit-MIME transport)
       RFC 1869 (SMTP service extensions)
       RFC 1870 (Message Size Declaration)
       RFC 1985 (ETRN command)
       RFC 2034 (SMTP Enhanced Status Codes)
       RFC 2821 (SMTP protocol)
       Not: RFC 2920 (SMTP Pipelining)
       RFC 3207 (STARTTLS command)
       RFC 3461 (SMTP DSN Extension)
       RFC 3463 (Enhanced Status Codes)
       RFC 5321 (SMTP protocol, including multi-line 220 banners)

DIAGNOSTICS
       Problems and transactions are logged to syslogd(8).

BUGS
       The  postscreen(8)  built-in  SMTP  protocol  engine currently does not
       announce support for AUTH, XCLIENT or XFORWARD.  If you  need  to  make
       these  services  available  on port 25, then do not enable the optional
       "after 220 server greeting" tests, and do not use  DNSBLs  that  reject
       traffic from dial-up and residential networks.

       The  optional "after 220 server greeting" tests involve postscreen(8)'s
       built-in SMTP protocol engine. When these tests succeed,  postscreen(8)
       adds  the client to the temporary whitelist, but it cannot not hand off
       the "live" connection to a Postfix SMTP server process in the middle of
       a session.  Instead, postscreen(8) defers attempts to deliver mail with
       a 4XX status, and waits for the client to disconnect.  When the  client
       connects  again, postscreen(8) will allow the client to talk to a Post-
       fix SMTP server process (provided that the  whitelist  status  has  not
       expired).   postscreen(8)  mitigates  the  impact of this limitation by
       giving the "after 220 server greeting" tests a long expiration time.

CONFIGURATION PARAMETERS
       Changes to main.cf are not picked up  automatically,  as  postscreen(8)
       processes  may run for several hours.  Use the command "postfix reload"
       after a configuration change.

       The text below provides only a parameter summary. See  postconf(5)  for
       more details including examples.

       NOTE:  Some  postscreen(8) parameters implement stress-dependent behav-
       ior.  This is supported  only  when  the  default  parameter  value  is
       stress-dependent  (that  is,  it looks like ${stress?{X}:{Y}}, or it is
       the $name of an  smtpd  parameter  with  a  stress-dependent  default).
       Other  parameters  always  evaluate as if the stress parameter value is
       the empty string.

COMPATIBILITY CONTROLS
       postscreen_command_filter ($smtpd_command_filter)
              A mechanism to transform commands from remote SMTP clients.

       postscreen_discard_ehlo_keyword_address_maps  ($smtpd_discard_ehlo_key-
       word_address_maps)
              Lookup tables, indexed by the remote SMTP client  address,  with
              case  insensitive  lists of EHLO keywords (pipelining, starttls,
              auth, etc.) that the postscreen(8) server will not send  in  the
              EHLO response to a remote SMTP client.

       postscreen_discard_ehlo_keywords ($smtpd_discard_ehlo_keywords)
              A  case insensitive list of EHLO keywords (pipelining, starttls,
              auth, etc.) that the postscreen(8) server will not send  in  the
              EHLO response to a remote SMTP client.

TROUBLE SHOOTING CONTROLS
       postscreen_expansion_filter (see 'postconf -d' output)
              List     of     characters     that     are     permitted     in
              postscreen_reject_footer attribute expansions.

       postscreen_reject_footer ($smtpd_reject_footer)
              Optional information  that  is  appended  after  a  4XX  or  5XX
              postscreen(8) server response.

       soft_bounce (no)
              Safety  net to keep mail queued that would otherwise be returned
              to the sender.

BEFORE-POSTSCREEN PROXY AGENT
       Available in Postfix version 2.10 and later:

       postscreen_upstream_proxy_protocol (empty)
              The name of the proxy  protocol  used  by  an  optional  before-
              postscreen proxy agent.

       postscreen_upstream_proxy_timeout (5s)
              The  time  limit  for  the  proxy  protocol  specified  with the
              postscreen_upstream_proxy_protocol parameter.

PERMANENT WHITE/BLACKLIST TEST
       This test is executed immediately after a remote SMTP client  connects.
       If  a  client is permanently whitelisted, the client will be handed off
       immediately to a Postfix SMTP server process.

       postscreen_access_list (permit_mynetworks)
              Permanent white/blacklist for remote SMTP client IP addresses.

       postscreen_blacklist_action (ignore)
              The action that postscreen(8) takes when a remote SMTP client is
              permanently  blacklisted with the postscreen_access_list parame-
              ter.

MAIL EXCHANGER POLICY TESTS
       When postscreen(8) is configured to monitor all primary and  backup  MX
       addresses,  it can refuse to whitelist clients that connect to a backup
       MX address only. For small sites, this requires configuring primary and
       backup  MX  addresses on the same MTA. Larger sites would have to share
       the postscreen(8) cache between primary and backup  MTAs,  which  would
       introduce a common point of failure.

       postscreen_whitelist_interfaces (static:all)
              A  list  of local postscreen(8) server IP addresses where a non-
              whitelisted remote SMTP client can obtain postscreen(8)'s tempo-
              rary whitelist status.

BEFORE 220 GREETING TESTS
       These  tests  are  executed  before the remote SMTP client receives the
       "220 servername" greeting. If no tests remain after the successful com-
       pletion  of  this phase, the client will be handed off immediately to a
       Postfix SMTP server process.

       dnsblog_service_name (dnsblog)
              The name of the dnsblog(8) service entry in master.cf.

       postscreen_dnsbl_action (ignore)
              The action that postscreen(8) takes when a remote SMTP  client's
              combined DNSBL score is equal to or greater than a threshold (as
              defined      with      the      postscreen_dnsbl_sites       and
              postscreen_dnsbl_threshold parameters).

       postscreen_dnsbl_reply_map (empty)
              A  mapping from actual DNSBL domain name which includes a secret
              password, to the DNSBL domain name that  postscreen  will  reply
              with when it rejects mail.

       postscreen_dnsbl_sites (empty)
              Optional list of DNS white/blacklist domains, filters and weight
              factors.

       postscreen_dnsbl_threshold (1)
              The inclusive lower bound for blocking  a  remote  SMTP  client,
              based   on   its  combined  DNSBL  score  as  defined  with  the
              postscreen_dnsbl_sites parameter.

       postscreen_greet_action (ignore)
              The action that postscreen(8) takes when a  remote  SMTP  client
              speaks  before  its  turn  within  the  time  specified with the
              postscreen_greet_wait parameter.

       postscreen_greet_banner ($smtpd_banner)
              The text in the  optional  "220-text..."  server  response  that
              postscreen(8) sends ahead of the real Postfix SMTP server's "220
              text..." response, in an attempt to confuse bad SMTP clients  so
              that they speak before their turn (pre-greet).

       postscreen_greet_wait (normal: 6s, overload: 2s)
              The  amount  of  time  that  postscreen(8) will wait for an SMTP
              client to send a command before its turn, and for DNS  blocklist
              lookup results to arrive (default: up to 2 seconds under stress,
              up to 6 seconds otherwise).

       smtpd_service_name (smtpd)
              The internal service that postscreen(8) hands off  allowed  con-
              nections to.

       Available in Postfix version 2.11 and later:

       postscreen_dnsbl_whitelist_threshold (0)
              Allow  a  remote  SMTP  client  to  skip "before" and "after 220
              greeting" protocol tests, based on its combined DNSBL  score  as
              defined with the postscreen_dnsbl_sites parameter.

       Available in Postfix version 2.11 and later:

       postscreen_dnsbl_timeout (10s)
              The time limit for DNSBL or DNSWL lookups.

AFTER 220 GREETING TESTS
       These tests are executed after the remote SMTP client receives the "220
       servername" greeting. If a client passes all tests during  this  phase,
       it  will  receive  a  4XX  response  to all RCPT TO commands. After the
       client reconnects, it will be allowed to talk  directly  to  a  Postfix
       SMTP server process.

       postscreen_bare_newline_action (ignore)
              The  action  that  postscreen(8) takes when a remote SMTP client
              sends a bare newline character, that is, a newline not  preceded
              by carriage return.

       postscreen_bare_newline_enable (no)
              Enable  "bare  newline" SMTP protocol tests in the postscreen(8)
              server.

       postscreen_disable_vrfy_command ($disable_vrfy_command)
              Disable the SMTP VRFY command in the postscreen(8) daemon.

       postscreen_forbidden_commands ($smtpd_forbidden_commands)
              List of commands that the postscreen(8) server considers in vio-
              lation of the SMTP protocol.

       postscreen_helo_required ($smtpd_helo_required)
              Require that a remote SMTP client sends HELO or EHLO before com-
              mencing a MAIL transaction.

       postscreen_non_smtp_command_action (drop)
              The action that postscreen(8) takes when a  remote  SMTP  client
              sends non-SMTP commands as specified with the postscreen_forbid-
              den_commands parameter.

       postscreen_non_smtp_command_enable (no)
              Enable "non-SMTP command" tests in the postscreen(8) server.

       postscreen_pipelining_action (enforce)
              The action that postscreen(8) takes when a  remote  SMTP  client
              sends multiple commands instead of sending one command and wait-
              ing for the server to respond.

       postscreen_pipelining_enable (no)
              Enable "pipelining" SMTP protocol  tests  in  the  postscreen(8)
              server.

CACHE CONTROLS
       postscreen_cache_cleanup_interval (12h)
              The amount of time between postscreen(8) cache cleanup runs.

       postscreen_cache_map (btree:$data_directory/postscreen_cache)
              Persistent storage for the postscreen(8) server decisions.

       postscreen_cache_retention_time (7d)
              The amount of time that postscreen(8) will cache an expired tem-
              porary whitelist entry before it is removed.

       postscreen_bare_newline_ttl (30d)
              The amount of time that postscreen(8) will use the result from a
              successful "bare newline" SMTP protocol test.

       postscreen_dnsbl_ttl (1h)
              The amount of time that postscreen(8) will use the result from a
              successful DNS blocklist test.

       postscreen_greet_ttl (1d)
              The amount of time that postscreen(8) will use the result from a
              successful PREGREET test.

       postscreen_non_smtp_command_ttl (30d)
              The amount of time that postscreen(8) will use the result from a
              successful "non_smtp_command" SMTP protocol test.

       postscreen_pipelining_ttl (30d)
              The amount of time that postscreen(8) will use the result from a
              successful "pipelining" SMTP protocol test.

RESOURCE CONTROLS
       line_length_limit (2048)
              Upon  input,  long  lines  are chopped up into pieces of at most
              this length; upon delivery, long lines are reconstructed.

       postscreen_client_connection_count_limit         ($smtpd_client_connec-
       tion_count_limit)
              How many simultaneous connections  any  remote  SMTP  client  is
              allowed to have with the postscreen(8) daemon.

       postscreen_command_count_limit (20)
              The  limit  on the total number of commands per SMTP session for
              postscreen(8)'s built-in SMTP protocol engine.

       postscreen_command_time_limit (normal: 300s, overload: 10s)
              The  time  limit  to  read   an   entire   command   line   with
              postscreen(8)'s built-in SMTP protocol engine.

       postscreen_post_queue_limit ($default_process_limit)
              The  number  of  clients  that can be waiting for service from a
              real Postfix SMTP server process.

       postscreen_pre_queue_limit ($default_process_limit)
              The number of non-whitelisted clients that can be waiting for  a
              decision  whether  they will receive service from a real Postfix
              SMTP server process.

       postscreen_watchdog_timeout (10s)
              How much time a postscreen(8) process may take to respond  to  a
              remote  SMTP  client  command  or  to  perform a cache operation
              before it is terminated by a built-in watchdog timer.

STARTTLS CONTROLS
       postscreen_tls_security_level ($smtpd_tls_security_level)
              The SMTP TLS security level for the postscreen(8) server; when a
              non-empty value is specified, this overrides the obsolete param-
              eters postscreen_use_tls and postscreen_enforce_tls.

       tlsproxy_service_name (tlsproxy)
              The name of the tlsproxy(8) service entry in master.cf.

OBSOLETE STARTTLS SUPPORT CONTROLS
       These parameters are supported for compatibility with  smtpd(8)  legacy
       parameters.

       postscreen_use_tls ($smtpd_use_tls)
              Opportunistic  TLS:  announce  STARTTLS  support  to remote SMTP
              clients, but do not require that clients use TLS encryption.

       postscreen_enforce_tls ($smtpd_enforce_tls)
              Mandatory TLS: announce STARTTLS support to remote SMTP clients,
              and require that clients use TLS encryption.

MISCELLANEOUS CONTROLS
       config_directory (see 'postconf -d' output)
              The  default  location of the Postfix main.cf and master.cf con-
              figuration files.

       delay_logging_resolution_limit (2)
              The maximal number of digits after the decimal point  when  log-
              ging sub-second delay values.

       command_directory (see 'postconf -d' output)
              The location of all postfix administrative commands.

       max_idle (100s)
              The  maximum  amount of time that an idle Postfix daemon process
              waits for an incoming connection before terminating voluntarily.

       process_id (read-only)
              The process ID of a Postfix command or daemon process.

       process_name (read-only)
              The process name of a Postfix command or daemon process.

       syslog_facility (mail)
              The syslog facility of Postfix logging.

       syslog_name (see 'postconf -d' output)
              The  mail  system  name that is prepended to the process name in
              syslog records, so that "smtpd"  becomes,  for  example,  "post-
              fix/smtpd".

SEE ALSO
       smtpd(8), Postfix SMTP server
       tlsproxy(8), Postfix TLS proxy server
       dnsblog(8), DNS black/whitelist logger
       syslogd(8), system logging

README FILES
       POSTSCREEN_README, Postfix Postscreen Howto

LICENSE
       The Secure Mailer license must be distributed with this software.

HISTORY
       This service was introduced with Postfix version 2.8.

       Many ideas in postscreen(8) were explored in earlier  work  by  Michael
       Tokarev, in OpenBSD spamd, and in MailChannels Traffic Control.

AUTHOR(S)
       Wietse Venema
       IBM T.J. Watson Research
       P.O. Box 704
       Yorktown Heights, NY 10598, USA

                                                                 POSTSCREEN(8)

Im Folgendem wollen wir uns die einzelnen Test einmal genauer betrachten und anschließend unsere individuelle Konfiguration für unseren Postfix SMTP-Mailserver erstellen. Hierzu legen wir uns z.B. am Ende unserer /etc/postfix/main.cf eine neue Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN an.

 # vim /etc/postfix/main.cf
...
 
################################################################################
## POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN
#

erste Schnelltests

black- & whitelist

Einen der ersten tests, die postscreen anstellt ist die Prüfung der Clien-IP-Adresse auf Eintrag eines Eintrags in der Black-/White-Liste. Der Konfigurationsparameter hierzu lautet postscreen_access_list.

Wir tragen also einen Eintrag in unserer neuen Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN hierzu ein.

 # vim /etc/postfix/main.cf
# Django : 2014-10-29 - PERMANENT WHITE/BLACKLIST TEST
# default: postscreen_access_list = permit_mynetworks
postscreen_access_list = permit_mynetworks
                         cidr:/etc/postfix/postscreen_white-blacklist

Wir haben hier also alle Hosts aus mynetworks und eine zusätzliche Cidr-Tabelle /etc/postfix/postscreen_whitelist definiert.

Diese Datei legen wir gleich mal als nächstes an.

 # vim /etc/postfix/postscreen_whitelist
/etc/postfix/postscreen_white-blacklist
# Django : 2014-10-29
# access-Tabelle: Wer wird von postscreen ausgenommen und wer nicht?
# Tabelle zum black- und whitelisten einzelner Hosts auf Basis ihrer 
# IP-Adressen. In der rechten Tabellenspalte können die AKtionen 
# "permit", "reject" und "dunno" gesetzt werden.
# Nach dem Ändern und/oder Erweitern der Tabelle, muß ein
# laufender Postfix über die Änderungen mit einem reload informiert 
# werden: 
#             $ systemctl reload postfix.service
#
# Es muss hier keine Datenbank mit postmap erzeugt werden, da 
# Postfix die ASCII-Konfigurationsdatei direkt auswertet!
#
88.217.171.167/32               permit
 
192.168.2.0/24                  dunno
 
213.183.2.247/32                reject
213.183.9.35/32                 reject

In der rechten Tabellenspalte können folgende drei Aktionen gesetzt werden:

  • permit Es werden keine weiteren postscreen-Test durchgeführt. Die Verbindung wird sofort an einen SMTP-Daemon weitergereicht.
  • dunno Nichts weiter unternehmen und Client zum nächsten Test weiterreichen.
  • reject Client blacklisten und weitere Suche in der Tabelle beenden. Abhängig vom Parameter postscreen_blacklist_action mit der weiteren Bearbeitung der Clientverbindung verfahren.

Den Parameter postscreen_blacklist_action definieren wir nun als nächsten.

 # vim /etc/postfix/main.cf
 # default: postscreen_blacklist_action = ignore
 postscreen_blacklist_action = drop

Hier stehen uns drei Aktionen zur Verfügung:

  • ignore Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.
  • enforce Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode 550 abschliessen. Die Informationen HELO, SENDER und EMPFÄNGER werden gelogged. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.
  • drop Die Verbindung sofort mit einem SMTP-Fehlercode 521 beenden. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.

temporäre whitelist

Als nächstes prüft postscreen, ob der Client einen temporären Whitelisting Eintrag hat; d.h. hat der Client früher schon einmal einen postscreen-Test positiv abgeschlossen.

Will man selbst einen Blick in die temporäre whitelist-Datenbank werfen, so muss man erst mal den Postfix-Daemon stoppen.

 # systemctl stop postfix.service

Anschließend kann man mit Hilfe des Befehls postmap einen Blick in die Datenbank werfen.

 # postmap -s btree:/var/lib/postfix/postscreen_cache
 103.25.223.73   1415110281;1415031447;1417615882;1417615882;1417615882
 104.43.131.15   1415281935;1415199135;1417787536;1417787536;1417787536
 107.170.40.75   1415400834;1415318034;1417906434;1417906434;1417906434
 108.163.243.186 1415369879;1415287079;1417875480;1417875480;1417875480
 ... 

Neben den IP-Adressen findet man dort jede Menge Timestamps, die jedoch nur Postfixintern zu Anwendung kommen und auch sonst nicht weiter von Belang sind.

MX Policy Test

Es ist kein großes Geheimnis, dass SPAMer die im DNS hinterlegten Prioritäten gerne ignorieren und bevorzugt den Backup MX ansprechen. Dies machen sie in der Hoffnung, der Backup MX ist eventuell schlechter gepflegt als der primäre MX.

Der dritte Test, den postscreen anstellt überprüft nun genau, dieses absondere Verhalten dieser Zombie-Clients zu prüfen.

Hat man nur einen MX mit nur einer IP, dann kann man die Standardkonfigurationsoption, die postscreen mitbringt, getrost beibehalten und diesen Test somit überspringen!

Mit der Option postscreen_whitelist_interfaces kann man definieren, auf welchen Interfaces/IP-Adressen das automatische Setzen der Whitelist aktiviert und eben deaktiviert werden soll. Die eben angesprochene Standardoption zeigt auf static:all, also auf alle zur verfügung stehenden IP-Adressen.

Wenn wir nun eine weitere IP-Adresse auf unserem Mailserver binden und im DNS als Backup-MX definieren, können wir quasi einen Pseudo-Backup-MX mimen. Schlägt dann ein Client immer nur bzw. zuerst auf der IP-Adresse des definierten Backup-MX auf, dann ist dies höchstwahrscheinlich ein SPAM-Bot. Solch einen Client wollen wir definitiv nicht bertrauen, sondern diesen immer durch alle Postscreen-Test schicken. Dies erreichen wir mit folgender Konfigurationsoptiom, die wir nun in der Sektion POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN anfügen.

 # vim /etc/postfix/main.cf
...
 
# Django : 2014-10-29 - MAIL EXCHANGER POLICY TESTS
# default: postscreen_whitelist_interfaces = static:all
postscreen_whitelist_interfaces = !88.217.171.167
                                  static:all

Der Eintrag definiert nun, dass das Eintragen in die automatische temporäre Whitelist af allen IP-Adressen/Interfaces erfolgen soll, aber nicht auf der IP-Adresse 88.217.171.167!

WICHTIG:
Das klapp natürlich nur, wenn der alle postscreen-Prozesse von einem master-Daemon gesteuert werden! Möchte man zwischen mehreren Mailservern die temporäre Whitelist sharen, sind zusätzliche Konfigurationsmaßnahmen notwendig!

Konfigurationsbeispiel

  1. memcached installieren, konfigurieren und starten.
     # yum install memcached -y
     # vim /etc/sysconfig/memcached
     # systemctl start memcached
  2. Auf jeden MX-Host in der /etc/postfix/main.cf eintragen unter der Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN :
    postscreen_cache_map = memcache:/etc/postfix/postscreen_cache
    proxy_write_maps = proxy:btree:/var/lib/postfix/postscreen_cache 

    Ferner legen wir die zusätzliche Konfigurationsdatei /etc/postfix/postscreen_cache an.

    # Django : 2014-11-07 postscreen-cache Konfigurationsdatei
    #
    memcache = inet:217.91.103.190:11211
    backup = proxy:btree:/var/lib/postfix/postscreen_cache
    key_format = postscreen:%s

    Anschließend führen wir einen Reload des Postfix-Masterdaemon durch.

     # systemctl reload postfix

Nach diesen ersten Schnelltests für der Postscreen-Daemon noch weitere Tests aus, die man in zwei Gruppen einteilen kann, die wir uns nun noch ansehen und konfigurieren werden.

"Pre 220 SMTP Server Greeting" Tests

Die zweite Gruppe an Tests führt Postscreen aus, noch bevor der SMTP-Daemon die initiale Begrüßung „220 … ESMTP Postfix“ an den Client sendet. Die kurze Verzögerung, meist im Bereich von Sekunden, wird über den Parameter postscreen_greet_wait gesteuert. Besteht der Client diese Vor „220 SMTP Server Greeting“ Tests, erhält der Client einen Eintrag in der temp. whitelisting Tabelle und die aktuelle Verbindung wird vom postscreen-Daemon sofort an einen SMTP-Daemon weitergereicht, der mit der weiteren Annahme und Bewertung der Sendung fortfahren kann.


Dies erfolgt aber nur wenn keine weiteren Nach „220 SMTP Server Greeting“ Tests definiert und aktiviert wurden!

Pregreet Test

Beim ersten Test in dieser Kategorie macht sich postscreen eine weitere Eigenschaft von SPAM-Bots/-Zombies zu nutze. Diese missachten nämlich die RFC-Konformität und versuchen sofort nach der ersten Meldung des Servers, ihren Müll abzuliefern. Der postscreen Daemon sendet erst einmal eine nicht RFC-konformen greeter. Bsp.:

 220-mx01.nausch.org ESMTP Postfix

Dann wartet der Server die mit Paramater postscreen_greet_wait definierte Zeit ab und sendet dann erst den richtigen greeter.

 220 mx01.nausch.org ESMTP Postfix

Erst hier beginnt ein orgnungsgemäßer konfigurierter Mailserver/Client mit dem Dialog. SPAM-Bots/-Zombies hingegen legen meist sofort los und senden nach der ersten Zeile bereits ihren HELO/EHLO, schließlich wollen diese ja in der kurzen Zeit bist die IP-Adresse auf einer Blocklist landet, möglichst viel SPAM versenden. Der postscreen Daemon erkennt dies und führt abhängig vom Parameter postscreen_greet_action die gewählte Aktion aus:

  • ignore Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.
  • enforce Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode 550 abschliessen. Die Informationen HELO, SENDER und EMPFÄNGER werden gelogged. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.
  • drop Die Verbindung sofort mit einem SMTP-Fehlercode 521 beenden. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.

DNSBL-Abfragen und DNSWL-Abfragen

Parallel zu diesem Test, kann der postscreen Daemon bereits mit der Client-IP-Adresse eine oder mehrere Blocklisting-Server oder auch Whitelist-Server befragen. Ähnlich wie mit dem Daemon policyd-weight kann man hier einzelnen Listen eine unterschiedliche Gewichtung zuweisen und so gezielter ein Ergebnis über „hopp“ oder „top“ erlangen. Die Definition der gewählten Listen erfolgt über den Parameter postscreen_dnsbl_sites. Wir ergänzen also die Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN mit den von uns gewählten Listen ein.

 # vim /etc/postfix/main.cf
...
 
# Django : 2014-10-29 - BEFORE 220 GREETING TESTS
# default: postscreen_dnsbl_threshold = 1
postscreen_dnsbl_threshold = 2
#
# default: postscreen_dnsbl_sites =
postscreen_dnsbl_sites = zen.spamhaus.org*2
                         bl.spamcop.net*1
                         b.barracudacentral.org*1

Nutzt man auf Grund der Verwendung bzw. des Mailaufkommens sich eine SPAMHAUS DNSBL Lizenz, trägt man diesen Lizenzstring entsprechend mit an. Bsp:

postscreen_dnsbl_sites = <individueller-spamhaus-lizenzkey>.zen.spamhaus.org*2
                         bl.spamcop.net*1
                         b.barracudacentral.org*1

Damit nun der postscreen-Daemon beim Blocken mit einem 550er Returncode nicht den Lizenzkey <individueller-spamhaus-lizenzkey>.zen.spamhaus.org mitmeldet, müssen wir die Rückmeldung entsprechend „kastrieren“. Wir tragen hierzu in unserer Postscreen-Konfiguration noch folgende Zeile nach.

 # vim /etc/postfix/main.cf
...
 
postscreen_dnsbl_sites = <individueller-spamhaus-lizenzkey>.zen.spamhaus.org*2
                         bl.spamcop.net*1
                         b.barracudacentral.org*1
 
# Django : 2014-11-08 Blocklist-Rückmeldung maskieren
# default: postscreen_dnsbl_reply_map =
postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply

Anschließend legen wir uns noch diese Mapping-Tabelle an.

 # vim /etc/postfix/dnsbl_reply
# Django : 2014-11-08 550er DNSBL Rückmeldung verstecken
<individueller-spamhaus-lizenzkey>.zen.spamhaus.org        zen.spamhaus.org

Der Parameter postscreen_dnsbl_threshold legt fest, ab welcher Punktezahl, in unserem Konfigurationsbeispiel also beim Erreichen des Wertes 2, der postscreen-Daemon tätig werden soll. Dabei stehen uns folgende Aktionen zur Verfügung:

  • ignore Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.
  • enforce Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode 550 abschliessen. Die Informationen HELO, SENDER und EMPFÄNGER werden gelogged. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.
  • drop Die Verbindung sofort mit einem SMTP-Fehlercode 521 beenden. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.

"Post 220 SMTP Server Greeting" Tests

In der dritten und letzten Phase kann postscreen mit seiner internen SMTP-Engine sog. deep protocol Tests anstellen. Diese Tests sind weitaus tiefergehender im SMTP-Protokoll und unterscheiden sich damit wesentlich von den „Pre 220 SMTP Server Greeting-“ und den DNSBL-Tests. Eine wesentliche Einschränkung gibt es bei den „Post 220 SMTP Server Greeting“ Tests, der nicht verschwiegen werden sollte. Ein bisher unbekannter Client muss nach dem erfolgreichen Bestehen der Tests erneut mit dem MX verbinden, da der postscreen-Daemon den bestehenden und bereits begonnenen SMTP-Dialog nicht an einen „richtige“ SMTP-Daemon weiterreichen kann. Postscreen ist kein SMTP-Proxy! Daher muss sich der Client, erneut und hoffentlich mit der gleichen IP-Adresse erneut melden.

Damit es nicht zu unnötigen Verzögerungen kommt, sind folgende Maßnahmen sehr hilfreich:

  • Whitelisting: Bekannte und vertrauenswürdige Absender, die mit verschiedenen IP-Adressen beim Versenden operieren, am besten mit Hilfe des postscreen_dnsbl_whitelist_threshold's die „Pre 220 SMTP Server Greeting-“ und „Post 220 SMTP Server Greeting“ Tests überspringen lassen.
  • Multihome-MX: Hat man nur einen Mailserver, so kann man sich mit folgendem Trick behelfen. Der Mailserver bekommt eine zweite IP-Adresse, die über das DNS als Backup-MX, also mit einer höheren Priorität versehen, veröffentlicht wird. So erhöht man die Rückkehrerquote, ähnlich wie bereits beim Konfigurationsparameter postscreen_whitelist_interfaces.
  • cache-sharing: Bei größeren Installationen mit Hilfe von memcached unbedingt die caching-Daten mit einer groß bemessenen memcache_table teilen! Deteils hierzu sind bereits beim Punkt MX Policy Test beschrieben.
  • 25: die SMTP-Engine von Postscreen unterstützt weder AUTH, XCLIENT noch XFORWARD Funktionen! Werden diese Funktionen auf Port 25 benötigt, dann scheidet der Einsatz der „Post 220 SMTP Server Greeting“-Tests leider aus.
  • Submission: MUAs wird ausschließlich der Submisssion-port 587 zum Einliefern der Nachrichten angeboten. So können diese gezielt die postscreen-tests umgehen.

Wir tragen also einen Eintrag in unserer neuen Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN hierzu ein.

 # vim /etc/postfix/main.cf
 # Django : 2014-10-29 
 # default: postscreen_dnsbl_whitelist_threshold = 0
 postscreen_dnsbl_whitelist_threshold = -1

"Command Pipelining" Tests

Standardmäßig ist ein SMTP-Halbduplex-Protokoll, d.h. der Sender wie auch der Empfänger sendet immer einen Befehl ein Befehl bzw. eine Antwort und wartet dann auf eine Bestätigung/Antwort von der Gegenseite. Die Postscreen interne SMTP-Engine unterdrückt das ESMTP-Kommando Pipelining; d.h. Pipelining wird nicht angeboten. Setzt man nun die Option postscreen_pipelining_enable = yes, so erkenmnt postscreen Mail-Zombies, die Protokollwidrig trotzdem versuchen mehrere befehle auf einmal zu senden.

Wir tragen also einen Eintrag in unserer neuen Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN hierzu ein.

 # vim /etc/postfix/main.cf
 # Django : 2014-10-29 
 # default: postscreen_pipelining_enable = no
 postscreen_pipelining_enable = yes

Folgende Aktionen stehen uns bei positiven Testergebnis zur Verfügung:

  • ignore Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.
  • enforce Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode 550 abschliessen. Die Informationen HELO, SENDER und EMPFÄNGER werden gelogged. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.
  • drop Die Verbindung sofort mit einem SMTP-Fehlercode 521 beenden. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.

"Non-SMTP Command" Tests

Ein weitere Protokollanomalie von SPAM-Bots ist die Verwendung von SMTP-Befehlen oder besser gesagt von nicht SMTP-Befehlen, wie z.B. connect oder exit. Der Postscreen-Daemon greift dabei standardmäßig auf die gleichen verbotenen SMTP-Befehle zurück, wie die der SMTP-Daemons.

Setzt man die Konfigurationsoption postscreen_non_smtp_command_enable = yes erkennt postscreen diese Protokollverstöße und kann entsprechend tätig werden.

Wir tragen also einen Eintrag in unserer neuen Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN hierzu ein.

 # vim /etc/postfix/main.cf
 # Django : 2014-10-29 
 #postscreen_non_smtp_command_enable = no
 postscreen_non_smtp_command_enable = yes

Folgende Aktionen stehen uns bei positiven Testergebnis zur Verfügung:

  • ignore Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.
  • enforce Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode 550 abschliessen. Die Informationen HELO, SENDER und EMPFÄNGER werden gelogged. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.
  • drop Die Verbindung sofort mit einem SMTP-Fehlercode 521 beenden. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.

"Bare Newline" Tests

SMTP ist eine zeilenorientierte Protokoll, d.h. jede gesendete Zeile hat eine begrenzte Länge und wirden mit <CR> <LF> abgeschlossen. Zeile, die nur mit einem <LF>, also einem fehlenden <CR>, abgeschlossen sind, sind laut dem SMTP-Protokoll nicht erlaubt. Viele SPAM-Bots machen aber gerade diese Protokollverstöße. Somit kann Postscreen diese Protokollanomalie erkennen und ja nach Konfiguration eine Entscheidung treffen.

Wir tragen also einen Eintrag in unserer neuen Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN hierzu ein.

 # vim /etc/postfix/main.cf
 # Django : 2014-10-29 
 # default: postscreen_bare_newline_enable = no
 postscreen_bare_newline_enable = yes
 # default: postscreen_bare_newline_action = ignore
 postscreen_bare_newline_action = drop

Folgende Aktionen stehen uns bei positiven Testergebnis zur Verfügung:

  • ignore Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.
  • enforce Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode 550 abschliessen. Die Informationen HELO, SENDER und EMPFÄNGER werden gelogged. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.
  • drop Die Verbindung sofort mit einem SMTP-Fehlercode 521 beenden. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.

main.cf

Im Gesamten ergibt sich nun folgende Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN in unserer Konfigurationsdatei /etc/postfix/main.cf

...
 
################################################################################
## POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN
#
# Django : 2014-10-29 - PERMANENT WHITE/BLACKLIST TEST
# default: postscreen_access_list = permit_mynetworks
postscreen_access_list = permit_mynetworks
                         cidr:/etc/postfix/postscreen_whitelist
#
# default: postscreen_blacklist_action = ignore
postscreen_blacklist_action = drop
 
 
# Django : 2014-10-29 - MAIL EXCHANGER POLICY TESTS
# default: postscreen_whitelist_interfaces = static:all
postscreen_whitelist_interfaces = !88.217.171.167
                                  static:all
 
 
# Django : 2014-10-29 - PRE 220 GREETING TESTS
#
# default: postscreen_greet_banner = $smtpd_banner
#
# default: postscreen_greet_action = ignore
postscreen_greet_action = enforce
 
# default: postscreen_dnsbl_threshold = 1
postscreen_dnsbl_threshold = 2
#
# default: postscreen_dnsbl_sites =
postscreen_dnsbl_sites = zen.spamhaus.org*2
                         bl.spamcop.net*1
                         b.barracudacentral.org*1
                         #swl.spamhaus.org*2
#                        
# default: postscreen_dnsbl_action = ignore
postscreen_dnsbl_action = enforce
 
 
# Django : 2014-10-29 - POST 220 GREETING TESTS
#
# default: postscreen_dnsbl_whitelist_threshold = 0
postscreen_dnsbl_whitelist_threshold = -1
#
# default: postscreen_pipelining_enable = no
postscreen_pipelining_enable = yes
#
# default: postscreen_pipelining_action = enforce
#
# default: postscreen_non_smtp_command_enable = no
postscreen_non_smtp_command_enable = yes
# default: postscreen_non_smtp_command_action = drop
#
# default: postscreen_bare_newline_enable = no
postscreen_bare_newline_enable = yes
#
# default: postscreen_bare_newline_action = ignore
postscreen_bare_newline_action = drop
#

master.cf

Zum Aktivieren unseres Postscreen-Daemon aktivieren wir nun den bereits vorgesehenen Eintrag zu Postscreen bzw. tragen diese nach:

 # vim /etc/postfix/master.cf
#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
#
# Django : 2014-10-29 postscreen
#
smtp      inet  n       -       n       -       1       postscreen
smtpd     pass  -       -       n       -       -       smtpd
  -o smtpd_sasl_auth_enable=no
dnsblog   unix  -       -       n       -       0       dnsblog
tlsproxy  unix  -       -       n       -       0       tlsproxy
 
...

Zur Aktivierung unserer Konfigurationsänderungen führen wir nun noch einen Restart des Postfix-Master DAemon durch.

 # systemctl restart postfix

Den Serverstatus können wir uns nun mit Hilfe des folgenden Aufrufes anzeigen lassen.

 # systemctl status postfix
postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled)
   Active: active (running) since Mon 2014-11-10 20:57:24 CET; 18s ago
  Process: 15133 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
  Process: 15148 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
  Process: 15146 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
  Process: 15143 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
 Main PID: 15221 (master)
   CGroup: /system.slice/postfix.service
           ├─15221 /usr/libexec/postfix/master -w
           ├─15222 pickup -l -t unix -u
           └─15223 qmgr -l -t unix -u

Nov 10 20:57:23 vml000087.dmz.nausch.org systemd[1]: Starting Postfix Mail Transport Agent...
Nov 10 20:57:24 vml000087.dmz.nausch.org postfix/master[15221]: daemon started -- version 2.11.3, configuration /etc/postfix
Nov 10 20:57:24 vml000087.dmz.nausch.org systemd[1]: Started Postfix Mail Transport Agent.

Pass New

Folgender Auszug aus einem Maillog zeigt einen neuen Client der alle Tests bestanden hat.

<code>Nov  8 06:39:36 vml000080 postfix/postscreen[12580]: CONNECT from [66.220.144.178]:27747 to [10.0.0.80]:25
Nov  8 06:39:42 vml000080 postfix/postscreen[12580]: [66.220.144.178]27747: discarding EHLO keywords: DSN
Nov  8 06:39:43 vml000080 postfix/postscreen[12580]: [66.220.144.178]27747: discarding EHLO keywords: DSN
Nov  8 06:39:44 vml000080 postfix/postscreen[12580]: NOQUEUE: reject: RCPT from [66.220.144.178]:27747: 450 4.3.2 Service currently unavailable; from=<postmaster@facebookmail.com>, to=<dmarc-reports@nausch.org>, proto=ESMTP, helo=<mx-out.facebook.com>
Nov  8 06:39:49 vml000080 postfix/postscreen[12580]: PASS NEW [66.220.144.178]:27747
Nov  8 06:39:49 vml000080 postfix/postscreen[12580]: DISCONNECT [66.220.144.178]:27747

Reconnect

Folgender Auszug aus einem Maillog zeigt einen Reconnect eines bereits bekannten Client.

Nov  8 16:24:29 vml000080 postfix/postscreen[23895]: CONNECT from [88.198.212.215]:49376 to [10.0.0.80]:25
Nov  8 16:24:29 vml000080 postfix/postscreen[23895]: PASS OLD [88.198.212.215]:49376

Pregreet und DNSBL

Im folgendem Beispiel sehen wir gleich zwei Ergebnisse. Zum Einen hat der Client nicht abgewartet bis zum vollständigen Begrüßungscode und zum anderen wurde der Schwellwert für die gewichtete DNSBL von 2 erreicht.

Nov  8 16:21:50 vml000080 postfix/postscreen[23895]: CONNECT from [36.224.135.17]:1900 to [10.0.0.80]:25
Nov  8 16:21:50 vml000080 postfix/postscreen[23895]: PREGREET 21 after 0.35 from [36.224.135.17]:1900: HELO 217.91.103.190\r\n
Nov  8 16:21:50 vml000080 postfix/postscreen[23895]: DNSBL rank 2 for [36.224.135.17]:1900
Nov  8 16:21:51 vml000080 postfix/postscreen[23895]: NOQUEUE: reject: RCPT from [36.224.135.17]:1900: 550 5.7.1 Service unavailable; client [36.224.135.17] blocked using zen.spamhaus.org; from=<z2007tw@yahoo.com.tw>, to=<vkihwpdh@yahoo.com.tw>, proto=SMTP, helo=<217.91.103.190>
Nov  8 16:21:51 vml000080 postfix/postscreen[23895]: HANGUP after 1 from [36.224.135.17]:1900 in tests after SMTP handshake
Nov  8 16:21:51 vml000080 postfix/postscreen[23895]: DISCONNECT [36.224.135.17]:1900

Pregreet und COMMAND COUNT LIMIT

Bei folgendem Beispiel sehen wir wiederum einen Preegreet-Verstoß. Weiterhin sehen wir eine Überschreitung beim eingestellten postscreen_command_count_limit von 20.

Nov  3 17:20:10 vml000080 postfix/postscreen[7924]: CONNECT from [50.31.146.101]:46294 to [10.0.0.80]:25
Nov  3 17:20:10 vml000080 postfix/postscreen[7924]: PREGREET 21 after 0.14 from [50.31.146.101]:46294: HELO vps.w21099.com\r\n
Nov  3 17:20:11 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<hotmabox@yahoo.com>, proto=SMTP, helo=<vps.w21099.com>
Nov  3 17:20:11 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<hotmabox@yahoo.com>, proto=SMTP, helo=<vps.w21099.com>
Nov  3 17:20:12 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<hotmabox@hotmail.com>, proto=SMTP, helo=<vps.w21099.com>
Nov  3 17:20:12 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<hotmabox@hotmail.com>, proto=SMTP, helo=<vps.w21099.com>
Nov  3 17:20:13 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<goomabox@gmail.com>, proto=SMTP, helo=<vps.w21099.com>
Nov  3 17:20:13 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<goomabox@gmail.com>, proto=SMTP, helo=<vps.w21099.com>
Nov  3 17:20:13 vml000080 postfix/postscreen[7924]: COMMAND COUNT LIMIT from [50.31.146.101]:46294 after MAIL
Nov  3 17:20:13 vml000080 postfix/postscreen[7924]: DISCONNECT [50.31.146.101]:46294

BARE NEWLINE

Beim letzten Logging-Beispiel sehen wir, dass der Postscreen-Daemon bei einer bestehenden TLS-Session einen Bare Newline Verstoß entdeckt hatte.

Nov  9 17:59:25 vml000080 postfix/tlsproxy[1654]: CONNECT from [85.199.49.140]:40225
Nov  9 17:59:26 vml000080 postfix/tlsproxy[1654]: Anonymous TLS connection established from [85.199.49.140]:40225: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov  9 17:59:58 vml000080 postfix/postscreen[1144]: BARE NEWLINE from [85.199.49.140]:40225 after quit
Nov  9 17:59:58 vml000080 postfix/postscreen[1144]: DISCONNECT [85.199.49.140]:40225
Nov  9 17:59:58 vml000080 postfix/tlsproxy[1654]: DISCONNECT [85.199.49.140]:40225

weitere Beispiele

Weitere Beispiele zu Postscreen und dessen Loggingfunktionalitäten findet man auf der Seite von Wietse Venema.

Will man sich einen generellen Überblick über die Postscreen-Auswirkungen beim Mailverkehr informieren, greift man am besten auf Mailgraph-NG zurück.

BILD: Postscreen Statistik von Mailgraph-NG

Alles in allem kann man festhalten. Mit Hilfe von Postscreen erhöht man nicht nur die Erreichbar- und Verfügbarkeit seines Mailservers, sondern man erreicht auch ähnliche wenn nicht gar bessere SPAM/UCE/Virenmail-Schutz, wie zu früheren Zeiten mit greylisting und policyd-weight. Vor allem die vielen Verzögerungen bei der Mailzustellung, die bei Greylisting bis dato von den Endusern mehr oder minder beklagt wurden, gehören mit Postscreen der Vergangenheit an!

Somit kann man guten Gewissens den Einsatz und dem Vorzug von Postscreen vor Greylisting und policyd-weight vornehmen!

Links


1)
Mail Transfer Agent
Cookies helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. Weitere Information
  • centos/mail_c7/spam_3.txt
  • Zuletzt geändert: 20.04.2018 10:33.
  • (Externe Bearbeitung)