Spamassassin & Email Aliases

V

Vibe

Verified User
Joined
Aug 3, 2005
Messages
120
Hi everyone,

Just a basic question regarding Spamassassin with user accounts vs. alias email addresses.

While logged in as root (ssh) under /home/username/ I see that each domain configured with spamassassin has a user_spam directory that holds each email accounts' spam file (e.g. "spam box"). I also notice that alias accounts are treated the same in that there is also a spam file for each alias.

If 3 users share an alias will spam assassin filter all spam to the alias spam file alone, or will the spam be filtered into each users email file as well (mbox format here)?

*OR* does the filtering stop at the alias file alone?

The problem that I can see occurring is that if users share a common alias, any spam filtered into the alias file alone may give rise to non-spam emails not being delivered, which will not be available to the user (can't login with an alias :-).

Does anyone encounter issues with this?

Thanks for sharing any information!

Michael
 
Just wanted to post an update. From what I have read, Spamassassin is supposed to overlook email aliases on the server, and only act upon actual email accounts. However, on my system Spamassassin is creating spam files for email accounts AND aliases in /home/username/.spamassassin/user_spam/.

Does anyone know what interaction takes place with DirectAdmin/alias configuration and Spamassassin?

This is a problem in that there is no way to check whatever is tagged as spam at the alias level. Email/spam sent to aliases is not making it to user email accounts.

Any help would be greatly appreciated - thanks in advance!

Michael
 
I have the very same problem. I have a domain example.com, and a domainalias (or pointer) domain2.com. Now /home/admin/.spamassassin/user_spam is getting filled with files like [email protected], while these spammessages SHOULD be sent to [email protected].

Not only can I not check if there are any false positives, but there is the bigger problem of these spamfolders getting bigger and bigger, and there is no easy way of cleaning it up from time to time (yes it can be done from within DA, but I prefer to do it from my mailclient of course).
 
Hi Dualdot -

As an update John (DA) suggested the following:

*******************
edit your /etc/exim.conf, and add 1 extra condition line:

spamcheck_director:
driver = accept
condition = "${if and { \
{!def:h_X-Spam-Flag:} \
{!eq {$received_protocol}{spam-scanned}} \
{!eq {$received_protocol}{local}} \
{exists{/home/${lookup{$domain}lsearch{/etc/virtual/domainowners}{$value}}/.spamassassin/user_prefs}} \
{if eq {}{${if exists{/etc/virtual/${domain}/passwd}{${lookup{$local_part}lsearch{/etc/virtual/${domain}/passwd}}}}}{0}{1}}\
} {1}{0}}"
retry_use_local_part
transport = spamcheck
no_verify

This will only run Spamassassin for the pop users, thus won't add spamboxes for non accounts.

*******************

I tried adding the above (bold line - no carriage return after "if eq{}{${if") to exim.conf - however, all email regardless of recipient (alias/forwarder or actual account) was no longer being scanned by spamassassin.

This can be a big issue in that email directed to an alias/forworder will not be scanned *AND* will not be available for clients/users to review for false positives (can't login to an alias :( ).
 
Uhm okay so you're saying that adding that line to exim.conf only makes it worse? :)
 
Exactly...on our system it doesn't work. I am not certain if it is a syntax issue or ??? I just posted the info to see if anyone else has an idea. Hopefully someone can shed some light on this.

Ahhh...Dualdot...I misread your original post - my mistake.

The issue I am having revolves around email aliases and not domain. For example [email protected] being an email alias that is directed to [email protected] and [email protected].

On our system, Spamassassin treats [email protected] as an actual email account by creating a spambox in /home/user/.spamassassin/user_spam. This won't work as there is no way to check the spam box for an alias other than through SSH. Fun stuff for sure :).
 
Last edited:
You may have copied something incorrectly; Since John gave you the line I'm sure he won't mind if you ask him to double-check it for you :) .

Jeff
 
Vibe: the aliasses may be different, but the problem is the same :) I also get a spambox for an emailaddress that doesn't exist (an alias). Have you asked John yet?
 
Hi Jeff,

I was thinking I copied something incorrectly too :). I tried playing with the code a bit without success. What is strange is that I have literally spent hours looking for some type of documentation regarding SpamAssassin and the issue of alias email addresses and have not found anything on newsgroups, google, the SpamAssassin blog or the installation/maintenance documentation - very weird!

Because of this I am assuming that EVERYONE has the same issue but doesn't realize it.

Dualdot - I did send John a second email yesterday to let him know that the code he sent doesn't appear to be working. Hopefully he will be able to get back to me with some ideas. I don't want to be a "pain in the rear" as I am sure he is very busy. I will definitely post more information as I learn/hear more.

Thank you both for your input!

Michael
 
