senderbase poor seit postfix umstellung

bulb82

New Member
Ein fröhliches Hallo in die Runde.

Wir haben Ende Juni unseren Mail-Dienst von Qmail auf Postfix umgestellt. Seit der umstellung werden wir von senderbase.org als poor eingestuft. Daher können wir keine Mails mehr an Dell.com oder avnet.com senden. Die letzte E-Mail ging laut Logs noch über Qmail raus.

E-Mail-Versendet
Code:
Jun 28 09:40:18 s15440429 qmail-remote-handlers[4815]: from=***@gryps.de
Jun 28 09:40:18 s15440429 qmail-remote-handlers[4815]: to=***@avnet.com
Jun 28 09:40:18 s15440429 qmail-remote-handlers[4815]: hook_dir = '/usr/local/psa/handlers/before-remote'
Jun 28 09:40:18 s15440429 qmail-remote-handlers[4815]: recipient[3] = '***@avnet.com'
Jun 28 09:40:18 s15440429 qmail-remote-handlers[4815]: handlers dir = '/usr/local/psa/handlers/before-remote/recipient/***@avnet.com'
Jun 28 09:40:21 s15440429 qmail: 1309246821.526532 delivery 3466: success: 12.9.139.96_accepted_message./Remote_host_said:_250_ok:__Message_359633202_accepted/
Jun 28 09:40:21 s15440429 qmail: 1309246821.527151 status: local 0/10 remote 0/20
Jun 28 09:40:21 s15440429 qmail: 1309246821.527314 end msg 12700500

Seit der umstellung bekomme ich im maillog folgende Fehlermeldung:
Code:
Jun 30 15:46:11 s15440429 postfix/smtp[7222]: D2985787189B: host smtp.ins.Dell.com[143.166.224.193] refused to talk to me: 554-ps-smtp.us.dell.com 554 Connections from this sending hostname s15440429.onlinehome-server.info, IP address of: 212.227.141.104 are being rejected due to low SenderBase Reputation score (below -2). Your SenderBase organization: None. See http://www.senderbase.org/ for more information.

Eine Anfrage über Telnet auf den Dell Server liefert folgendes zurück
Code:
[root@s15440429 ~]# telnet 143.166.83.183 25
Trying 143.166.83.183...
Connected to 143.166.83.183.
Escape character is '^]'.
554-pc-smtp.us.dell.com
554 Connections from this sending hostname mail.gryps.de, IP address of: 212.227.141.104 are being rejected due to low SenderBase Reputation score (below -2). Your SenderBase organization: 3772893. See http://www.senderbase.org/ for more information.
Connection closed by foreign host.

Jetzt frag ich mich natürlich, warum sind wir nun als poor eingestuft.Siehe Link mit der entsprechenden IP 212.227.141.104

Jetzt hab ich das Gefühl, dass eventuell etwas an meiner Postfix-Konfiguration nicht stimmt.

