Excluding Certain Recipients

Christopher Hicks chicks at CHICKS.NET
Mon Jan 7 21:07:27 GMT 2002


On Mon, 7 Jan 2002, Nick Phillips wrote:
> If you are able to automate the process, why not do as someone else
> suggested, and automate dumping a procmail recipe into users' home
> directories?

Because, as I originally explained, the users do not exist on the mail
server in question.  They're reading e-mail off of a variety of remote POP
servers.  Dropping in procmail recipes doesn't work on NT boxes or boxes
where the POP users don't have UNIX user accounts.  My hope is to migrate
all of my POP-only users away from having UNIX user accounts to help
security.

Again, I really like procmail.  I have a 10k .procmailrc that I've been
tweaking for seven or eight years.  It's just not a solution to the
problem in question.

> How so? It achieves what I understood to be the desired aim of not
> delivering spam on a per-user basis.

Does it work in sendmail which the majority of people use?  No.  So it
didn't answer the question.

> If you're talking about whether to scan or not on a per-user basis,
> then I agree that it may be worth adding support to mailscanner to
> configure scanning/not scanning on a per-domain basis, but per-user is
> IMO pushing it.

There's basically no difference from a systems design perspective.  If the
one is OK, the other is too.

> Again, if you're talking about scanning-or-not, then per-user or
> per-domain config can obviously *only* be done within mailscanner.
> I've (possibly kind of) agreed with you about that above, so back to
> the spam - I see it more as a delivery-kind-of-thing, over which an
> individual user can easily be given control with no modifications to
> mailscanner required.

But if we're modifying mailscanner to allow scanning-or-not, what harm
is there in making it a bit more poweful and allowing some other logical
options to be tweaked?

> > > Better: less bloat.
> > Precisely what I'm looking for.
> Glad we agree wholeheartedly on something ;)

[cheering.]

> > > >  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.
>
> Shurely (for the Private Eye readers amongst you) the fact that you filter
> based on a header makes no difference to whether or not the config works
> for both queues, especially if you only do it for messages which you are
> actually delivering. Or maybe I'm just seeing things in an Exim-centric way.
> Please enlighten further.

Presuming you came up with someway pre-procmail for sendmail to allow such
filtering, you wouldn't want that to be occuring on the incoming sendmail.
Doing it twice may or may not work, depending on how the filter is setup.
Presuming it does work, why do it twice?  It's just a waste.

> b) It'd be great to have qmail support for mailscanner... if there's
> anything I can do to help without going so far as installing qmail,
> shout. [why do I still feel like I might live to regret saying that??
> ;) ]

qmail is an odd bird.  I wouldn't fight with it except that ezmlm is so
wonderful.  I haven't tried pushing mailscanner over there yet.  I'm
deploying it gradually.  So, you have a while before we get to see if you
regret it.

> > > Easier: one less thing to learn, as above.
> >
> > I know perl, sendmail, and qmail.  But I know perl a heck of a lot better
> > and it integrates with everything else we're using and going to use for
> > the forseeable future.
>
> But for most users, they will know their MTA and their MDA, and the
> simper this new mailscanner thingy is, the better.

Yes.  But adding the feature as I conceive it doesn't complicate anything
for those people whatsoever.  It's there if you want to go use, otherwise
it doesn't come over and bite you.

> I don't feel a burning desire to learn the intricacies of sendmail.cf
> in order to demonstrate this; instead, I would expound the virtues of
> an MTA with a human-comprehensible configuration. Like Exim. Or maybe
> Postfix or Qmail even, but I'm not familiar with either of those two.
> Either way, since that's presumably not what anyone wants to hear, I
> won't. Much.

sendmail has it's warts.  It's also had a number of warts removed in a
very public and embarassing way.  But for most people running UNIX's out
of the box, it just works.  For me, it does things that I can't easily do
with the others yet.

> > Take 100 admins who can code perl as well as Randal and sendmail as well
> > as Eric Allman and most would prefer to code in perl!  I suspect Eric
> > would fall in that category himself.
>
> ;)  Take 100 admins who are familiar with both Exim and sendmail...
> no, I said I wouldn't.

Your distaste for sendmail is perfectly reasonable.  I sympathise to a
large degree.  It can be a real bear.  But for the majority of people out
there, it is the ONLY mta.  Discussing mailscanner's future features based
on exim or qmail simply isn't relevant for the vast majority of systems
and admins out there.

> > > Easier: you only have to maintain filtering in one place.
> >
> > (A) This isn't simply filtering.  (B) Maintaining it in one place (within
> > mailscanner) is the whole point.
>
> (a) then those bits that aren't need to be considered separately;
> (b) I don't expect generic procmail-style filtering to be added to mailscanner
>     any time soon.

Neither do I.  I'm not trying to create generic filtering.  I'm not trying
to replace the MTA.  I'm just trying to configure mailscanner dynamically
based on recipient.  My personal trivial goal of that is to be able to
drop spam from those who don't want it.  The other logical option is to
get clueless newbies to configure Outlook, Eudora, and Netscape.  I could
make web pages for all of that and still have to walk most of them through
it over the phone.  It's easier to fix it on the server.  I'm lazy.  I use
perl.  Go figure.

> > > Easier: easier to configure mailscanner "correctly" (so as not to let
> > > bad things happen when/where they shouldn't).
> >
> > If you don't add user-specific configs, nothing changes.  It's like pine.
> > The feature isn't there unless you choose to go turn it on.  No harm done.
>
> Fine in theory, but in the Real World, I doubt it.

Doubt is good.  Yet I've seen no substance to your doubt.  You agree,
even, that per-domain config of mailscanner makes sense.  So, why doesn't
per-recip make sense?  From a design perspective the difference is
non-existant.  (sendmail's virtusertable comes to mind.  The
virtusertable cleanly handles entire domains or single users without any
trouble.)

> > > 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.
> >
> > If a recipient doesn't have anything specifically configured for them,
> > they get the defaults.  There's little harm done.
>
> Again, that's avoiding the issue of longer-term configuration management.

I disagree.  :)  The long-term maintenance of the thing is my prime
motivation.  Coordinating configuration across dozens of different
machines running nasty software that I don't control and an (mercifully)
not responsible for is far harder than maintaining it in a few central
places.

I don't have a random sig-generator, but here's one of my favs:

--
</chris>

"Bother," said Pooh as he struggled with /etc/sendmail.cf, "It never
does quite what I want. I wish Christopher Robin was here."



More information about the MailScanner mailing list