>Why not break the smtpd into two parts, the way qmail's pop3d
>separates auth from mail access. The first part handles everything
>before DATA, and this can be as simple as a shell or perl script.
Doesn't break up very nicely, since it's quite common to do multiple
mail messages in one transaction with a RSET (which I know isn't really
necessary) after each one.
This seems to be a reasonable place to use an exit routine. That is,
each time you get a RCPT TO address, optionally fork and run a program
specified in a control file or environment variable. The program
might get the MAIL FROM as the first argument, RCPT TO as second
argument, and inherits the TCP environment variables from smtpd. The
program can do any processing it wants and returns 0 if the recipient
should be added to the list, 1 for don't add, 2 for don't add and
don't say anything because the program's already written an error
message, and maybe 100 for croak instantly.
This lets people implement any funky smtp filtering they want without
cluttering smtpd with patches. I gather Dan doesn't think much of
this idea, but I don't see what's wrong with it. Certainly exit
routines have been around for a long time and are a well-proven
extension mechanism. It's sort of the inverse of the way that
"except" and "bouncesaying" work. Yeah, it could screw up the SMTP
dialog, but patches can screw it up worse.
--
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869
[EMAIL PROTECTED], Village Trustee and Sewer Commissioner, http://iecc.com/johnl,
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail
