Busy, stopping email

The past couple of months have been busy: I've been working on different deliverables for OpenSolaris, SMF, and SFW. I'll try to give summaries on each of these items as they complete in the coming weeks, but I thought I should mention the consequences of some anti-spam provisions I implemented on opensolaris.org in February. Since these restrictions can cause mail to OpenSolaris lists to be dropped, you may wish to read on.

At the time, we had essentially no anti-spam on opensolaris.org's mail pipeline, and we relying on Mailman (which handles our 120+ lists) to reject spam directly, or for list moderators to do so manually. We knew that some lists were promptly moderated, and others less so, but figured things were working, for the most part. This state of affairs then changed.

It was public news that there was a jump in spam volume the previous fall. On opensolaris.org, spam hit all of our addresses, including administrative aliases for list subscription and removal. Mailman requires time to process each request, and with the rate of inflow, finally built to a backlog of almost 35 000 unprocessed Mailman administrative queries in early February. For a potential OpenSolaris list subscriber, this translated to a multi-hour wait for subcription requests—no way to make it easy to get in on a conversation.

To stop the -subscribe and -unsubscribe addresses from getting pounded, I started activating the basic anti-spam features of Postfix (which we have run on opensolaris.org since the initial setup). Presently, we expect a host to have legitimate DNS entries and to not be on various blacklists, and we expect envelopes to be well-formed. The backlog started to clear as these controls were in place, and was completed with no dropped requests a day or two later. (We had one hiccough: I had initially written the configuration so that Postfix didn't trust the Mailman outbound mail, which meant that we did both anti-spam on the inbound submission and also on the dozens or hundreds of outbound messages to the list subscribers. Once we straightened that out, things have been much better.)

Since we imposed these requirements after initial subscriptions, it is possible that a valid subscriber to a Mailman list can no longer send mail acceptable for opensolaris.org. This problem is particularly likely to be related to a host lacking a valid MX record. If you've sent mail to opensolaris.org that hasn't appeared in the lists, please check that you have a valid MX record. You can use one of the web forms offering MX lookups, but on an OpenSolaris-based system it's easy to do this using nslookup(1M):

$ nslookup

> set querytype=mx
> rosseau.eng.sun.com
Server:         192.168.1.2
Address:        192.168.1.2#53

** server can't find rosseau.eng.sun.com: NXDOMAIN

> rosseau.sfbay.sun.com
Server:         192.168.1.2
Address:        192.168.1.2#53

Non-authoritative answer:
rosseau.sfbay.sun.com   mail exchanger = 10 btmx1.sun.com.
rosseau.sfbay.sun.com   mail exchanger = 10 btmx3.sun.com.
rosseau.sfbay.sun.com   mail exchanger = 10 btmx4.sun.com.
rosseau.sfbay.sun.com   mail exchanger = 20 mx3.sun.com.
rosseau.sfbay.sun.com   mail exchanger = 20 mx4.sun.com.

Authoritative answers can be found from:
sun.com nameserver = ns1.sun.com.
....
>

(In fact, rosseau lost its eng.sun.com MX record in the past couple of weeks, so I, too, got caught by the new policy.)

Both our Mailman instance and our many moderators are much happier now, processing many fewer, mostly legitimate list postings. If you've a valid MX record, aren't blacklisted, and are still having problems, website-discuss is the place to ask.

[ T: OpenSolaris Postfix Mailman spam ]