SEO-SPAM: Unnütz und Irreführend

Schon mal eine Rechnung für was bekommen, was nie passiert ist und nie passieren wird ?

Guckt Euch das mal an :

Spam zum Abschluß eines unnützen SEO VertragsDa wird einem suggeriert, daß man eine Rechnung nicht beglichen hätte. Tatsächlich bestand aber nie ein Vertrag. Sowas nennt man dann „versuchten Betrug“. Das Kleingedruckte in Hellgrau auf Weiß klärt dann zwar auf, daß das ja nur ein Angebot wäre, aber wenn man das nicht annimmt, besteht die Chance, daß genau dieses Angebot verfällt 😀 Nach Art und Aufmachen ist das Schreiben geeignet einen falschen Eindruck einer Sache zu liefern, was den Tatbestand des versuchten Betrugs erfüllen dürfte. Das Kleingedruckte da wird die Firma nicht retten 🙂 ( Falls es diese überhaupt gibt)

Nach § 263 StGB macht sich strafbar: „Wer in der Absicht, sich oder einem Dritten einen rechtswidrigen Vermögensvorteil zu verschaffen, das Vermögen eines anderen dadurch beschädigt, dass er durch Vorspiegelung falscher oder durch Entstellung oder Unterdrückung wahrer Tatsachen einen Irrtum erregt oder unterhält.“

Der Rest von der EMail war dann natürlich auch genau in der Machart, wo unwahre Sachen groß und fett hervorgehoben, aber Einschränkungen extraklein dargestellt werden. Wäre das eine Deutsche Firma gewesen, wärs bei der Polizei gelandet, oder noch besser, beim Abnahmanwalt 😉

Ich habe da mal nachgesehen und in der EMail einen Link zu einer Subdomain „meines Domainnamens“ gefunden, was die Antispamfilter gleich als tolles Indiz für Spam genutzt haben:

http://www.domainde.domapillar.win/unsubscribe.php

