No User: command implementation?

Question

Hello folks,
I'd just like a confirmation here as I haven't seen it black on white in other posts in the forum but have seen enough signs to expect the worst here :(
I gather that libspamass.so does NOT supply the User: command in its implementation of the spamd protocol. Correct? So this means no per-user preferences are possible (SQL, LDAP etc etc).
Cheers

Answer 1

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.