SPAM-Abwehr mit Hilfe von Greylisting
Ein auf SPAM-Versand optimiertes System, wird in aller Regel sehr viel daran gelegen sein, möglichst eine große Anzahl von Nachrichten in möglichst kürzester Zeit zu verschicken. Jede Verzögerung beim SPAM-Versand wird sich äußerst ungünstig auf die Erfolgsquote des Versenders auswirken. Hintergrund beim Thema greylisting ist nun, unbekannte Einlieferer mit einem temporären Fehler abzuweisen und so eine erneute erstmalige Zeitverzögerung zu erzwingen. Vergleichbar mit einer belegten Rufnummer bei einem Faksimilegerät.
Beides, greylisting wie auch policyd-weight setzen auf das PDP1) von Postfix auf. Mit Hilfe des Policy Delegation Protocols besitzt Postfix eine mächtige Schnittstelle, an der u.a. die wichtigsten Merkmale einer angebotenen eMail an eine externe Instanz zur Prüfung und Bewertung weitergegeben wird und anschließend darüber eine Entscheidung mitgeteilt bekommt, was mit der eMail passieren soll.
Für den ersten groben SPAM-Schutz setzen wir auf greylisting-Mechanismen. Greylisting macht es sich zu eigen, das unterschiedliche Verhalten von SPAMern und richtigen Mailservern zu betrachten. Beim greylisting werden folgende vier Schritte durchlaufen bzw. bewertet:
- Der MTA bewertet die drei folgenden technischen Eckdaten eines Zustellversuches, nachdem das einlieferndes System sein RCPT TO: abgesetzt hat:
- Absender-IP-Adresse
- eMail-Adresse des Absenders
- eMail-Adresse des Empfängers
- Das Tripple aus IP-Adresse, Sender- und Empfänger-eMail-Adresse speichert der MTA nun in einer separaten Berkley-DB ab. Ist dieses Tripple neu, d.h. es wurde noch keine eMail von dem Absender an unseren Empfänger von diesem Mailserver eingeliefert, wird diue Annahme erst einmal mit einem temporärer Fehler 4xx abgeweisen.
- Ist der einliefernde Host ein SPAMer wird er die Nachricht verwerfen und sein Glück bei anderen weniger geschützten MTTAs versuchen. Ein richtiger Mailserver wird seine eMail in die deferred-Queue einstellen und nach wenigen Minuten einen erneuten Zustellversuch unternehmen.
- Kommt der einliefernde Mailserver erneut, wird nun das Tripple aus IP-Adresse, Sender- und Empfänger-eMail-Adresse positiv bewertet und unser MTA wird mit der weiteren Prüfung und Bewertung der eMail fortfahren. Ob und wann ein erneuter Zustellversuch unternommen wird, hängt einzig und allein vom Versender ab.
Installation
Für das Thema greylisting greifen wir auf das Paket postgrey von David Schweikert aus dem EPEL-Repository zurück.
Wir installieren also zu erst einmal das betreffende Paket mit Hilfe von YUM.
# yum install postgrey -y
Was uns das RPM alles auf unseren Server gebracht hat, finden wir mit Hilfe des Befehls rpm heraus.
# rpm -qil postgrey
Name : postgrey Version : 1.34 Release : 12.el7 Architecture: noarch Install Date: Wed 05 Nov 2014 12:52:11 PM CET Group : Unspecified Size : 106568 License : GPLv2+ Signature : RSA/SHA256, Sun 16 Feb 2014 08:03:16 PM CET, Key ID 6a2faea2352c64e5 Source RPM : postgrey-1.34-12.el7.src.rpm Build Date : Fri 07 Feb 2014 01:44:13 AM CET Build Host : buildvm-03.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://postgrey.schweikert.ch/ Summary : Postfix Greylisting Policy Server Description : Postgrey is a Postfix policy server implementing greylisting. When a request for delivery of a mail is received by Postfix via SMTP, the triplet CLIENT_IP / SENDER / RECIPIENT is built. If it is the first time that this triplet is seen, or if the triplet was first seen less than 5 minutes, then the mail gets rejected with a temporary error. Hopefully spammers or viruses will not try again later, as it is however required per RFC. /etc/postfix/postgrey_whitelist_clients /etc/postfix/postgrey_whitelist_clients.local /etc/postfix/postgrey_whitelist_recipients /etc/sysconfig/postgrey /usr/lib/systemd/system/postgrey.service /usr/sbin/postgrey /usr/sbin/postgreyreport /usr/share/doc/postgrey-1.34 /usr/share/doc/postgrey-1.34/COPYING /usr/share/doc/postgrey-1.34/Changes /usr/share/doc/postgrey-1.34/README /usr/share/doc/postgrey-1.34/README-rpm /usr/share/man/man8/postgrey.8.gz /var/spool/postfix/postgrey
Konfiguration
Genau genommen müssen wir eigentlich nicht postgrey sondern postfix konfigurieren.
Bei der Grundkonfiguration unseres Postfix-SMTP-Servers hatten wir bereits in der Section SMTP Recipient Restrictions die nötige Konfigurationszeile angelegt. Wir aktivieren also die zugehörige Option check_policy_service unix:postgrey/socket in der Konfigurationsdatei.
# vim /etc/postfix/main.cf
... ################################################################################ ## SMTP RECIPIENT RESTRICTIONS # # Django : 2014-10-29 - Schutz unserer Empfänger mit Hilfe der Recipient # Restrictions # default: smtpd_recipient_restrictions = smtpd_recipient_restrictions = # Postmaster, abuse und andere aufgaben- oder funktionsgebundene # eMail-Adressen (Role-Accounts) whitelisten check_recipient_access btree:/etc/postfix/access_recipient-rfc # Black- und Whitelisting (Kapitel 8.2.3 White- und Blacklisting) check_client_access cidr:/etc/postfix/access_client check_helo_access btree:/etc/postfix/access_helo check_sender_access btree:/etc/postfix/access_sender check_recipient_access btree:/etc/postfix/access_recipient # Unsere eigenen Nutzer zulassen-/erlauben # (Kapitel 8.2.2 Relaying erlauben und verbieten) permit_sasl_authenticated permit_mynetworks # RBL überprüfen (Kapitel 10.11 Realtime Blackhole Lists) reject_rbl_client zen.spamhaus.org reject_rbl_client ix.dnsbl.manitu.net reject_rbl_client bl.spamcop.net reject_rhsbl_client multi.uribl.com # Greylisting via postgrey checken via Unix-Socket # (Kapitel 9.2.5 postgrey installieren) check_policy_service unix:postgrey/socket # Policyd-Weight check over TCP-Connection # (Kapitel 9.3 policyd-weight installieren) # check_client_access btree:/etc/postfix/policyd_weight_client_whitelist, # check_policy_service inet:127.0.0.1:12525 # Dynamische Prüfung auf existente Relay-Empfänger # (Kapitel 12.2.2 Dynamische Empfänger-Verifizierung) reject_unverified_recipient # Backupserver (MX) erlauben permit_mx_backup # alles andere an relaying verbieten # (Kapitel 8.2.2 Relaying erlauben und verbieten) reject_unauth_destination # Quota-Status-Policy-Daemon am Dovecot-Backend-System # Dovecotbuch (ISBN 978-3-95539-74-7) Seite 219 ff. # (Kapitel 11.11 "Der Quota-Policy-Server für Postfix") check_policy_service inet:10.0.0.77:10000 # Zu guter Letzt alles durchlassen, was bis jetzt noch nicht # beanstandet wurde permit
postgrey starten
Beim vorliegenden postgrey-RPM ist neben der Festlegung von User- und Dateirechten auch gleich ein passendes Startupscript installiert worden. Somit reicht ein einfaches service postgrey start aus:
# systemctl start postgrey
Fragen wir nun den Status des Daemon ab erhalten wir den genauen Status angezeigt.
# systemctl status postgrey
postgrey.service - Postfix Greylisting Service
Loaded: loaded (/usr/lib/systemd/system/postgrey.service; disabled)
Active: active (running) since Wed 2014-11-05 13:09:04 CET; 7s ago
Docs: man:postgrey(8)
Process: 6074 ExecStart=/usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket --pidfile=/var/run/postgrey.pid --group=postgrey --user=postgrey --greylist-text=Greylisted for %%s seconds --daemonize $POSTGREY_OPTS (code=exited, status=0/SUCCESS)
Process: 6072 ExecStartPre=/bin/rm -f /var/run/postgrey.pid (code=exited, status=0/SUCCESS)
Main PID: 6076 (/usr/sbin/postg)
CGroup: /system.slice/postgrey.service
└─6076 /usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket --pidfile=/var/run/postgrey.pid --group=postgrey --user=postgrey --greylist-text=Greylisted for %s seconds --daemonize --...
Nov 05 13:09:04 vml000087.dmz.nausch.org systemd[1]: PID file /var/run/postgrey.pid not readable (yet?) after start.
Nov 05 13:09:04 vml000087.dmz.nausch.org postgrey[6076]: Process Backgrounded
Nov 05 13:09:04 vml000087.dmz.nausch.org postgrey[6076]: 2014/11/05-13:09:04 postgrey (type Net::Server::Multiplex) starting! pid(6076)
Nov 05 13:09:04 vml000087.dmz.nausch.org postgrey[6076]: Binding to UNIX socket file "/var/spool/postfix/postgrey/socket"
Nov 05 13:09:04 vml000087.dmz.nausch.org postgrey[6076]: Setting gid to "996 996"
Nov 05 13:09:04 vml000087.dmz.nausch.org postgrey[6076]: Setting uid to "996"
Nov 05 13:09:04 vml000087.dmz.nausch.org systemd[1]: Started Postfix Greylisting Service.
Auch im Maillog finden wir diese Zeilen wieder.
# less /var/log/maillog
Nov 5 13:09:04 vml000087 postgrey[6076]: Process Backgrounded Nov 5 13:09:04 vml000087 postgrey[6076]: 2014/11/05-13:09:04 postgrey (type Net::Server::Multiplex) starting! pid(6076) Nov 5 13:09:04 vml000087 postgrey[6076]: Binding to UNIX socket file "/var/spool/postfix/postgrey/socket" Nov 5 13:09:04 vml000087 postgrey[6076]: Setting gid to "996 996" Nov 5 13:09:04 vml000087 postgrey[6076]: Setting uid to "996"
Mit einem Blick in die Prozessliste können wir uns vergewissern, ob der daemon auch gestartet wurde:
# ps auxw | grep postgrey
postgrey 6076 0.0 1.3 171852 14032 ? Ss 13:09 0:00 /usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket --pidfile=/var/run/postgrey.pid --group=postgrey --user=postgrey --greylist-text=Greylisted for %s seconds --daemonize --delay=60
Damit nun unser Diesnt beim Starten automatisch starten, sorgen wir mit folgendem Aufruf.
# systemctl enable postgrey
ln -s '/usr/lib/systemd/system/postgrey.service' '/etc/systemd/system/multi-user.target.wants/postgrey.service'
Wollen wir überprüfen ob der Dienst automatisch startet, verwenden wir folgenden Aufruf.
# systemctl is-enabled postgrey
enabled
Die Rückmeldung enabled zeigt an, dass der Dienst automatisch startet; ein disabled zeigt entsprechend an, dass der Dienst nicht automatisch startet.
postgrey Administration
Die Konfigurationsdateien rund um postgrey befinden sich im Verzeichnis /etc/postfix/:
# ll /etc/postfix/postgrey*
-rw-r--r--. 1 root root 8343 May 4 2011 /etc/postfix/postgrey_whitelist_clients -rw-r--r--. 1 root root 59 Feb 7 2014 /etc/postfix/postgrey_whitelist_clients.local -rw-r--r--. 1 root root 188 May 4 2011 /etc/postfix/postgrey_whitelist_recipients
Die Konfigurationsdateien im Verzeichnis /etc/postfix/ haben folgende Bedeutung bzw. werden für folgende Funktionen benötigt:
- postgrey_whitelist_clients Tabelle zur Definition von Ausnahmeregeln beim Greylisting-Daemon, die bestimmte Absender whitelisted.
# less /etc/postfix/postgrey_whitelist_clients
# postgrey whitelist for mail client hostnames # -------------------------------------------- # put this file in /etc/postfix or specify its path # with --whitelist-clients=xxx # # postgrey version: 1.34, build date: 2011-05-04 # greylisting.org: Southwest Airlines (unique sender, no retry) southwest.com # greylisting.org: isp.belgacom.be (wierd retry pattern) isp.belgacom.be # greylisting.org: Ameritrade (no retry) ameritradeinfo.com # greylisting.org: Amazon.com (unique sender with letters) amazon.com # 2004-05-20: Linux kernel mailing-list (unique sender with letters) vger.kernel.org # 2004-06-02: karger.ch, no retry karger.ch # 2004-06-02: lilys.ch, (slow: 4 hours) server-x001.hostpoint.ch # 2004-06-09: roche.com (no retry) gw.bas.roche.com # 2004-06-09: newsletter (no retry) mail.hhlaw.com # 2004-06-09: no retry (reported by Ralph Hildebrandt) prd051.appliedbiosystems.com # 2004-06-17: swissre.com (no retry) swissre.com # 2004-06-17: dowjones.com newsletter (unique sender with letters) returns.dowjones.com # 2004-06-18: switch.ch (works but personnel is confused by the error) domin.switch.ch # 2004-06-23: accor-hotels.com (slow: 6 hours) accor-hotels.com # 2004-06-29: rr.com (no retry, reported by Duncan Hill) /^ms-smtp.*\.rr\.com$/ # 2004-06-29: cox.net (no retry, reported by Duncan Hill) /^lake.*mta.*\.cox\.net$/ # 2004-06-29: motorola.com (no retry) mot.com # 2004-07-01: nic.fr (address verification, reported by Arnaud Launay) nic.fr # 2004-07-01: verizon.net (address verification, reported by Bill Moran and Eric, adapted by Adam C. Mathews) /^s[cv]\d+pub\.verizon\.net$/ # 2004-07-02: cs.columbia.edu (no retry) cs.columbia.edu # 2004-07-02: papersinvited.com (no retry) 66.216.126.174 # 2004-07-02: telekom.de (slow: 6 hours) /^mail\d+\.telekom\.de$/ # 2004-07-04: tiscali.dk (slow: 12 hours, reported by Klaus Alexander Seistrup) /^smtp\d+\.tiscali\.dk$/ # 2004-07-04: freshmeat.net (address verification) freshmeat.net # 2004-07-11: zd-swx.com (unique sender with letters, reported by Bill Landry) zd-swx.com # 2004-07-11: lockergnome.wc09.net (unique sender with letters, reported by Bill Landry) lockergnome.wc09.net # 2004-07-19: mxlogic.net (no retry, reported by Eric) p01m168.mxlogic.net p02m169.mxlogic.net # 2004-09-08: intel.com (pool on different subnets) /^fmr\d+\.intel\.com$/ # 2004-09-17: cox-internet.com (no retry, reported by Rod Roark) /^fe\d+\.cox-internet\.com$/ # 2004-10-11: logismata.ch (no retry) logismata.ch # 2004-11-25: brief.cw.reum.de (no retry, reported by Manuel Oetiker) brief.cw.reum.de # 2004-12-03: ingeno.ch (no retry) qmail.ingeno.ch # 2004-12-06: rein.ch (no retry) mail1.thurweb.ch # 2005-01-26: tu-ilmenau.de (no retry) piggy.rz.tu-ilmenau.de # 2005-04-06: polymed.ch (no retry) mail.polymed.ch # 2005-06-08: hu-berlin.de (slow: 6 hours, reported by Joachim Schoenberg) rz.hu-berlin.de # 2005-06-17: gmail.com (big pool, reported by Beat Mueller) proxy.gmail.com # 2005-06-23: cacert.org (address verification, reported by Martin Lohmeier) cacert.org # 2005-07-27: polytech.univ-mrs.fr (no retry, reported by Giovanni Mandorino) polytech.univ-mrs.fr # 2005-08-05: gnu.org (address verification, reported by Martin Lohmeier) gnu.org # 2005-08-17: ciphirelabs.com (needs fast responses, reported by Sven Mueller) cs.ciphire.net # 2005-11-11: lufthansa (no retry, reported by Peter Bieringer) /^gateway\d+\.np4\.de$/ # 2005-11-23: arcor-online.net (slow: 12 hours, reported by Bernd Zeimetz) /^mail-in-\d+\.arcor-online\.net$/ # 2005-12-29: netsolmail.com (no retry, reported by Gareth Greenaway) netsolmail.com # mail.likopris.si (no retry, reported by Vito Robar) 193.77.153.67 # jcsw.nato.int (several servers, no retry, reported by Vito Robar) 195.235.39 # tesla.vtszg.hr (no retry, reported by Vito Robar) tesla.vtszg.hr # mailgw*.iai.co.il (pool of several servers, reported by Vito Robar) /^mailgw.*\.iai\.co\.il$/ # gw.stud-serv-mb.si (no retry, reported by Vito Robar) gw.stud-serv-mb.si # mail.commandtech.com (no retry, reported by Vito Robar) 216.238.112.99 # duropack.co.at (no retry, reported by Vito Robar) 193.81.20.195 # mail.esimit-tech.si (no retry, reported by Vito Robar) 193.77.126.208 # mail.resotel.be (ocasionally no retry, reported by Vito Robar) 80.200.249.216 # mail2.alliancefr.be (ocasionally no retry, reported by Vito Robar) mail2.alliancefr.be # webserver.turboinstitut.si (no retry, reported by Vito Robar) webserver.turboinstitut.si # mil.be (pool of different servers, reported by Vito Robar) 193.191.218.141 193.191.218.142 193.191.218.143 194.7.234.141 194.7.234.142 194.7.234.143 # mail*.usafisnews.org (no retry, reported by Vito Robar) /^mail\d+\.usafisnews\.org$/ # odk.fdv.uni-lj.si (no retry, reported by Vito Robar) /^odk.fdv.uni-lj.si$/ # rak-gentoo-1.nameserver.de (no retry, reported by Vito Robar) rak-gentoo-1.nameserver.de # dars.si (ocasionally no retry, reported by Vito Robar) mx.dars.si # cosis.si (no retry, reported by Vito Robar) 213.143.66.210 # mta?.siol.net (sometimes no or slow retry; they use intermail, reported by Vito Robar) /^mta[12].siol.net$/ # pim-N-N.quickinspirationsmail.com (unique sender, reported by Vito Robar) /^pim-\d+-\d+\.quickinspirationsmail\.com$/ # flymonarch (no retry, reported by Marko Djukic) flymonarch.com # wxs.nl (no retry, reported by Johannes Fehr) /^p?smtp.*\.wxs\.nl$/ # ibm.com (big pool, reported by Casey Peel) ibm.com # messagelabs.com (big pool, reported by John Tobin) /^mail\d+\.messagelabs\.com$/ # ptb.de (slow, reported by Joachim Schoenberg) berlin.ptb.de # registrarmail.net (unique sender names, reported by Simon Waters) registrarmail.net # google.com (big pool, reported by Matthias Dyer, Martin Toft) google.com # orange.fr (big pool, reported by Lo�c Le Loarer) /^smtp\d+\.orange\.fr$/ # citigroup.com (slow retry, reported by Michael Monnerie) /^smtp\d+.citigroup.com$/ # cruisingclub.ch (no retry) mail.ccs-cruising.ch # digg.com (no retry, Debian #406774) diggstage01.digg.com # liberal.ca (retries only during 270 seconds, Debian #406774) smtp.liberal.ca # pi.ws (pool + long retry, Debian #409851) /^mail[12]\.pi\.ws$/ # rambler.ru (big pool, reported by Michael Monnerie) rambler.ru # free.fr (big pool, reported by Denis Sacchet) /^smtp[0-9]+-g[0-9]+\.free\.fr$/ /^postfix[0-9]+-g[0-9]+\.free\.fr$/ # thehartford.com (pool + long retry, reported by Jacob Leifman) /^netmail\d+\.thehartford\.com$/ # abb.com (only one retry, reported by Roman Plessl) /^nse\d+\.abb\.com$/ # 2007-07-27: sourceforge.net (sender verification) lists.sourceforge.net # 2007-08-06: polytec.de (no retry, reported by Patrick McLean) polytec.de # 2007-09-06: qualiflow.com (no retry, reported by Alex Beckert) /^mail\d+\.msg\.oleane\.net$/ # 2007-09-07: nrl.navy.mil (no retry, reported by Axel Beckert) nrl.navy.mil # 2007-10-18: aliplast.com (long retry, reported by Johannes Feigl) mail.aliplast.com # 2007-10-18: inode.at (long retry, reported by Johannes Feigl) /^mx\d+\..*\.inode\.at$/ # 2008-02-01: bol.com (no retry, reported by Frank Breedijk) /^.*?.server.arvato-systems.de$/ # 2008-06-05: registeredsite.com (no retry, reported by Fred Kilbourn) /^(?:mail|fallback-mx)\d+.atl.registeredsite.com$/ # 2008-07-17: mahidol.ac.th (no retry, reported by Alex Beckert) saturn.mahidol.ac.th # 2008-07-18: ebay.com (big pool, reported by Peter Samuelson) ebay.com # 2008-07-22: yahoo.com (big pool, reported by Juan Alonso) yahoo.com # 2008-11-07: facebook (no retry, reported by Tim Freeman) /^outmail\d+\.sctm\.tfbnw\.net$/ # 2009-02-10: server14.cyon.ch (long retry, reported by Alex Beckert) server14.cyon.ch # 2009-08-19: 126.com (big pool) /^m\d+-\d+\.126\.com$/ # 2010-01-08: tifr.res.in (no retry, reported by Alex Beckert) home.theory.tifr.res.in # 2010-01-08: 1blu.de (long retry, reported by Alex Beckert) ms4-1.1blu.de # 2010-03-17: chello.at (big pool, reported by Jan-willem van Eys) /^viefep\d+-int\.chello\.at$/ # 2010-05-31: nic.nu (long retry, reported by Ivan Sie) mx.nic.nu # 2010-06-10: Microsoft servers (long/no retry, reported by Roy McMorran) bigfish.com frontbridge.com microsoft.com # 2010-06-18: Google/Postini (big pool, reported by Warren Trakman) postini.com # 2011-02-04: evanzo-server.de (no retry, reported by Andre Hoepner) /^mx.*\.evanzo-server\.de$/ # 2011-05-02: upcmail.net (big pool, reported by Michael Monnerie) upcmail.net
- postgrey_whitelist_clients.local Tabelle zur Definition von lokalen Ausnahmeregeln beim Greylisting-Daemon. Bei Bedarf wird man hier in dieser Tabelle individuelle Definitionen vornehmen.
# vim /etc/postfix/postgrey_whitelist_clients.local
# Clients that should not be greylisted. See postgrey(8). # 2008-10-08: 1und1.com (big pool, inserted by Django) #moutng.kundenserver.de /^.*\.kundenserver\.de$/
- postgrey_whitelist_recipients Tabelle zur Definition von Ausnahmeregeln beim Greylisting-Daemon, die bestimmte Empfänger whitelisted. In der Regel sind die Role-Accounts, wie abuse@, postmaster@ oder swat@.
# vim /etc/postfix/postgrey_whitelist_recipients
# postgrey whitelist for mail recipients # -------------------------------------- # put this file in /etc/postfix or specify its path # with --whitelist-recipients=xxx postmaster@ abuse@
Nach Änderungen an den Postgrey Ausnahmelisten postgrey_whitelist_clients.local und postgrey_whitelist_recipients ist der Daemon von den Änderungen mit einem reload in Kenntnis zu setzen!
# systemctl restart postgrey
erfolgreiches Greylisting
Am nachfolgenden Beispiel sehen wir, dass ein Connectversuch von einem uns unbekanntem Mailserver erst einmal mit einem 450er abgewiesen wird und später nocheinmal zugestellt werden soll.
Oct 12 04:35:39 nss postfix/smtpd[16118]: connect from mail04.mytoys-mail.de[213.61.120.248]
Oct 12 04:35:41 nss postgrey[8228]: action=greylist, reason=new, client_name=mail04.mytoys-mail.de, client_address=213.61.120.248, sender=newsletter@mytoys-mail.de, recipient=wtlbrft@nausch.org
Oct 12 04:35:41 nss postgrey[8228]: cleaning up old logs...
Oct 12 04:35:41 nss postfix/smtpd[16118]: NOQUEUE: reject: RCPT from mail04.mytoys-mail.de[213.61.120.248]: 450 4.2.0 <wtlbrft@nausch.org>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/nausch.org.html; from=<newsletter@mytoys-mail.de> to=<wtlbrft@nausch.org> proto=ESMTP helo=<mail04.mytoys-mail.de>
Oct 12 04:35:41 nss postfix/smtpd[16118]: disconnect from mail04.mytoys-mail.de[213.61.120.248]
Beim nächsten Zustellversuch wird die eMail dann entsprechend akzeptiert:
Oct 12 11:28:39 nss postfix/smtpd[21938]: connect from mail04.mytoys-mail.de[213.61.120.248] Oct 12 11:28:41 nss postgrey[8228]: action=pass, reason=triplet found, delay=24780, client_name=mail04.mytoys-mail.de, client_address=213.61.120.248, sender=newsletter@mytoys-mail.de, recipient=wtlbrft@nausch.org Oct 12 11:28:41 nss postfix/smtpd[21938]: 4EA6476022D: client=mail04.mytoys-mail.de[213.61.120.248] Oct 12 11:28:41 nss postfix/cleanup[21942]: 4EA6476022D: message-id=<200810120235.m9C2Zceo068208@mail04.mytoys-mail.de> Oct 12 11:28:41 nss postfix/qmgr[8783]: 4EA6476022D: from=<newsletter@mytoys-mail.de>, size=80786, nrcpt=1 (queue active) Oct 12 11:28:41 nss postfix/local[21943]: 4EA6476022D: to=<wtlbrft@nausch.org>, relay=local, delay=2.1, delays=2/0.02/0/0.06, dsn=2.0.0, status=sent (delivered to mailbox) Oct 12 11:28:41 nss postfix/qmgr[8783]: 4EA6476022D: removed Oct 12 11:31:13 nss postfix/smtpd[21938]: disconnect from mail04.mytoys-mail.de[213.61.120.248]
graphische Statistiken Greylisting
Will man sich einen generellen Überblick über die Greylisting-Auswirkungen beim Mailverkehr informieren, greift man am besten auf Mailgraph-NG zurück.
FAZIT
Postgrey hat sich in der Abwehr von SPAM und anderen unerwünschten Verkehrs bestens bewährt, kann so doch jede Menge des unerwünschten Traffics abgelehnt werden.
Da es aber bei der initilaen Kontaktaufnahme immer zu ca. 5 Minuten Verzögerung oder auch mehr kommt, sind viele Anwender unglücklich, wenn z.B. eine telefonisch avisierte Nachricht nicht sofort zugestellt wird. Auch bei sporadischer Kontaktaufnahme kommt es bisweilen zu Verzögerungen.
Mittlerweilen erzielt man mit entsprechend konfigurierten postscreen ähnlich gute Ergebnisse wie mit greylisting.
summa sumarum:
In Zeiten von immer stärkeren Echtzeitkommunikationswünschen seiten der Anwender/Kunden, setzt man statt auf greylisting nunmehr besser auf postscreen!
Links
1)
Policy Delegation Protocol
127.0.0.1