ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Alternative MAiling List Approach

2010-07-29 13:36:21
The REAL cause of the problem is that From: line. My proposal is that MLM  
should change the From: header in such a way that the mail appears to have  
come from MLM.example and not from discardable.example.

Hmmn.  I don't see how this does what ADSP users want.  There's the
obvious issue that this screws up lists that work perfectly well for
the 99% of people who don't use ADSP for the benefit of the 1% that do
use ADSP, but I'm assuming you don't see that as a problem.

The issue, as I understand it, is that very important people use ADSP
and send mail through mailing lists.  Even if list recipients have
full confidence in what the list sends, e.g., because it puts its own
signature on outgoing list mail, it's still essential to provide the
extra assurance that mail from the ADSP user is really from him.
Simply changing the From: header doesn't do that, since there's no way
to be sure that the list software did adequate verification of the
sender's identity.

One obvious solution is to forget ADSP and use S/MIME.  Header changes
don't affect it, and text footers added after the last MIME section
delimiter won't matter either.  Every current MUA supports S/MIME, so
users can easily verify that your mail is signed and really from you.

If S/MIME is too heavyweight, another simple approach is to put the
message body on a web page, and put an https: URL in the message body,
in a web server whose domain matches the From: address.  If the
message is From: bob(_at_)important(_dot_)example, and the URL is something like
https://important.example/bob/msg-1234.txt, recipients can be
confident that they're reading an untampered message.

I'll be happy to write this up for addition to the mailing list draft.
Or not.

R's,
John
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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