Facebook und Greylisting- ein Einzelfall?

S

siradlib

New Member
Hallo zusammen,

ich benutze auf meinem Mailserver (Strato vServer mit Plesk 9.5.2, MTA: QMail) recht erfolgreich Greylisting- oder zu erfolgreich?
Folgendes Phänomen hatte ich heute: Ein User beschwerte sich, dass er seit über einer Stunde auf eine Bestätigungsmail von Facebook warten würde.
Also bin ich mal auf die Suche gegangen und habe die /usr/local/psa/var/log/maillog untersucht.
Code: 
2010-07-21T14:10:30.707375+02:00 hXXXXXXX /var/qmail/bin/relaylock[1414]: /var/qmail/bin/relaylock: mail from [B]66.220.144.141[/B]:52697 ([B]outmail009.snc4.facebook.com[/B])
2010-07-21T14:10:31.417403+02:00 hXXXXXXX qmail-queue-handlers[1417]: Handlers Filter before-queue for qmail started ...2010-07-21T14:10:31.551354+02:00 hXXXXXXX qmail-queue-handlers[1417]: from=register+AdS5rcmllZ2VyQGxhemktYWthZGVtaWUuZGU@facebookmail.com
2010-07-21T14:10:31.551505+02:00 hXXXXXXX qmail-queue-handlers[1417]: to=jon.doe@mydomain.net
2010-07-21T14:10:31.551604+02:00 hXXXXXXX qmail-queue-handlers[1417]: hook_dir = '/usr/local/psa/handlers/before-queue'
2010-07-21T14:10:31.551884+02:00 hXXXXXXX qmail-queue-handlers[1417]: call_handlers: call executable = '/usr/local/psa/handlers/info/05-grey-horaMm/executable'
2010-07-21T14:10:31.554165+02:00 hXXXXXXX greylisting filter[1418]: Starting greylisting filter...2010-07-21T14:10:31.571599+02:00 hXXXXXXX qmail-queue-handlers[1417]: handlers_stderr: DEFER
…….
2010-07-21T14:15:32.097569+02:00 hXXXXXXX /var/qmail/bin/relaylock[10234]: /var/qmail/bin/relaylock: mail from [B]66.220.144.143[/B]:54600 ([B]outmail011.snc4.facebook.com[/B])
2010-07-21T14:15:32.795483+02:00 hXXXXXXX qmail-queue-handlers[10239]: Handlers Filter before-queue for qmail started ...2010-07-21T14:15:33.015939+02:00 hXXXXXXX qmail-queue-handlers[10239]: from=register+AdS5rcmllZ2VyQGxhemktYWthZGVtaWUuZGU@facebookmail.com
2010-07-21T14:15:33.016067+02:00 hXXXXXXX qmail-queue-handlers[10239]: to=jon.doe@mydomain.net
2010-07-21T14:15:33.016147+02:00 hXXXXXXX qmail-queue-handlers[10239]: hook_dir = '/usr/local/psa/handlers/before-queue'
2010-07-21T14:15:33.016394+02:00 hXXXXXXX qmail-queue-handlers[10239]: call_handlers: call executable = '/usr/local/psa/handlers/info/05-grey-horaMm/executable'
2010-07-21T14:15:33.018813+02:00 hXXXXXXX greylisting filter[11265]: Starting greylisting filter...2010-07-21T14:15:33.054784+02:00 hXXXXXXX qmail-queue-handlers[10239]: handlers_stderr: DEFER
…….
2010-07-21T14:25:33.416692+02:00 hXXXXXXX /var/qmail/bin/relaylock[32545]: /var/qmail/bin/relaylock: mail from [B]66.220.144.154[/B]:58789 ([B]outmail022.snc4.facebook.com[/B])
2010-07-21T14:25:34.118677+02:00 hXXXXXXX qmail-queue-handlers[32551]: Handlers Filter before-queue for qmail started ...2010-07-21T14:25:34.295441+02:00 hXXXXXXX qmail-queue-handlers[32551]: from=register+AdS5rcmllZ2VyQGxhemktYWthZGVtaWUuZGU@facebookmail.com
2010-07-21T14:25:34.295577+02:00 hXXXXXXX qmail-queue-handlers[32551]: to=jon.doe@mydomain.net
2010-07-21T14:25:34.295685+02:00 hXXXXXXX qmail-queue-handlers[32551]: hook_dir = '/usr/local/psa/handlers/before-queue'
2010-07-21T14:25:34.295972+02:00 hXXXXXXX qmail-queue-handlers[32551]: call_handlers: call executable = '/usr/local/psa/handlers/info/05-grey-horaMm/executable'
2010-07-21T14:25:34.298249+02:00 hXXXXXXX greylisting filter[32552]: Starting greylisting filter...2010-07-21T14:25:34.991422+02:00 hXXXXXXX qmail-queue-handlers[32551]: handlers_stderr: DEFER
…….
2010-07-21T14:45:35.526292+02:00 hXXXXXXX /var/qmail/bin/relaylock[11823]: /var/qmail/bin/relaylock: mail from [B]66.220.144.147[/B]:33400 ([B]outmail015.snc4.facebook.com[/B])
2010-07-21T14:45:36.224510+02:00 hXXXXXXX qmail-queue-handlers[11826]: Handlers Filter before-queue for qmail started ...2010-07-21T14:45:36.397763+02:00 hXXXXXXX qmail-queue-handlers[11826]: from=register+AdS5rcmllZ2VyQGxhemktYWthZGVtaWUuZGU@facebookmail.com
2010-07-21T14:45:36.397905+02:00 hXXXXXXX qmail-queue-handlers[11826]: to=jon.doe@mydomain.net
2010-07-21T14:45:36.398008+02:00 hXXXXXXX qmail-queue-handlers[11826]: hook_dir = '/usr/local/psa/handlers/before-queue'
2010-07-21T14:45:36.398281+02:00 hXXXXXXX qmail-queue-handlers[11826]: call_handlers: call executable = '/usr/local/psa/handlers/info/05-grey-horaMm/executable'
2010-07-21T14:45:36.400599+02:00 hXXXXXXX greylisting filter[11827]: Starting greylisting filter...2010-07-21T14:45:36.443449+02:00 hXXXXXXX qmail-queue-handlers[11826]: handlers_stderr: DEFER
Wie man sieht, unternimmt Facebook insgesamt vier Anläufe, eine Registrierungsmail für den User zuzustellen. Wenn man allerdings genauer hinsieht und die von mir fett markierten Namen und IPs der einliefernden Mailserver beachtet, fällt auf, dass die Zustellversuche immer von anderen Mailservern kommen, die aber alle bei Facebook stehen.

