[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[cobalt-users] Re:FW: RaQ4 - Blocking e-mail



At 10:04 AM -0400 7/1/02, Jolley, Carl is rumored to have typed:

> "Tim Skipper" <mailinglists@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > How can I block, preferably on a site-by-site basis if possible,
> > e-mail being accepted from a given domain?
>
> Tim, use procmail, which is already installed on your RaQ4.  Do the
> following.

   This doesn't "block" email, it only trashes it. (And personally, I'd use
an external file of domain names instead of trying to place them all within
the rc file itself, and I'd _never_ use the From: header field alone since
spam rarely will come from the same machine the From: header field's been
forged to read, but that stuff's the sort of thing best discussed on the
procmail mailing list.)

   To truly _block_ mail, that is refuse to accept the mail in the first
place and drop the connection to the sender machine like a hot potato, you
need to do it on a system-wide basis through the /etc/mail/access file. Note
that the Cobalts reserve the top of that file for themselves, but you may use
the underneath to block email from specific users, domains, or netblocks.

   The full scoop is available at sendmail.org (required reading if you want
to get the most from your mail server), but to block specific domains, place
lines like:

yourwebcentral.com	REJECT

   ...which will send a standard, "Permission Denied" error. If you want to
customize the error message received, you can do something like:

adv-data.com	572 Get Lost

   ...to reject mail from a single IP, try:

64.29.137.97	REJECT

   ...and, of course, if you want to avoid receiving mail from an entire
C-netblock _and_ send a customized error, you can do something like:

65.240.69	559 Drop Dead

   Changes will take effect as soon as you rebuild your access.db; you don't
need to restart sendmail.

   Again, though, before you start adding things to your access database,
you'll need to bone up on sendmail at sendmail.org (like why sending a
400-level error is probably NOT what you want to do and why sending a
500-level error probably IS). Take a few hours and read the information
there...it's good stuff.

         Charlie