Tag DIY

• udev, thinkpad docks, sawfish

  12021:135:6 ( 2021-05-16)

  • udev
  • Dock script: sawfish to the rescue
  • What I do when docking

  The other day someone gave me another dock for my thinkpad, and I eventually decided to use it at home. I've had a dock at the office for a long time, and docking there involved running a complex script configuring the network environment, running a window manager on some display on a desktop machine, and only exiting when the dock was supposed to end; its execution was triggered when the wake-up script noticed a dock was present.

  Now, when there are two docks and one is for rather conventional at-home use (essentially, simply configuring a different monitor and network adapter), I decided to do it properly and go through udev. Which turned out to be tricky enough that I'll turn this note to my future self into a blog post.

  udev

  What turned out to be the most complicated part was figuring out the udev rules. That's because for ages I have been using:

  udevadm info -a -p some/sysfs/path
  

  to work out matchable attributes for a device. That's more or less fine if all you're after is rules for attaching devices. For the dock, however, the removal event is important, too. But when the removal event comes in, udev has forgotten essentially all of the attributes that come from info -a, and rules that work with add simply won't fire with remove.

  So, here's my new policy: I'll use:

  udevadm monitor --environment --udev
  

  (where the udev option restricts events to udev rather than kernel events, which for the deluge of events coming from the dock seemed smart; I may want to revisit that). When you then plug in or out things, you'll directly see what events you can match against. Nice.

  Except of course for the deluge of events just mentioned: A dock just has quite a few devices. The event for the device I consider most characteristic, however, makes two add events, and I've not found a good way to tell the two of them apart. Still, this is what I've put into /etc/udev/rules.d/95-docking.rules:

  ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="17ef", \
    ENV{ID_MODEL_ID}=="1010",  ENV{DEVTYPE}=="usb_device", \
    RUN+="/bin/su <your user id> -c '/full-path-to-dock-script start'"
  
  ACTION=="remove",  ENV{SUBSYSTEM}=="usb", ENV{PRODUCT}=="17ef/1010/5040", \
    ENV{DEVTYPE}=="usb_device", \
    RUN+="/bin/su <your user id> -c '/full-path-to-dock-script stop'"
  

  Important (and having forgotten about it again gave me quite a bit of frustration): Rather sensibly, udev has no idea of the shell path and will just fail silently when it cannot execute what's in RUN. Hence you must (essentially) always give full path names in udev RUN actions. In case of doubt, try RUN+="/usr/bin/logger 'rule fires'" in a rule and watch the syslog.

  For this kind of thing, by the way, you'll rather certainly want to use su (or go through policykit, but I can't bring mayself to like it). You see, I want the dock script in my home directory and owned by me; having such a thing be executed as root (which udev does) would be a nice backdoor for emergencies, but will generally count as a bad idea.

  On the double dock event… well, we're dealing with shell scripts here, so we'll hack around it.

  Dock script: sawfish to the rescue

  udev only lets you execute short scripts these days and rigorously kills everything spawned from udev rules when it has finished processing the events. I suppose that's a good policy for general system stability and reducing unpleasant surprises. But for little hacks like the one I'm after here, it seems to be a bit of a pain at first.

  What it means in practice is that you need something else to execute the actual dock script. In my case, that thing is my window manager, sawfish, and having the window manager do this is rather satisfying, which reinforces my positive feeling towards udev's kill policy (although, truth be told, the actual implemenation is in shell rather than in sawfish's scheme).

  To keep everything nicely together, the docking script at its core is a bash case statement, in essence:

  !/bin/bash
  # bookkeeping: we need to undock if that file is present
  UNDOCK_FILE=~/.do-undock
  
  # display for the window manager we talk to
  export DISPLAY=:0
  
  case $1 in
    start)
      sawfish-client -c "(system \"urxvt -geometry -0+0 -e $0 on &\")"
      ;;
    stop)
      sawfish-client -c "(system \"urxvt -geometry -0+0 -e $0 off &\")"
      ;;
    on)
      if [[ -f $UNDOCK_FILE &&
        $((`date +"%s"` - `date -r $UNDOCK_FILE +"%s"`)) -lt 20 ]]; then
          # debounce multiple dock requests
         exit 1
      fi
      touch $UNDOCK_FILE
  
      # let udev do its thing first; we're no longer running from udev
      # when we're here.
      udevadm settle
  
      # Commands to dock follow here
      ;;
    off)
      if [ -f ~/.do-undock ]; then
        rm ~/.do-undock
        # Commands to undock in here.
      fi
      ;;
    *)
      echo "Usage $0 (start|stop|on|off)"
      ;;
  esac
  

  The plan is: Udev calls the script with start and stop, which then arranges for sawfish to call the script from sawfish with the on and off arguments.

  There's a bit of bookkeeping with a file in home I keep to see whether we need to undock (in my setup, that's not necessary at work), and which I use to unbounce the duplicate dock request from udev. That part could be improved by using lockfile(1), because the way it is written right now there are race conditions (between the -f, the date, and the touch) – perhaps I'll do it when next I have time budgeted for OS fiddling.

  One think I like a lot is the udevadm settle; this basically lets my script rely on a defined state where all the devices it may want to talk to are guaranteed to be initialised as far as udev goes. This is so much nicer than that sleep 3 you can see in too many places.

  What I do when docking

  Why go into all this trouble and not let whatever automagic is active pick up the screen and the new network interface and be done with it? Well, partly because I don't run most of the software that does that magic. But of course having a shell script lets me say what I actually want:

  • disable sleep on lid closing (that's special to my own ACPI hacks from the depths of time)
  • configure the the external screen as primary (that's something like xrandr --output DP2-1 --off ; xrandr --fb 2048x1152 --output DP2-1 --auto for me; don't ask why I first need to switch off the display, but without it the --auto will get confused).
  • switch to an empty (“dock-only” if you will) page on the desktop (that's wmctrl -o 4096,1152 for me).
  • sure enough, switch on some desktop glitz that I'm too stingy for when off the grid.

  One thing I'm currently doing in the dock script that I shouldn't be doing there: I'm now using a wacom bamboo pad I've inherited as a mouse replacement at home and was suprised that no middle mouse button (Button2) was configured automatically on it. Perhaps some search engine will pick this up and save a poor soul looking for a quick solution reading man pages and xsetwacom output:

  xsetwacom set "Wacom BambooPT 2FG 4x5 Pad pad" Button 8 2
  xsetwacom set "Wacom BambooPT 2FG 4x5 Pad pad" Button 9 2
  

  (this makes both buttons in the middle middle mouse buttons; I'll see if I like that on the long run). Of course, in the end, these lines belong into a udev rule for the wacom tablet rather than a dock script. See above on these.

• Mailman3: "Cannot connect to SMTP server localhost on port 25"

  12021:058:0 ( 2021-02-27)

  • Badly Misleading Error Messages
  • Template Management Half-Broken
  • Disable Emergency Moderation After Moving
  • Oh No, CSRF Token

  I've been a fairly happy mailman user for about 20 years, and I ran mailman installations for about a decade in the 2000s.

  Over the last week or so, I've spent more time setting up a mailman3 list off and on than I've spent with mailman guts in all the years before, which includes recovery form one or two bad spam attacks. Welcome to the brave new world of frameworks and microservices.

  Perhaps the following words of warning can help other mailman3 deployers to not waste quite as much time.

  Badly Misleading Error Messages

  Most importantly, whatever you do, never call mailman as root. This will mess up permissions and lead to situations really hard to debug. In particular, the error message from the post's title:

  Cannot connect to SMTP server localhost on port 25
  

  apparently can have many reasons (or so the recipes you find on the net suggest), few of which have anything to do with SMTP, but one clearly is when mailman can't read or write to queue files or templates or whatever and bombs out while trying to submit mail.

  Morale: Don't claim too much when writing error messages in your programs.

  Unfortunately, I've fixed the thing accidentally, so I can't say what exactly broke. The take away still is that, in Debian (other installations' mailman users might be called something else) you run mailman like this:

  sudo -u list mailman
  

  However, I can now say how to go about debugging problems like these, at least when you can afford a bit of mailman unavailability. First, stop the mailman3 daemon, because you want to run the thing in the foreground. Then set a breakpoint in deliver.py by inserting, right after def deliver(mlist, msg, msgdata), something like:

  import pdb; pdb.set_trace()
  

  Assuming Debian packaging, you will find that file in /usr/lib/python3/dist-packages/mailman/mta.

  Of course, you'll now need to talk to the debugger, so you'll have to run mailman in the foreground. To do that, call (perhaps adapting the path):

  sudo -u list /usr/lib/mailman3/bin/master
  

  From somewhere else, send the mail that should make it to the mail server, and you'll be dropped into the python debugger, where you can step until where the thing actually fails. Don't forget to remove the PDB call again, as it will itself cause funky errors when it triggers in the daemonised mailman. Of course, apt reinstall mailman3 will restore the original source, too.

  Template Management Half-Broken

  When I overrode the welcome message for a mailing list, the subscription notifications to the subscribing users came out empty.

  This time, there was at least something halfway sensible in the log:

  requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http://localhost/postorius/api/templates/list/kal.sofo-hd.de/list:user:notice:welcome
  

  Until you read up on the mailman3 system of managing templates (which, roughly, is: store URIs from where to pull them), it's a bit mystifying why mailman should even try this URI. Eventually, one can work out that when you configure these templates from Postorius, it will take the URI at which mailman should see it, Postorius, from POSTORIUS_TEMPLATE_BASE_URL in /etc/mailman/mailman-web.py. This is preconfigured to the localhost URI, which proabably only rarely is right.

  To fix it, change that setting to:

  POSTORIUS_TEMPLATE_BASE_URL = 'http://<your postorious vserver>/postorius/api/templates/'
  

  Of course it'll still not work because the old, wrong, URI is still in mailman's configuration. So, you'll have to go back to the template configuration in Postorius and at least re-save the template. Interestingly, that didn't seem to fix it for me for reasons I've not bothered to fathom. What worked was deleting the template and re-adding it. Sigh.

  As soon as you have more than one template, I expect it's faster to change the URIs directly in mailman's database, which isn't hard, as seen in the next section.

  [Incidentally: does anyone know what the dire warnings in the docs about not using sqlite3 on “production” systems actually are about?]

  Disable Emergency Moderation After Moving

  Basically because I was hoping to get a more controlled migration, I had set one list on the old server to emergency moderation before pulling the config.pck. Don't do that, because at least as of now mailman3 has the notion of emergency moderation but makes it hard to switch it on or off. I eventually resorted to directly touching mailman's config database (if you've configured mailman to use something else than sqlite, the shell command is different, but the query should be the same):

  $ sudo -u list sqlite3 /var/lib/mailman3/data/mailman.db
  [on the sqlite prompt:]
  update mailinglist set emergency=0 where list_id='<your list id>';
  

  Note that <your list id> has a dot instead of the at, so if your list is mylist@example.org, its id is mylist.example.org.

  Oh No, CSRF Token

  The list I cared about most could be joined from an external web site, transparently posting to mailman2's cgi-bin/mailman/subscribe (oh! CGI! How am I missing you in the age of uwsgi and Django!). Looking at its counterpart for modern mailman3, the first thing I noted is that there's a CSRF token in it – if you've not encountered them before, it's a couple of bytes the originating server puts into a web form to prevent what Postorius' authors feels is Cross Site Request Forgery.

  Of course, what I wanted was exactly that: Post to Postorius from a different web site. I don't feel that's forgery, very frankly.

  I didn't see an obvious way to turn it off, and I was a bit curious about mailman3's own http API, so I wrote a few lines of code to do this; the API part itself was straightforward enough, something like:

  result = requests.post(
    getConfig("mailmanAPI")+"/members", {
      'list_id': getConfig("mailmanListname"),
      'subscriber': toSubscribe,
      'pre_verified': False,
      'pre_confirmed': False,
      'pre_approved': True,},
    auth=(getConfig("mailmanAPIUser"),
      getConfig("mailmanAPIPassword")),
    timeout=1)
  

  – but of course it sucks a bit that subscribing someone requires the same privilege level as, say, creating a mailing list or changing its description. And all that just to work around CSRF prevention. Sigh.

  On top of that, I've tried K-SAT on the pre_X booleans to try and see if anything gives me the tried and tested workflow of “let folks enter a mail address, send a confirmation link there, subscribe them when it's being clicked“. No luck. Well, let's hope the pranksters don't hit this server until I figure out how to do this.

  ---

  Hm. I think I'm a bit too locked in into mailman to migrate away, but I have to say I wish someone would port mailman2 to python3 and thus let mailman2 hang on essentially forever. It did all a mailing list manager needs to do as far as I am concerned, and while it wasn't pretty with the default browser stylesheets, even now, almost a decade into mailman3, it works a whole lot more smoothly.

  Or perhaps there's a space for a new mailing list manager with a trivially deployable web interface not requiring two separate database connections? Perhaps such a thing exists already?

  Well, summing up, the central migration advice again: Mind the sudo option in

  sudo -u list mailman import21 my-list@example.org config.pck
  

• A Mail Server on Debian

  12021:051:8 ( 2021-02-21)

  • Preparation
  • Exim4
  • DNS Edits
  • SSL
  • Aliases
  • Client Connections
  • Monitoring

  After decades of (essentially) using other people's smarthosts to send mail, I have recently needed to run a full-blown, deliver-to-the-world mail server (cf. Das Fürchten lernen; it's in German, though).

  While I had expected this to be a major nightmare, it turns out it's not so bad at all. Therefore I thought I'd write up a little how-to-like thing – perhaps it will help someone to set up their own mail server. Which would be a good thing. Don't leave mail to the bigshots, it's too important for that.

  Preparation

  You'll want to at least skim the exim4 page on the Debian wiki as well as /usr/share/doc/exim4/README.Debian.gz on your box. Don't worry if any of that talks about things you've never heard about at this point and come back here.

  The most important thing to work out in advance is to get your DNS to look attractive to the various spam estimators; I didn't have that (mostly because I moved “secondary” domains first), which caused a lot of headache (that article again is in German).

  How do you look attractive? Well, in your DNS make sure the PTR for your IP is to mail.<your-domain>, and make sure mail.<your-domain> exists and resolves to that IP or a CNAME pointing there. Note that this means that you can forget about running a mail server on a dynamic IP. But then dynamic IPs are a pain anyway.

  Before doing anything else, wait until the TTL of any previous records of this kind has expired. Don't take this lightly, and if you don't unterstand what I've been saying here, read up on DNS in the meantime. You won't have much joy with your mail server without a reasonable grasp of reverse DNS, DNS caching, and MX records.

  Use the opportunity to set the TTL of the MX record(s) for your domain(s) to a few minutes perhaps. Once you have configured your mail system, you can then quickly change where other hosts will deliver their mail for your domain(s) and raise the TTLs again.

  Exim4

  Debian has come with the mail transfer agent (MTA; the mail server proper if you will) exim4 installed by default for a long, long time, and I've been using it on many boxes to feed the smart hosts for as long as I've been using Debian. So, I'll not migrate to something else just because my mail server will talk to the world now. Still, you'll have to dpkg-reconfigure exim4-config. Much of what's being asked by that is well explained in the help texts. Just a few hints:

  • “General type of mail configuration” would obviously be “internet site“.
  • Mail name ought to be <your domain>; if you have multiple domains, choose the one you'd like to see if someone mails without choosing any.
  • Keep the IP addresses to listen on empty – you want other hosts to deliver mail on port 25. Technically, it would be enough to listen only on the address your MX record points to, but that's a complication that's rarely useful.
  • Relaying mail for non-local domains is what you want if you want to be a smart host yourself. You'll pretty certainly want to keep this empty as it's easy to mess it up, and it's easy to configure authenticated SMTP even on clients (also see client connections on avoiding authenticated SMTP on top).
  • Exim also is a mail delivery agent (MDA), i.e., something that will put mail for domains it handles into people's mail boxes. I'll assume below that you select Maildir format in home directory as the delivery method. Maildir is so much cooler than the ancient mboxes, and whoever wants something else can still use .forward or procmail.
  • And do split your configuration into small files. Sure, you'll have to remember to run update-exim4.conf after your edits, but that litte effort will be totally worth it after your next dist-upgrade, when you won't have to merge the (large) exim4 config file manually and figure out what changes you did where.

  DNS Edits

  With this, you should be in business for receiving mail. Hence, make your MX record point to your new mail server. In an NSD zone file (and NSD is my choice for running my DNS server), this could look like:

  <your domain>.  IN MX 10 <your domain>.
  

  (as usual in such files: Don't forget the trailing dots).

  A couple of years ago, it was all the craze to play games with having multiple MX records to fend off spam. It's definitely not worth it any more.

  While I personally think SPF is a really bad idea, some spam filters will regard your mail more kindly if they find an SPF record. So, unless you have stronger reasons to not have one than just “SPF is a bad concept and breaks sane mailing list practices, .forward files and simple mail bouncing”, add a record like this:

  <your domain>.                3600    IN      TXT     "v=spf1" "+mx" "+a" "+ip4:127.0.0.1" "-all"
  

  – where you have to replace the 127.0.0.1 with your IP and perhaps add a similar ip6 clause. What this means: Mail coming from senders in <your domain> ought to originate at the IP(s) given, and when it comes from somewhere else it's fishy. Which is why this breaks good mailing list practices. But forunately most spam filters know that and don't interpret these SPF clauses to narrow-mindedly.

  SSL

  I'm not a huge fan of SSL as a base for cryptography – X.509 alone is scary and a poor defense against state actors –, but since it's 2021, having non-SSL services doesn't look good. Since it's important to look good so people accept your mail, add SSL to your exim installation.

  Unless you can get longer-living, generally-trusted SSL certificates from somewhere else, use letsencrypt certificates. Since (possibly among others) the folks from t-online.de want to see some declaration who is behind a mail server on such a web site, set up a web server for mail.<your-domain> and obtain letsencrypt SSL certificates for them in whatever way you do that.

  Then, in the post-update script of your letsencrypt updater, run something like:

  /bin/cp mail.crt mail.key /etc/exim4/ssl/
  /usr/sbin/service exim4 restart
  

  (which of course assumes that script runs as root or at least with sufficient privileges). /etc/exim4/ssl you'll have to create yourself, and to keep your key material at least a bit secret, do a:

  chown root:Debian-exim /etc/exim4/ssl
  chmod 750 /etc/exim4/ssl
  

  – that way, exim can read it even if it's already dropped its privileges, but ordinary users on your box cannot.

  Then tell exim about your keys. For that, use some file in /etc/exim4/conf.d/main; such files are the main way of configuring the exim4 package in non-trivial ways. I have 00_localmacros, which contains:

  MAIN_TLS_ENABLE = yes
  MAIN_TLS_CERTIFICATE = /etc/exim4/ssl/mail.crt
  MAIN_TLS_PRIVATEKEY = /etc/exim4/ssl/mail.key
  

  – that ought to work for you, too.

  Then, do the usual update-exim4.conf && service exim4 restart, and you should be able to speak SSL with your exim. The easiest way to test this is to install the swaks package (which will come in useful when you want to run authenticated SMTP or similar, too) and then run:

  swaks -a -tls -q HELO -s mail.<your domain> -au test -ap '<>'
  

  This will spit out the dialogue with your mail server and at some point say 220 TLS go ahead or so if things work, some more or less helpful error message if not.

  Aliases

  Exim comes with the most important aliases (e.g., postmaster) pre-configured in /etc/aliases. If you want to accept mail for people not in your /etc/passwd, add them there.

  The way this is set up, exim ignores domains; if you told exim to accept mails for domain1.de and domain2.fi, then mail to both user@domain1.de and user@domain2.fi will end up in /home/user/Maildir (or be rejected if user doesn't exist and there's no alias either). If you want to have domain-specific handling, add a file /etc/exim4/forwards that contains pairs like:

  drjekyll@example.org: mrhyde@otherexample.org
  

  The standard Debian configuration of Exim will not evaluate this file; to make it do that, drop a file wil something like:

  # Route using a global incoming -> outgoing alias file
  
  global_aliases:
    debug_print = "R: global_aliases for $local_part@$domain"
    driver = redirect
    domains = +local_domains
    allow_fail
    allow_defer
    data = ${lookup{$local_part@$domain}lsearch{/etc/exim4/forwards}}
  

  into (say) /etc/exim4/conf.d/router/450_other-aliases. After the usual update-exim4.conf, you should be good to go.

  Client Connections

  This setup only accepts mail for transport locally, and it will only deliver locally. That is: This isn't a smarthost setup yet.

  For delivery from remote systems, we're using ssh because pubkey auth is cool. This even works from an exim on the remote system …

• Das Fürchten lernen

  12021:039:2 ( 2021-02-08)

  • Kapitel 1: t-online.de
  • Kapitel 2: arcor.de

  Nachdem ich in einer Zeit, als es üblich war, einfach von überall her Mails anzunehmen, tatsächlich mal ein ganz klassisches Sendmail betrieben habe, hatte ich seit den späten 90er Jahren nur noch Mailserver, die bei Smart Hosts eingeliefert haben, also kurzerhand alle ausgehende Mail an den gleichen anderen Server weitergereicht haben. – und umgekehrt auch alle Mails von dort bezogen.

  Im letzten Jahr allerdings hat das immer weniger funktioniert. Irgendwie scheint es, als hätten mit Corona die diversen Mail-Betreiber immer gewagtere Politiken ausgerollt, die vielleicht ein wenig Spam, vor allem aber die Zuverlässigkeit von Mail bekämpften; gleichzeitig nimmt die Bereitschaft erkennbar ab, die Weisheit dieser Politiken nochmal zu überdenken und im Fall von Fehlfunktionen zu klären, was eigentlich kaputt ist.

  Gegen die Politiken kann ich nichts tun, gegen das stille Verschlucken von Mails gibts eine Lösung: Ich muss wieder selbst einen richtigen, direkt ausliefernden Mailserver betreiben. Denn das ist ja eigentlich das Schöne an offenen Standards: JedeR kanns selbst machen.

  Allerdings: einfach einen Server aufsetzen und los gehts, das ist im kommerzialisierten Internet nur noch selten möglich (Mumble sei hier mal als löbliche Ausnahme erwähnt). Im Web zum Beispiel gehts ohne https und die damit zusammenhängenden Verrenkungen kaum noch, von den mittlerweile üblichen Labyrinthen aus Reverse Proxies und Containerfarmen ganz zu schweigen.

  Bei Mail, so scheint es, ist es noch viel schlimmer; ich hatte ja schon damit gerechnet, dass es da und dort etwas fummelig würde in Zeiten von SPF, DKIM, DANE und so fort.

  Dass es aber so schlimm ist, hätte ich nicht gedacht. Und so glaube ich, dass dieses Blog mutieren wird zu einer Geschichte von einem, der auszog, das Fürchten zu lernen – und insbesondere, warum immer weniger Leute eigene Infrastruktur betreiben und sich das Internet immer weiter zentralisiert.

  Kapitel 1: t-online.de

  Einliefern bei t-online.de:

  2021-02-07 11:27:26 1l8hHU-00087u-Mk H=mx00.t-online.de [194.25.134.8]:
  SMTP error from remote mail server after initial connection:
  554 IP=116.203.206.117 - A problem occurred. (Ask your postmaster
  for help or to contact tosa@rx.t-online.de to clarify.)
  

  Na klasse. „A problem occurred“. Auch mit richtig viel Mühe kann ich mir keine weniger Informative Fehlermeldung vorstellen.

  Duckduckgo berichtet, dass das halt einfach so ein whitelisting der Telekom ist und dass mensch den Laden freundlich bitten muss. Wie bitte? Was machen die eigentlich, wenn irgendwer aus Singapur einliefert? Erwarten die ernsthaft, dass auch so ein Laden bei ihnen anklopft?

  So kann mensch Standards natürlich auch aushöhlen.

  Aber immerhin: selbst am Samstag abend um acht antwortet jemand auf Kontaktmails – es sieht ganz so aus, als hätte die Telekom das an irgendwelche Kontraktoren ausgelagert. Und die wollen, dass an dem Mailserver ein Webserver hängt, auf dem, so sieht es aus, ein Impressum nach Medienstaatsvertrag liegen soll. Wozu? Keine Ahnung. Ich habe gefragt und keine sinnvolle Antwort bekommen. Und mit welchem Recht ein doch recht großer Laden einfach anderen Leuten Vorschriften machen will, welche Daten sie zu publizieren haben, bleibt natürlich offen.

  Tatsächlich bin ich in dem Punkt auch etwas empfindlich, denn die Hartleibigkeit, mit der die Exekutive im Medienstaatsvertrag den erklärten Willen des Bundestags aus dem Telemediengesetz auszuhebeln versucht... nun, das ist Thema für einen anderen Post.

  Na ja, zumindest für t-online.de sollte es mein alter Smarthost noch eine Weile tun; kriege ich halt weiter nicht mit, wenn da was kaputt ist.

  Mein MTA, exim4, hat auf Debian-Systemen die praktische Datei /etc/exim4/hubbed.hosts. Da steht t-online.de jetzt erstmal drin. Ich werde ein andermal über unnötige Komplexität jammern.

  Kapitel 2: arcor.de

  Einliefern bei arcor.de:

  2021-02-07 17:41:20 1l8n7d-0001gH-Qj ** <elided>@arcor.de R=dnslookup
  T=remote_smtp H=mx2.vodafonemail.de [2.207.150.241]: SMTP error
  from remote mail server after initial connection:
  554 fra1frontrelay13.vodafonemail.de ESMTP not accepting messages
  

  Was ist das jetzt schon wieder für eine Teufelei? Duckduckgo führt auf eine Forendiskussion die ein Vodafon-Mitarbeiter wie folgt beendet:

  wir befinden uns mitten in dem Umzug zu einem anderen Mailbetreiber. Die Arbeiten sind ca bis Ende Janaur [aus dem Kontext ist 2021 abzuleiten – A.] abgeschlossen.

  Ich geh davon aus, dass die Emailadresse Deiner Homepage auf einer Blacklist steht und daher von unserem Spamfilter aussortiert wird.

  Dafür kann ich zum jetzigen Stand kein technisches Ticket aufnehmen.

  Wie bitte? „Kein technisches Ticket“? Für eine doch recht drastische Fehlfunktion eines wirklich fundamentalen Internetdiensts, nämlich E-Mail?

  Au weia. Nun, kommt arcor.de halt auch erstmal in die Hubbed Hosts. Vielleicht probiere ich es Anfang März nochmal, kann ja sein, dass dann die Zeit ist für ein „technisches Ticket aufnehmen“.

  Es sieht nicht gut aus für offene Standards.

« Seite 3 / 3