Excluding Certain Recipients

Nick Phillips nwp at LEMON-COMPUTING.COM
Mon Jan 7 18:56:11 GMT 2002


On Mon, Jan 07, 2002 at 12:46:30PM -0500, Christopher Hicks wrote:
> This has devolved almost beyond the point of being useful.  I'm probably
> going to write something to do what I want within the next few months and
> put the patch out there if somebody else doesn't beat me to it.  If
> anybody is interesting in participating in building something like this,
> plesae let me know directly.

I'm feel like there must be a better way; if discussing/arguing about it
helps find that way, so much the better...

> > Users don't write perl.
>
> The point was to show the concept.  Making a user-readable config file
> could be even simpler.

OK, so a dead simple config file. Like one with a list of addresses for
which spam should be bounced, or one with a list of addresses for which
mail should not be scanned, or whatever.

It's going to be a lot of work either to keep that/them up-to-date, or to
automate the process.

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?


> > 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.
>
> That isn't even a cheat answer, it's a non-answer.

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

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.

> Ah, but the complexity isn't kept in one place, it's kept in many.  Many
> of us run a variety of MTA's.  I run sendmail for user-level stuff and
> backup MX's, and qmail for ezmlm.  All three contexts make mailscanner
> relevant and all of them may need to be customized based on the recipient.
> Maintaining what is essentially the customization of mailscanner within
> mailscanner makes much more sense than making a gazillion different MTA's
> do it.

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.

> Because the issue exists beyond that.  Everything mailscanner does can't
> be simplified to a header-based filter.  You're trying to use a saw when
> you need a hammer.

Again, depends what we're talking about.

> > Better: less bloat.
>
> Precisely what I'm looking for.

Glad we agree wholeheartedly on something ;)

> > >  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.

>  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.

a) Clearly you do have the choice; feel free :)

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?? ;) ]


> > 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.


> > Easier: yes you could still use the same sendmail config.
>
> You haven't shown how to do the issues in question in sendmail and it is
> quite easy to conceive of situations where it can't be done by the MTA at
> all.

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.


> 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.


> > 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.


> > 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.


> sendmail doesn't scare me.  I do understand it.  I like it even.  I've
> played with the sendmail.cf calculator and all.  But sendmail is poor at a
> variety of things and ghastly at others.  sendmail makes a very poor tool
> with which to configure mailscanner, for instance.

And I wouldn't want to use it for that purpose. I think we must have had
a little misunderstanding somewhere.


> > Complexity == bad.
>
> Precisely.  Trying to configure mailscanner via the MTA is complex and
> will only get more complex as people try to do more interesting things.

See above.


> > 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.

Anyway, Jules is the one who makes the decisions, and one of the reasons
I like working with him is that he's far more ruthless than me about rejecting
feature requests/bloat/whatever... still I must admit I can imagine a
reasonably elegant implementation of per-domain configuration.

Cheers,


Nick

P.S. Oh look, another perfectly relevant yet random .sig...
--
Nick Phillips -- nwp at lemon-computing.com
It may or may not be worthwhile, but it still has to be done.



More information about the MailScanner mailing list