[Mimedefang] Re: Sendmail config (slightly OT) (Jan Pieter Cornet)

[Dirk the Daring]

On Wed, 12 Jan 2005 Jan Pieter Cornet) wrote:

>On Wed, Jan 12, 2005 at 04:07:59PM -0500, Dirk the Daring wrote:
>>   Global RBLs are fine, and the sooner I drop the spammer's connection,
>
>Not everything that's on an RBL is necessarily spam :) You might want
>to protect "ceo at yourcompany" with l2.spews, but not abuse at yourcompany...
>But it's OK to start with central blacklists, and step up to doing it
>in MD later of course, if or when it becomes necessary...

   That's why I employ FEATURE(`delay_checks') as I noted in another
message. This allows E-Mail from "legit" RBLed sites to reach me for
whitelisting.

   And *I* am the "ceo" :-)

>> >LOCAL_CONFIG
>> >F{VirtHost}/etc/mail/virtuser.domains
>>
>>    I'm unclear on how that is different. Won't the contents of Class
>> {VirtHost} get added to Class {R}? Or is this a way to bypass that?
>> Since this is a pure relay, with NO local accounts, should I even use
>> Class {VirtHost}?
>
>It's different precisely because it DOES NOT add class {VirtHost} to
>class {R}. The default VIRTUSER_DOMAIN_FILE macro will do that for you,
>in a misguided attempt to be user-friendly, but you don't have to use
>that macro.

   OK, I understand the difference - the m4 macro wants "helpful" and
does both things, but if I manually set the value of Class {VirtHost} it
doesn't propogate to Class {R}. That makes sense.

>>    I tend to agree, but then how do accomplish the things I want to do
>> such as having an /etc/mail/access entry like
>> 	to:someaddr@		REJECT
>>    and having that applied to ALL Domains I host? So that
>> SMTP RCPT TO: someaddr at domain1.com results in a REJECT, as does SMTP
>> RCPT TO: someaddr at domain2.com
>
>You can't. You can't have it both ways. Once use put the domains in
>class {w}, recipients will ALWAYS be treated the same, you cannot split

   OK, Class {w} is out. This is the problem I noted in my last E-Mail
to the list in reply to Ashley's message, and it seems to be confirmed
on the  Sendmail website, at http://www.sendmail.org/m4/anti_spam.html,
down near the bottom where FEATURE(`delay_checks') is discussed, where
it says that the implied "localdomain" following an access db entry ending
in an @ is checked against Class {w}.

   So if I don't use Class {w}, and it seems I should not, I'm back to
the "stone knives and bear skins" level of management (at least until I
get MD running).

>You might consider "blocking some list of aliases in every domain"
>is not basic filtering anymore, and delay that until you have MD
>running :)

   It still something I need to have, and given that getting MD running
is fairly high on the List Of Things To Do, I can stomach the manual
blocks in /etc/mail/access until MD is operational.

>Oh... one more thing. From your questions I take it that your "IO"
>host will simply accept every address on all domains that you host,
>and then bounce the stuff that's rejected on the target machines.
>This is generally considered a bad idea these days. We (unfortunately)
>have this setup for some clients in a batched-SMTP setup, and I regularly
>see spammers drop thousands upon thousands of dictionary spam on those

   Yeah, that is my v1.0 implementation.

>Fortunately, MD to the rescue again. MD has a function
>md_check_against_smtp_server(), that allows you to check a recipient
>against a remote SMTP server, while the recipient is being offered to us.
>You will very probably want to use it. And it's dead easy because your
>sendmail setup will already provide MIMEDefang with the correct remote
>host to check against (in $rcpt_host, given that $rcpt_mailer =~ /smtp/).

   Yep. Another reason that getting MD running is so high on the List Of
Things To Do. Main purpose of this thread is for me to get sendmail
operating as best it can before I start working on MD. I want to have
sendmail all tweaked and configured, then I'll start implementing MD and
SA and CLAM. The md_check_against_smtp_server() function sounds like its
a feature I'll be using.

   Thanks again for your input.