Tom, (and Hamish),
(thanks for your private mail, sounde very useful,
I'll reply to it separately)
| I use HEADER and not Envelope. There is always one FROM address
| in either case and that is what you are really looking for when
| you are whitelisting/blacklisting.
Just a quick side remark here.
Using From header field is probably ok, especially for your application
(described in private mail). It is what SA does, and SA's (manual)
white/blacklisting is available via amavisd-new as well.
(btw, did you know that RFC2822 explicitly states that it is valid
to have more than one address in the From field!
E.g. a secretary (Sender) mailing a scientific paper
of two authors (From) to the publisher)
amavisd-new adds its own (manual) white/blackisting, which is
based on envelope sender address. I consider this more useful
and predictable, especially for whitelisting mailing lists,
where you often want to whitelist the mailing list manager address,
not all hundreds of correspondents, or rely on some parsing guesswork
to obtain list name. All three variants (hash, ACL, regexp) lookups
are available.
It would be best to delegate this functionality to SA as well, but,
as already noted, it has no way of receiving envelope information
from the calling application.
(end of sidestep)
| How might one enable this? Even one AWL would be very useful.
| Unfortunately under the current build that I have, AWL is, for
| some reason, disabled or not functioning properly.
| If Hamish has a patch that is "sane" for including AWL then
| couldn't it be considered for inclusion into the main branch?
| From: Hamish Marson
| I have it enabled on mine. I can send you a diff if you like. It takes
| about 10 lines (Including adding config option to amavisd.conf).
As suggested by Hamish Marson, you need to create an address factory:
+ my $addrlistfactory;
+ require Mail::SpamAssassin::DBBasedAddrList;
+ $addrlistfactory = Mail::SpamAssassin::DBBasedAddrList->new();
+ $spamassasin_obj->set_persistent_address_list_factory($addrlistfactory);
+ }
$spamassasin_obj->compile_now; # ensure all modules etc. are preloaded
and add option:
userprefs_filename => "/etc/mail/spamassassin/local.cf"
to the Mail::SpamAssassin::NoMailAudit->new call.
| From: Hamish Marson
| I know
| Mark doesn't like it (And probably for good reasons that I havent even
| considered), but I've used it on Marks amavisd-new version for a while
| now & I have to say it's been quite useful. If only because I can easily
| & quickly add people to the blacklist or whitelist by putting them in
| the AWL list...
|
| For me it get's it right more than it doesn't... I don't recall it
| getting anything wrong when using AWL...
...
| That's exactly how I run it (With the 20021130 version of amavisd-new).
| With a single global list for the whole site (~27000 users). And it's on
| the gateway that just does relaying... No local delivery at all. I'm
| curious... And haven't thought greatly about it as you seem to have
| done. Why is a single global list bad in your opinion? Rather than a
| single one? When running our mail systems, I'm quite happy with a global
| list...
I have no real objection, and I'll look into adding these few lines
of code into amavisd-new December release, for those wanting to use it.
My reasoning (possibly wrong) was that the strength of AWL comes
brom building a set of correspondents _for_each_recipient_
(a mesh for the entire site), and it is unlikely that different
local users would have many common correspondents. The stress
here is on autoWHITElisting, not blacklisting. My impression was
that building a set of correspondents for an entire site is hardly
of any use. Seems like you have different experience, and if it can
indeed be useful, I don't mind making it available.
From: Tom Allison <[EMAIL PROTECTED]>
| spamc/spamd does it under a single AWL and I've not heard much to
| retract it.
I don't think this is correct. spamc tries hard to pass
username (related to envelope recipient address) to spamd:
-u username
This argument has been semi-obsoleted. To have spamd use per-user-
config files, run spamc as the user whose config files spamd should
load. If you're running spamc as some other user, though, (eg. root,
mail, nobody, cyrus, etc.) then you can still use this flag.
and spamd can change UID accordingly. There is aslo the whole SQL machinery
in SA to handle AWL for virtual users that have no home directory
(and no AWL file) on the host running SA.
From: [EMAIL PROTECTED] (Justin Mason)
| > Although Bayesian works best when it is trained for a particular
| > user, it is still _very_ useful with a single site-wide database.
| > Given a larger set of ham/spam messages to train, the lack
| > of specialization can be compensated to some degree.
| >
| > AWL on the other hand (as I understand it) is only useful
| > as a per-recipient information. (but I may be wrong here)
|
| yep, pretty correct. Well, the AWL should work OK for all recipients
| too, though. But bayes will work better.
That was my feeling as well, but I only have experience
with bayesian (first my own brew, now the SA variant).
Mark
-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
