Conversely, since at least 80% of non-spam mail comes from Windows, shouldn't we assign major non-spam points to mail coming from Windows boxes? Statistics are a wonderful thing

Wouldn't that end up flagging most messages from Exchange servers as spam?

On the other hand, most people probably receive far more trojaned Windows spam than legitimate mail from Exchange users, so it might a fair tradeoff. Heh.

Whose remote TCP stack would you connect to?
Most of the time tracking a spam back to the individual sending machine (windows) is impossible-
So all you'll see are intermediary MTAs (likely not windows)

Are you blocking dynamic (dialup, cable, DSL) IPs from connecting directly to your mailservers yet? AOL does, so do I and I wrote the SpamPal plugin which does it client-side. NJABL has the one I use, here's the list of possibilities I know about:

MXNJABL YES dnsbl.njabl.org 127.0.0.3
MXPANAM NO dialups.visi.com 127.0.0.2
MXDULRU NO dul.ru 127.0.0.1
MXLEAD NO spamguard.leadmon.net 127.0.0.2
MXSORBS NO dul.dnsbl.sorbs.net 127.0.0.10

YES is the one I have turned on, domain is the place to send the DNS query, IP is the result code which means dynamic. The usual reversed byte order for a DNS query. Can cache the results for a long time (a week perhaps) with a local DNS server - these don't change much.

You will get some complaints. Mail address whitelists are a good idea to cut them - if you track outgoing for a while you can build the list in advance. If it turns out that you don't have an efficient way to compare addresses, calculate CRC-32 and just use that - you don't care enough about the rare collisions (false positive whitelisting) for it to matter. No idea if your mail system does this efficiently or not.

For those who don't know, trojan-captured systems tend not to use the mail servers of their ISP. They tend to directly connect to the mail server of the destination site. Hence, direct to MX spam and blocking of such connections, or even ISPs blocking the ability of their customers to make outbound connections on the normal port used to connect to those servers.

No, we don't. We should, though. I'll do it at least for my personal mail.

You mentioned QMTP, why are you guys using postfix and not qmail? If security, performance, and ease of administration are at the top of your requirements, you should take a serious look at it.

I don't like djb.

Me either, but hey I swallow my pride, his software is the best.

Well, it's not in Debian, so as far as I'm concerned it's not part of my free software world.

Touche:
http://packages.debian.org/stable/mail/qmail-src
Sure you have to "compile" it (using the qmail-build command that comes with the package) but djb doesn't allow qmail to be distributed in binary form anyways, mostly for academic reasons

I'm aware of that. Did you notice the big red [non-free] marker after the title?

I'm sure this HTTP + QMTP thing is swell... but could you explain how it's not reinventing the SMTP wheel, please?

Because I couldn't figure out how to get SMTP to accept+defer immediately without blocking the SMTP client.

It's a quick hack.

But it's also good because, like QMTP, there's much less round-tripping, and the client can keep a persistent connection open and reuse it. Yes, you can do that with SMTP too, but none of the perl modules seem to support it. Or I haven't seen.

If we ever get our mail non-sucky, we could remove this hack.

I don't like djb either. ;^>

Postfix 2 can accept/defer at SMTP time, though it does make the client wait. (There's really no way not to if you're going to give them a 45x or 55x.) In my experience (feed data to amavisd, so to SA), it's not long enough that anyone hangs up on you.