Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
--On 4 August 2010 15:22:32 +0100 Graham Murray wrote: > Ian Eiloart writes: > >> So, in an ideal world, mail clients would expose the List-* headers >> (especially the unsubscribe* header) in ways that are useful to the >> user, and obviate the need for MLMs to mess with subject lines and >> bodies. >> >> *In my view, MLMs are required in UK law to add unsubscribe information >> in a way that users can easily find it. The List-unsubscribe header >> isn't adequate, only because very few clients display it. > > There is not always even the need to expose these to the user. Some mail > clients (such as gnus), when they detect List-* headers add an > unsubscribe menu (and because it is emacs, keyboard) action. Yes, that's what I meant by 'expose in ways that are useful to the user', though I should have been more explicit. > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
Charles Lindsey wrote: > > But this assumes that the author is in a position to apply those > remedies. If he is a lowly employee of some large security-conscious > organization (say Paypal) there is probably a company rule that > everything goes out under the company domain name, and employees are > forbidden from sending emails with From: set to anything else (at least > when sent from company equipment in company time). > > But it may still be in the company's interest for ite employees to > subscribe to mailing lists (e.g. list discussing security - such as this > one). > > Yes, the company has shot itself in the foot, but in the Real World (TM) > that is a Regular Situation, and it is probably more useful to devise > schemes that work in spite of foot shooting than to waste effort trying > to stop the foot shooting in the first place. > Charles, I think we need to put more faith in the domains wanting and declaring ADSP policies. Why would an individual, company, corporation, especially major one with a high value branded domain implement two technologies (SPF and ADSP) for the main purpose to publicly expose and declare to the world a highly exclusive and restrictive mail operations policies and yet then still think or expect there would be permissible corporate "loopholes" for external usage of their domain which would be end up 100% conflictive with their stated policies? If Paypal or anyone explicitly declares restrictive policies with no subjective considerations (its not soft, its not neutral, its not sometimes signed, but always sign with hard policies), then I don't think it is expected by them the ADSP aware receivers are going to ignore faulty paypal.com messages and just pass it on. paypal.com stated very strongly: SPF: -ALL policy, only their machines can send mail ADSP: DKIM=DISCARDABLE only paypal signs as 1st party They specifically declared: If the sending machines are not ours, don't trust it and reject it. If the message is invalid (no signature or not signed by paypal), get rid of it. You can get any more explicit than this publicly exposed policy. I'm sure paypal.com knew what it was doing when they internally discussed and consciously decided to create those very exclusive and restrictive policies. IMO, it also creates a DISCLAIMER for themselves. Whats the point in 2nd guessing an restrictive SPF and/or ADSP domain? The are not neutral in this declaration. They are very specific. They don't want you to resign it. That is why, IMO, it is far easier for a MLS to preempt all restrictive ADSP domains. This solves all MLS conflicts related to ADSP domains. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
Ian Eiloart writes: > So, in an ideal world, mail clients would expose the List-* headers > (especially the unsubscribe* header) in ways that are useful to the user, > and obviate the need for MLMs to mess with subject lines and bodies. > > *In my view, MLMs are required in UK law to add unsubscribe information in > a way that users can easily find it. The List-unsubscribe header isn't > adequate, only because very few clients display it. There is not always even the need to expose these to the user. Some mail clients (such as gnus), when they detect List-* headers add an unsubscribe menu (and because it is emacs, keyboard) action. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
--On 3 August 2010 19:34:55 +0200 "Rolf E. Sonneveld" wrote: > > > Changes that merely add new header fields, such as those specified by > [LIST-ID], [LIST-URLS] and [MAIL] are generally the most friendly to > a DKIM-participating email infrastructure in that their addition by > an MLM will not affect any existing DKIM signatures unless So, in an ideal world, mail clients would expose the List-* headers (especially the unsubscribe* header) in ways that are useful to the user, and obviate the need for MLMs to mess with subject lines and bodies. *In my view, MLMs are required in UK law to add unsubscribe information in a way that users can easily find it. The List-unsubscribe header isn't adequate, only because very few clients display it. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
--On 3 August 2010 15:30:17 +0200 "Rolf E. Sonneveld" wrote: > > Trusting the MLM may be possible for you personnly for this particular > mailing list, but your choice is not scaleable to the Internet at large. > Or is the general consensus that (in the long run) the reputation of the > MLM domain is sufficient for the verifier/receiver of MLM distributed > mail? I don't read that in the draft. > > /rolf It's the MLM that sent the message. Therefore any judgement of trustworthiness must be made with regard to the MLM. If the sender domain wants to make some assertion about the message that will survive the MLM, then it needs to sign something that the MLM isn't going to change. Perhaps, in addition to a full strength DKIM signature, it could add a signature of the From:, Date: and Message-ID headers. If the signing MTA knows that the email is going to a list, it could even sign the list-post header that's going to be added. The point is to offer a signature that satisfies ADSP, while reducing the opportunity for replay attacks. Of course, if you're publishing ADSP discardable policies, you probably don't want to offer any opportunity for replay attacks. But there is, at least, a way of making DKIM, ADSP and lists work together if the sender wants to do that. For MLM managers, they should simply reject at SMTP time if they are about to break ALL the DKIM signatures of a message from a discardable domain. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 10:34 AM, Rolf E. Sonneveld wrote: > > > Changes that merely add new header fields, such as those specified by > [LIST-ID], [LIST-URLS] and [MAIL] are generally the most friendly to > a DKIM-participating email infrastructure in that their addition by > an MLM will not affect any existing DKIM signatures unless those > fields were already present and covered by a signature’s hash or a > signature was created specifically to disallow their addition (see > the note about "h=" in Section 3.5 of [DKIM]). The shortest path to > success for DKIM would be to mandate that all MLM software be redesigned > or re-configured with that goal in mind. > > However, the practice of applying headers and footers to message > bodies is common and not expected to fade regardless of what > documents this or any standards body might produce. This sort of > change will invalidate the signature on a message where the body hash > covers the entire entire message. Thus, the following sections also > investigate and recommend other processing alternatives. > > That's not really answering my question, unfortunately. I'm asking what you intend to use the original signature's verification status for with the knowledge that you will have a non-zero false positive rate. We did our experiment with spear-phishing in mind: ie, can we tag mail purporting to originate from us with a bad/missing signature with an acceptable false positive rate. It was pretty close. I don't know what problem your proposal is intending to solve. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 06:40 PM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Tuesday, August 03, 2010 9:21 AM To: Murray S. Kucherawy Cc: Rolf E. Sonneveld; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature But didn't we also say that such reverified signatures don't get any additional meaning with 'z=' reprocessing? Sorry, I don't understand. I guess I don't either. You're saying use of "l=" and "z=" got your mail-through-lists signature verification statistics up to 95%. However, RFC4871 says "Copied header field values are for diagnostic use" which I interpret to mean (and I think discussion on the list back then also agreed) that the information in a "z=" tag isn't supposed to contribute to the canonicalization algorithms, but instead can only be used for diagnostic purposes (i.e., "This signature failed, and via the 'z=' we know why... but it still failed."). Furthermore, the use of "l=" is discouraged in RFC4871 and in the MLM draft: par. 3.5: INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might allow display of fraudulent content without appropriate warning to end users. The "l=" tag is intended for increasing signature robustness when sending to mailing lists that both modify their content and do not sign their messages. However, using the "l=" tag enables attacks in which an intermediary with malicious intent modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient's eyes and to defeat duplicate message detection algorithms. Examples are described in Security Considerations (Section 8 <http://tools.ietf.org/html/rfc4871#section-8>). To avoid this attack, signers should be extremely wary of using this tag, and verifiers might wish to ignore the tag or remove text that appears after the specified content length. and A possible mitigation to this incompatibility is use of the "l=" tag to bound the portion of the body covered by the body hash, but this not workable for [MIME] messages and moreover has security considerations (see Section 3.5 of [DKIM]). Its use is therefore discouraged. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 06:53 PM, Michael Thomas wrote: > On 08/03/2010 09:40 AM, Murray S. Kucherawy wrote: >>> -Original Message- >>> From: Michael Thomas [mailto:m...@mtcc.com] >>> Sent: Tuesday, August 03, 2010 9:21 AM >>> To: Murray S. Kucherawy >>> Cc: Rolf E. Sonneveld; ietf-dkim@mipassoc.org >>> Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to >>> preserve original DKIM signature and at the same time add a new DKIM >>> signature >>> >>>> But didn't we also say that such reverified signatures don't get any >>>> additional meaning with 'z=' reprocessing? >>> >>> Sorry, I don't understand. >> >> I guess I don't either. You're saying use of "l=" and "z=" got your >> mail-through-lists signature verification statistics up to 95%. >> However, RFC4871 says "Copied header field values are for diagnostic >> use" which I interpret to mean (and I think discussion on the list >> back then also agreed) that the information in a "z=" tag isn't >> supposed to contribute to the canonicalization algorithms, but >> instead can only be used for diagnostic purposes (i.e., "This >> signature failed, and via the 'z=' we know why... but it still >> failed."). > > Yeah, well, sue me for flipping that MUST NOT the bird. It works, z= > is signed > by the originator, and it's probably as high a recovery rate that > you'll ever > get going through mailing lists. We weren't proposing that it be part > of any > standard, and our reasons had nothing to do with ADSP either. All I'm > saying is > that if you want mailing list signature recovery, we've already done > that and > wrung out about as much as can be hoped for. > > As I asked earlier, what is the purpose of this anyway? We were doing > it to > deal with spear-phishing attacks. Maybe I've missed the motivation for > the > mime thingy. The motivation was the MLM draft document, par. 3.4. I quote: Changes that merely add new header fields, such as those specified by [LIST-ID], [LIST-URLS] and [MAIL] are generally the most friendly to a DKIM-participating email infrastructure in that their addition by an MLM will not affect any existing DKIM signatures unless those fields were already present and covered by a signature’s hash or a signature was created specifically to disallow their addition (see the note about "h=" in Section 3.5 of [DKIM]). The shortest path to success for DKIM would be to mandate that all MLM software be redesigned or re-configured with that goal in mind. However, the practice of applying headers and footers to message bodies is common and not expected to fade regardless of what documents this or any standards body might produce. This sort of change will invalidate the signature on a message where the body hash covers the entire entire message. Thus, the following sections also investigate and recommend other processing alternatives. It was my intention to add one such 'processing alternative'. Now the question is: does it cover the remaining 5% or not? And if so (if we could get to 100%), is it worth the (huge) effort to rewrite DKIM? /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 09:40 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: Michael Thomas [mailto:m...@mtcc.com] >> Sent: Tuesday, August 03, 2010 9:21 AM >> To: Murray S. Kucherawy >> Cc: Rolf E. Sonneveld; ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to >> preserve original DKIM signature and at the same time add a new DKIM >> signature >> >>> But didn't we also say that such reverified signatures don't get any >>> additional meaning with 'z=' reprocessing? >> >> Sorry, I don't understand. > > I guess I don't either. You're saying use of "l=" and "z=" got your > mail-through-lists signature verification statistics up to 95%. However, > RFC4871 says "Copied header field values are for diagnostic use" which I > interpret to mean (and I think discussion on the list back then also agreed) > that the information in a "z=" tag isn't supposed to contribute to the > canonicalization algorithms, but instead can only be used for diagnostic > purposes (i.e., "This signature failed, and via the 'z=' we know why... but > it still failed."). Yeah, well, sue me for flipping that MUST NOT the bird. It works, z= is signed by the originator, and it's probably as high a recovery rate that you'll ever get going through mailing lists. We weren't proposing that it be part of any standard, and our reasons had nothing to do with ADSP either. All I'm saying is that if you want mailing list signature recovery, we've already done that and wrung out about as much as can be hoped for. As I asked earlier, what is the purpose of this anyway? We were doing it to deal with spear-phishing attacks. Maybe I've missed the motivation for the mime thingy. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
> -Original Message- > From: Michael Thomas [mailto:m...@mtcc.com] > Sent: Tuesday, August 03, 2010 9:21 AM > To: Murray S. Kucherawy > Cc: Rolf E. Sonneveld; ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to > preserve original DKIM signature and at the same time add a new DKIM > signature > > > But didn't we also say that such reverified signatures don't get any > > additional meaning with 'z=' reprocessing? > > Sorry, I don't understand. I guess I don't either. You're saying use of "l=" and "z=" got your mail-through-lists signature verification statistics up to 95%. However, RFC4871 says "Copied header field values are for diagnostic use" which I interpret to mean (and I think discussion on the list back then also agreed) that the information in a "z=" tag isn't supposed to contribute to the canonicalization algorithms, but instead can only be used for diagnostic purposes (i.e., "This signature failed, and via the 'z=' we know why... but it still failed."). -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 09:15 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of Michael Thomas >> Sent: Tuesday, August 03, 2010 7:59 AM >> To: Rolf E. Sonneveld >> Cc: ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to >> preserve original DKIM signature and at the same time add a new DKIM >> signature >> >> When we wrote our dkim implementation, we did a bunch of work within >> the >> existing DKIM framework (using l= and z=) that allowed us to get most >> original signatures to reverify through mailing lists (~95%). No work >> needed on the mailing list software at all. > > But didn't we also say that such reverified signatures don't get any > additional meaning with 'z=' reprocessing? Sorry, I don't understand. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Michael Thomas > Sent: Tuesday, August 03, 2010 7:59 AM > To: Rolf E. Sonneveld > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to > preserve original DKIM signature and at the same time add a new DKIM > signature > > When we wrote our dkim implementation, we did a bunch of work within > the > existing DKIM framework (using l= and z=) that allowed us to get most > original signatures to reverify through mailing lists (~95%). No work > needed on the mailing list software at all. But didn't we also say that such reverified signatures don't get any additional meaning with 'z=' reprocessing? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Rolf E. Sonneveld > Sent: Tuesday, August 03, 2010 6:30 AM > To: Bill Oxley @ Cox > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] MLMs and the use of multipart/alternative to > preserve original DKIM signature and at the same time add a new DKIM > signature > > Or is the general consensus that (in the long run) the reputation of > the > MLM domain is sufficient for the verifier/receiver of MLM distributed > mail? I don't read that in the draft. That's definitely my forward-looking view, but it's hard to include text in a document that points to something in the future with any degree of certainty. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
> Trusting the MLM may be possible for you personnly for this particular > mailing list, but your choice is not scaleable to the Internet at large. Or > is the general consensus that (in the long run) the reputation of the MLM > domain is sufficient for the verifier/receiver of MLM distributed mail? I > don't read that in the draft. How do you sort list mail now? By List-id, or by individual From lines? Everyone I know sorts by the list. In a few cases I do bozo filtering to dump individual messages, but that's on genuine mail from bozos, so signatures aren't an issue. If people expect mail recipients to stop treating a list as a single mail stream and instead as unrelated messages from the contributors, it'd be helpful if they explained why 30 years of practice is going out the window. To me this looks very much like the drunk searching for his keys under the streetlight. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
I trust the reputation and blame the reputation of the MLM as a single standalone author. I have no interest in the contributors reputation. As a receiver who is on many lists I unsubscribe when the list no longer meets my viewing needs. As a admin of mail systems I dont want to interrupt that flow unless virus or spam is egregious On Aug 3, 2010, at 9:30 AM, Rolf E. Sonneveld wrote: > On 08/03/2010 02:13 PM, bill.ox...@cox.com wrote: >> When I receive an email from DKIM mailing list, I know that it may contain >> messages from Dave Hector John Doug et all but in my mind the from is DKIM >> mailing list. The only dkim sig I am interested in is ietf-dkim@mipassoc.org >> and if I bothered to check adsp for etf-d...@mipassoc.org I wouldnt waste >> time checking any other signatures/adsp assertions from participants as I >> see a mailing list as an aggregator. > > Again, I am not talking about ADSP. > >> If I was designing mailing list software I would strip any incoming headers >> that made any assertions about the authors, sign the pile with my dkim sig >> and forward as designed. I would be asserting that etf-d...@mipassoc.org is >> the author/aggregator not a forwarding service. Trying to have 3rd party in >> a hands off transaction assert or check that the authoring party may be who >> they say they are and making decisions upon adsp discardable that may or may >> not be valid is beyond any sensible solution. >> thanks, now back into lurk mode >> > > Trusting the MLM may be possible for you personnly for this particular > mailing list, but your choice is not scaleable to the Internet at large. > Or is the general consensus that (in the long run) the reputation of the > MLM domain is sufficient for the verifier/receiver of MLM distributed > mail? I don't read that in the draft. > > /rolf > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 03:03 AM, Rolf E. Sonneveld wrote: > With this situation in mind, I wrote my proposal, to provide the > verifier on the receiving side with a means to verify the original DKIM > signature. Rolf, When we wrote our dkim implementation, we did a bunch of work within the existing DKIM framework (using l= and z=) that allowed us to get most original signatures to reverify through mailing lists (~95%). No work needed on the mailing list software at all. What you're proposing would be close to 100% reverify rate of the lists that choose to implement what you're proposing. Right now that's 100% * 0% :) But even if it was accepted and caught on, it would still be a *very* long time before you got to anywhere close to what we achieved. Maybe this would be good for the pathological cases, but it probably wouldn't be good enough to trust for, say, ADSP-discardable or any other indicator/service that said that you should treat unsigned/broken signatures harshly. I guess the meta question here is what the purpose is you have in mind. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On Tuesday, August 03, 2010 08:02:34 am Hector Santos wrote: > It seems much easier for MLS (Mail List Servers) to preempt > restrictive ADSP Domains from subscribing and from submitting mail to > the list enabled with DKIM resigning. This would also give you the use case to deal with of restrictive ADSP published after someone has already subscribed. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 02:13 PM, bill.ox...@cox.com wrote: > When I receive an email from DKIM mailing list, I know that it may contain > messages from Dave Hector John Doug et all but in my mind the from is DKIM > mailing list. The only dkim sig I am interested in is ietf-dkim@mipassoc.org > and if I bothered to check adsp for etf-d...@mipassoc.org I wouldnt waste > time checking any other signatures/adsp assertions from participants as I see > a mailing list as an aggregator. Again, I am not talking about ADSP. > If I was designing mailing list software I would strip any incoming headers > that made any assertions about the authors, sign the pile with my dkim sig > and forward as designed. I would be asserting that etf-d...@mipassoc.org is > the author/aggregator not a forwarding service. Trying to have 3rd party in a > hands off transaction assert or check that the authoring party may be who > they say they are and making decisions upon adsp discardable that may or may > not be valid is beyond any sensible solution. > thanks, now back into lurk mode > Trusting the MLM may be possible for you personnly for this particular mailing list, but your choice is not scaleable to the Internet at large. Or is the general consensus that (in the long run) the reputation of the MLM domain is sufficient for the verifier/receiver of MLM distributed mail? I don't read that in the draft. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
When I receive an email from DKIM mailing list, I know that it may contain messages from Dave Hector John Doug et all but in my mind the from is DKIM mailing list. The only dkim sig I am interested in is ietf-dkim@mipassoc.org and if I bothered to check adsp for etf-d...@mipassoc.org I wouldnt waste time checking any other signatures/adsp assertions from participants as I see a mailing list as an aggregator. If I was designing mailing list software I would strip any incoming headers that made any assertions about the authors, sign the pile with my dkim sig and forward as designed. I would be asserting that etf-d...@mipassoc.org is the author/aggregator not a forwarding service. Trying to have 3rd party in a hands off transaction assert or check that the authoring party may be who they say they are and making decisions upon adsp discardable that may or may not be valid is beyond any sensible solution. thanks, now back into lurk mode Bill On Aug 3, 2010, at 6:03 AM, Rolf E. Sonneveld wrote: > On 08/03/2010 02:36 AM, John Levine wrote: >>> The proposal is to preserve the original message + DKIM signature and to >>> add the new (probably partially rewritten) output message, combined into >>> a multipart/alternative structure. The combined message is sent by the >>> MLM to the recipient. >>> >> Once again, I can only see this as screwing up the 99+% of users for >> whom the lists work just fine for the<1% who consider themselves so >> important that they need to mark their list mail with ADSP. >> > > I did not have ADSP in mind when writing this proposal. Let me be clear > about ADSP: IMO domains that publish adsp=discardable and yet send mail > with that domain via mailing lists, get what they deserve: problems. > >> Imagine you're a list manager. Your list has 1000 subscribers. Two >> of them demand that you do something to prevent address forgery due to >> forged unsigned messages, a problem that you have never observed to >> happen on your lists. What do you do? I know what I'd do. >> > > In a nutshell the problem of the combination DKIM + MLM can be > summarized (and simplified) as follows. > > On the plus side: > > 1. the mail that is received by a subscriber to a mailing list carries > (most of the time) the original From. > 2. the original DKIM signature can still be present in the message (if > we recommend the MLM authors to not remove DKIM-Signatures) > > However... > > 3. the MLM rewrites the Subject (in many cases) > 4. the MLM adds a footer (many cases) > 5. see par. 3.3 of Murrays draft for more things MLMs do to messages > > That means, we have a signature + From, but we no longer have a reliable > copy of the message to verify them. > > 6. we can tell the MLM authors to change their code to no longer do 3., > 4. and 5. but, as Murray describes in par. 3.4: > > > However, the practice of applying headers and footers to message > bodies is common and not expected to fade regardless of what > documents this or any standards body might produce. > > > With this situation in mind, I wrote my proposal, to provide the > verifier on the receiving side with a means to verify the original DKIM > signature. > > /rolf > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 02:02 PM, Hector Santos wrote:
> Rolf,
>
> It seems much easier for MLS (Mail List Servers) to preempt
> restrictive ADSP Domains from subscribing and from submitting mail to
> the list enabled with DKIM resigning.
>
> Follow the specification and apply it accordingly using engineering
> sense. No Subjective concepts. We need persistent expectations across
> the board. The problem here is that list managers what to sign
> everything with disregard to policy. There is no way you going to get
>
>DKIM+POLICY+MLS
>
> correct. Something has to give. Support policy is an answer, getting
> rid of it is another so that at least everyone can work under the same
> plane.
>
> It would easy to add new common sense options to our list server such:
>
> List DKIM/ADSP options:
>
> [X] DKIM Sign this list
>
> [CLICK FOR DKIM SIGNING OPTIONS]
>
> [X] Disallow ADSP DISCARDABLE domains from subscribing.
> [X] Disallow ADSP DISCARDABLE domain list submissions.
>
> [X] Send Notification to domain for ADSP=DISCARD Policy
> restricted subscription or submissions.
>
> [EDIT NO-ASDP-ALLOW-SUBSCRIPTION TEMPLATE]
> [EDIT NO-ASDP-DISCARD-SUBMISSIONS TEMPLATE]
>
> The template #1 would probably say:
>
> Dear {MSG.FROM}
>
> Sorry, but you can not subscribe to this list using
> a restricted ADSP DKIM=DISCARDABLE policy for your
> domain. If we had accept your subscription, there is
> risk of harming the subscription status of other members
> already on the list. We don't wish to do that.
>
> Remedies:
>
> 1) Remove the DKIM=DISCARDABLE ADSP policy or change
>ADSP policy to DKIM=ALL and reapply to subscribe
>to the list.
>
> 2) Use another domain that isn't ADSP restricted.
>
> The template #2 would probably say:
>
> Dear {MSG.FROM}
>
> Sorry, message submission to this list is restricted to
> domains with non-ADSP DISCARDABLE policies only.
> If we had accepted it, there is risk of harming the
> subscription status of other members of the list. We don't
> wish to do that.
>
> Remedies:
>
> 1) Remove the DKIM=DISCARDABLE ADSP policy or change
>ADSP policy to DKIM=ALL and resubmit your message.
>
> 2) Use another domain that isn't ADSP restricted.
>
> I can't remove popular features even if I wanted to and I seriously
> doubt any RFC will change this for most systems:
>
> [X] Add [LIST] Tag to Subject Line
> [X] Add Footer [EDIT FOOTER TEMPLE]
> [X] Set Reply-To to List address
> [_] Strip HTML
> [_] Strip Attachments
>
> and all other inherent integrity breaking ideas in MLS software and
> used by MLM (Mail List Managers).
>
> We need to fit DKIM/POLICY into the system. Not fit the SYSTEM into
> DKIM/POLICY. -1 towards ideas of altering 5322.From lines which will
> only open a nasty can of worms. We would be breaking all kinds of
> Authorship From expectations, including touching base with copyright
> related issues.
>
> Or get rid of POLICY if its hurting DKIM implementation for list
> servers. Working it to standardization yet list managers with DKIM
> resigners intentionally ignoring it is not going to work very well.
> Not supporting it is one thing, yet allowing ADSP domains to submit
> mail is another thing. It doesn't mix well.
>
> If this becomes the behavior what will happen is SMTP systems will be
> force to accept mail to discard it. They won't be be able to reject
> mail at the transport level because that will promote a bounce towards
> the list server and this will hurt members of the list.
>
> We can't dictate to SMTP developer and operators not to employ session
> level rejections.
>
My proposal was and is _not_ aimed at ADSP and _not_ at policies in
general. The proposal only identifies a means to make MLMs (and
re-signers in general) in a way 'transparant' for receivers of a mail.
Nothing more, nothing less.
/rolf
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
Rolf,
It seems much easier for MLS (Mail List Servers) to preempt
restrictive ADSP Domains from subscribing and from submitting mail to
the list enabled with DKIM resigning.
Follow the specification and apply it accordingly using engineering
sense. No Subjective concepts. We need persistent expectations across
the board. The problem here is that list managers what to sign
everything with disregard to policy. There is no way you going to get
DKIM+POLICY+MLS
correct. Something has to give. Support policy is an answer, getting
rid of it is another so that at least everyone can work under the same
plane.
It would easy to add new common sense options to our list server such:
List DKIM/ADSP options:
[X] DKIM Sign this list
[CLICK FOR DKIM SIGNING OPTIONS]
[X] Disallow ADSP DISCARDABLE domains from subscribing.
[X] Disallow ADSP DISCARDABLE domain list submissions.
[X] Send Notification to domain for ADSP=DISCARD Policy
restricted subscription or submissions.
[EDIT NO-ASDP-ALLOW-SUBSCRIPTION TEMPLATE]
[EDIT NO-ASDP-DISCARD-SUBMISSIONS TEMPLATE]
The template #1 would probably say:
Dear {MSG.FROM}
Sorry, but you can not subscribe to this list using
a restricted ADSP DKIM=DISCARDABLE policy for your
domain. If we had accept your subscription, there is
risk of harming the subscription status of other members
already on the list. We don't wish to do that.
Remedies:
1) Remove the DKIM=DISCARDABLE ADSP policy or change
ADSP policy to DKIM=ALL and reapply to subscribe
to the list.
2) Use another domain that isn't ADSP restricted.
The template #2 would probably say:
Dear {MSG.FROM}
Sorry, message submission to this list is restricted to
domains with non-ADSP DISCARDABLE policies only.
If we had accepted it, there is risk of harming the
subscription status of other members of the list. We don't
wish to do that.
Remedies:
1) Remove the DKIM=DISCARDABLE ADSP policy or change
ADSP policy to DKIM=ALL and resubmit your message.
2) Use another domain that isn't ADSP restricted.
I can't remove popular features even if I wanted to and I seriously
doubt any RFC will change this for most systems:
[X] Add [LIST] Tag to Subject Line
[X] Add Footer [EDIT FOOTER TEMPLE]
[X] Set Reply-To to List address
[_] Strip HTML
[_] Strip Attachments
and all other inherent integrity breaking ideas in MLS software and
used by MLM (Mail List Managers).
We need to fit DKIM/POLICY into the system. Not fit the SYSTEM into
DKIM/POLICY. -1 towards ideas of altering 5322.From lines which will
only open a nasty can of worms. We would be breaking all kinds of
Authorship From expectations, including touching base with copyright
related issues.
Or get rid of POLICY if its hurting DKIM implementation for list
servers. Working it to standardization yet list managers with DKIM
resigners intentionally ignoring it is not going to work very well.
Not supporting it is one thing, yet allowing ADSP domains to submit
mail is another thing. It doesn't mix well.
If this becomes the behavior what will happen is SMTP systems will be
force to accept mail to discard it. They won't be be able to reject
mail at the transport level because that will promote a bounce towards
the list server and this will hurt members of the list.
We can't dictate to SMTP developer and operators not to employ session
level rejections.
--
HLS
Rolf E. Sonneveld wrote:
> On 08/03/2010 02:36 AM, John Levine wrote:
>>> The proposal is to preserve the original message + DKIM signature and to
>>> add the new (probably partially rewritten) output message, combined into
>>> a multipart/alternative structure. The combined message is sent by the
>>> MLM to the recipient.
>>>
>> Once again, I can only see this as screwing up the 99+% of users for
>> whom the lists work just fine for the<1% who consider themselves so
>> important that they need to mark their list mail with ADSP.
>>
>
> I did not have ADSP in mind when writing this proposal. Let me be clear
> about ADSP: IMO domains that publish adsp=discardable and yet send mail
> with that domain via mailing lists, get what they deserve: problems.
>
>> Imagine you're a list manager. Your list has 1000 subscribers. Two
>> of them demand that you do something to prevent address forgery due to
>> forged unsigned messages, a problem that you have never observed to
>> happen on your lists. What do you do? I know what I'd do.
>>
>
> In a nutshell the problem of the combination DKIM + MLM can be
> summarized (and simplified) as follows.
>
> On the plus side:
>
> 1. the mail that is received by a subscriber to a mailing list carries
> (most of the time) the original From.
> 2. the original DKIM signature can still be present in the message (if
> we recommend the MLM authors to not remove DKIM-Signatures)
>
> However...
>
> 3. t
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 02:36 AM, John Levine wrote: >> The proposal is to preserve the original message + DKIM signature and to >> add the new (probably partially rewritten) output message, combined into >> a multipart/alternative structure. The combined message is sent by the >> MLM to the recipient. >> > Once again, I can only see this as screwing up the 99+% of users for > whom the lists work just fine for the<1% who consider themselves so > important that they need to mark their list mail with ADSP. > I did not have ADSP in mind when writing this proposal. Let me be clear about ADSP: IMO domains that publish adsp=discardable and yet send mail with that domain via mailing lists, get what they deserve: problems. > Imagine you're a list manager. Your list has 1000 subscribers. Two > of them demand that you do something to prevent address forgery due to > forged unsigned messages, a problem that you have never observed to > happen on your lists. What do you do? I know what I'd do. > In a nutshell the problem of the combination DKIM + MLM can be summarized (and simplified) as follows. On the plus side: 1. the mail that is received by a subscriber to a mailing list carries (most of the time) the original From. 2. the original DKIM signature can still be present in the message (if we recommend the MLM authors to not remove DKIM-Signatures) However... 3. the MLM rewrites the Subject (in many cases) 4. the MLM adds a footer (many cases) 5. see par. 3.3 of Murrays draft for more things MLMs do to messages That means, we have a signature + From, but we no longer have a reliable copy of the message to verify them. 6. we can tell the MLM authors to change their code to no longer do 3., 4. and 5. but, as Murray describes in par. 3.4: However, the practice of applying headers and footers to message bodies is common and not expected to fade regardless of what documents this or any standards body might produce. With this situation in mind, I wrote my proposal, to provide the verifier on the receiving side with a means to verify the original DKIM signature. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On 08/03/2010 12:56 AM, Steve Atkins wrote:
> On Aug 2, 2010, at 3:37 PM, Rolf E. Sonneveld wrote:
>
>
>> Hi, all
>>
>> in the light of the discussion about draft-ietf-dkim-mailinglists I'd
>> like to propose an alternative way to solve the MLM dilemma on how to
>> deal with original DKIM signature/message versus sending out a modified
>> version of the message. This proposal may be impractical or hard to
>> realize, but I'd just thought I had to share it with you.
>>
>
>> The proposal is to preserve the original message + DKIM signature and to
>> add the new (probably partially rewritten) output message, combined into
>> a multipart/alternative structure. The combined message is sent by the
>> MLM to the recipient. For the original message + DKIM signature, we
>> could register a Content-Type of e.g. message/dkim-original-message with
>> IANA. The output message would be the other part of the
>> multipart/alternative, with the normal MIME structure of the MLM output
>> message. A sample message sent by an MLM (or more in general, by a
>> re-signer) would look like:
>>
> Does this mean that anyone can take their own content and
> a message DKIM signed by someone else, and then send it out
> such that their content will be displayed, but the (non-displayed)
> signed message will be checked?
>
No, it means that for both message parts a DKIM signature is checked for
presence and the results of both are made available to the receiver
('receiver' as in Murrays draft defined in par. 3.1). So effectively it
means that in the situation you described, the 'own content' is
displayed but lacks a verified DKIM signature and as such should be
treated as a message without DKIM signature. The proposal just means to
provide a way to tunnel the original contents of a message + DKIM
signature and enable the verifier to verify not only the DKIM signature
provided by the resigner, but also the original DKIM signature as well.
The A-R results of the original DKIM signature, provided by the resigner
as part of the new DKIM signature can only be trusted if the
verifier/receiver trusts the resigner. With the original DKIM signature
+ message present, there is no need for this trust relation; the
verifier itself can verify.
/rolf
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
>The proposal is to preserve the original message + DKIM signature and to >add the new (probably partially rewritten) output message, combined into >a multipart/alternative structure. The combined message is sent by the >MLM to the recipient. Once again, I can only see this as screwing up the 99+% of users for whom the lists work just fine for the <1% who consider themselves so important that they need to mark their list mail with ADSP. Imagine you're a list manager. Your list has 1000 subscribers. Two of them demand that you do something to prevent address forgery due to forged unsigned messages, a problem that you have never observed to happen on your lists. What do you do? I know what I'd do. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On Aug 2, 2010, at 3:37 PM, Rolf E. Sonneveld wrote: > Hi, all > > in the light of the discussion about draft-ietf-dkim-mailinglists I'd > like to propose an alternative way to solve the MLM dilemma on how to > deal with original DKIM signature/message versus sending out a modified > version of the message. This proposal may be impractical or hard to > realize, but I'd just thought I had to share it with you. > > The proposal is to preserve the original message + DKIM signature and to > add the new (probably partially rewritten) output message, combined into > a multipart/alternative structure. The combined message is sent by the > MLM to the recipient. For the original message + DKIM signature, we > could register a Content-Type of e.g. message/dkim-original-message with > IANA. The output message would be the other part of the > multipart/alternative, with the normal MIME structure of the MLM output > message. A sample message sent by an MLM (or more in general, by a > re-signer) would look like: Does this mean that anyone can take their own content and a message DKIM signed by someone else, and then send it out such that their content will be displayed, but the (non-displayed) signed message will be checked? If so, this seems like exactly the reply attack that DKIM was designed to prevent. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
Hi, all in the light of the discussion about draft-ietf-dkim-mailinglists I'd like to propose an alternative way to solve the MLM dilemma on how to deal with original DKIM signature/message versus sending out a modified version of the message. This proposal may be impractical or hard to realize, but I'd just thought I had to share it with you. The proposal is to preserve the original message + DKIM signature and to add the new (probably partially rewritten) output message, combined into a multipart/alternative structure. The combined message is sent by the MLM to the recipient. For the original message + DKIM signature, we could register a Content-Type of e.g. message/dkim-original-message with IANA. The output message would be the other part of the multipart/alternative, with the normal MIME structure of the MLM output message. A sample message sent by an MLM (or more in general, by a re-signer) would look like: From: "Rolf E. Sonneveld" To: DKIM List Date: Mon, 02 Aug 2010 11:43:39 +0200 Subject: Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for discussion DKIM-Signature: ... DKIM signature provided by re-signer goes here ... MIME-version: 1.0 Content-Type: multipart/alternative; boundary=boundary1234 --boundary1234 Content-Type: message/dkim-original-message ... original version of message including all original headers and _original DKIM signature_ goes here ... --boundary1234 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII ... output message of MLM goes here ... --boundary1234-- As per MIME RFC 2046 (par. 5.1.4) multipart/alternative provides a means of presenting multiple versions of the same information, where the receiving MUA can decide which one to display to the recipient. In a sense we can view the original message and the one, that is being sent out by the MLM, more or less as two incarnations of the same message, and as such I think the multipart/alternative can be used. As the message/dkim-original-message subtype will not be recognized by MUA's, we can be sure that the end user will be presented by the MLM rewritten version of the message. The advantages of using this approach are: - the original DKIM-signature is preserved. The verifier can verify both the original DKIM signature of the author domain, as well as the DKIM signature of the MLM domain. - any FBL can use the message/dkim-original-message information to send the feedback to the proper place - no need to rewrite From address (and Sender, Reply-To) - this approach can be used for other 're-signing' mail agents in the chain between sender and recipient - it can also be used when there is more than one re-signer in the chain (nested multipart/alternative structure) to provide a generic solution Disadvantages of this approach are: - it requires the verification paragraph of DKIM to be rewritten - the size of MLM redistributed messages is doubled roughly (hey, nobody complained about the extra size of text/plain + text/html messages ;-)) - it will probably require more changes in MLM software than the other proposals I'm sure there is a whole lot more to say about this proposal, more pros, more cons etc. I solicit your comments! /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
