Re: [ietf-dkim] On changing From: when sending through lists
On Wed, 11 Aug 2010 01:09:57 +0100, John Levine jo...@iecc.com wrote: I have to say that this particular proposal is currently no more than 1/3 baked, since unless I've missed something, I don't see much effort to work out failure and security models. For example: OK, in the scenarios which follow, you is some MLM, and the proposition is that the MLM might decide to alter the From: header (e.g. by percent encoding), plus some other useful changes. - Who do you accept forwarded messages from? List subscribers? Anyone? Subscribers and people who sign up on a forward-me pseudo list? The MLM (aka you) makes that decision according to the purpose of his list. Those factors might well influence whether he changes the From: or not. - If a forwarded message ITYM one that is forwarded back to the original author via the percent hack is rejected or bounces, what do you do? At what point should you stop trying to forward? That is a matter of policy for the MLM to decide. Presumably if it is a 4xx response you keep trying, and if it is a 5xx you pass it back up the Return Path. That is, more or less, current common practice. ... If you get mail to an address that you don't forward any more do you reject it? Drop it? Something else? Again that is a matter of policy for the MLM. It would be polite to reject with some 5xx and/or some explanation up the Return Path. It would be a kindness to continue to forward it at least for a while. - What do you do when someone unsubscribes? When someone bounces off the list? When someone changes his subscription address? (Yes, there are MLMs that let you do that.) Policy again. there is no obligation to forward bounces off the list (indeed an open relay is already considered bad practice). A changed subscription simply causes the percent hack to be applied to the new address. For unsubscription, see the previous scenarios. - What kind of spam filtering is appropriate for forwarded messages? For returning bounces? Should you try to distinguish between real bounces and spam to bounce addresses ? Probably best to forward regardless, which gives the same effect as if the responder had replied directly himself. As a minor benefit, it lets you discover that your members are sending spam, if you really want to follow that path. Essentially, your forwarding practice should seek to emulate the current situation where the responder replies to the original author directly. - Many MUAs collect outgoing addresses into the local address book, so people who really have one address will now appear to have N+1 if they subscribe to N lists. Is that a problem? Why or why not? If it's a problem, what should you do about it? That is the only point you have raised that might have some merit. It does not seem like a showstopper to me, but the possibility ought to be documented as part of the proposal. If the percentified address in the address book stops working then, according to the answers given above, the responder will soon get to know about it, exactly the same as when someone currently changes their address and fails to notify everyone affected. That's all that occurs to me in five minutes, but I'm sure that if you actually try it, you'll find lots more. Keep shooting. Maybe you will eventually find your foot :-) . -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] On changing From: when sending through lists
On 8/11/10 1:49 PM, Charles Lindsey wrote: On Wed, 11 Aug 2010 01:09:57 +0100, John Levine jo...@iecc.com wrote: - Many MUAs collect outgoing addresses into the local address book, so people who really have one address will now appear to have N+1 if they subscribe to N lists. Is that a problem? Why or why not? If it's a problem, what should you do about it? That is the only point you have raised that might have some merit. It does not seem like a showstopper to me, but the possibility ought to be documented as part of the proposal. If the percentified address in the address book stops working then, according to the answers given above, the responder will soon get to know about it, exactly the same as when someone currently changes their address and fails to notify everyone affected. Obfuscating who sent a message is not good, especially in light of what motivated use of ADSP policy that is causing this problem. Unfortunately, ADSP as currently structured is too restrictive for all but ~0.0008% of legitimate domains, or even ~0.375% of domains being heavily phished. ADSP's extremely limited use indicates it is _not_ the mailing-lists that need to change. ADSP policies can be structured to permit specific third-party service exceptions, which resolves these problems without changing mailing-list and MUA code that would impact millions of users. Finally, modifying From header fields will not offer any reasonable transitional strategy able to resolve the problems facing ADSP within any reasonable time frame. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] On changing From: when sending through lists
I have to say that this particular proposal is currently no more than 1/3 baked, since unless I've missed something, I don't see much effort to work out failure and security models. For example: OK, in the scenarios which follow, you is some MLM, and the proposition is that the MLM might decide to alter the From: header (e.g. by percent encoding), plus some other useful changes. ... [ various comments ] OK, fine. I'm looking forward to your I-D. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] On changing From: when sending through lists
On Aug 1, 2010, at 3:43 PM, Murray S. Kucherawy wrote: This makes at least the third time this has been suggested by someone. I believe (though I'm willing to be corrected) that the draft should therefore cover this possibility and either advocate it or explain why it's a bad idea. The latter is acceptable; the material is on-topic, and we're trying to relay implementation advice and experience here, so it can be a cookbook of what to do as well as what not to do. Comments? And if you agree, your rationales in either direction? (I'll take Daniel's text at that link into account.) Weighing in a bit late...I think this approach should be included in the document. It's an entirely reasonable approach with some existing implementations, and it may not be as surprising to end users as it is to those of us who read raw email headers daily before breakfast. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] On changing From: when sending through lists
Comments? And if you agree, your rationales in either direction? (I'll take Daniel's text at that link into account.) Unless I misunderstand, this is a paper proposal that has never been implemented that addresses a quite possibly purely hypothetical problem. There's nothing wrong with unimplemented paper designs, but what you do with them is to write them up in an I-D, ask the IETF to publish it as Experimental (something I'd encourage the WG to do for this one), and once there's at least a modest amount of real life experience, perhaps come back and propose an updated version for standards track. For a good idea of the way this can work, look at the EAI group. It published a variety of Experimental RFCs fof non-ASCII email addresses, and now after they have some experience, they're moving ahead with one that seems to work less badly than the others. It's not the one I'd have expected them to pick, but when I read the messages about their experience, I see why they made the choice they did. I have to say that this particular proposal is currently no more than 1/3 baked, since unless I've missed something, I don't see much effort to work out failure and security models. For example: - Who do you accept forwarded messages from? List subscribers? Anyone? Subscribers and people who sign up on a forward-me pseudo list? - If a forwarded message is rejected or bounces, what do you do? At what point should you stop trying to forward? If you get mail to an address that you don't forward any more do you reject it? Drop it? Something else? - What do you do when someone unsubscribes? When someone bounces off the list? When someone changes his subscription address? (Yes, there are MLMs that let you do that.) - What kind of spam filtering is appropriate for forwarded messages? For returning bounces? Should you try to distinguish between real bounces and spam to bounce addresses ? - Many MUAs collect outgoing addresses into the local address book, so people who really have one address will now appear to have N+1 if they subscribe to N lists. Is that a problem? Why or why not? If it's a problem, what should you do about it? That's all that occurs to me in five minutes, but I'm sure that if you actually try it, you'll find lots more. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] On changing From: when sending through lists
On Sun, Aug 1, 2010 at 6:43 PM, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Daniel Black Sent: Thursday, July 29, 2010 5:15 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Alternative MAiling List Approach On Thursday 29 July 2010 21:21:41 Charles Lindsey wrote: I promised to do this some while back, but only just got a round tuit. Ah the mythical round tuit. I put a similar idea through when once I had a round tuit. Feel free to follow the threads. http://mipassoc.org/pipermail/dkim-dev/2009-September/000202.html This makes at least the third time this has been suggested by someone. I believe (though I'm willing to be corrected) that the draft should therefore cover this possibility and either advocate it or explain why it's a bad idea. The latter is acceptable; the material is on-topic, and we're trying to relay implementation advice and experience here, so it can be a cookbook of what to do as well as what not to do. Comments? And if you agree, your rationales in either direction? (I'll take Daniel's text at that link into account.) Well, I'm on a mailing list (a custom one) that re-writes the From to the mailing list, and frankly I like it. -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] On changing From: when sending through lists
On 08/02/2010 12:43 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Daniel Black Sent: Thursday, July 29, 2010 5:15 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Alternative MAiling List Approach On Thursday 29 July 2010 21:21:41 Charles Lindsey wrote: I promised to do this some while back, but only just got a round tuit. Ah the mythical round tuit. I put a similar idea through when once I had a round tuit. Feel free to follow the threads. http://mipassoc.org/pipermail/dkim-dev/2009-September/000202.html This makes at least the third time this has been suggested by someone. I believe (though I'm willing to be corrected) that the draft should therefore cover this possibility and either advocate it or explain why it's a bad idea. The latter is acceptable; the material is on-topic, and we're trying to relay implementation advice and experience here, so it can be a cookbook of what to do as well as what not to do. Include the option in the document with it's pros and cons: +1. As for the option itself (rewriting From): -1. Reasons: - I don't think it's a good idea to overwrite any Reply already set by the author of the message; it breaks the meaning of Reply-To as defined in RFC5322 - As per par. 6.3.2 of RFC5322 the From: address is not the right field to rewrite, IMO. If anything would have to be rewritten, it would be the Sender address. Comments? And if you agree, your rationales in either direction? (I'll take Daniel's text at that link into account.) /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] On changing From: when sending through lists
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Daniel Black Sent: Thursday, July 29, 2010 5:15 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Alternative MAiling List Approach On Thursday 29 July 2010 21:21:41 Charles Lindsey wrote: I promised to do this some while back, but only just got a round tuit. Ah the mythical round tuit. I put a similar idea through when once I had a round tuit. Feel free to follow the threads. http://mipassoc.org/pipermail/dkim-dev/2009-September/000202.html This makes at least the third time this has been suggested by someone. I believe (though I'm willing to be corrected) that the draft should therefore cover this possibility and either advocate it or explain why it's a bad idea. The latter is acceptable; the material is on-topic, and we're trying to relay implementation advice and experience here, so it can be a cookbook of what to do as well as what not to do. Comments? And if you agree, your rationales in either direction? (I'll take Daniel's text at that link into account.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
