Hi Matt!
Thanks for the hints...
I currently use spamass-milter which seems to send the email address
to SA but excludes the domain. For example on a email like
sa...@domain.com it seems to check the DB using sales. This generally
wouldn't be a problem on a small corp server however I have many
virtual sites on the server so there could be many 'sales' users.
Ideally if spamass-milter could pass the entire email address to SA I
could deal with this in my control panel.
I do use the $GLOBAL user for global settings and this part does work fine
Thanks,.
Scott.
On Mon, May 16, 2011 at 5:39 AM, Matt Elson
<mailing_lists.spamassassin_us...@melson.fastmail.net> wrote:
>
>
> On Fri, 13 May 2011 10:59 -0600, "Scott" <sst...@gmail.com> wrote:
>> I am using Sendmail and SQL prefs with SA. The problem I am having is
>> that Sendmail seems to only send the username to SA when filtering so
>> our aliases only use the default settings.
>
> What "glue" are you using to have Sendmail call SpamAssassin? I use
> sendmail w/ mimedefang in my environment, and am passingly familiar with
> MailScanner, so I'm not sure how relevant my experience is, but
> hopefully this helps a little.
>
>> I should mention that we are using system users and aliases. I have
>> tried something like the following in the local.cf but it still only
>> filters the username.
>>
>> user_scores_sql_custom_query SELECT preference, value FROM
>> userpref WHERE username = CONCAT(_USERNAME_,'@',_DOMAIN_) OR username
>> = '$GLOBAL' OR username = CONCAT('%',_DOMAIN_) ORDER BY username ASC
>
> Do you have a username of $GLOBAL in your SQL database with the settings
> you want to apply? For example, over in my envrionment I have the
> following:
>
> | @GLOBAL | score | URIBL_SEM_RED 0 |
> 5014363 |
>
> Of course, I believe this only works if you would be comfortable with
> the alias names using the preferences defined for the GLOBAL user over
> what their individual user preferences may be.
>
>> Any ideas?
>
> The other thing I ran into (and this may be dependent on the glue) is
> that I didn't have access in my "glue" to the expanded aliases, just the
> initial address in the RCPT TO. (It's been a long time since I've
> looked into this, it may not be the case anymore or just a consequence
> of using mimedefang/milter.). That is to say, if I had an alias called
> matthew.el...@example.com going to els...@example.com, I didn't actually
> have direct access to the "actual" address/username - Matthew.Elson is
> what got sent to SpamAssassin (which sounds like it may be happening to
> you, it would seem to explain some of the behavior at least).
>
> There were two thoughts I had at the time (caveat, it was a long time
> ago and my first exposure to Sendmail, so no guarantees).
>
> 1) Do the alias expansion in the "glue". For example, I have a routine
> to have mimedefang lookup the alias file in the aliases.db (or ldap
> server), grab it, and then and send along the "real" username to
> SpamAssassin.
> 2) Throw another sendmail up and do the filtering there *after* the
> first/initial sendmail has done alias expansion. To clarify, it's
> basically something like this:
>
> External Mail ---> Initial Mail Server w/ Aliases ---> <Sendmail w/
> Mimedefang+SA>.
>
> That way, by the time SA gets involved, Matthew.Elson has become
> els...@example.com. Likewise, any aliases that deliver to multiple
> recipients have also been broken up to the individual users and their
> preferences applied.
>
> The second is actually the solution I wound up going with at the time,
> but I don't really recommend it for all environments (my environment had
> a strict requirement that each user have their own preferences and
> bayesian database that would survive all alias expansion) and I heavily
> suspect there are far more elegant solutions.
>
> Matt
>
