Elias Oltmanns wrote:
Hi all,

it seems to me that the signature based approach towards retraining, as it is implemented in DSPAM, might be vulnerable to a certain kind of attack described below and I'd like to discuss with you whether this actually poses a problem in reality and whether any thing should or, indeed, can be done about it.

Consider this situation: An ISP is running DSPAM on its mail system. Customer C has received an email on his DSPAM protected account and, for some sensible reason, feels like forwarding that email to recipient R. Assuming that R is actually a mailing list possibly archived on the web, many people have access to that forwarded email which, unless somebody has deliberately taken precautionary steps against it, will still contain the DSPAM signature. Depending on the nature of the mailing list C might even feel inclined to forward several emails to R so a sufficiently eager person of bad humor or intentions might collect a certain amount of signature data and use it to mess up C's DSPAM database. The situation might get even worse if the ISP has actually set up group training and several of its customers are unwittingly spreading their signatures in public places. Especially when the uid is stored in those signatures and the ISP has set up global addresses for retraining, perhaps even systems like spamcop could be abused by someone to gather signature data and launch an attack against that ISP.
[snip]

one should not allow retraining from "unsecure" sources. Either require authentication or make sure the IP matches the user.

in postfix, this goes as

# assumptions:
# smtpd_delay_reject=yes. (This is the default)
# sasl enabled and working
# [optional, recommended] smtpd_sender_login_maps correctly defined.

smtpd_restriction_classes = ... enforce_auth

smtpd_sender_restrictions =
        check_recipient_access hash:/etc/cpostfix/retrain_rcpt

enforce_auth =
        reject_sender_login_mismatch
        permit_sasl_authenticated
        reject

        
retrain_rcpt:

[EMAIL PROTECTED]       enforce_auth
[EMAIL PROTECTED]       enforce_auth
...


Reply via email to