Brad Knowles wrote:
> At 10:54 PM -0400 9/1/1996, Stan Ryckman wrote:
> >Check out procmail. Even if sendmail delivers your mail, you
> >can have it forwarded through procmail, which will give you
> >incredible numbers of options. I use it to do very complicated
> >mail sorting here.
> That doesn't refuse the message -- sendmail still accepts it, and
> then it's up to you to either /dev/null it or try to bounce it. What
> you really want to do is completely refuse delivery.
It "refuses it" from the end user's viewpoint, which is what I think
the original poster was requesting. It goes through the delivery
process (including possible explosion), thus eating system resources
(but not the end user's allocation of same, and not the end user's
time), but the original poster said "gracefully refuse" which led me
to believe that's what she wanted.
On the other hand, I (probably ill-advisedly) added:
> >If you're a system administrator, then you could consider running
> >procmail *instead* of sendmail; it can do that as well.
> Uh, no. Speaking as someone who has installed procmail before,
> it has no concept of the SMTP protocol. It is not capable of being
> run as a replacement for sendmail. It *can* be installed as a
> replacement for the local mailer (usually /bin/mail, or mail.local,
> or somesuch), per the instructions found in the procmail distribution.
How long ago? I probably wasn't very clear; I meant as a MDA, not as
a MTA. You don't have to use sendmail as the MDA. The man page says:
If running suid root or with root privileges, procmail will
be able to perform as a functionally enhanced, backwards
compatible mail delivery agent.
You can then use procmail to globally not deliver an arbitrary match
to any user's mailbox.
> (if you understand what's being
> blocked, it's virtually trivial for the folks on the other end to
> make changes to bypass the blocks you're putting in).
Yup. You then might have to be vague about "what's being blocked"
to avoid giving away the show. LISTSERVs are doing this now to
block spam, and the documentation states that they won't reveal
the algorithms because it will just show up in the next "How To
Spam The Internet" type of book (not a direct quote).
It's probably always best to give end users a chance to "accept
everything" anyway -- protects against a defective blocking algorithm
for users for whom losing something might be more costly than
wading through spam. That means accepting it via SMTP, looking at
the headers and/or body, and only then deciding how to distribute it
(Yes, I'm aware of implications regarding searching the body --
I'm thinking of identifying characteristics such as addresses, phone
numbers, etc. which would serve as identifiers of known problem
mailers, not as content filters.)