main.cf
Code:
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
mail_owner = postfix
myhostname = mail.gryps.de
inet_interfaces = all
mydestination = localhost.$mydomain, localhost, localhost.localdomain
unknown_local_recipient_reject_code = 550
alias_maps = hash:/etc/aliases, hash:/var/spool/postfix/plesk/aliases
alias_database = hash:/etc/aliases
debug_peer_level = 2
debugger_command =
	 PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
	 xxgdb $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.3.3/samples
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
inet_protocols = all
virtual_mailbox_domains = $virtual_mailbox_maps, hash:/var/spool/postfix/plesk/virtual_domains
virtual_alias_maps = $virtual_maps, hash:/var/spool/postfix/plesk/virtual
virtual_mailbox_maps = hash:/var/spool/postfix/plesk/vmailbox
transport_maps = hash:/var/spool/postfix/plesk/transport
smtpd_tls_cert_file = /etc/postfix/postfix_default.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_security_level = may
smtpd_use_tls = yes
smtp_tls_security_level = may
smtp_use_tls = no
smtpd_timeout = 3600s
smtpd_proxy_timeout = 3600s
disable_vrfy_command = yes
mynetworks = 127.0.0.0/8 [::1]/128
smtpd_sender_restrictions = check_sender_access hash:/var/spool/postfix/plesk/blacklists, permit_sasl_authenticated, check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
smtp_send_xforward_command = yes
smtpd_authorized_xforward_hosts = 127.0.0.0/8 [::1]/128
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_mynetworks, check_client_access pcre:/var/spool/postfix/plesk/no_relay.re, permit_sasl_authenticated, reject_unauth_destination
virtual_mailbox_base = /var/qmail/mailnames
virtual_uid_maps = static:110
virtual_gid_maps = static:31
virtual_transport = plesk_virtual
plesk_virtual_destination_recipient_limit = 1
mailman_destination_recipient_limit = 1
smtpd_client_restrictions = 
message_size_limit = 40960000

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").
#
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - n - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025
#submission inet n - n - - smtpd
# -o smtpd_enforce_tls=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#smtps inet n - n - - smtpd
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#628 inet n - n - - qmqpd
pickup fifo n - n 60 1 pickup -o content_filter=smtp:127.0.0.1:10027
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 1 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
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}
#
# The Cyrus deliver program has changed incompatibly, multiple times.
#
old-cyrus unix - n n - - pipe
flags=R user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -m ${extension} ${user}
# Cyrus 2.1.5 (Amos Gouaux)
# Also specify in main.cf: cyrus_destination_recipient_limit=1
cyrus unix - n n - - pipe
user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -r ${sender} -m ${extension} ${user}
#
# See the Postfix UUCP_README file for configuration details.
#
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
#
# Other external delivery methods.
#
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

plesk_virtual unix - n n - - pipe flags=DORhu user=popuser:popuser argv=/usr/lib64/plesk-9.0/postfix-local -f ${sender} -d ${recipient} -p /var/qmail/mailnames
mailman unix - n n - - pipe flags=R user=mailman:mailman argv=/usr/lib64/plesk-9.0/postfix-mailman ${nexthop} ${user} ${recipient}
127.0.0.1:10025 inet n n n - - spawn user=mhandlers-user argv=/usr/lib64/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue
127.0.0.1:10026 inet n - n - - smtpd -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions= -o receive_override_options=no_unknown_recipient_checks
127.0.0.1:10027 inet n n n - - spawn user=mhandlers-user argv=/usr/lib64/plesk-9.0/postfix-queue 127.0.0.1 10026 before-remote
plesk_saslauthd unix y y n - 1 plesk_saslauthd status=5 listen=6 dbpath=/var/spool/postfix/plesk/passwd.db


smtps inet n - n - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025 -o smtpd_tls_wrappermode=yes

Hat jemand eine Idee woran es liegen könnte?
Gibt es eine Möglichkeit den Grund für die Sperrung bei senderbase herauszufinden?
 
Beim kurzen Überfliegen konnte ich jetzt spontan nichts verdächtiges erkennen.
Kannst du mir eine kurze Testmail schicken (Mailadresse bekommst du per PN)?
Anhand der Header kann ich besser beurteilen, was schlecht oder gut ist - und bei meinen eigenen Systemen weiß ich auch, welche Header von mir und welche vom entfernten System sind ;)
 
Hallo Lord Gurke,

du haste eine E-Mail bekommen. Den Header dazu auch noch mal hier:
Code:
From ***@***.de  Thu Jul 14 08:07:55 2011
Return-Path: <***@***.de>
X-Original-To: ***@***.de
Delivered-To: ***@***.de
Received: from s15219798.onlinehome-server.info (unknown [127.0.0.1])
	by s15219798.onlinehome-server.info (Postfix) with ESMTP id 7E08682F0005
	for <***@***.de>; Thu, 14 Jul 2011 06:07:55 +0000 (UTC)
Received: from mail.gryps.de (unknown [212.227.141.104])
	by s15219798.onlinehome-server.info (Postfix) with ESMTP
	for <***@***.de>; Thu, 14 Jul 2011 06:07:55 +0000 (UTC)
Received: from mail.gryps.de (localhost.localdomain [127.0.0.1])
	by mail.gryps.de (Postfix) with ESMTP id 5347F7871896;
	Thu, 14 Jul 2011 08:07:55 +0200 (CEST)
