SpamAssassin at SMTP time with exim

[Jim Hickstein]

> For those who can afford the burden it places on new contacts, you can do
> a particularly twisted thing with list software, and make it help you with
> this;  make them "have to subscribe" or use the password-of-the-day to
> get by the receptionist.   Doesn't work for certain kinds of mail
> accounts, but it's a thought.

I once conceived (a long time ago), but of course never implemented, a 
thing I call "secretary".  Anything not on the whitelist goes to it, and it 
autoreplies with, basically, "Do you have an appointment?".  It generates a 
cookie that a correspondent can use in a reply to make the appointment, 
i.e. get to the human (but not necessarily onto the whitelist).

Surely the world has caught up with me, and this is available, now, by some 
name.  Right?  I've seen pieces of it, but not exactly this way, and not 
that work in anything but a UNIX and /var/mail environment, where the MUA 
and MTA run on the same host.

The problem with all of these things turns out to be how easy or hard it is 
for the user to manage the whitelist.  For a single user, vi(1) and 
procmail might be OK, but I want to offer this solution to my customers[1], 
and writing the code for the user interface (surprise!) is where theory and 
practice part company.  Even for myself, my mail is not delivered to a UNIX 
account, so procmail really isn't an option.  And with all due respect to 
Heather, I don't want procmail wrangling to turn into a full-time job.

[1] Plug: www.imap-partners.net.  I run an IMAP server (a Mirapoint box) 
which otherwise does a good job of dealing with the user interface by 
itself.  But this is an area (currently) where I must add value externally, 
and it's a lot of work.  Even the user-accessible filters in the box can't 
"see" a user's address book, so the whitelist must be constructed and 
maintained very laboriously.  So much so that I frankly haven't bothered. 
And I get a lot of spam, as I've been in WHOIS for many, many years.