ietf-mxcomp
[Top] [All Lists]

Re: onus on mailing lists

2004-03-18 15:09:53

On Thu, Mar 18, 2004 at 09:50:09AM -0500, Meng Weng Wong wrote:
| List-Archive: <http://www.imc.org/ietf-mxcomp/mail-archive/>
| List-Unsubscribe: 
<mailto:ietf-mxcomp-request(_at_)imc(_dot_)org?body=unsubscribe>
| List-ID: <ietf-mxcomp.imc.org>

We shouldn't forget about all the unsubscribe mechanisms via HTTP
that tend to be more (l)user friendly.

Another problem is that because these headers are subject to forgery,
the spammer can forge
 List-Unsubscribe: 
<mailto:ietf-mxcomp-request(_at_)imc(_dot_)org?body=unsubscribe>
which fools the MUA; putting that metadata into the SPF record moves
the announcement back into a space that's controlled by the purported
sender domain.  You only want to trust a List-Unsubscribe if the message
itself passes RMX/DMP/LMAP/MXCOMP/MARID tests.

I don't think I can follow you here?
Well behaved MLMs use double-ACK for opt-in as well as opt-out.
However I am aware that with this list I could probably unsubscribe all
of you with a single batch job.

IMHO the proposal should not make workarounds to try to fix security
flaws in MLM software or their configuration.

ezmlm e.g. shows (and I think at least majordomo can also do this) how you
can use safe crypto cookies for confirmation of the subscribe and unsubscribe
process. This can be securely done without any LMAP checking at all:
   new(_at_)example(_dot_)net  requests unsubscribe for  
joe(_at_)example(_dot_)com
   MLM creates unique secret with a token only known to the MLM and
       sends it back to joe(_at_)example(_dot_)com(_dot_) It also has a upper 
limit on
       duration of validity
Now the mailbox joe(_at_)example(_dot_)com has a cookie that will only 
unsubscribe
joe(_at_)example(_dot_)com from one particular ML. You can even forward that 
cookie
to your new account  new(_at_)example(_dot_)net  and still use the cookie 
together
with the address  joe(_at_)example(_dot_)com  to unsubscribe  
joe(_at_)example(_dot_)com  (and
none else).

A LMAP check would IMHO even be counterproductive here.

        \Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"


<Prev in Thread] Current Thread [Next in Thread>