Excluding Certain Recipients

Nick Phillips nwp at LEMON-COMPUTING.COM
Mon Jan 7 16:44:40 GMT 2002


On Mon, Jan 07, 2002 at 10:56:21AM -0500, Christopher Hicks wrote:
> On Mon, 7 Jan 2002, Nick Phillips wrote:
> > On Sun, Jan 06, 2002 at 03:44:11PM -0500, Christopher Hicks wrote:
> > > I think there's an opportunity here for a more general feature.
> > This could get ridiculously complex, couldn't it?
>
> No. I think it would be much simpler.

You're mistaken. Honest. Trust me [cheesey smile]...


> $RecipCfg = {
>         bob at domain.com => {
>                 Scan => 'No',
>         },
>         tom at domain.com => {
>                 Spam => 'Delete',
>         },
>         kim at domain.com => {
>                 # gets lots of virus, lets be insanely thorough
>                 SpamScanners => [innoculate,fprot,sophos],
>         },
> };

Users don't write perl.


> How would you express that in sendmail.cf?

I don't use sendmail. OK, so that's a cheat's answer, but I'd put something
like this:

if ("${if exists {/home/$sender_address_local_part/.nospam} {1}{0}}" is "1")
  and $h_X-MailScanner-Spam: contains "spamassassin"
then
  fail text "This looks like spam to me..."
endif

in my Exim system filter.


> > Wouldn't it be better to use some kind of filter in the MTA config
> > after it's passed through mailscanner?
>
> Better?  Not noticably.

Better: the complexity is kept in one place (the MTA), which has had years
of practice to get it right. MTAs have historically been insecure because
they are complex. Speaking for myself, I don't want mailscanner to get more
complex than it has to be, because that *will* introduce bugs.

Better: one less thing for an admin to learn; an admin will almost certainly
have to learn how to do things like delivery dependent on header matching
with their MTA/MDA combination anyway, so why make them learn how to do it
with mailscanner too?

Better: less bloat.


>  Easier?  Certainly not.  I like sendmail, but I
> wouldn't want to have to force it to do this sort of thing.  For one
> thing, I like the same sendmail.cf being usable for the incoming and
> outgoing queues.  That wouldn't work if it the outgoing queue had to
> enable various filters.  But even more importantly, given the choice
> between making sendmail filter or adding the functionality into
> mailscanner myself, I'd much rather write perl.  And that way, once I
> add mailscanner to my qmail boxes I don't have to worry about dorking with
> qmail to get it to do what I want either.

Easier: one less thing to learn, as above.

Easier: yes you could still use the same sendmail config.

Easier: no perl coding to do.

Easier: you only have to maintain filtering in one place.

Easier: easier to configure mailscanner "correctly" (so as not to let bad
things happen when/where they shouldn't).


Seriously, if sendmail (or procmail) scares you to the point that you don't
like the idea of making it filter based on a header, you shouldn't be using
it - find something you can understand and make behave as desired.


> > I'd rather not see too much duplicated complexity between mailscanner
> > and MTAs - especially with MTAs' histories of getting it wrong.
>
> Broke MTA's would seem to make doing it right once much more sensible. :)

To butcher several quotes:
"Those that do not learn from history are condemned to repeat it, badly"

Complexity == bad.


Every time we make it possible to misconfigure mailscanner in such a way as
to do Bad Things, we condemn some poor sod to lose mail/get viruses/whatever
in exactly that way. Murphy's Law.

Goodness me, the random .sig generator comes up with an appropriate one yet
again...


Cheers,


Nick
--
Nick Phillips -- nwp at lemon-computing.com
Today's weirdness is tomorrow's reason why.
                -- Hunter S. Thompson



More information about the MailScanner mailing list