Qmail woes

I wouldn't recommend anyone ever to use qmail, no matter how beautiful the architecture might strike you. It's confusing, takes a solid two hours to even find a document to read, and there doesn't at all seem to be much community support for it. Most of the time you're left to your own devises with a--excuse my saying so--retarded mail server.

Maybe you know about Transport Layer Security, or TLS for short. It's a common enough thing, SMTP servers are known for their use of TLS. Well, Qmail probably isn't, because the only TLS support there is is a huge patch whose website is presently down.

As it turns out, one of these days my TLS support had just given up. Qmail doesn't tell you though, oh no -- not at all. You have to dump the I/O it does with Gmail to know anything is going wrong.

If I were you, and I was using Qmail with TLS support (like I do), then I'd check if my SMTP server goes wonky after I send STARTTLS. Mine did, and didn't tell me.

Why does this matter? Well, as it turns out, Gmail doesn't deliver messages when TLS fails like this, and I can't really blame them because my server advertised support for TLS.

So in short: stay away from Qmail, don't accept patches from strangers and don't wake up too late.


RTNETLINK complaining about "No buffer space available" (also SIOCSIFADDR)

I'm writing this to save somebody a headache.

My router does IPv4 and IPv6, and has been doing so for a while. I started noticing that when connecting to my own server from my own home, it would take a while. I whittled it down to it trying to connect with IPv6 first, failing and then falling back to IPv4 which worked fine.

Now, why had my IPv6 died? To cut a long story short, here's why:

router # ip link show eth1
4: eth1:  mtu 576 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:50:bf:21:b2:52 brd ff:ff:ff:ff:ff:ff

Look closely. Closer. The MTU isĀ 576. No buffer space? Well, that just means the MTU is too low for IPv6! The error mesasge couldn't have been more clear! Err...

router # ip link set eth1 mtu 1500

BAM! Now it works again.

So why was the MTU set to 576? dhcpcd set it to that value! A-ha. Apparently this also happens to dhclient, and I guess the two are intertwined in some weird open-source way. My more persistent solution?

router # unlink /lib/dhcpcd/dhcpcd-hooks/10-mtu

BAM! Now it won't break for a while.


RSS 2.0