-------- Original-Nachricht --------
> Datum: Thu, 23 Aug 2007 09:13:27 +1000
> Von: Daniel Rose <[EMAIL PROTECTED]>
> An: [email protected]
> Betreff: Re: [dspam-users] [RFC] Signature leakage and its consequences
> 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.
>
Yes and no. I just need a reliable way to know that "John Doe" is "John Doe".
If now someone claims to be "John Doe" and I can not verify that, then I don't
trust him to be "John Doe".
> 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.
>
GMX is not mine. But indeed they require SMTP AUTH in order to send mails over
their servers.
> 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.
>
If they don't do that, then what are they doing? How do they prevent other
users to misuse their servers for sending mail? If they don't do some kind of
authentication then they are a open relay.
> 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.
>
I have a directory service as well. It is used for many things. And I use it
directly from Postfix to do SMTP AUTH. But I use it as well for HTTP
authentication, IMAP authentication, POP3 authentication, FTP authentication,
etc...
> Is this what you're saying? Do you get any customers who complain about
> having to auth to send mail?
>
No. No one complains. In the old days I used to have POP before SMTP but today
every client supports SMTP AUTH and it is common to do authentication for
sending mails. We live in a world where allowing every one to send mails over
your server is very dangerous. Without SMTP AUTH I would expose my self to much
bigger problems. Imagine all those spam bots/trojans/etc sending mail from a
clients system. This would be a mess if I would allow them to send
unauthenticated mails over the server. I would be in no time on some blocking
list and this is what I want to prevent. And imagine if I would allow everyone
out there to claim to be "John Doe <[EMAIL PROTECTED]>" and would allow them to
send forged mails. This would be bad. Postfix (after 2.1) makes it very easy
for me to enforce SMTP AUTH.
Using the global aliases for training/retraining is just one way of training
DSPAM. You can still implement the DSPAM web ui and train that way. If you have
a directory you can use to authenticate users from within your HTTP server then
this might be a possible solution. I have users hating to train the anti-spam
filter. So they refuse to do training. I have users where they love the web ui
and hate the global training alias. And I have users where they hate everything
which is not implemented directly in their mail client. So I am forced to allow
many ways for training/retraining DSPAM. I personally prefer the web ui but
this is me. I have users where explaining the web ui would be a crazy task.
They just don't get along with the web ui. It is to hard for them. But two
simple buttons (a big red X with the text SPAM and one green check mark with
the text NOT SPAM) in their inbox is what they understand.
I have users sitting behind IBM Notes or behind MS Outlook. And both products
allow you to integrate buttons with logic in the client. So this is what I used
to implement a easy way of training DSPAM. And since both clients allow you to
define filters either on the client or on the server I don't deliver messages
tagged by DSPAM as spam to their inbox. Those mails get delivered to a junk
folder. In this junk folder they have just one button (the green one). If they
press this button, then I retrain DSPAM, then I change the content of the
message (Yes, yes. I change the subject to not include the spam tag (if it is
there) and I change the header to not have the spam class) and then move that
mail back to the inbox.
In the inbox they only have one button (the red X) and if they press that
button then I retrain DSPAM, change headers, change subject (if needed) and
move the message to the junk folder.
While I still think that the web ui is enough for most people... I have made
the experience that the above two buttons help a lot. On one installation I
only had the web ui and no one was training. Months after the first
implementation still most part of the users never ever trained. A quick
interview of a bunch of users showed that they either are over strained with
the web ui or they don't have time to open a web browser and do the training in
the web ui or they don't know that they can train the filter (but it was
communicated that they can do that and documentation existed on how to do it)
or it showed that they simply don't care. But most of them said that they would
train if they would be able to train from within their mail client. So it was
obvious that implementing something inside their mail clients is the only way
to get them to train their filter. And after doing those two simple buttons and
one filter (for moving/delivering spam mails to the junk folder) the training
increased. Now most of them do train their filter. And the good thing is that
they see that training helps them to get better results.
Off course there are always those which refuse to train. But DSPAM allows you
even to handle that. You could run a classification or merged group as a parent
for each user and then you as the system admin can train this group and
increase the catch rate. And running DSPAM in TOE mode allows you to keep the
quality of the tokens if the user refuses to train. If they don't train then
DSPAM will just stay as bad or good as it was but will not get worse or better.
I have to confess that I am using DSPAM for years. I have learned my lessons
with that product. In the beginning I made so much errors. I needed some time
to get to the point where I am today. My setup is done in such a way that the
used parent group for all the users is automatically (but slowly and not
permanent) trained with ham and spam data. I do as well maintain a automatic
whitelist outside of DSPAM (as soon as one of my users is sending a mail to an
external user I do capture that recipient/recipients and add them for some time
into the automatic white list). I do as well train the parent group with
outbound mails. And and and...
DSPAM allows you to do a lot of things.
> --
> Daniel Rose
> National Library of Australia
// Steve
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