Received: from gcw8k.gryps.local (p5B289B76.dip0.t-ipconnect.de [91.40.155.118])
	by mail.gryps.de (Postfix) with ESMTP;
	Thu, 14 Jul 2011 08:07:55 +0200 (CEST)
Received: from gcw8k.gryps.local ([fe80::4975:d6e1:b13:8a9f]) by
 gcw8k.gryps.local ([fe80::4975:d6e1:b13:8a9f%10]) with mapi; Thu, 14 Jul 2011
 08:07:54 +0200
From: "***" <***@gryps.de>
To: "***" <***@***.de>
CC: "***@***.de" <***@***.de>
Date: Thu, 14 Jul 2011 08:07:50 +0200
Subject: =?iso-8859-1?Q?Header_f=FCr_mehr_Infos?=
Thread-Topic: =?iso-8859-1?Q?Header_f=FCr_mehr_Infos?=
Thread-Index: AcxB7FyFm1X39Zl/R+GcmQLn7Bb01Q==
Message-ID: <4EE0A8BAC0489C429F59905A25154FA5359E73144B@gcw8k.gryps.local>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: multipart/alternative;
	boundary="_000_4EE0A8BAC0489C429F59905A25154FA5359E73144Bgcw8kgrypsloc_"
MIME-Version: 1.0
 
Moin, moin,

ich habe nun folgendes herausgefunden. Einer unserer Kunden auf unserem Server beantwortet Spam-E-Mails mit Antwort-E-Mails in dem er die Kunden informiert, dass er Spam E-Mails versendet. Die E-Mail über die er diese sendet, aht jedoch kein Postfach.
Jetzt spiel unser Server mit dem anderen Server Ping-Pong. Jetzt stell sich für mich jedoch die Frage, ob dies eventuell auch ein Auslöser für eine schlechte Reputation sein kann?

Es ist sicher keine Lösung, aber kann man doch machen, oder?
 
Der Reply, daß Spam versandt werden, ist sicherlich ein Grund für eine schlechte Reputation - geht ja schließlich i.d.R. an jemanden, der den Spam gar nicht geschickt hat. Siehe hierzu auch Backscatter
Würde dein Server mir diese Spam-Replys schicken, würde ich ihn übrigens vermutlich auch blacklisten...
 
Wie trennt man aber dann die Sinnvollen Antworten vom Spam. Eigentlich soll man doch auch ein Softbounce senden, wenn die Adresse nicht existiert, oder das Postfach voll ist?
Bei dem Kunden sind es ca. 7-10mails am Tag. Kann mir nicht vorstellen, dass dies das problem auslöst.
 
Ich denke, dein Kunde hat einen Autoreply für als Spam erkannte Mails? Hast du zumindest so beschrieben. Und das ist absolut sinnfrei, da geschätzte 99,99% aller Spams mit gefakten Absender-Adressen verschickt werden - der Reply geht also an den Falschen.
Und es spielt auch nicht die Menge die entscheidende Rolle, sondern, daß dein Server diese Replys versendet (ist ja auch eine Art Backscatter).
 
Wie trennt man aber dann die Sinnvollen Antworten vom Spam. Eigentlich soll man doch auch ein Softbounce senden, wenn die Adresse nicht existiert, oder das Postfach voll ist?

AFAIK, soll man nach den Backscatter-"Regeln" sowas hart rejecten - sprich die Mail bleibt in der Mail-Queue des Sender-MTA. Es gibt IMHO auch keinen Grund warum sich Dein MTA darum kümmern soll.
 
Solltest du die Mail annehmen (der Check, ob der Empfänger existiert, sollte natürlich gelaufen sein), weil du sie erst danach durch den Spamfilter jagst, dann erzeuge keinen Bounce, wenn die Mail als Spam identifiziert wurde (steck sie in einen Spam-Ordner oder wenn der User es so will, kannst du sie auch löschen - nur eine Antwort versenden solltest du dann in keinem Fall).
 
Senderbase Reputation

Hallo,

