[EMAIL PROTECTED] wrote:
> -------- Original-Nachricht --------
>> Datum: Wed, 22 Aug 2007 14:06:47 +0200 Von: Elias Oltmanns
>> <[EMAIL PROTECTED]> An: [email protected]
>> Betreff: Re: [dspam-users] [RFC] Signature leakage and its
>> consequences
[...]
>> 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.
>>
> 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.
This is rather an important point. Perhaps it would be good advice to
say it *should* be done without, see below.
> 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'm confused. Whats this dspam-retrain transport for? Is it a new
feature in 3.8.0?
> 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).
>
> Now assume I have an account and you have an account on that server.
> And now assume I got (how ever) a signature belonging to a mail you
> have received (for example !DSPAM:4,46cc4dd8264013699821073!). Now if
> I would send a message to the global training alias and use your
> signature (with our without the UID) then DSPAM will bark and not
> retrain your database because DSPAM is forced to use my user name
> (--user switch) in the training script.
That's not quite true, I'm sorry to say. If there is a uid embedded in
the signature, DSPAM will use that uid totally disregarding the --user
option on your command line. If there is no uid in the signature, you
are right, of course.
>
> This is just one way of doing it.
And its rather an obvious way too, I have to admit (with the
restriction mentioned above). Tahnks for the hint.
> You could do it with user specific alias addresses if you like. For
> example: dspam-ham-<[EMAIL PROTECTED]>, dspam-spam-<[EMAIL PROTECTED]> and
> dspam-retrain-<[EMAIL PROTECTED]>.
>
> Then the user would just need to send a miss classified mail to
> [EMAIL PROTECTED] or [EMAIL PROTECTED] or
> [EMAIL PROTECTED]
>
> Then you do the same stuff as above with the restriction class and
> then you process everything with a Postfix recipient access map using
> regex or pcre. For example (with PCRE):
> /^(dspam\-(ham|spam|retrain))\-(.*)$/ FILTER ${1}
>
> This is as well just one way of doing it. I could name at least two
> other methods of doing it.
Right, so here is another challange: Everything you described so far
actually entrusted the MTA with the decision which user's dataset
should be queried for the presented signature and, if found, retrained
accordingly. Earlier I have pointed out that it is actually dangerous to
embed the uid in the signature in the first place, because DSPAM will
switch to that uid on retraining whatever might be specified as the
--user option on the command line. So, unless someone can come up with
another example configuration, the following excerpt from the DSPAM
README should be considered misleading, to say the least, as far as
signatures with embedded uids are concerned:
--8<---------------cut here---------------start------------->8---
Note About Security:
You might be wondering if a user can forward a spam to another user's
address, or whether a spammer can forward a spam to another user's
notspam address. The answer is "no". The key to all mail-based retraining
is the signature embedded in each email. The signature is stored with
each user's own user id, and so not only does the incoming message have
to bear a valid signature, but it also has to be stored on the system with
the correct user id. This prevents any kind of alias abuse.
--8<---------------cut here---------------end--------------->8---
Am I wrong in thinking that setting
UIDInSignature on
is dangerous in spam filter contexts? It may be useful for other
classification purposes but I don't see how I can safely use it for spam
filtering.
[...]
>> Personally, I definitely prefer the global alias approach over any
>> other solution which is, obviously, why I'm so interested in solving
>> this issue.
>>
> You mean one global alias for each action for all users (aka:
> [EMAIL PROTECTED])?
Yes.
> Or you mean an alias for each action for each user (aka:
> [EMAIL PROTECTED])?
No.
[...]
>> Those, who generally download their emails -- for various good
>> reasons like being only intermittently connected to the web,
>> possibly on a low bandwidth link -- may find it more convenient to
>> forward (at least false negatives) to an alias.
>>
> It would be stupid to only focus on FN's and let FP's out of the game.
>
That's not what I meant to imply. Personally, I only download my *real*
emails meaning those that have been classified as innocent. The rest is
sent to a junk folder by a filtering rule. So, I need an alias for
retraining false negatives, because those emails aren't on the server
anymore by the time I check them. Since I have to check my junk folder
on the server anyway, I wouldn't strictly need an alias for false
positives but could use a web interface or a reclassification folder
instead.
Regards,
Elias