Ergebnis: Dank Greylisting und den immer wieder "neuen" Mailservern kommt die Registrierungsmail nie an. :mad:

Als Gegenmaßnahme habe ich jetzt mal alle von Facebook derzeit verwendeten Mailserver (66.220.144.0/24 und 69.63.0.0/16) in einer Whitelist platziert.

Nun macht mich die Sache allerdings nachdenklich: Ist das eine Schwachstelle von Greylisting oder eine Fehlkonfiguration der Mailserver von Facebook?
Und gibt es noch andere Provider, die bei einem erneuten Zustellversuch den Mailserver wechseln? Die kämen ja durch eine Grey List nur extrem schwer/spät durch... :eek:

Wie seht ihr das?

Ich freue mich auf eure Einschätzungen!

LG siradlib
 
Bei web.de, GMX, Freenet, Ebay und vermutlich noch vielen anderen großen Läden gibt es ebenfalls dieses Phänomen.
Die Mails werden bei denen in eine große Queue geschmissen und irgendein Mailserver von denen fischt sich die raus und versucht sie zuzustellen.

Warum da nicht immer die selbe Maschine versucht, zuzustellen habe ich nie herausgefunden - ein Grund könnte jedoch sein, um die Mail auch zustellen zu können, wenn einer der vielen Mailserver mal auf einer Blackliste steht, was bei den Gratisanbietern durchaus passieren kann.

Aus diesen Gründen habe ich bei mir das Greylisting komplett abgeschaltet und frage lieber zwei DNSBLs ab. Der Spam, der da noch durchkommt, würde erfahrungsgemäß auch durchs Greylisting kommen, weil er von echten Mailservern verschickt wird (z.B. geknackte Hotmail-Accounts).
 
Danke für Deine Antwort!

Lord Gurke said:
Bei web.de, GMX, Freenet, Ebay und vermutlich noch vielen anderen großen Läden gibt es ebenfalls dieses Phänomen.
[....]
Aus diesen Gründen habe ich bei mir das Greylisting komplett abgeschaltet und frage lieber zwei DNSBLs ab. Der Spam, der da noch durchkommt, würde erfahrungsgemäß auch durchs Greylisting kommen, weil er von echten Mailservern verschickt wird (z.B. geknackte Hotmail-Accounts).
Click to expand...
Mh, das hatte ich fast befürchtet- damit steht Greylisting bei mir jetzt auf der (mentalen) Abschussliste. :mad:
Welche DNSBLs benutzt Du?
Laß mich raten, die erste ist iX/manitu. Und die zweite?
 
