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
...