ich habe aktuell das gleiche Problem. Bin seit zwei Wochen mit der Reputation auf poor gesetzt worden. Bei mir war der Auslöser wohl ein PLESK inkl. Qmail Update. Dabei wurde der Hostname verstümmelt (PLESK Bug :mad:). Habe das erst nach einem Tag gemerkt. Das hat wohl gereicht um auf die "böse Liste" zu kommen. Ich habe mich dann an den SenderbaseSupport <support@senderbase.org> gewendet und von dem "kleinen Unfall" erzählt. Man antwortete mir folgendes:

IP 87.106.x.x has a poor reputation because it has rDNS association to a generic webhosting server (s1532xxxx.onlinehome-server.info). Webhosting servers should not be sending mailout directly as they are intended for webhosting. In general, your mail should be going out through an email dedicated IP/mail server. If onlinehome-server.info is hosting for you (mydomain.de) they should be directing the outbound mail for the website through some type of smarthost system such the the mail goes out through a dedicated mail server. If you are hosting the site yourself, we suggest getting a separate IP with fwd/rev DNS to mydomain.de and making sure that all mail sent from the IP has a matching helo string to the rDNS of the IP, this will ensure authenticated SMTP mail delivery.

I see that mydomain.de has fwd DNS to the IP, however, the IP actually has fwd/rev DNS to s1532xxxx.onlinehome-server.info

Once these issues are addressed, the reputation of the IP should improve within 3 days.

Da ich natürlich nicht für jede Domain eine eigene IP mit eigenem rDNS einstellen kann, war meine Idee, in die Zone der Domain als Mailserver der Domain: s1532xxxx.onlinehome-server.info. einzutragen. Auf diese Weise Ist der Hostname und der rDNS auf den MX gleich. Vorher hatte ich für beispiel.de auch immer beispiel.de als Mailserver angegeben. In dem Fall ist dann der rDNS und der Hostname nicht mehr identisch. Ich denke mal das hat zu dem poor scoring geführt. Sicher bin ich noch nicht, da ich das heute erst umgestellt habe. Werde aber den SenderbaseSupport dazu noch mal befragen ob das so richtig ist. Was meint ihr?
 
Ändern den Reverse-DNS-Eintrag deiner Domain von s1532xxxx.onlinehome-server.info auf eine Domain, die dir gehört, z.B. mail.deinedomain.de (wobei mail.deinedomain.de natürlich auch zu deiner IP auflösen muß. Und bei QMail verwendest du auch mail.deinedomain.de im HELO. Das ist die sauberste Lösung.
Einige Provider verwenden halt auch generische Domain-Namen wie s1532xxxx.onlinehome-server.info als mögliches Spam-Merkmal, deshalb solltest du zusehen, daß du diesen Namen gar nicht verwendest.
 
So ganz verstehe ich den unterschied nicht...

Sowohl die Subdomain s1532xxxx.onlinehome-server.info als auch meinedomain.de zeigen doch auf die gleichen IP-Adressen. Daher gehören Sie mir doch beide, oder nicht?
 
s1532xxxx.onlinehome-server.info ist eine generische Domain, die dein Server-Provider deinem Server verpaßt hat. Das Problem ist weniger, ob die Domain dir gehört oder nicht (sie gehört IMHO doch eher deinem Provider als dir, zumal sie auch auch unter seiner Kontrolle steht), sondern vielmehr der generische Charakter des Names mit den vielen Ziffern. Wie ich schon schrieb, verwenden einige Spamfilter derartige Namen als mögliches Spammerkmal. Daher solltest du diesen nicht verwenden.
 
Glaub ich nicht, wie kann dann die IP 212.227.137.40 mit dem Hostnamen s15367147.onlinehome-server.info einen Status Good haben.
 
Der generische Hostname ist ein Merkmal (von vielen), das einige Spamfilter (ebenfalls von vielen) verwenden. Ich habe nie behauptet, daß Senderbase dieses Merkmal berücksichtigt - aber wenn du die Reputation korrigieren willst, scheinen sie ja doch hinzuschauen, wie man an der zitierten Mail von Twinstar erkennen kann. Deine Reputation ist ja vermutlich auf Grund von Backscatter, den jemand an Senderbase gemeldet hat, runter gesetzt worden.
Und was s15367147.onlinehome-server.info mit einer guten Reputation betrifft: Wenn sonst alles sauber ist, dann reicht NUR der generische Hostname eben nicht für eine schlechtere Reputation aus.
 
Hallo Twinstar,

hast du das Problem in den Griff bekommen? Falls ja, wie?
Habe seit ein paar Tagen das gleiche Problem mit meinem 1und1 Server.
Werde jetzt auch mal den Hostname etc. ändern und hoffen...

VG
hookx
 
Generische Domain

s1532xxxx.onlinehome-server.info ist eine generische Domain, die dein Server-Provider deinem Server verpaßt hat. Das Problem ist weniger, ob die Domain dir gehört oder nicht (sie gehört IMHO doch eher deinem Provider als dir, zumal sie auch auch unter seiner Kontrolle steht), sondern vielmehr der generische Charakter des Names mit den vielen Ziffern. Wie ich schon schrieb, verwenden einige Spamfilter derartige Namen als mögliches Spammerkmal. Daher solltest du diesen nicht verwenden.

Ok, jetzt habe ich es Schwarz auf Weiß von 1und1:

(...)

Der derzeit ausgewählte Domainname wird in ähnlicher Form (sXXXXXXXX.onlinehome-server.info) von anderen 1&1 Kunden benutzt. Dadurch hat die Domain *.onlinehome-server.info schnell ein negatives Rating. :p

Hier der Teil aus dem Rating:
SenderBase reputation score
Poor
Domain
onlinehome-server.info

Wir empfehlen daher ein anderen rDNS Eintrag zu setzen. Die Grundkonfiguration s15324xxx.onlinehome-server.info wird von uns nur gesetzt, da dies bei Bestellung die bekannte Domain ist.

Wir wünschen Ihnen ein erholsames Wochenende.

Also mache ich es wie auch hier schon empfohlen und setze mail.meinedomain.de als MX, HOST, HELO und rDNS.
Dann sehen wir mal weiter ob das die Reputation verbessert. ;)
 
