I have recently configured a Postfix mail server to use SpamAssassin as a before-content filter using SpamPD as described on the SpamAssassin Wiki. I have been quite impressed with how well it is working, with one exception. A few email messages have been getting rejected with the following error message:

After a bit of investigation I found that the problem is due to a few mail servers that include the AUTH parameter to the MAIL FROM command, even when not authenticated. However, this server is configured to allow authentication only over TLS/SSL. The problem is that the AUTH parameter is passed through SpamPD to the receiving instance of postfix, which rejects the MAIL FROM command because the connection from SpamPD is not using TLS/SSL. To solve the problem, add "-o smtpd_tls_auth_only=no" to the postfix receiving entry in master.cf from the example as follows:

I was recently assisting a colleague to setup VNC on a headless server for remote graphical administration. I had followed one of the many VNC+GDM tutorials on the Internet and everything was working great. Then, after a reboot, it stopped. Here's what happened:

Symptoms

The server is running Debian Squeeze and is configured similarly to the settings in this HOWTO on the Ubuntu Forums. After working quite well for several months, the server was rebooted and it ceased to work at all. Whether connecting using VNC or directly over XDMCP I was presented with the generic black X cursor over a black/white/grey patterned screen and the GDM greeter was nowhere in sight.

After much poking and prodding and technical assistance I determined the key symptom. Everything works well when the server is booted with a monitor connected. When started without a monitor, X would fail to start with the following error:

(EE) open /dev/fb0: No such file or directory
(EE) intel(0): No modes.
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

Although this shouldn't be a problem for the VNC session (which doesn't require an X display on the video hardware), it was.

Solution

Fixing this problem simply required disabling the GDM server instance running on the display hardware. With this server disabled in the GDM configuration, everything works smoothly regardless of whether or not a monitor is connected. On Debian, the default server can be disabled by editing /usr/share/gdm/defaults.conf and commenting out the following line (around line 604 in my version):

Bug Report?

I'm not knowledgeable enough about how GDM and XDMCP are supposed to work to know if this is a bug or expected behavior. Any feedback on this point would be greatly appreciated.