CustomFunction: WhiteListFutureSender

[paddy]

On Thu, Nov 25, 2004 at 12:00:27PM -0500, William Burns wrote:
> paddy wrote:
>
> >On Tue, Nov 23, 2004 at 11:46:00AM -0500, William Burns wrote:
> >
> >
> >>Mail sent from "long.name at address.com" AND "lname at address.com" is
> >>associated w/ a mailbox named "lname". I had to do a bunch of manual
> >>configs to get the outbound recip. address written to the right
> >>local-user database/file. That way, procmail could check one file for
> >>the "lname" user at delivery time.
> >>
> >>
> >
> >I'm impressed.  I have a growing list of uses for a piece of code that
> >does a reasonable job of mapping email address to user and vice versa,
> >and I suspect I would find something very useable in webmin already,
> >but I've not got around to it yet.  For this CF I've just tried to
> >do the simplest thing possible.
> >
> >
> You mean mapping aliases to a single user, or a user to all his
> correspondants?

mapping aliases to a single user, and vice versa.

I have no interest in mapping correspondant to correspondant except the
present case in hand (which is a 'real-time' requirement).

> As for finding aliases, that mainly means combing the config files,
> databases, maps, etc, that an MTA uses for routing and delivering local
> mail.

Yeah, exactly.  I'm about to dig through that part of webmin on a related
mission.  Judging from the webmin philosophy, and what I've already seen
in the interface, I'm hoping to find the code I'm after, already made.

> From the point of view of a gateway w/ no access to these files, I'm
> not sure how the alias problem could be "100%" solved, or that this
> problem even needs to be solved.

Different problem, and not one I'm looking to solve immediately.
I would look towards LDAP.

> >For this kind of whitelisting it strikes me that the desired effect
> >need not stop at correspondent to correspondent.  Some organisations
> >might wish to have returns whitelisted to the whole of their domain,
> >and it might be possible to have domain to domain whitelisting,
> >if one could avoid whitelisting domains like hotmail.com ...
> >This is why I was thinking about hooking the whitelisting effect in
> >through spamassassin scores - so that these effects could be implemented
> >as functions, and the weightings for parameters found by trial and error.
> >
> >Whether I'll ever get that far is another matter :)
>
> You're looking to get spamassasin doing domain-to-domain whitelisting
> based on historic spam scores?
> Interesting... I did that w/ more manual configs. (key vendors,
> customers, etc.)

I didn't want to mention it my original posting as I didn't want the
smell of vapourware detracting from the fragrance of fresh cut code :)

I am quite enthusiastic about the idea, but if I reflect soberly for a
moment I must say that I don't know if it would improve much on a well-run
bayes system.  All it does really is change the weight given to specific
factors in the light of knowledge which (as far as I can think) the bayes
system wouldn't usually give special weight to.

> W/ domains like yahoo, I've had the problem of legit. mailing lists,
> where the "from" address is not consistent.

This is where the idea starts from - there is no reliable way to detect
all replies (other than whitelisting everything!)

> To deal w/ this, I gave users the ability to whitelist e-mail address
> "suffixes". That way, in the most common case where a number is
> pre-pended to an otherwise consistent address, the user can still get
> this mail whitelisted.

Yeah the mailscanner config language is pretty powerful, incorporating
regexes which will easily cover this requirement. But I don't immediately
imagine automating this solution for WLFS by a list of exceptions, so
much as by incorporating some fuzziness in the address matching.

> On the other hand, users find having to manually use a seperate
> "suffix"  feature to be tedious. Usage has been low.

Yeah, I've come to the conclusion that the user-interface is a critical
component of any mail filtering system.

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!