Elias wrote:
Could you explain more explicitly how you'd suggest to go about it? I'm
particularly interested in this case where Daniel has set up global
aliases for retraining. As far as I can see, only DSPAM can tell who the
retraining request came from by looking up the uid part of the signature
in its database. In order to make sure that the request *really*
originated from the same user DSPAM thinks it did, postfix, or any other
MTA for that matter, would have to perform some sort of authentication
(like SASL) and check afterwards whether the authenticated user is
permitted to retrain the data of the user specified in the uid part of
the signature. This would require postfix to parse the message with a
similar algorithm as DSPAM does and it would also have to have access to
DSPAMs uid mapping table, the latter being not a big deal, admittedly.
steeeeeveee responded:
There are many ways to implement a global training alias. No one forces you to
use UID's in the signature. It can be done without. Anyway... I will try to
explain two approaches:
I have created 3 transports in Postfix. One for training as spam (lets call it dspam-spam) and one for training as ham
(lets call it dspam-ham) and one for retraining (lets call it dspam-retrain). I have set up a restriction class in
Postfix to only allow SASL authenticated users to use the global training alias. Not authenticated users are denied
access. After that I call the transport either with "FILTER dspam-ham" or with "FILTER dspam-spam"
or "FILTER dspam-retrain". The transports are then normal pipe transports calling the DSPAM binary and using
the option "--user ${sender}" and other switches (depending on which one is called).
I think here we diverge. In my setup this is a pilot; potentially a replacement
for "crap filter" in the diagram shown earlier, if it works out well.
The clients use outlook/exchange. My solution then in my situation would be to
add postfix rules to the dspam host so only the exchange host can send mail to
spam@ and [EMAIL PROTECTED] In this case, the message sent earlier which
retrained would instead be quietly swallowed, or bounced, whatever.
In fact that's a pretty straightforward fix. Sorry this has dragged on! I
think we've been a bit bogged down in version and regexes and so on.
Do we all agree then that:
If outgoing mail from users is authed, pass that auth to dspam, by blocking
mail from other hosts or other means.
If outgoing mail from users is NOT authed, you cannot stop people from
retraining each other's data unless you add some auth.
Now, as for unauthed users, ste*ve* said:
I am an ISP.
I don't trust anyone not authenticated.
This implies that customers of gmx must setup authentication in their mail
client in order to send mail. This is not especially difficult really, and it
may be best practice and so on and so forth, but most ISPs don't do this.
Universities often have cool unix setups, and corporations usually have
exchange or some other directory service for auth, but ISPs generally use
vanilla smtp, as far as I can tell.
Is this what you're saying? Do you get any customers who complain about having
to auth to send mail?
--
Daniel Rose
National Library of Australia
