CustomFunction: WhiteListFutureSender

[paddy]

On Mon, Nov 22, 2004 at 05:55:20PM -0500, William Burns wrote:
> Paddy:
>
> This is very cool.
> I've got a similar scheme on one of my mail servers (That's not running
> MailScanner)
> I refer to this as an AutoWhitelist.

Yeah, I didn't know what to call this, but in the milter-sender implementation
the option is called WhiteListFutureSender, so I went with that.

Avoiding confusion with the SA AWL (AutoWhiteList) feature seemed like a
good idea too.

> paddy wrote:
>
> >The idea is to whitelist recipients of outgoing mail from known
> >(client) relays, for return mail.  When such an outgoing mail is
> >detected the value "<sender_ip>,<recipient>" is stored as the key in
> >a tied hash along with a value that can be increased by subsequent
> >hits, and aged by a cron job.
> >
> Have you created something to filter mail based on your database? I
> don't understand how the sender_ip is used.

Ah yes ... that will be because the code I posted is nonsense!

what _should_ go into the hash key (for the simplest implementation)
is the from and to address pair. So, something more like:

        my $l=0;
        my $ip = $message->{clientip};
        my $f = $message->{from};
        for $r (@{$message->{to}}){
                $List{"$f,$r"} += 1 if $wlfs_senders{$ip};
                $l += $List{"$r,$f"};
        }

Mind you, I haven't even tested this on the one machine, this time!

And this also raises the question of what to do with mail that is
whitelisted to one of multiple recipients.

> The mail that you trigger on is the outgoing mail, right?
> In that case the sender IP is going to be the address of one of your
> end-user PCs. Or... The IP address of a mail server if you're running
> this on a mail gateway?

Yes, the idea is to use the IP address of the client relay, to identify
the outgoing mail.  Of course then the implementation only works for
mail coming from that relay, but it saved me thinking about forged
from addresses ...

> In case you're interested...

Absolutely, yes.

> In my system (a kludge) I keep a separate database (a.k.a. text file)

<grins>

> for each of my users. Each database contains a list of addresses to
> which that user sent mail. (There are two databases per user actually,
> the other one contains domains that the user manually chose to whitelist)
> When inbound mail is being delivered to a local mailbox, there's a
> procmail script that checks the user's databases for the sender's
> address. Any mail from a username not listed in the per-user whitelist
> databases gets tagged w/ "[Unknown User]" in the subjectline.

We don't deliver all our mail locally, some goes out by mailertable, so a
procmail implementation is less attractive than a mailscanner one.  Although
I prefer the idea of a text file per-user - best user interface there is.
The tricky bit might be working out who you're delivering to ...

Procmail gets you delivery time, which is nice for solving the 'where is
the database' and the 'whitelisted to one of multiple recipients' problems.

A quick look sugests it may be possible to modify the subject line with
something like:

  my $newsubject = "[Unknown User]".$message->{subject};
  $global::MS->{mta}->ReplaceHeader($message, 'Subject:', $newsubject);

But, again, I haven't tested this, nor do I understand it (yet).

It strikes me that aside from 'store, deliver, bounce, ...' there is a
language of actions hiding in mailscanner along the lines of:

        modfiy header
        insert header

and probably others too.

> >Praise, questions, comments, corrections, flames, whatever, all welcome.
> >
> >
> Praise.

Excellent selection!

> -Bill

Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall

------------------------ MailScanner list ------------------------
To unsubscribe, email jiscmail at jiscmail.ac.uk with the words:
'leave mailscanner' in the body of the email.
Before posting, read the MAQ (http://www.mailscanner.biz/maq/) and
the archives (http://www.jiscmail.ac.uk/lists/mailscanner.html).

Support MailScanner development - buy the book off the website!