Facebook gibt im SPF-Record
Code: 
"v=spf1 ip4:69.63.179.25 ip4:69.63.178.128/25 ip4:69.63.184.0/25 ip4:66.220.144.128/25 ip4:66.220.155.0/24 mx -all"
die verwendeten MX-Pools an. Die würde ich einfach vom Greylisting ausnehmen.
 
Hab die Pappnasen, wie auch alle grossen Mailprovider vom greylisting ausgenommen, gab nur Ärger. Bin mittlerweile dazu übergegangen, nur noch dynamisch aussehende Adressen, bzw. eher Hostnamen ins greylisting laufen zu lassen.

Grüsse
Basti
 
traced said:
Bin mittlerweile dazu übergegangen, nur noch dynamisch aussehende Adressen, bzw. eher Hostnamen ins greylisting laufen zu lassen.
Click to expand...
Heißt das, Du läßt erstmal alles über eine DNSBL laufen und machst danach (bei "verdächtigem" Hostnamen) Greylisting?
Weißt Du, wie man das innerhalb von Plesk konfigurieren kann? Ich habe mich bisher nicht wirklich mit der Spamabwehr-Konfiguration von Plesk beschäftigt.
 
Das ist auch bei mir der Grund weswegen ich kein Greylisting mehr einsetze, sondern Policyd-weight, Spamassassin und ClamAv in der Kombination. Was eigentlich 99% des Spams erwischt.
 
LordGurke, Dankeschön nochmal.
Spricht ja eigentlich nichts gegen DNSBLs- wenn da nicht die einliefernden Mailclients wären, deren (meist dynamische) IPs gerne mal auf einer Blacklist landen. Soweit ich das verstehe, gibt es nur die Alternative, Mailclients nach vorheriger Authentifizierung Mails über Port 587 anliefern zu lassen (dort greifen DNSBLs nicht).
Hieße für mich: Ich muss alle Kunden verständigen und sie bitten, den SMTP-Port ihres Mailclients von 25 auf 587 zu stellen... :eek:

Wie machst Du das denn, läßt Du Mailclients (mit Authentifizierung) ausschließlich über Port 587 einliefern?
 
CentY said:
Das ist auch bei mir der Grund weswegen ich kein Greylisting mehr einsetze, sondern Policyd-weight, Spamassassin und ClamAv in der Kombination.
Click to expand...

Policyd-weight klingt gut! Ist für Dich aber dann ein (besserer) Ersatz für DNSBLs (die ja auch ausgewertet werden von Policyd-weight), richtig?
Hast Du dann nicht auch die Bedingung, dass Mailclients zwingend über Port 587 einliefern müssen?
 
Nö, wozu. Sobald der Client sich authentifzieren konnte werden alle anderen Checks (wie Policyd-weight usw.) nicht mehr ausgeführt.

Policyd-Weight ist noch mehr als nur DNSBls, er macht Checks ob es sich um dynamische IPs handelt, ob der Helo mit der Domain die sendet übereinstimmt usw..
 
siradlib said:
Heißt das, Du läßt erstmal alles über eine DNSBL laufen und machst danach (bei "verdächtigem" Hostnamen) Greylisting?
Weißt Du, wie man das innerhalb von Plesk konfigurieren kann? Ich habe mich bisher nicht wirklich mit der Spamabwehr-Konfiguration von Plesk beschäftigt.
Click to expand...

Nein, die Reihenfolge ist bei mir:
policyd-weight -> wenn dynamisch greylist -> amavisd-new -> empfänger.

Wie man das mit Plesk machen könnte ist mir ein Rätsel, mein Setup ist eine dedizierte Debian Box mit Postfix :)

Grüsse
 
traced said:
Wie man das mit Plesk machen könnte ist mir ein Rätsel, mein Setup ist eine dedizierte Debian Box mit Postfix :)
Click to expand...

Mist, so ist das, wenn man sich bei der Systeminstallation nicht wirklich Gedanken um den MTA und die Spamabwehr macht. Ich sehe schon, ich habe viel zu lernen/testen/auszuprobieren. ;)
 
You must log in or register to reply here.
Back
Top