[SA-exim] User prefs

Derrick 'dman' Hudson dman at dman.ddts.net
Tue, 2 Jul 2002 21:39:02 -0500


---------------------- multipart/signed attachment
On Mon, Jul 01, 2002 at 04:09:52PM -0700, Mikel Tidwell wrote:
| On Mon, 1 Jul 2002, Derrick 'dman' Hudson wrote:
| -> On Mon, Jul 01, 2002 at 03:27:53PM -0700, Mikel Tidwell wrote:

| So, either I can use sa-exim, which doesn't allow me to set up user prefs,

yes

| or I can use the site mentioned (specifically the page
| http://dman.ddts.net/~dman/config_docs/exim4_spamassassin.html), which al=
so
| tells me I can't use user configurations? :(

Oh, yeah, I didn't include user-prefs support in the exact examples
given.  There are 2 ways that (should) work to provide user prefs :

1)  add a '-u' option to spamc (read the docs on how to use it)

2)  run the delivery as root so that in the filter command you can
    'su' to the local user
    (also so that 'exim' is run as a "trusted" user so it can set
    $received_protocol)
=20
| -> However, I do not recommend using both sa-exim and that technique at
| -> the same time.  Sending each message through SA at least 2 times isn't
| -> going to improve anything, especially if you reject some message at
| -> SMTP-time that a user's prefs would have kept.  It's a tradeoff there.
|=20
| Am I missing an option that does let me use user_prefs?

Other than the '-u' on spamc (IIRC) there is also the option of using
a SQL backend.  I know nothing of it other than it exists -- I don't
need it for myself so I haven't read up on it.

| I can completely understand that my exim is mostly jumbled by now ;>
| I worked on it late at night one night, until about 4 or 5 am...

:-).

| I didn't think it was actually being scanned twice, because the
| mainlog of exim only shows one score per email.

The mainlog will show stuff from sa-exim (prefixed with "SA:" or
something like that).

The way the config I published does it you won't see scores in the
mainlog, but you will see a "new" message injected into the queue for
every message that arrives via SMTP.  You can tell which is which by
seeing which router/transport handled the delivery on the outgoing
part of the log and what the received protocol was on the incoming
part of the log.

| Perhaps I don't understand what exactly using sa-exim means.  I
| thought the local_scan patch was it, but looking over my notes, I don't
| think I ever got it working without the patch.

sa-exim _is_ the patch.  (well, with the new version it is a patch and
a .so, but you could compile the function into exim and not use
dlopen() at all)

If you don't use the patch, then you're not using sa-exim but just
exim configured to integrate SA (eg the doc on my site).

| Can I bounce messages if I don't use local_scan?

You can try.  Most spam has an invalid sender address which means the
bounces will just be stuck on your queue.

That's the real advantage to using sa-exim -- you can *reject* (not
bounce) the message at SMTP time.  Rejecting is just like bouncing,
except that the misaddressed bounce is not stuck on _your_ queue.
(and false positives still get back to the sender)

| That's a really nice feature...

Yes.  I love rejecting the junk :-).

| but if it's bouncing vs user white/blacklists, I'll choose the
| latter.  I don't want to keep people's lists for them.

I certainly understand that.

-D

--=20

The remote desktop feature of Windows XP is really nice (and *novel*!).
As a Microsoft consultant can *remotely* disable the personal firewall
and control the system.  We'll ignore the fact that this tampering with
the firewall is not logged, and more importantly, that the firewall
isn't restored when the clowns from Redmond are done with their job.
                                                            -- bugtraq
=20
http://dman.ddts.net/~dman/


---------------------- multipart/signed attachment
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.merlins.org/archives/sa-exim/attachments/a4e6cec7/attachment.bin

---------------------- multipart/signed attachment--