Yeah but we ARE paying customers with a problem :)

I'm looking forward for new info.
 
Anyone find the solution?

how to make alises work?

and how to make email not exist won't be scaned..?

I mean if I use the :blackhole: for domain, all the email account doesn't exist will be scaned by spamassassin, and create many spam file.
 
Hello,

I think I've found a cleaner version of it.. that actually works ;)
Code: 
spamcheck_director:
  driver = accept
  condition = "${if and { \
                        {!def:h_X-Spam-Flag:} \
                        {!eq {$received_protocol}{spam-scanned}} \
                        {!eq {$received_protocol}{local}} \
                        {exists{/home/${lookup{$domain}lsearch{/etc/virtual/domainowners}{$value}}/.spamassassin/user_prefs}} \
                        {exists{/etc/virtual/${domain}/passwd}} \
                        {!eq {}{${lookup{$local_part}lsearch{/etc/virtual/${domain}/passwd}}}} \
                } {1}{0}}"
  retry_use_local_part
  transport = spamcheck
  no_verify
But in testing I quickly noticed that this meant the system account doesn't get checked, only the pop account will be scanned. An even messier "or" would need to be inserted in that last "eq" statment. pseudo code:

or {eq user is system from /etc/virtual/domainowners}{!eq {}lookup user from passwd}

So if you only want to scan you pop accounts, the above code is perfect. It doesn't scan the system user account.. more needs to be added, but... it would be very ugly to try and do.

John
 
JOHN! You are THE MAN!!!

This works PERFECTLY. I just tested on our server and can verify email accounts are being scanned properly AND alias email addresses are being scanned. Better yet, any email alias/forwarder addressed to a "local" user is scanned and if tagged, placed in their email account's spam box. Also, alias addresses that forward to remote accounts are NOT scanned - so no load on the server!

Beautiful!

Thank you for all of your help!

Michael
 
John, should I put this into the exim.conf masters I maintain?

Thanks.

Jeff
 
well.. it's not "complete"... it's very good at what it does. But what it doesn't do:
- does not scan the catch-all
- does not scan the main system pop account.
- does not scan forwarders/aliases

So it will be great for your pop users, and you won't get any mystery inboxes being created, but your catch-all and system account will receive unfiltered spam. So It's still not the best solution, but works great for pop accounts. I'd probably hold off for the time being (unless you dont think the above are that big of a deal)

I guess another spamcheck_director could be added as "spamcheck_director_2".. to handle the extra cases (system username and aliases), so that we don't end up with too much of a mess in the above.. might solve those issues.

The catch-all would be the only one that can't really be done, because it's not the exim.conf, it's the filter. The filter itself doesn't know that it's a non-existant mailbox, hence the original problem. And the filter syntax isn't flexible enough to figure it out.

John
 
Thanks for your points. Well taken.

I'll wait for you to add the spamcheck_director_2.

Except everyone on the exim lists tells me it's not a director. It's really a router-transport set. Or so they're telling me.

I understand the catchall problem, and can probably fix it even in the filter, though I don't have time to study it right now.

I'm also being told that we're doing this inefficiently; that we should do it at SMTP DATA time.

I'm looking for a way to do it then, and add headers; so then we could do everything later with filters or more complex router-transport sets.

Unfortunately it takes a while to get a handle on it and everyone wants it now :) .

Jeff
 
Hmmm...this is very interesting. On our system we have been performing tests using the changes John shared.

For our configuration Spamassassin *is* scanning aliases/forwarders, and if tagged as spam, depositing the email to the corresponding user - hence my extreme enthusiasm.

I will perform some additional tests to see if the system accounts are being scanned and let everyone know. Thanks again John!

Michael
 
Hello,

Is the forwarder forwarding to a regular pop account?
If so, it's the pop account that's being scanned after the email is forwarded (forwarders themselves don't have inboxes). Or else, there is some magic/fluke in our favor, which is totally fine by me ;)

John
 
It still have problem with setting domain_pointer, it will create two spam file in user_spam folder..
 
Hi John,

You exactly right. The forwarder/alias is directed to a *local* pop email account. I believe, like you mentioned, the email is then being scanned when it arrives to the user account. This is *exactly* what I was looking for. Before, a spam box was being created in the name of the forwarder address which prevented us from viewing possible "false positives" through SquirrelMail.

Now any email directed to a local user (be it their local pop address or through a forwarder to a local pop account) is being scanned and all spam is being placed in their "user_spam" directory for each domain.

The "side-effect" that also takes place is that forwarders to external email addresses are *not* being scanned - which is what I wanted also.

I will post again to see if the admin accounts are being scanned properly when I have the opportunity.

Thanks again!
 
Last edited:
You must log in or register to reply here.
Back
Top