Re: [cobalt-users] Sendmail features

[Larry Smith <lesmith@xxxxxxxxx>]

On Friday 11 April 2003 05:12 pm, Bruce Timberlake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > could somebody come up with some suggestions for the following problem?
> > I have a user on my cobalt, say abc@xxxxxxxxxx, that I do not want to
> > receive any email for because of the amount of spam coming in on that
> > useraccount. Removing the user from the cobalt is not an option, neither
> > is installing some anti-spam software. What I did is edit the
> > virtusertable and instead of delivering the email to abc, I bounce the
> > emails with 'error: nouser'. It works fine, but I guess it is not the
> > best solution because the emails bounce and since alot of spam does not
> > have a valid sender, the emails just keep bouncing back and forth, don't
> > they?
>
> Redirect the mail to user 'nobody' instead of trying to bounce it.
> /etc/mail/aliases redirects all mail for 'nobody' to /dev/null.
>
> So your virtusertable entry would look like:
>
> abc@xxxxxxxxxxxxxxx	nobody
>
> Remember you need to put the full host in there as abc@xxxxxxxxxx gets
> "rewritten" to abc@xxxxxxxxxxxxxxx, then rewriting to the local username
> gets attempted.
>
> Remember also to rebuild virtusertable:
>
> makemap hash /etc/mail/virtusertable < /etc/mail/virtusertable
>
> - --

Bruce ,

  Not to be arguementative (sp?), but.....  you are completely correct and 
this is a perfectly "legit" way of "disposing" of the mail - but it does not 
stop the mail from coming in, and taking up time, processes, etc on "the" 
server in question.  Same problem with any "bit-bucket" or internal filtering 
- the spam or un-desirable email has already been "delivered" to your system 
and you then have to "do" something with it.

I much prefer up front "error" response (yes, all 500 code sendmail responses 
indicate total failure and the remote is supposed to cease and desist at that 
point).  From my perspective, my server has only had to say "no" at that 
point, not accept the message, process it, then deliver it to nobody (which 
then gets "delivered" to null - yes a "double" process of sorts).  Also the 
up front failure means the mail "stays" on the relay/proxy/spammers system - 
taking up their space and processing and cpu and such instead of mine.

Better approach is to find that "user" in the normal virtusertable list, copy 
the line, then delete it, go to the bottom of the virtusertable and paste the 
line in and change the ending to the generic "no such user" error message.  
Even though the user "exists", the server will give a 553 no such user error 
to each sendmail call at the RCPT TO line - which means you have not even 
accepted anything yet...  (and the appropriate makemap hash virtusertable < 
virtusertable, and restart sendmail).....

Larry Smith
SysAd ECSIS.NET
sysad@xxxxxxxxx