search

mpaperno / spampd

SpamPD - Spam Proxy Daemon. A spam-filtering SMTP/LMTP proxy server using SpamAssassin in Perl. Since 2002.
GNU General Public License v3.0
34 stars 10 forks source link

Proof of concept of per-user settings #27

Closed Moosemorals closed 3 years ago

Moosemorals commented 4 years ago

A rough proof of concept of per-user settings for spampd.

It pulls the user name from the recipient and uses that to call SA->read_scoreonly_config and SA->signal_user_changed before parsing and checking the message.

It works for me(tm), probably because I'm using spampd in LMTP mode between postfix and dovecot (so the recipient address has been aliased) and I've set destination_recipient_limit = 1 in postfix/main.cf to guarentee that there's only one recipient address.

mpaperno commented 3 years ago

Hi @Moosemorals , thanks for the patch, and sorry for the delay.

The patch is OK, but the main issue, as has come up in the past, is that this ONLY works with destination_recipient_limit = 1 in Postfix. Or some other way to limit each spam check to 1 recipient. There's no way for spampd to verify this. I think it can lead to major confusion, among other things,

For per-user settings it may make more sense to use final-delivery side checks (between incoming SMTP and the final mailbox, eg. Dovecot/etc). The LMTP protocol is useful for that too. If you haven't yet, you may want to check out how "Mail in a box" sets things up.

Having said all that, I'm not totally opposed to having such a feature in SpamPD itself, as long as it's very clearly documented and maybe even with a logged warning or something like that (basically so it's very clear that per-user configs are enabled). And/or having further discussions on which implementation would be best. It would also be nice for the Internet-facing server to reject spammy mail entirely, but that may be a separate issue.

OTOH I'm not currently using any of this in production, so my interest is mainly "academic" and I have limited testing scenarios. I'd need to work with someone with a practical application and a way to test more broadly.

I'd prefer to see patches against the newer v2.6 which is currently in next branch. You may also find that version easier to work with, or to use for making your own filter since the code is more modular.

Thanks again, -Max