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

[Dirk the Daring]

On Tue, 11 Jan 2005 Jan Pieter Cornet wrote:

>On Tue, Jan 11, 2005 at 10:59:42AM -0500, Dirk the Daring wrote:
>>    The main purpose IO has in life is to be a mail relay for multiple
>> Domains that I host - there is NO need for local delivery (i.e. there
>>    Servers A, B and C all relay OUT thru IO (that is, they are all
>> configured to regard IO as their "Smart" mailhost). Only IO sends E-Mail
>> out from my network.
>
>Note that it saves hassles and confusion if you split the I and O
>functionality here, ie. have one dedicated incoming MX server, and
>one dedicated outgoing smarthost.
>You can combine them, of course, this is just what I'd recommend.
>Hardware cost should be peanuts compared to the ease of maintenance

   You left the issues of supplying UPS-protected power, and cooling
to deal with the heat dissipation, out of your cost calculations.
Really, this is a small-time operation running on a shoestring that's as
much wishful thinking as anything else. A single machine does fine.

>>    IO is configured to use RBLs with the FEATURE(`dnsbl') and
>> FEATURE(`enhdnsbl') entries in sendmail.cf. It does this successfully.
>
>You could move that to mimedefang, with some added flexibility (eg,
>we do that to allow per-recipient selectable DNSbls). But it works well

  Global RBLs are fine, and the sooner I drop the spammer's connection,
the sooner that resource is freed for legit E-Mail. No one on my system
is going to be interested in twiddling with their RBLs - that's what
they've got me for.

>>    The problem arises in how to properly route E-Mail. I can't use
>> RELAY_DOMAINS (Class {R}), as that bypasses the access db for the listed
>> Domains. If I use RELAY_DOMAINS, it becomes impossible to blacklist
>
>Class {R} is evil. And a downright security risk if you do not control
>the DNS of one of the domains in it. Do not use it.

   Agreed - I have no desire to use Class {R}, and have already
eliminated it from my configuration. I need to be able to blacklist
based on recipients.

>>    I can use FEATURE(`virtusertable') to translate addresses to the
>>    The problem being that I cannot use VIRTUSER_DOMAIN_FILE because
>> those entries get added to Class {R} and again break the access db.
>
>You do not have to use VIRTUSER_DOMAIN_FILE. That is just a macro
>that fills class {VirtHost}. You simply put all domains that you
>wish to relay for in /etc/mail/virtuser.domains, and put this in your
>sendmail.mc:
>
>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}?

>>    As a final complication, I also can't use /etc/mail/local-host-names
>> (Class {w}), because that breaks mailertable (i.e. mailertable is not
>> consulted for Domains in Class {w}). Besides, as I noted, there is no
>> local delivery at all.
>
>You don't want Class {w}, that will make userX at domain1 equivalent
>to userX at domain2, which is not necessarily what you want.

   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

>> 	1) Is there any definitive listing of what tables are
>> 		consulted in what order and when during the
>> 		sendmail mail-handling process?
>
>Well, cf.README (or the README in the cf/ subdirectory) does
>something, but it doesn't really do it very well. Look for the
>section marked

   I've read that, back-to-front, and its basically a rehash of other
docs in the Bat Book and also online at www.sendmail.org/features

   Someone else suggested using the debug commands.

>Or, easier and better configurable, do it within MIMEDefang:
>
>sub filter_end {
>    if ( grep { /foulword|badlanguage|deity/ } @Recipients ) {
>	return action_bounce("No swearing");
>    }
>}
>
>This has the side-effect of blocking messages completely that
>are even Cc-ed to those with the illegal usernames. Which can be
>construed as a feature.

   That's probably going to be my long-term route. I was just trying to
get some basic blocking working before I started on implementing MD and
SA. And yes, blocking the addresses in CC is fine by me.