Re: [Exim] bug on m$-exchange that could attack also exim !

Pàgina inicial
Delete this message
Reply to this message
Autor: Andreas Metzler
Data:  
A: exim-users
Assumpte: Re: [Exim] bug on m$-exchange that could attack also exim !
On Tue, Aug 26, 2003 at 12:49:41PM +0200, Leonardo Boselli wrote:
> I have found a way in which somebody could subscribe other people's
> address .
> This is due to an autoanswer script that send back to the alleged poster
> a message with


> ....
> From: ignare.user@???
> Subject: Re: original subject
>
> I am on vacation until 31 august. Your messages will be read after that
> date . Signed
> .....


> Someone could then send a mail to somelist-subscribe@somedomain
> using as a from address ignare.user@???.
> The list manager would semd to confirm request to that address, and
> the autoresponder would send back something that contain the "key"in
> the subject and so the subscription process is completed.
> It works fine with yahoogroups, btw ....

[...]

I had started with this reply...
---------
Use some sane autoreponder that does not reply to list-mails at all
like exim filter "if personal then vacation endif" or classic
vacation(1), by checking for Precedence: headers and the fact that
your address is listed in To/From/Cc.
---------
... when I realized that these confirm messages look like regular mail,
they don't have a Precedence: header and list me in the To: header.

> Is there a way to word autoanswer replies to avoid this "autosubscribe
> feature" ??


I cannot see a straightforward one except for not quoting the original
subject. No wait. You could use rfc-2047 encoding, I don't think the
list-software'll do rfc-2047 decoding, so the magic string will be
masqueraded:

headers charset "UTF-8"
if personal then
     mail
     expand file .vacation.msg
     log  .vacation.log
     once .vacation
     once_repeat 7d
     subject =?UTF-8?B?$funct64{$h_subject}?=
fi


But $funct64 which would encode any string to base64 does not exist as
expansion operator. (Be aware that this is not proper rfc2047
encoding because we don't take care of the 75 characters-limit
per encoded word).
             cu andreas