No User: command implementation?

Hi,

Correct. This wasn't added due to the massive processing cost. As you can only supply a single username, if you were to scan an email which had 100 local recipients for example, you would have to spam-scan the email 100 times (whereas currently you scan it once).

Ideally the protocol would allow you to specific many recipients, and spamassassin would only apply the settings for each user in turn, dramatically reducing the costs -- but unfortunately this isn't the case.

Regards,

Shane.

shane_hjortha at 2007-7-9 5:53:34 >

Hi,

> On this machine, I'd like to set up a sendmail

> service, integrate spamassassin and configure MS 6.2

> on my other machine to send all mails received

> through the tcp_local channel to it for spam

> processing with per-user preferences.

>

> Would you have any comments to make about that?

If you are able to use per-user preferences with sendmail then great :) I personally wonder about the value of such a set-up. There are other complexities, such as how do you identify the 'user'? When an email is sent sendmail will see the mail address. How do you translate this back to a UID or something similar. What about group mailing lists etc. I actually had this exact conversation with the developers of messaging server (per-user spamassassin preferences) and unfortunately we weren't able to come up with any answers that covered enough bases -- without of course modifying the spamd protocol :(

To back-up a bit, when you say you have per-user preferences, what kind of preferences are we talking about?

I set up a spamassassin filtering service for a university I used to work for (15,000 odd staff/50,000 odd students). Apart from allowing the users to customise where the emails were delivered (email folder) and the spam threshold, this was enough. The only per-user settings I could think of added would be perhaps bayesian information. The problem here is training the database per/user.

Anyway something to think about.

Regards,

Shane.

shane_hjortha at 2007-7-9 5:53:34 >

Hi,

> Well, sendmail will take the user portion of the

> e-mail address and look up the LDAP store in DS 5.2

> for objects having UID="user portion of the e-mail

> address" AND posixAccount value in the multi-valued

> objectClass attribute (it also queries LDAP for some

> alias that = "user portion of the e-mail address" but

> I don't remember the specific attribute that sendmail

> filters by in its LDAP query). I read this out of the

> DS 5.2 log whilst looking for sendmail's interaction

> with the LDAP server.

I figured that this would be the case. Where this gets complex is if you start having multiple domains, rewrite rules, email forwarding etc. For a controlled environment implementation such as what you describe it is very-much workable.

> Then once sendmail gets its spamassassin verdict, I

> need it to return the message back to MS 6.2. I

> haven't got that detail worked out yet (neither do I

> know whether I can actually do it without modifying

> sendmail source code).

Probably the easiest way to get this back to messaging server is to add an email header (e.g. X-Spam-Level: *******) and then use a sieve filter in each users entry to filter as appropriate. This is how I implemented our Spam filtering.

> Regarding user preferences, custom whitelists and

> blacklists would be useful. It would also be useful

> to give each user the facility to decide on his own

> threshold score (as you mentioned).

All of these can be controlled/implemented through sieve-filters. We implemented custom whitelists (not blacklists as we didn't want students rejecting 'important' emails). There has been discussion on this forum with regards to implementing blacklists in LDAP that way you can reject-before-accept emails.

Most of the work tends to be on the user-interface level -- writing the tool that tweaks the appropriate Sieve-filter/LDAP/SQL entries for the user.

> Yes, group mail processing would be a problem but I

> get the impression that the developers of Messaging

> Server have tended to discard features that pose

> operational problems rather than implement them and

> leave it to the system engineers to decide upon their

> application.

Unfortunately (and as support cases show all too clear) given messaging server admins a loaded gun such as this is usually a mistake. The current spamassassin plugin has proven to be very popular, and easy to implement.

If more advanced admins want to implement their own improved/custom version they can do so through any number of approaches (of which you are using one). I personally chose to write a custom channel which was able to virus-scan/spam-scan/replace attachments in one sweep just the way my organisation liked.

If I was to do something like this today, I would go down the milter approach (coming soon in messaging server 6.3).

> In this case, I think that libspamass.so

> should have implemented the User command but come

> with it disabled by default. Similarly, when we

> discussed mailfromdnsverify, the extra verifications

> would have been useful but were omitted and during

> that thread it was hinted that the processing load of

> those extra verifications was a factor in the

> decision to omit them.

I didn't necessarily agree with this either, which is why I recommend that you log an RFE to have this facility improved. The mailfromdnsverify code hasn't been modified in a *very* long time -- so unless an actual customer asks for improvements they won't occur. The developers have plenty on their plate already so request from inside tend to have less impact then those from paying customers.

> Resource provisioning is the

> system engineer's problem, not the developers'.

Can I quote you on this :)

Regards,

Shane.

shane_hjortha at 2007-7-9 5:53:34 >