Der Inhaber der Second Level Domain ist eine „Firma“ aus Hong Kong, die oh Wunder, einen Whoisparkingservice benutzt. na sowas, wieso tut eine seriöse Firma das wohl 😉 Spamassassin kennt da gleich eine Menge Regeln, die das zuverläßig als das outen was es ist: Spam 😀

 Pkte Regelname Beschreibung
 ---- ---------------------- --------------------------------------------------
 1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist
 [URIs: domapillar.win]
 1.9 URIBL_ABUSE_SURBL Enthält URL in ABUSE-Liste (www.surbl.org) -
 changed from JP to ABUSE bug 7279
 [URIs: domapillar.win]
 2.5 URIBL_DBL_SPAM Contains a spam URL listed in the DBL blocklist
 [URIs: domapillar.win]
 0.0 HTML_MESSAGE BODY: Nachricht enthält HTML
 0.1 URIBL_SBL_A Contains URL's A record listed in the SBL blocklist
 [URIs: www.domainde.domapillar.win]
 0.6 URIBL_SBL Enthält URL in SBL-Liste (http://www.spamhaus.org/sbl/)
 [URIs: www.domainde.domapillar.win]
 0.0 LOTS_OF_MONEY Huge... sums of money
 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines
X-Spam-MARK-Flag: YES
Subject: *SPAM* -> domain.de Expiration SEO

Die Masche ist natürlich alles andere als neu und wird immer wieder aus der Mottenkiste geholt. Ich habe erst gedacht, die wollten mir teuer die Domain auf einen AmiRegistrar umziehen, so ablenkend ist das formuliert. Das wird auch gern rumgemailt, daß eine Domain ausläuft und man die doch aktiv verlängern müßte. Das ist aber in Deutschland mit deutschen Registraren unüblich, d.h. die verlängern sich automatisch. Das wird von deutschen Registraren auch für andere TLDs so gehandhabt, weil die Kunden das für .DE Domains so gewohnt sind, womit ein versehentliches Auslaufen der Domain nie passieren wird.

Also wie immer: Ab in die Digitale Mülltonne damit.

Jitsi + Linphone = kein Telefon

Einen ganzen Vormittag kann man damit verbrennen, wenn Jitsi und Linphone zusammen laufen und beide SIP VOIP Anschlüsse bedienen können sollen. „Sollen“, weil „können“ tun sie es nicht, bis man die wahre Ursache erkennt 🙂

Falls der geneigte Leser etwas Frust aus dem Text herausliest, „etwas“ ist stark untertrieben.

Was war passiert ?

Nun, ich hatte LinPhone4 installiert, um es auszuprobieren und es behalten, weil es, an dem Tag, besser mit Sipgate funktionierte, als Jitsi, welches mit Sipgate gar nicht mehr kann 🙁  Jetzt mußte ich feststellen, daß ich mit LinPhone ohne irgendwelche Fehlermeldungen auf UI Seite, weder angerufen werden, noch selbst anrufen konnte, egal auf welchem Konto!

Nachdem ich in den Einstellungen von LinPhone die Position des Logs gefunden hatte, fielen mir dort wiederholt diese Zeilen auf:

2017-10-05 11:25:17:394 ERROR No listening point matching for [udp://sipgate.de:5060]
2017-10-05 11:25:17:394 ERROR belle_sip_client_transaction_send_request(): no channel available

Natürlich neben jeder Menge „Technobabble“ des Clienten, versteht sich 🙂

Was sagt uns das ?

Antwort: Nichts 🙂

Lediglich 1 .. in Worten EINE ..  Webseite konnte Google finden, die schon mal was davon gehört hatte. Zum Glück, war es die richtige.

Übersetzt meint die Fehlermeldung, daß das Programm keinen Kommunikationskanal öffnen konnte. Nur wieso nicht, darüber schweigt es sich aus. Hellseher haben halt immer Konjunktur, weil der Rest blöd genug ist, Raum für deren „Notwendigkeit“ zu schaffen. Dank der einen Webseite, war es dann aber zum Glück recht einfach, der Ursache auf die Spur zu kommen.

Auflösung

Einen „Channel“ etabliert man, in dem man einen TCP Port bindet und dem Gegenüber sagt, das man darauf angerufen werden kann. Wieso man beim „Anrufen“ nicht direkt mit dem SIP Provider eine TCP-Connection aufmachen kann, will ich gar nicht wissen, wenn man SIP lernen will, wird man eh durch Unlogik erschlagen. IMHO, eins der schlechtesten Protokolle aller Zeiten. Stückwerk ^10.

Ok, was braucht man um einen Port zu binden ? Eine Portnummer und niemanden, der schneller als man selbst war! Mit anderen Worten, Jitsi hatte sich schon permanent auf Port 5060 gebunden, weswegen Linphone das nicht konnte. Soweit, so in den RFCs für TCP Ports vorgesehen. Warum Linphone das nicht schreiben kann, ist ein weiteres Rätsel, weil die Fehlermeldung des TCP/IP Stacks zu dem „Fehler“ ist eindeutig!

Jetzt bietet LinPhone in den Kontoeinstellungen an, daß man statt Port 5060 zufällige Ports benutzen kann. Wieso das nicht der Standard ist, wird man nie erfahren. Jedenfalls funktioniert das SIP Konto sofort, wenn man die feste Portzuweisung abgeschaltet hat:

Fazit: In Jitsi habe ich jetzt SIP deaktiviert, damit entfällt auch das Binden des Ports.

Da Jitsi eh derzeit nicht mit Sipgate kann, spielt das es keine Rolle mehr. Warum das alles am Tag, an dem ich Linphone ausprobiert habe, funktioniert hat, ist ein weiteres Mysterium.

Das VOIP stinkt, dürfte vielen leidgeplagten Telefonanschlußinhabern bekannt sein, wie sehr das grade stinkt, hier im Überblick:

Skype:

Old: Raustelefonieren geht, angerufen werden geht nicht.
New: Raustelefonieren geht, Gui ist Mist, angerufen werden, geht nicht, weil sobald man „abnimmt“ legt Skype auf! Fix in Sicht ? Nein. Problem bekannt ? Seit Monaten.

Jitsi:

Fritz!box: Raus geht, Rein geht.
Sipgate: Raus geht, Rein geht nicht.

Jitsi Android:

Fritz!box: geht gar nicht.
Sipgate: Raus geht, Rein geht.

LinPhone:

Fritz!box: geht beides
Sipgate: geht beides

Einzig gültiger Kommentar zu Sipgate+Jitsi: AAAAAAAAAAAAAAAAAAAARRGGS!

Fedora – PHP 7 – ZipArchive

Wer mit Fedora 25+ die Meldung „PHP Fatal error: Uncaught Error: Class ‚ZipArchive‘ not found in /www/pages/….“ sieht, wenn er eine Webanwendung installiert, der braucht folgenden Fix:

libzip-1.1.3-1.fc25.x86_64
php-pecl-zip-1.13.5-1.fc25.x86_64

Dafür das in die Konsole eingeben:

dnf install php-pecl-zip

und dann ggf. noch einen Neustart seines Webservers, wenn man PHP als Modul einsetzt, was man nicht machen sollte.