The latest posts in full-text for feed readers.
This does not work anymore on 2026-07-06, and I did not investigate why.
At work I had to block some very annoying spammers from POSTing to the contact form on the website. I ssh'ed into the Ubuntu server and blocked their IP addresses with ufw:
$ ufw insert 1 deny from 203.17.245.205
Unfortunately, this did not work. The spammers were still able to access the nginx webserver in the Docker container:
203.17.245.205 - - [17/Apr/2025:11:58:28 +0200] "POST /contact HTTP/1.1" 200 24111 "https://example.org/contact" "Mozilla/5.0 (Macintosh; Intel Mac OS X 12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 OPR/89.0.4447.51"
It turns out that Docker heavily uses iptables for its container networking, and that the rules in the default INPUT chain of the filter table that are generated by ufw are too late in the game - earlier rules already route the packets into the containers.
The iptables section in the Docker documentation tells us that rules need to be put into the DOCKER-USER chain:
$ iptables -I DOCKER-USER 1 -j DROP -s 203.17.245.205
In the end, the chain looked like this:
$ iptables -L DOCKER-USER --numeric --line-numbers
Chain DOCKER-USER (1 references)
num target prot opt source destination
1 DROP 0 -- 103.106.241.170 0.0.0.0/0
2 DROP 0 -- 113.176.64.56 0.0.0.0/0
3 DROP 0 -- 176.102.128.140 0.0.0.0/0
4 DROP 0 -- 193.163.116.88 0.0.0.0/0
5 DROP 0 -- 103.255.9.53 0.0.0.0/0
6 DROP 0 -- 116.212.106.162 0.0.0.0/0
7 DROP 0 -- 5.254.26.39 0.0.0.0/0
8 DROP 0 -- 5.254.26.37 0.0.0.0/0
9 DROP 0 -- 203.17.245.205 0.0.0.0/0
10 DROP 0 -- 172.111.204.6 0.0.0.0/0
11 DROP 0 -- 94.43.48.194 0.0.0.0/0
12 DROP 0 -- 188.169.38.71 0.0.0.0/0
13 DROP 0 -- 181.204.9.178 0.0.0.0/0
14 DROP 0 -- 103.246.84.78 0.0.0.0/0
15 DROP 0 -- 122.175.12.83 0.0.0.0/0
16 DROP 0 -- 92.255.57.64 0.0.0.0/0
17 DROP 0 -- 185.208.8.200 0.0.0.0/0
18 RETURN 0 -- 0.0.0.0/0 0.0.0.0/0
Published on 2025-04-18 in linux
Last week I wanted to demo my Open DMARC Analyzer installation to my colleagues. I shared my browser window, entered the analyzer's URL and ... waited for 15 seconds. Clicking on links also took over 10 seconds.
Afterwards I checked other websites on my server and also found them unresponsive; they took more than 10 seconds to load - even static pages. Sometimes they didn't load at all and Firefox showed a "could not connect" error.
The server load was ok - around 300% on a 12 core system. Next I checked the web server's load and was overwhelmed: Apache's server-status page showed that of the 150 workers, 150 were busy.
Nearly all of them were fetching content from my git server:
root@ahso5:~> curl -s localhost/server-status | html2text
[...]
0-0 x 195/ R 0.70 0 0 309 0.0 0.66 0.66 176.236.195.170 http/1.1 git.cweiske.de:443
2-0 x 123/ R 0.57 0 0 331 0.0 0.66 0.66 a100:a08b:7a85: http/1.1 git.cweiske.de:443
4-0 x 94/ R 0.48 28 0 37 0.0 1.57 1.57 81:e464:5ff7: http/1.1 git.cweiske.de:443
5-0 x 84/ R 0.49 0 0 767 0.0 0.67 0.67 e254:8545:2fa1: http/1.1 git.cweiske.de:443
6-0 x 79/ R 0.47 4 0 59 0.0 0.46 0.46 181.94.228.41 http/1.1 git.cweiske.de:443
9-0 x 64/ R 0.43 0 0 211 0.0 0.43 0.43 177.170.151.186 http/1.1 git.cweiske.de:443
10-0 x 94/ R 0.47 3 0 25 0.0 0.50 0.50 168.220.176.186 http/1.1 git.cweiske.de:443
11-0 x 99/ R 0.48 0 0 1055 0.0 0.52 0.52 560e:54ad:4599: http/1.1 git.cweiske.de:443
12-0 x 145/ R 0.59 0 0 652 0.0 0.89 0.89 181.54.0.0 http/1.1 git.cweiske.de:443
13-0 x 120/ R 0.50 27 0 44 0.0 0.67 0.67 188.30.63.72 http/1.1 git.cweiske.de:443
[...]
As first measure, I wanted to stop returning any content on my git server and decided to return "HTTP/1.1 402 Payment required" errors to all requests on that domain.
<VirtualHost *:443>
[...]
ServerAdmin "fuckoff@ai.bots"
RedirectMatch 402 "^"
ErrorDocument 402 "Fuckoff, AI bots"
ServerSignature Off
</VirtualHost>
The RedirectMatch alone showed a "internal server error" message to the browser. Adding the error document solved it.
Unfortunately, the problem was not solved - loading the error page was still slow, took more than 10 seconds or timed out. I had so many AI crawler bots attacking my server that even sending out the 1k "402" error response was not fast enough and saturated the 150 workers:
To cope with the onslaught, I increased the workers from 150 to 512 with a config option:
MaxRequestWorkers 512
ServerLimit 512
This temporarily worked until...
root@ahso5:~> curl -s localhost/server-status | html2text
Current Time: Monday, 20-Apr-2026 15:13:53 CEST
Restart Time: Monday, 20-Apr-2026 15:01:06 CEST
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 12 minutes 46 seconds
Server load: 1.51 1.49 1.04
Total accesses: 76795 - Total Traffic: 538.0 MB - Total Duration: 1199990
CPU Usage: u74.88 s62.19 cu73.39 cs58.62 - 35.1% CPU load
100 requests/sec - 0.7 MB/second - 7.2 kB/request - 15.6259 ms/request
512 requests currently being processed, 0 workers gracefully restarting, 0 idle workers
RRRRRRRRRRRRRRRRRCRRRRRRRRRCRRRRRRRRWRRRRRRRRRCRCRCRCCRRRCCRRRRC
RRRRCRRRRRRRRRCRCCRRRRRRRRRRRRRRRCRRCRRRRCRCRRRRRRCRRRRCRRCCRRRR
RRCRCCRRRRRRCRRRCCRRRRRRRRRRCRCRRRRRRRRRRRRCRCRCRRRCCRRRRRRCKRRC
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRKRRRRCRCRRRRCRRCCRCRRCRRRRRRRRR
CRRRRCRRRRRCCRRCRRRRRRRRRRCRCRCRRRRRRCRRCRRRRCRRRRRRRCRCRRRRRRRR
RCRRRRRRRRCRRCRRRRCRRRRRCCCKRCRRRKRRRKRRCRCRRRRCCRCRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRCRRRRCRRRRRRRRRRRRRRWRRRRRRRRRRRRCRRRRRRRCRRRRRR
RRRRKRRRRRRRRRRCRRRRRRRRCRCRRRRRRRRRCRCRRRRRRRRRRRRRRRRCRRRRRRCR
512 requests currently being processed
.
The bots adjusted and just requested more error responses!
Luckily this was only a spike; the number of parallel requests averaged between 200 and 300, 80 per second:
$ tail -f /var/log/apache2/cweiske/git.cweiske.de-access.log | pv --line-mode --rate > /dev/null
[80,2 /s]
After ~3 hours, the bot controller noticed that no sensible responses came back from my server and the requests fell back to the normal ~20 per second.
Looking at the awstats log analytics I saw that most of the clients only fetched a single URL and then vanished:
The "user-agent" header did not indicate bots: They masked as normal browsers from all kinds of common operating systems with current version numbers.
Throwing 20 IP addresses into Maxmind's GeoIP demo page showed:
That makes them impossible to block because you can't identify them.
My main problem was the the other websites on my server were unreachable because the bots downloaded every single page from the git server. The best solution would be if I could limit the parallel requests on this vhost, so that enough would be free for the other domains.
Apache2 has no native support for that (v1 had), but I found mod_vhost_limit. Compiled it, configured it and now I only allow 10 parallel requests to my git server.
In 2026-01, the git vhost had 2.25 GiB of traffic. The april number is 120 GiB, and the month still has 4 days.
The sad thing is: Those git repositories take 419 MiB on the hard disk. When using git clone to download them, it would take ~500 MiB to get all of them at once.
"AI" training data crawlers are dumb as hell, and their operators do not care that they waste resources and bring down servers one after the other.
When you work for one of those companies: I hate you.
In 2026-05-15 my feed reader brought me this: Blocking DDoS from scraper bots the easy way via HTTP-401 Basic Auth .
I decided to implement that: Require a username and password for expensive pages like commit messages, diffs and file listings - but not for the other URL paths.
At first I created a htpasswd file:
$ htpasswd -bc /etc/apache2/git-dummy.htpasswd let mein
and then I used that for some URL paths:
[...]
AuthType Basic
AuthName "AI crawler block: Use let as username and mein as password."
ErrorDocument 401 "AI crawler block: Use 'let' as username and 'mein' as password."
AuthUserFile /etc/apache2/git-dummy.htpasswd
Require valid-user
[...]
]]>
It turns out that browsers do not show the text in the "AuthName" configuration anymore, which are sent to the client in the WWW-Authenticate header:
WWW-Authenticate: Basic realm="AI crawler block: Use let as username and mein as password."
This is the reason error page for status code 401 has to contain the same text.
Myriads of web server operators have the same problem.
AI crawling protection: The threat of gold-rush-style AI crawling of the web is not a new problem, but the impact on our infrastructure kept increasing. In the past, blocking of certain IP ranges would be enough and keep us protected for days. However, more and more AI companies seem to hide behind residential proxies, abusing consumer IP addresses to distribute traffic. Rate-limiting is no longer effective, because given IP addresses might only do about two requests per day.
As a consequence, we have decided to protect certain expensive routes of Codeberg.org and most of Weblate (Codeberg Translate) behind Anubis, which requires the browser to do some computation via JavaScript to prove they have capacity. While this causes a slight increase of energy demand, legitimate users will only solve the challenge rarely, while large amounts of energy usage due to the heavy crawling. Most current crawlers do not seem to execute the code, and their requests don't reach our backends.
The issue are residential proxies (RESIP):
Published on 2026-04-26 in bigsuck, server
Wir waren letztens zum Konzert von Reis against the Spülmaschine mit ihrem Album "Tourlaub". Sie nehmen bekannte Lieder und legen - sehr lustige - deutsche Text auf die Melodien drauf.
Hier eine Liste der Reis-Tracks und der Originaltitel:
Update 2026-06-03: Das alles steht schon bei Musicbrainz: Release "Tourlaub".
Published on 2026-06-02 in music
Im Dezember 2024 kaufte ich für 36,75€ gebrauchte Schlittschuhe bei kleinanzeigen.de - damals noch mit "ebay"-Präfix. Der Verkäufer betrog mich: Er verschickte die Schlittschuhe nicht.
Meine Anzeige bei der Polizei führte zu einem Strafverfahren durch die Staatsanwaltschaft Bayreuth und endete mit einer vollstreckten Geldstrafe von 1.000€.
| Differenz | Datum | Aktion |
|---|---|---|
| Kleinanzeigen | ||
| 2024-12-01 | Nachricht von mir an Verkäufer | |
| 1 Tag | 2024-12-02 | Verkäuferantwort: Schlittschuhe sind noch da |
| 1 Tag | 2024-12-02 | Ich frage nach Kontonummer (IBAN) |
| 1 Tag | 2024-12-02 | Verkäufer schickt IBAN |
| 1 Tag | 2024-12-02 | Ich überweise die 36,75€ |
| 1 Tag | 2024-12-02 | Verkäufer schreibt: Melde mich, Wenn das Geld angekommen ist und das Paket verschickt ist. |
| 10 Tage | 2024-12-11 | Nachfrage, wie der Stand ist |
| 14 Tage | 2024-12-15 | Nochmalige Nachfrage |
| 15 Tage | 2024-12-16 | Frist an Verkäufer: Entweder sind die Schlittschuhe in 1 Woche bei mir, oder das Geld wieder auf meinem Konto |
| Polizei Sachsen | ||
| 1 Monat | 2025-01-04 | Ich reiche "Strafanzeige Betrug" bei der Onlinewache der Polizei Sachsen ein |
| 1 Monat | 2025-01-09 |
E-Mail von einem Polizisten der sächsischen Polizei:
Ihre Anzeige vom 04.01.2025 [...] ist in der Onlinewache der Polizei des Freistaates Sachsen eingegangen. Sie wurde unter der Vorgangsnummer 1054/25/xxx registriert. |
| Polizei Bayern | ||
| 2 Monate | 2025-02-28 | Anruf von einem Polizisten aus Pegnitz (Bayern): Der Herr ist der Polizei bekannt und wird vorgeladen werden. Ich soll noch den Zahlungsbeleg per E-Mail an die Polizei schicken |
| 3 Monate | 2025-03-17 |
Der Betrüger war bei der Polizei und meinte, sein Handy ist verloren/kaputt gegangen und er hatte die Zugangsdaten nicht mehr. Schlittschuhe sind noch da. Ich entscheide mich, das Geld zurück haben zu wollen. |
| 3 Monate | 2025-03-27 | Anruf von der Polizei Pegnitz, ob das Geld schon zurücküberwiesen wurde. Wurde es nicht. |
| Staatsanwaltschaft Bayreuth | ||
| 4 Monate | 2025-04-07 |
Brief von der Staatsanwaltschaft Bayreuth:
"Belehrung über die Befugnisse des Verletzten".
Ich bekomme ein Aktenzeichen und das Verfahren einen Titel:
Strafverfahren: Ermittlungsverfahren gegen [Name] wegen Betruges |
| 1 Jahr, 5 Monate | 2026-05-06 | Ich schreibe der Staatsanwaltschaft Bayreuth eine E-Mail und frage nach dem Stand des Strafverfahrens. |
| 1 Jahr, 5 Monate | 2026-05-13 |
Briefpost von der Staatsanwaltschaft Bayreuth:
unter Bezugnahme auf Ihre Anfrage vom 05.05.2026 wird mitgeteilt, dass das vorliegende Strafverfahren durch Strafbefehl beendet wurde. Der Beschuldigte wurde wegen Betrugs zu einer Geldstrafe von 1.000,- Euro verurteilt. Das Verfahren ist bereits rechtskräftig erledigt und vollstreckt. |
Ich freue mich sehr, daß der Betrüger eine solche Strafe bekommen hat.
Published on 2026-05-14 in leben, polizei
From 2012 to 2023 I had been using djbdns/dbdns' tinydns, and even wrote a small script to update my home server's IP address via a simple SSH connection - DynDNS, securely authenticated and without any external services.
In 2023 I switched to NLnet Labs Name Server Daemon (NSD) because tinydns is not updated anymore and doesn't properly integrate with systemd. This was the time I lost my DynDNS service :(
Now I finally managed to update my ssh-dyndns script to support NSD.
It was a bit complicated because updating Bind .zone files is hard.
When using SSH to connect to the dyndns user account on the server, the script takes the client's IP address and overwrites a .zonepart file - it contains two DNS entries only, one for the IP and one for the date:
home.cweiske.de. 300 A 212.99.194.43 home.cweiske.de. TXT "Last update 2026-05-07 21:27:20+02:00 300"
An $INCLUDE for the .zonepart files is hard-coded into the actual .zone file:
;Dyndns $INCLUDE /etc/nsd/zones/dyndns/home.cweiske.de-v4.zonepart $INCLUDE /etc/nsd/zones/dyndns/home.cweiske.de-v6.zonepart
To make it as secure as possible, the dyndns directory is writable by the dyndns user - but not the actual zone files. I use sudo and zsu to update the zone's serial number.
sudoers is configured to allow passwordless calls to zsu and nsd-control from the dyndns user, but only with hard-coded zone names:
dyndns ALL = NOPASSWD: \ /usr/local/src/ssh-dyndns/nsd/zsu -fn /etc/nsd/zones/cweiske.de.zone,\ /usr/sbin/nsd-control reload cweiske.de
Published on 2026-05-08 in linux, network, server
Today I noticed a new way to send spam to many people: Google Groups, a mailing list platform.
In the last days I got many automatic replies from people and companies I don't know and never contacted: out-of-office reminders and "thank you, we will take care" mails.
The mails were sent to support@gh.onlinebildunchkeiten.de and all contained mailing list headers:
Precedence: list
Mailing-list: list phn@gh.onlinebildunchkeiten.de; contact phn+owners@gh.onlinebildunchkeiten.de
List-ID: <phn.gh.onlinebildunchkeiten.de>
X-Spam-Checked-In-Group: suppsdhsdksdhee@gh.onlinebildunchkeiten.de
X-Google-Group-Id: 320817839263
List-Post: <https://groups.google.com/a/gh.onlinebildunchkeiten.de/group/phn/post>,
<mailto:phn@gh.onlinebildunchkeiten.de>
List-Help: <https://support.google.com/a/gh.onlinebildunchkeiten.de/bin/topic.py?topic=25838>,
<mailto:phn+help@gh.onlinebildunchkeiten.de>
List-Archive: <https://groups.google.com/a/gh.onlinebildunchkeiten.de/group/phn/>
List-Subscribe: <https://groups.google.com/a/gh.onlinebildunchkeiten.de/group/support/subscribe>,
<mailto:support+subscribe@gh.onlinebildunchkeiten.de>
List-Unsubscribe: <mailto:googlegroups-manage+320817839263+unsubscribe@googlegroups.com>,
<https://groups.google.com/a/gh.onlinebildunchkeiten.de/group/phn/subscribe>
This was a Google group mailing list! And as usual with Google things, there was no way to report spam or abuse.
I imagine the process to be as follows:
The nice thing for spammers is that Google servers have good reputation and won't be blocked by administrators. This spam mails have a high chance of passing mail filters.
It is possible to unsubscribe from this spam list by sending an e-mail to a personalized e-mail address that you can find in the e-mail's List-Unsubscribe header. Make sure you send it from the same e-mail address it is sent to; that can be found in one of the Received headers :(
When sending an e-mail to the unsubscription address, a confirmation comes back with an image:
The text is written in thai (according to ChatGPT):
โรงเรียนบ้านปางสุด - Ban Pang Sut School
สพป.นครสวรรค์ เขต 2 - Nakhon Sawan Primary Educational Service Area Office 2
At least the text part is signed with
vay.xylontrix.cfd admins
.
cfd is a valid top-level domain, and xylontrix.cfd
is registered, according to the
ICANN lookup tool.
It does not stop. I got subscribed to more spammer lists:
2026-03-19: Four groups but from 9 different domains: capturesoul[.]com, cosmoroyal[.]de, festbock[.]de, hotsurf[.]de, leysite[.]de, pharnisch[.]de, saycon[.]de, sfp888[.]com, softytools[.]de. Group names were de3, de5, ds2 and ds9. When unsubscribing from de5, I got the message that I unsubscribed from "bv".
This time with an unsubscription image!
According to ChatGPT the text means Onprachak School 'Phet Rian'
.
2026-04-27: 12 groups from 6 domains in the last week: bwty-sports[.]com, hethbeauty[.]de, foodletter[.]de, techshoppro[.]de, ttitu[.]de, signtunes[.]de
When unsubscribing, I got this for the first time for some of the lists:
Address not found
Your message wasn't delivered to googlegroups-manage+23+unsubscribe@googlegroups.com because the address couldn't be found, or is unable to receive mail.The response was:
Failed to load suspended group domain
Other people also noticed that problem:
Published on 2025-10-09 in bigsuck, web
We have two Shelly Button 1 devices: Physical buttons that when pressed, connect to the Wifi network and do HTTP requests. I configured one to switch lights in the living room on and off.
The bottom case of the button fell of; when inspecting that I saw that the lithium ion battery was too thick to fit into the case:
Shelly support wrote in German:
Eventuell liegt ein Defekt des Li-Ionen Akku vor.
Wir bieten diesen Akku nicht als Ersatzteil an,
laut Spezifikation handelt es sich um einen Li-Ionen Akku 3,7V, 400 mAh.
and the English translation:
The li-ion battery may have a defect. We do not provide replacements for this battery, according to the specification it is a Li-Ion battery 3.7V, 400 mAh.
According to a Thread on shelly-forum.com there are replacement batteries on Aliexpress with the name "652530" - but switched cables.
Published on 2026-04-26 in bigsuck, hardware
Spammers are using Wordpress installations with open registration to send spam e-mails to uninvolved users.
The mails are sent via the "Register" function that is linked on the Wordpress login page wp-login.php. The registration form has two fields: "Username" and "Email".
The username allows spaces, and this is where the spammers input a domain name and a promotional text. The domain name gets auto-linked by e-mail clients, making it easy for users to go to the spammer's site.
Such a spammy Wordpress registration e-mail looks like this:
Username: www.spammer.example.com - 1.2342 BTC To set your password, visit the following address: https://legitsite.example.net/wp-login.php?login=www.spammer.example.com%20-%201.2342%20BTC&key=oSxUtw01QIFHoxHvokfd&action=rp https://legitsite.example.net/wp-login.php
Everything after the Username: in that line is provided by the spammer.
Two things should be fixed here by Wordpress:
Let's see what the Wordpress developers say to my ticket.
2024-11: Reddit: Spammed with 100+ Fake WordPress Login Emails (Help!)
Имя пользователя: www.spammer.example.com - 1.34862 BTC BINANCE Чтобы задать пароль, перейдите по следующей ссылке: https://legitsite.example.net/wp-login.php?login=www.spammer.example.com%20-%201.34862%20BTC%20BINANCE&key=AD9lhUMLbyHwqdPCVXEL&action=rp https://legitsite.example.net/wp-login.php
Nombre de usuario: www.spammer.example.com - 11 743 EURO BTC Para establecer tu contraseña, visita la siguiente dirección: https://legitsite.example.net/wp-login.php?login=www.spammer.example.com%20-%2011%20743%20EURO%20BTC&key=VzYajJhlHltX21Yxl6YQ&action=rp https://legitsite.example.net/wp-login.php
Published on 2025-03-11 in bigsuck, web
Ich habe versucht, 2 Messer bei www.markenmesser24.com zu kaufen. Es wurde nur eins geliefert, und das auch erst fast 3 Wochen. Das Geld für das zweite habe ich zurückbekommen.
Aus Unternehmenssicht war das vermutlich eine Verkettung unglücklicher Umstände, aus meiner Sicht Schlampigkeit.
Ich habe ein Messer in doppelter Ausführung bestellt. Bestellbestätigung kam, alles gut.
Es sollte rechtzeitig zu Ostern kommen, aber 4 Tage sind ja eigentlich genug Zeit.
Karfreitag: Bisher keine Messer in der Post.
Nachfrage per E-Mail, wie denn der Bestellstatus ist.
Automatische Antwort: Urlaub vom 30.03.-09.04.2026
.
Diese Information war weder auf der Website, noch in der Bestellbestätigung zu sehen - nicht zum Zeitpunkt meiner Bestellung, und auch jetzt nicht.
Nachfrage per E-Mail, wie denn der Bestellstatus ist.
Automatische Antwort: Urlaub vom 30.03.-09.04.2026
.
Päckchen kommt an, aber nur mit einem Messer. Der Preis auf der Rechnung ist reduziert, aber es gibt keine Begründung
Nachfrage per E-Mail, warum nur eins geliefert wurde.
Erste(!) Antwort vom Shopbetreiber Alexander Pasche: Messer erst jetzt versendet, weil Bestellungen aus der Urlaubszeit abgearbeitet werden müssen. Nur eins versendet, weil er einen Fehler im Lagerbestand hatte. Zuviel bezahltes Geld wurde zurücküberwiesen.
Rückfrage, ob er das fehlende Messer nicht doch noch beim Lieferanten nachbestellen kann.
Automatische Antwort: Urlaub vom 30.03.-09.04.2026
.
Antwort, daß das Geld ja erstattet wurde und deshalb keine Nachlieferung erfolgen kann.
Fehler:
Im Impressum und im Flyer wird www.markenmesser24.de beworben. Über Suchmaschinen bekommt man aber www.markenmesser24.com, und auch meine Bestellung lief darüber.
Unter http:// bekommt man für die .de-Domain keine Antwort (weder mit noch ohne www).
Mit https:// kommt ein SSL-Fehler:
$ curl -i https://www.markenmesser24.de/
curl: (35) TLS connect error: error:0A000438:SSL routines::tlsv1 alert internal error
Im Footer der Website steht eine Telefonnummer. Diese hatte ich im Laufe der 2.5 Wochen 2x versucht zu erreichen, aber nie ist jemand rangegangen.
Im Impressum steht warum: (07:00-08:30)
.
Ein Witz.
Bei Trustpilot haben andere Leute ähnliches berichtet.
Published on 2026-04-23 in kundeistkönig
Geo coordinates from t-shirts.
TOM TAILOR 53°37'15.6"N TOM TAILOR 9°57'26.5"E
CASUAL 1962 CLASSICS
This is the "Tom Tailor Outlet Store" in Hamburg Niendorf, 53.621000, 9.957361.
FUTURE ADVENTURER
38.8830 °N // 77.0163 °W
This is the "Mary W. Jackson NASA Headquarters" in Washington, DC, USA at 38.8830, -77.0163.
A WEfashion sweater ("Be awesome today") shows on the back:
52.103032 //
5.065654
The coordinates point to the "DHL E-Commerce" storehouse at Reactorweg 23 in Utrecht, NL at 52.103032, 5.065654
Published on 2026-01-03 in leben