Last edited by a moderator:
Danke für die Info.
Ich habe mir schon gedacht, dass da auch was bei 1und1 im argen ist, meine Anfrage bei 1und1 wurde jedoch einfach mit "Auf solche Listen haben wir keinen Einfluss" abgefertigt.

Habe meinen Hostname, rDNS und HELO gestern geändert und warte jetzt auf einen Rescan von Senderbase...
 
Senderbase Reputation

Danke für die Info.
Ich habe mir schon gedacht, dass da auch was bei 1und1 im argen ist, meine Anfrage bei 1und1 wurde jedoch einfach mit "Auf solche Listen haben wir keinen Einfluss" abgefertigt.

Habe meinen Hostname, rDNS und HELO gestern geändert und warte jetzt auf einen Rescan von Senderbase...

Ich habe in der letzten Zeit mit einigen Mailserver Admins gesprochen die IronPort einsetzen und die haben mir alle gesagt, daß man sich in Abhängigkeit der "guten" E-Mails (Menge/Qualität) die versendet werden schrittweise in der Reputation verbessert. Man sagte mir auch, keiner wisse genau, wie IronPorts Reputation arbeitet. Das hält sich Cisco relativ bedeckt. :(
 
Ich habe mir schon gedacht, dass da auch was bei 1und1 im argen ist, meine Anfrage bei 1und1 wurde jedoch einfach mit "Auf solche Listen haben wir keinen Einfluss" abgefertigt.

Diese Aussage ist ja auch erst mal richtig, auch wenn sie dir natürlich nur wenig hilft. Ein wenig Glück gehört natürlich dazu, mal an einen Support-Mitarbeiter zu geraten, der sich gut auskennt, und eine tiefgreifendere Antwort geben kann.

@Twinstar: Cisco hält sich bei der Ermittlung seiner Reputation ziemlich bedeckt, um den Spammern nicht zu viel zu verraten. Machen große Mail-Provider nicht anders. Von GMX weiß man zwar, daß sie u.a. Spamassassin einsetzen, aber mit eigenem Regelwerk und weiteren Mechanismen wie unterschiedlichen Blacklisten, Bayes-Filter und vermutlich noch einigen anderen Sachen. Würde das alles bekannt werden, würden die Spammer sich drauf einstellen und der Filter wäre weniger effektiv.
 
Back
Top