Re: [ietf-dkim] Lists "BCP" draft available
>For non-MIME mail, though, isn't a basic text append the way to do it? I suppose, although it is my impression that in non-nerd circles, the amount of non-MIME mail is too small to be worth worrying about. FWIW, I've seen list software edit a footer into the HTML code of a message. Ain't no way a signature can survive that, so the reasonable approach is, as always, for the list to sign and recipients to key on the list's signature. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
Going back through a few months of mail on the flight to IETF, preparing to post an update to this draft... The intent of that paragraph is actually not to encourage use of "l=", but rather just to include it in the discussion. An MLM designer will probably want to try "l=" to solve this problem but may not be aware of the implications of its use, so it just points the reader back to the warning about it in RFC4871. For non-MIME mail, though, isn't a basic text append the way to do it? From: Serge Aumont [mailto:serge.aum...@cru.fr] Sent: Tuesday, May 11, 2010 7:38 AM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Lists "BCP" draft available [...] Section 3.4 At last, another idea usefulness is that draft in : "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 has security considerations (see Section 3.5 of [DKIM])." The "l=" tag is one of the worth idea of DKIM if introduced because of message body footer added by some MLM. MLM must not add anything after the end of a message because this break Mime content. When adding a footer, MLM should add an extra mime part, and this often require to modify mime headers. So "l=" tag should not ne considered as an efficient way to protect DKIM signature. I known that the problem is comming from rfc-4871 but I propose to remove this sentence from this draft. Serge Aumont ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Monday, June 14, 2010 10:22 AM > To: MH Michael Hammer (5304) > Cc: DKIM List > Subject: RE: [ietf-dkim] Lists "BCP" draft available > > > What you describe is NOT "collateral damage". The effect you describe is > > not unintended or accidental. > > Aw, come on. When the person publishing ADSP doesn't understand what he's > saying, the damage he causes is entirely unintended and accidental. > Unintended and accidental does not equal collateral. > If you're saying that ADSP was designed as a gun pre-aimed at one's foot, > I wouldn't disagree. > I am not saying that. The fact that something can be misused does not mean that it is pre-aimed at one's foot. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
--On 14 June 2010 16:07:03 +0200 "John R. Levine" wrote: > It's collateral to the extent that one's users complain about not getting > perfectly good mail. My understanding of "collateral damage" is that third parties are damaged. In an email correspondence, the sender and recipient are the first and second parties respectively. This may or may not be damage, but it's not collateral. -- 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] Lists "BCP" draft available
On 6/14/10 7:07 AM, John R. Levine wrote: >> I would appreciate you describing in detail this "collateral damage". If >> it involves discarding of mail from the domain in question then it is >> not collateral. What else do you have for us? >> > It's collateral to the extent that one's users complain about not getting > perfectly good mail. "Your friend's mail admins glorp plugh ADSP grungle > bleep" isn't a very satisfactory response to users. Pointing to > legalistic language in some web page with a three letter acronym won't > help. > > There's also the problems that have been noted with people bouncing off > mailing lists. Yes, in that case both ends are doing the wrong thing, but > if either did the right thing and forgot about ADSP we wouldn't have the > problem. > John, How will "doing the right thing" with ADSP resolve mailing list abuse? > The sooner we stop wasting time trying to fix ADSP and start getting > shared drop lists, the sooner there's some hope of using DKIM to keep > simple forgeries out of peoples' inboxes. > Is a shared-drop list an improved "discardable" list, and what does "discardable" mean in respect to Author Domain Signing Policy? Should all critical and potentially phished transactions be marked "discardable" and not generate DSN?" Should "all" be receive the same delivery treatment as "discardable"? Does "discardable" mean something other "all" and no NDNs? Should ADSP also indicate whether third-party services are being used? Reputation alone will not resolve abuse issues with a steady increase of abuse coming from reputable sources, and reputation certainly will not resolve a phishing issue, especially when senders are compelled to change email domains without a means to specifically and unilaterally authorize third-parties. Any general third-party authorization would increase abuse emitted by mailing lists, which would prove counter productive, especially without a defined method to identify third-party services. Of course, it remains possible for senders to make such a list themselves and to note how third-party services can be identified. An authorization scheme would leave "drop lists" control in the hands of the senders being trusted, or in the hands of their delegated authority (detail will be added in the draft to explain this function). -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of John R. Levine > Sent: Monday, June 14, 2010 6:23 AM > To: Ian Eiloart > Cc: DKIM List > Subject: Re: [ietf-dkim] Lists "BCP" draft available > > >> There's a fairly key difference you're missing here. For ADSP, each > >> domain publishes what it thinks is its own policy, so if you look at a > >> million domains, you have to guess about the competence of a million > mail > >> system managers. > >> > >> On the other hand, if you use one or two published drop lists, you can > >> afford to look at them and choose ones whose administrators are > >> competent, without having to individually vet each entry. > > > > Of course, I could also keep list of competent publishers of MX records. > > Indeed you could. And if the collateral damage from trying to use inept > MX records were as bad as the damage from trying to use inept ADSP > records, you probably would. > John, I would appreciate you describing in detail this "collateral damage". If it involves discarding of mail from the domain in question then it is not collateral. What else do you have for us? Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Monday, June 14, 2010 10:07 AM > To: MH Michael Hammer (5304) > Cc: DKIM List > Subject: RE: [ietf-dkim] Lists "BCP" draft available > > > I would appreciate you describing in detail this "collateral damage". If > > it involves discarding of mail from the domain in question then it is > > not collateral. What else do you have for us? > > It's collateral to the extent that one's users complain about not getting > perfectly good mail. "Your friend's mail admins glorp plugh ADSP grungle > bleep" isn't a very satisfactory response to users. Pointing to > legalistic language in some web page with a three letter acronym won't > help. > > There's also the problems that have been noted with people bouncing off > mailing lists. Yes, in that case both ends are doing the wrong thing, but > if either did the right thing and forgot about ADSP we wouldn't have the > problem. > > The sooner we stop wasting time trying to fix ADSP and start getting > shared drop lists, the sooner there's some hope of using DKIM to keep > simple forgeries out of peoples' inboxes. > > R's, > John John, What you describe is NOT "collateral damage". The effect you describe is not unintended or accidental. It is inherent. You may not like it but to describe it as "collateral damage" is an abuse of the English language. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> What you describe is NOT "collateral damage". The effect you describe is > not unintended or accidental. Aw, come on. When the person publishing ADSP doesn't understand what he's saying, the damage he causes is entirely unintended and accidental. If you're saying that ADSP was designed as a gun pre-aimed at one's foot, I wouldn't disagree. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> I would appreciate you describing in detail this "collateral damage". If > it involves discarding of mail from the domain in question then it is > not collateral. What else do you have for us? It's collateral to the extent that one's users complain about not getting perfectly good mail. "Your friend's mail admins glorp plugh ADSP grungle bleep" isn't a very satisfactory response to users. Pointing to legalistic language in some web page with a three letter acronym won't help. There's also the problems that have been noted with people bouncing off mailing lists. Yes, in that case both ends are doing the wrong thing, but if either did the right thing and forgot about ADSP we wouldn't have the problem. The sooner we stop wasting time trying to fix ADSP and start getting shared drop lists, the sooner there's some hope of using DKIM to keep simple forgeries out of peoples' inboxes. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
--On 11 June 2010 22:49:05 +0200 "John R. Levine" wrote: > > Of course not. That's an example of the reason that I don't find ADSP > useful (as opposed to manually vetted discard lists.) There's no way to > tell whether the party publishing discardable understands what they're > saying. > Right, but there's no way to tell whether a party publishing *any* DNS record understands what they're saying. You have to trust that they do. If something breaks as a result of a publication error, then it's the publisher's responsibility to fix that. Of course, any administrator who discovers a likely error should feel free to advise the publisher of that error. -- 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] Lists "BCP" draft available
--On 12 June 2010 17:22:34 +0200 "John R. Levine" wrote: >>> Of course not. That's an example of the reason that I don't find ADSP >>> useful (as opposed to manually vetted discard lists.) There's no way to >>> tell whether the party publishing discardable understands what they're >>> saying. >>> >> >> And likewise there is no way to tell whether the party implementing >> discard lists understand what they're doing. IMHO, we should stay away >> from assuming the presence or absence of a given level of expertise of >> the mail admins on this earth. > > There's a fairly key difference you're missing here. For ADSP, each > domain publishes what it thinks is its own policy, so if you look at a > million domains, you have to guess about the competence of a million mail > system managers. > > On the other hand, if you use one or two published drop lists, you can > afford to look at them and choose ones whose administrators are > competent, without having to individually vet each entry. Of course, I could also keep list of competent publishers of MX records. > R's, > John > ___ > 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] Lists "BCP" draft available
>> There's a fairly key difference you're missing here. For ADSP, each >> domain publishes what it thinks is its own policy, so if you look at a >> million domains, you have to guess about the competence of a million mail >> system managers. >> >> On the other hand, if you use one or two published drop lists, you can >> afford to look at them and choose ones whose administrators are >> competent, without having to individually vet each entry. > > Of course, I could also keep list of competent publishers of MX records. Indeed you could. And if the collateral damage from trying to use inept MX records were as bad as the damage from trying to use inept ADSP records, you probably would. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
>> Of course not. That's an example of the reason that I don't find ADSP >> useful (as opposed to manually vetted discard lists.) There's no way to >> tell whether the party publishing discardable understands what they're >> saying. >> > > And likewise there is no way to tell whether the party implementing discard > lists understand what they're doing. IMHO, we should stay away from assuming > the presence or absence of a given level of expertise of the mail admins on > this earth. There's a fairly key difference you're missing here. For ADSP, each domain publishes what it thinks is its own policy, so if you look at a million domains, you have to guess about the competence of a million mail system managers. On the other hand, if you use one or two published drop lists, you can afford to look at them and choose ones whose administrators are competent, without having to individually vet each entry. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 06/11/2010 10:49 PM, John R. Levine wrote: ... So if we clarify that the recommended practice is to "silently >>> discard" (as some have described it), won't we have solved this >>> particularly problematic work flow? >>> >>> You're right, then it just falls back to mail mysteriously disappearing. >>> >>> >> why can't the MLM send bounce back to sender's mail-from address? >> > The MLM can't tell the difference between a rejection due to the recipient > address being invalid and due to ADSP. Rejecting due to ADSP is probably > wrong due to the spec, but sending mail to a list from a domain publishing > ADSP discardable is definitely wrong, so apportion the blame as you wish. > > >> John's response seems to imply that it is sender's responsibility not to >> send to lists in first place (if they use discardable). But can we be sure >> this will happen? >> > Of course not. That's an example of the reason that I don't find ADSP > useful (as opposed to manually vetted discard lists.) There's no way to > tell whether the party publishing discardable understands what they're > saying. > And likewise there is no way to tell whether the party implementing discard lists understand what they're doing. IMHO, we should stay away from assuming the presence or absence of a given level of expertise of the mail admins on this earth. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> That's an example of the reason that I don't find ADSP > useful (as opposed to manually vetted discard lists.) There's no way to > tell whether the party publishing discardable understands what they're > saying. I'm sure that some people would like to put: theirdomain.com.3600IN A 0.0.0.0 in their zone file and still be reachable. This is and always was a specious argument. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
>>> ... So if we clarify that the recommended practice is to "silently >> discard" (as some have described it), won't we have solved this >> particularly problematic work flow? >> >> You're right, then it just falls back to mail mysteriously disappearing. >> > why can't the MLM send bounce back to sender's mail-from address? The MLM can't tell the difference between a rejection due to the recipient address being invalid and due to ADSP. Rejecting due to ADSP is probably wrong due to the spec, but sending mail to a list from a domain publishing ADSP discardable is definitely wrong, so apportion the blame as you wish. > John's response seems to imply that it is sender's responsibility not to > send to lists in first place (if they use discardable). But can we be sure > this will happen? Of course not. That's an example of the reason that I don't find ADSP useful (as opposed to manually vetted discard lists.) There's no way to tell whether the party publishing discardable understands what they're saying. > - Wouldn't we have same problem with forwarders? and I don't think sender > can predict whether mail will go thru forwarders DKIM is not SPF. It is uncommon for a forwarder to break a DKIM signature. We designed it that way. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> If I understand correctly, the only receivers that would reject/discard such > messages are "participating" receivers. Therefore I think it's reasonable > for us to expect participating receivers to follow our guidance in the > DKIM-LISTS BCP. So if we clarify that the recommended practice is to > "silently discard" (as some have described it), won't we have solved this > particularly problematic work flow? You're right, then it just falls back to mail mysteriously disappearing. Remember that the ADSP RFC specifically says not to say discardable if you send mail through lists. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
Hi Eliot, By ‘standards compliant’ there I actually mean ‘not non-compliant’, meaning there’s no basis on which to coerce MLMs to change their behavior. I can change to the “RFC5322.From” notation if necessary. The use of FBL in this context is in line with how the MARF working group is using it and also lines up with the discussion that got this whole recent effort started. Is there some other definition I should be aware of? I’ve extended 3.2 as you suggested. For 4.1, I’ll need to go over it again, unless you (or someone else) has some suggestions. I just looked at it and it seemed reasonable to me; it’s not hard for me to figure out which lists I’m on that are and aren’t MLM-aware. This document might even encourage MLM operators to announce this to their users at subscription time so they can be appropriately informed. For 5.1, I’ve changed it to “mail streams”, which is defined earlier in the document. For 5.2 and 5.4, I’ve added some clarifying text. Thanks for the thorough review! -MSK From: Eliot Lear [mailto:l...@cisco.com] Sent: Monday, May 17, 2010 4:36 AM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Lists "BCP" draft available Hi Murray, Thanks for taking a shot at this. Here are some comments on the Lists draft. First, I support the draft becoming a working group document. However, I wonder if it requires simplification with a bit more discussion as to motivation. I'll get into some of that below. Introduction 3rd and 4th bullets should use consistent terminology, so I suggest: s/mailing list/MLM/ Section 1.2 MLM behaviors are well-established and standards compliant. I don't understand what you mean by standards compliant. Same section lower down: However, the fact that the From field of such a message is typically the same as for the original message and that recipients perceive the message as "from" the original author rather than the MLM creates confusion about responsibility and autonomy for the re-posted message. Isn't there standard terminology to distinguish between the From and from (e.g., SMTP-From)? Section 1.3 FBL? What a horrible misuse of an already common term. Is there a cite for this or can we change it? Section 3.1 I *love* the title of this section!!! However- I believe we need to be careful to cite the source of these definitions, so as to avoid conflict should they change. Section 3.2 The remainder of this document operates on the presumption that a message going through a re-posting MLM actually comprises two message transactions s/re-posting/resending/ ? I think, by the way, that 3.2 should probably be expanded with regard to the logic behind steps 1 and 2. Seems to me that's the thing that will help mailing list maintainers understand why the solution is correct. Section 4.1. I'm uncomfortable with this section. I don't know how an author is supposed to know whether an MLM is a participant or non-participant. Moreover, discrimination at the enterprise level seems like a great opportunity for us vendors to sell more hardware without much customer benefit. I would rather see this section simply say that messages originating from ADMDs that have strict ADSP polices are advised to not make use of either non-participating MLMs that corrupt signatures. Section 5.1 Authors may be well-advised to create a DNS domain specifically used for generating signatures when sending traffic to MLMs I think you have to be really clear on this point, because it can be read in one of several ways: * Author domain should be used expressly to transmit to MLMs, in which case you should make it clear when this should be the case (e.g., you couldn't imagine an entire enterprise redoing their email infrastructure to such an end) * The SIGNING domain and NOT the author domain should be used expressly to transmit to MLMs, in which case we have a problem I mentioned above; * Something else Section 5.2: In the case of verification of signatures on subscriptions, MLMs are advised to add an [AUTH-RESULTS] header field to indicate the signature(s) observed on the submission as it arrived at the MLM and what the outcome of the evaluation was. What if any level of operational trust should be placed in such a header? Section 5.4 A DKIM-aware resending MLM is encouraged to sign the entire message as it arrived, especially including the original signatures. Would I as an MLM want to resign a message that I received that itself was not signed? Do I want to confer more authority to that message than is warranted? Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 25/05/2010 18:37, Ian Eiloart wrote: > No, and of course a site needn't reject ADSP mail with broken signatures. > Indeed, to protect it's members from unwanted unsubscriptions, it might be > better to drop the email than reject it. But, then the sender might never > discover what they're doing wrong. Worse, such a configuration would do collateral damage: other "broken ADSP" cases (forwarders which aren't mailing-lists in the sense that we're describing) would lead to silent message loss. > If the recipient rejects the message, > then the list should be able to bounce back to the sender, since it was > originally properly signed. > Ideally, but without a reliable indication by the receiver that the refusal was for DKIM failure, there's no easy way for the MLM to know which bounces to return to the sender. - Roland -- Roland Turner | Director, Professional Services Group BoxSentry Pte Ltd | 3 Phillip Street #13-03, Singapore 048693 Mobile: +65 96700022 | Skype: roland.turner roland.tur...@boxsentry.com | http://www.boxsentry.com/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 24, 2010, at 9:08 AM, John R. Levine wrote: >> I guess the list should be rejecting his email! Then, perhaps, his >> organisation would get around to deploying a non-discardable domain. > > I've suggested it. They know they have a problem, but they won't yet say > what they're going to do about it. > I'll be happy to report on our decision once we've implemented it. FWIW, I agree with the recommendations made on this list, at least in the short-term. Step one: was to start using anything that wasn't under an ADSP=discardable assertion (so here I am using a me.com account). Step two: is to do something along the lines of what's been recommended here (a non-discardable domain). Step three: fix the status quo for *participating* MLM's by offering up a new technical solution that enables MLM's to assert that they've validated the original sender's signature. > As you may recall, they suggested that lists sign an A-R header and all > recipient systems track what lists they're subscribed to and do > complicated processing to see whether list mail was signed when it showed > up at the list. That is a mischaracterization of what I proposed. What I actually proposed was: > On Apr 26, 2010, at 1:19 PM, McDowell, Brett wrote: > >> On Apr 26, 2010, at 10:05 AM, MH Michael Hammer (5304) wrote: >> >>> I think we are having the wrong discussion. The real question is: >>> >>> "What are appropriate practices for mailing lists in handling DKIM >>> signed mail?" >> >> Agreed. >> >> From my perspective, I'd like to enable (not mandate or expect universal >> compliance with) the deployment scenario where the sender's DKIM signature >> is either maintained without adulteration or "proxied" by the list so the >> transient trust can be carried through the mailing list intermediary to the >> destination (per Murray's note which I'm also going to respond to). That's >> my use case. By sharing this use case I'm not trying to deprecate or >> undermine John Levine's original use case. But there is a diversity of >> valid/appropriate behavior by mailing lists vis-a-vis DKIM that we need to >> consider (which is why I'm so pleased to see Mike H. take our discussion in >> this direction). >> >> -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
--On 24 May 2010 13:41:37 -0700 Steve Atkins wrote: > >> >> I think that's probably the most principled thing to do. >> >> For self-protection, there's also the option of NOT sending the message >> with a VERPed sender address. That would mean that a subsequent >> rejection should not count against the recipient. If the list is using >> some other mechanism to count rejections, then that mechanism should >> not be used. > > If the recipient is rejecting mail from the list, then the list should > stop attempting to send mail to that recipient. It should not try and > guess why the mail is no longer wanted. No, there are plenty of reasons that a recipient might reject *some* email from a list, but not the rest. For example, the recipient site might be more fussy about RFC compliance in the email. I've been unsubscribed from Yahoo lists because they relayed mail with ';' separating email addresses in sender headers. > > We really don't want people to use ADSP (or, much worse, DKIM) as > an excuse for not handling bounces nor for sending unwanted email. No, and of course a site needn't reject ADSP mail with broken signatures. Indeed, to protect it's members from unwanted unsubscriptions, it might be better to drop the email than reject it. But, then the sender might never discover what they're doing wrong. If the recipient rejects the message, then the list should be able to bounce back to the sender, since it was originally properly signed. >>... > Cheers, > Steve -- 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] Lists "BCP" draft available
--On 24 May 2010 14:33:13 -0700 Steve Atkins wrote: > > On May 24, 2010, at 2:28 PM, Murray S. Kucherawy wrote: > >>> -Original Message- >>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >>> boun...@mipassoc.org] On Behalf Of Steve Atkins >>> Sent: Monday, May 24, 2010 1:42 PM >>> To: DKIM List >>> Subject: Re: [ietf-dkim] Lists "BCP" draft available >>> >>>>> Not at all. If we can agree that lists should reject discardable >>> mail >>>>> out of self defense, that's a good point to add to the BCP. >>> >>> +1 >>> >>> Refusing signups from those domains is probably a bit extreme, though. >> >> What about a warning at signup time if a "discardable" ADSP record is >> found for the registrant's domain? > > Seems like a reasonable UX design to me but probably > more a choice for the developer than a BCP, I think. > > (I think that refusing signups from ADSP using domains > may also be a reasonable choice for the developer or list > admin in some cases. But not something to put in a BCP.) Why not? At least mention that it might be polite to make such a warning. After all, the person signing up might have no clue at all that their domain is 'discardable'. I guess we can't claim that it's common practice, never might best common practice. But it is, surely, a good idea. > Cheers, > Steve > ___ > 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] Lists "BCP" draft available
On May 24, 2010, at 5:27 AM, Ian Eiloart wrote: >> We have one concrete failure scenario, in which someone who publishes >> dkim=discardable sends mail to a MLM that as usual breaks the signature, >> a subscriber's mail system carefully follows the ADSP and rejects that >> mail, causing the subscriber to be bounced off the list. (This really >> happened, on an IETF list.) The advice is obvious a) put a shim in >> front of your MLM to reject discardable mail and b) the usual advice not >> to use ADSP at all, but it definitely needs publishing. > > The other piece of advice should be to actually discard, rather than > rejecting, discardable email. That would have protected the subscriber from > automatic unsubscription. The advice should be to discard the mail vs. bouncing it back to the MLM. That solves the use case of subscribers being auto-unsubscribed to mail lists without undermining all the other use cases that led the IETF to standardize ADSP in the first place. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 20, 2010, at 6:01 PM, McDowell, Brett wrote: > B) I'm going to re-subscribe to this (and all outside-the-firewall mailing > lists) with a personal email address to avoid the current situation (of my > messages going to SPAM or the bit bucket due to the firm ADSP=discardable > policy on paypal.com and MLM's inability to sustain DKIM signatures in a form > receivers need to see it in order to verify the paypal.comsignature). It's a > temporary work-around and we are developing a long-term solution for our > employees that I'll write about once it's live so other ADSP=discardable > organization can learn from our experience. This is just a quick follow-up to let folks know that I'll be using this personal account for public mail lists until we have addressed the "DKIM+ADSP=discardable breaks MLM's/MLM's break DKIM+ADSP=discardable" problem in a more systemic manner. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Steve Atkins > Sent: Monday, May 24, 2010 1:42 PM > To: DKIM List > Subject: Re: [ietf-dkim] Lists "BCP" draft available > > >> Not at all. If we can agree that lists should reject discardable > mail > >> out of self defense, that's a good point to add to the BCP. > > +1 > > Refusing signups from those domains is probably a bit extreme, though. What about a warning at signup time if a "discardable" ADSP record is found for the registrant's domain? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 5/24/10 1:41 PM, Steve Atkins wrote: > > On May 24, 2010, at 9:19 AM, Ian Eiloart wrote: > > > Not at all. If we can agree that lists should reject discardable > > mail out of self defense, that's a good point to add to the BCP. > > Refusing signups from those domains is probably a bit extreme, > though. Providing immediate feedback regarding a domain likely to cause recipients to miss their conversation should reduce the number of subsequent support issues. Otherwise, lost conversations will likely generate complaints requiring detailed analysis to resolve. Refusals for either "all" or "discardable" when the list is known to invalidate Author Domain signatures ensures list participants receive full conversations. > If the recipient is rejecting mail from the list, then the list > should stop attempting to send mail to that recipient. It should not > try and guess why the mail is no longer wanted. > > We really don't want people to use ADSP (or, much worse, DKIM) as an > excuse for not handling bounces nor for sending unwanted email. The "discardable" assertion does NOT mean a mailing list will see rejections. Only the "all" assertion ensures this level of feedback. This is why it remains important to have "all" refused whenever "discardable" is discarded. The concept of "discardable" was to offer just this type of excuse. -Doug > Cheers, Steve > > ___ 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] Lists "BCP" draft available
On May 24, 2010, at 2:28 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of Steve Atkins >> Sent: Monday, May 24, 2010 1:42 PM >> To: DKIM List >> Subject: Re: [ietf-dkim] Lists "BCP" draft available >> >>>> Not at all. If we can agree that lists should reject discardable >> mail >>>> out of self defense, that's a good point to add to the BCP. >> >> +1 >> >> Refusing signups from those domains is probably a bit extreme, though. > > What about a warning at signup time if a "discardable" ADSP record is found > for the registrant's domain? Seems like a reasonable UX design to me but probably more a choice for the developer than a BCP, I think. (I think that refusing signups from ADSP using domains may also be a reasonable choice for the developer or list admin in some cases. But not something to put in a BCP.) Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 24, 2010, at 9:19 AM, Ian Eiloart wrote: > > > --On 24 May 2010 10:36:46 -0400 "John R. Levine" wrote: > >>> I do recall. Perhaps if the list (and other lists) were rejecting the >>> mail, they'd be more likely to act. We don't have to wait for them, do >>> we? >> >> Not at all. If we can agree that lists should reject discardable mail >> out of self defense, that's a good point to add to the BCP. +1 Refusing signups from those domains is probably a bit extreme, though. >> > > I think that's probably the most principled thing to do. > > For self-protection, there's also the option of NOT sending the message > with a VERPed sender address. That would mean that a subsequent rejection > should not count against the recipient. If the list is using some other > mechanism to count rejections, then that mechanism should not be used. If the recipient is rejecting mail from the list, then the list should stop attempting to send mail to that recipient. It should not try and guess why the mail is no longer wanted. We really don't want people to use ADSP (or, much worse, DKIM) as an excuse for not handling bounces nor for sending unwanted email. > That option isn't so easy to deploy though, because it's performed after > the signature is broken. And, there's no point sending the message because > we can't expect that it will be delivered. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
Roland Turner wrote: >> > Surely the stance of a dkim=discardable sender is that it is absolutely > OK to discard affected messages if there is any reason at all for doubt > and that, therefore, "non-participant" MLMs aren't, actually, breaking > anything. There's some risk that what a list thinks might be unrecoverable is not. I guess I don't see it as being especially valuable to do anything heroic in the middle of the mail path (= forwarders) rather than letting it be done end to end (where end=delivery domain). The amount of traffic here is tiny, and asking MLM's to do just about anything is in reality asking for very fragmented adoption. So what's the use? Getting MLM's to resign actually does something useful because you can attach its reputation to the message. But adoption will be spotty for years to come even if it's in their advantage. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
--On 24 May 2010 10:36:46 -0400 "John R. Levine" wrote: >> I do recall. Perhaps if the list (and other lists) were rejecting the >> mail, they'd be more likely to act. We don't have to wait for them, do >> we? > > Not at all. If we can agree that lists should reject discardable mail > out of self defense, that's a good point to add to the BCP. > I think that's probably the most principled thing to do. For self-protection, there's also the option of NOT sending the message with a VERPed sender address. That would mean that a subsequent rejection should not count against the recipient. If the list is using some other mechanism to count rejections, then that mechanism should not be used. That option isn't so easy to deploy though, because it's performed after the signature is broken. And, there's no point sending the message because we can't expect that it will be delivered. -- 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] Lists "BCP" draft available
On 5/24/10 1:23 AM, Michael Deutschmann wrote: > On Sat, 22 May 2010, Dave Crocker wrote: > >> If there is a desire and need to have the semantic be "came from the >> mailing list" then there needs to be a mailing list equivalent to ADSP, >> which correlates a DKIM signature with the domain in a List-ID header >> field. >> > That's not necessary. > > The weakness of the "except-mlist" approach is not the difficulty of > authenticating that a given mail really is from the list it purports to be > from. We have off-the-shelf technology to do that: the list manager just > needs to use a constant MAIL FROM: domain, and protect that domain with > SPF. > The SPF element authorized is often poorly defined, whose resolution can induce a large number of transactions against any third-party domain. This is especially true when attempts search for the possible element. Some now use SPF to signal reverse DNS PTR records having a defined label, which suggests cooperation among the 40,000 IP address owners. However, deployment of IPv6 will cause SPF and reverse DNS to become vast and difficult to manage. See: http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03 This scheme provides a LDSP type of third-party authorization where an "L" flag signals a required list-id (see: RFC2919). This scheme could even be extended to produce a policy similar to "except-mlist" along with an ability to make exceptions. If a BCP recommends "discardable" be discarded by mailing lists, it should also recommend "all" be rejected as well. Neither "all" nor "discardable" produces a compliant message when the Author Domain signature is invalidated. (A flag added to DKIM signatures to signal the presence of TPA policies.) > It requires some cooperation from the list owner, but so would "LDSP". > The TPA scheme does not require cooperation of list owners! > Rather, the weakness of "except-mlist" is that it requires that the MX > know which mailing lists each mailbox is legitimately subscribed to. > Without that, the badguys can pretend the victim subscribes to lists they > control. > The TPA scheme requires those seeking policy protections to provide the relationships for MX handling. The "except-mlist" approach places the burden upon the MX to know which mailing lists are safe. Unlike the TPA scheme, the "except-mlist" will not allow author domains a means to mitigate ongoing exploitation. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> I do recall. Perhaps if the list (and other lists) were rejecting the mail, > they'd be more likely to act. We don't have to wait for them, do we? Not at all. If we can agree that lists should reject discardable mail out of self defense, that's a good point to add to the BCP. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
--On 24 May 2010 09:08:42 -0400 "John R. Levine" wrote: >> I guess the list should be rejecting his email! Then, perhaps, his >> organisation would get around to deploying a non-discardable domain. > > I've suggested it. They know they have a problem, but they won't yet say > what they're going to do about it. > > As you may recall, they suggested that lists sign an A-R header and all > recipient systems track what lists they're subscribed to and do > complicated processing to see whether list mail was signed when it showed > up at the list. Oddly, that didn't get much traction. > > R's, > John I do recall. Perhaps if the list (and other lists) were rejecting the mail, they'd be more likely to act. We don't have to wait for them, do we? -- 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] Lists "BCP" draft available
> I guess the list should be rejecting his email! Then, perhaps, his > organisation would get around to deploying a non-discardable domain. I've suggested it. They know they have a problem, but they won't yet say what they're going to do about it. As you may recall, they suggested that lists sign an A-R header and all recipient systems track what lists they're subscribed to and do complicated processing to see whether list mail was signed when it showed up at the list. Oddly, that didn't get much traction. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
--On 23 May 2010 12:35:48 -0400 "John R. Levine" wrote: >> There may yet be a grey area for very sophisticated or experimental MLMs >> (like "Hmm... SpamAssassin medium score; maybe let it through but don't >> sign"), but then they don't need a BCP; we need them to publish the >> results of the experiment ;-) > > Quite right, and as always, the ASRG stands ready if someone wants to do > some, you know, research. > >> The only thing that leaves are non-participant MLMs and there really >> isn't much to be done with them. > > We have one concrete failure scenario, in which someone who publishes > dkim=discardable sends mail to a MLM that as usual breaks the signature, > a subscriber's mail system carefully follows the ADSP and rejects that > mail, causing the subscriber to be bounced off the list. (This really > happened, on an IETF list.) The advice is obvious a) put a shim in > front of your MLM to reject discardable mail and b) the usual advice not > to use ADSP at all, but it definitely needs publishing. The other piece of advice should be to actually discard, rather than rejecting, discardable email. That would have protected the subscriber from automatic unsubscription. > I'm surprised we haven't seen that problem on this list, since we have at > least one subscriber whose domain publishes dkim=discardable. I keep > having to fish his mail out of the spam folder. I guess the list should be rejecting his email! Then, perhaps, his organisation would get around to deploying a non-discardable domain. > R's, > John > ___ > 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] Lists "BCP" draft available
--On 23 May 2010 15:24:51 +0200 Eliot Lear wrote: > Hi Dave & John, > > I read both of you as actually agreeing in principle. My issue was > whether a signature would confer more authority upon a message than > perhaps it deserved, and how would an MLM behave in terms of its > incentives. In thinking about this, I'd have to say that you're both > right, that either the MLM is taking responsibility for the message or > it is not. There may yet be a grey area for very sophisticated or > experimental MLMs (like "Hmm... SpamAssassin medium score; maybe let it > through but don't sign"), I don't see the value of that. By forwarding the mail, they are -in practice- taking responsibility. By signing it, they're simply telling the world that they've done so. I'd think it dishonest of a list manager to do this kind of selective signing. > but then they don't need a BCP; we need them > to publish the results of the experiment ;-) > > The only thing that leaves are non-participant MLMs and there really > isn't much to be done with them. > > Eliot > > On 5/22/10 7:50 PM, Dave CROCKER wrote: >> >> On 5/17/2010 10:08 PM, John Levine wrote: >>> The signature means that this message really truly >>> came from the mailing list >> >> Actually, DKIM makes no statement about authorship or even actors in the >> handling sequence. It merely says that that verified domain is willing >> to take "some" responsibility for the message. >> >> The more we slip into loose references to authorship or operational >> origins, the more we wind up having to dig ourselves out of semantic >> mismatches later. >> >> If there is a desire and need to have the semantic be "came from the >> mailing list" then there needs to be a mailing list equivalent to ADSP, >> which correlates a DKIM signature with the domain in a List-ID header >> field. >> >> >> d/ > ___ > 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] Lists "BCP" draft available
On Sat, 22 May 2010, Dave Crocker wrote: > If there is a desire and need to have the semantic be "came from the > mailing list" then there needs to be a mailing list equivalent to ADSP, > which correlates a DKIM signature with the domain in a List-ID header > field. That's not necessary. The weakness of the "except-mlist" approach is not the difficulty of authenticating that a given mail really is from the list it purports to be from. We have off-the-shelf technology to do that: the list manager just needs to use a constant MAIL FROM: domain, and protect that domain with SPF. It requires some cooperation from the list owner, but so would "LDSP". Only if you have irrational Not Invented Here sentiments towards SPF does LDSP become needed. The SPF approach has the advantage that some lists are already in compliance, by accident. Rather, the weakness of "except-mlist" is that it requires that the MX know which mailing lists each mailbox is legitimately subscribed to. Without that, the badguys can pretend the victim subscribes to lists they control. Now, people keep arguing that "except-mlist" is pointless because no regular ISP is so well informed about its own users. But vanity domains like mine *do have the needed intelligence*. The only further knowledge they need, is which sites are publishing "unknown" because they don't sign everything yet, and which sites are publishing "unknown" solely because of the mailing list problem. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 24/05/2010 00:35, John R. Levine wrote: > >> The only thing that leaves are non-participant MLMs and there really isn't >> much to be done with them. >> > We have one concrete failure scenario, in which someone who publishes > dkim=discardable sends mail to a MLM that as usual breaks the signature, a > subscriber's mail system carefully follows the ADSP and rejects that mail, > causing the subscriber to be bounced off the list. (This really happened, > on an IETF list.) The advice is obvious a) put a shim in front of your > MLM to reject discardable mail and b) the usual advice not to use ADSP at > all, but it definitely needs publishing. > > I'm surprised we haven't seen that problem on this list, since we have at > least one subscriber whose domain publishes dkim=discardable. I keep > having to fish his mail out of the spam folder. > Surely the stance of a dkim=discardable sender is that it is absolutely OK to discard affected messages if there is any reason at all for doubt and that, therefore, "non-participant" MLMs aren't, actually, breaking anything. - Roland ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> There may yet be a grey area for very sophisticated or experimental MLMs > (like "Hmm... SpamAssassin medium score; maybe let it through but don't > sign"), but then they don't need a BCP; we need them to publish the > results of the experiment ;-) Quite right, and as always, the ASRG stands ready if someone wants to do some, you know, research. > The only thing that leaves are non-participant MLMs and there really isn't > much to be done with them. We have one concrete failure scenario, in which someone who publishes dkim=discardable sends mail to a MLM that as usual breaks the signature, a subscriber's mail system carefully follows the ADSP and rejects that mail, causing the subscriber to be bounced off the list. (This really happened, on an IETF list.) The advice is obvious a) put a shim in front of your MLM to reject discardable mail and b) the usual advice not to use ADSP at all, but it definitely needs publishing. I'm surprised we haven't seen that problem on this list, since we have at least one subscriber whose domain publishes dkim=discardable. I keep having to fish his mail out of the spam folder. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
Hi Dave & John, I read both of you as actually agreeing in principle. My issue was whether a signature would confer more authority upon a message than perhaps it deserved, and how would an MLM behave in terms of its incentives. In thinking about this, I'd have to say that you're both right, that either the MLM is taking responsibility for the message or it is not. There may yet be a grey area for very sophisticated or experimental MLMs (like "Hmm... SpamAssassin medium score; maybe let it through but don't sign"), but then they don't need a BCP; we need them to publish the results of the experiment ;-) The only thing that leaves are non-participant MLMs and there really isn't much to be done with them. Eliot On 5/22/10 7:50 PM, Dave CROCKER wrote: > > On 5/17/2010 10:08 PM, John Levine wrote: >> The signature means that this message really truly >> came from the mailing list > > Actually, DKIM makes no statement about authorship or even actors in the > handling sequence. It merely says that that verified domain is willing to > take > "some" responsibility for the message. > > The more we slip into loose references to authorship or operational origins, > the > more we wind up having to dig ourselves out of semantic mismatches later. > > If there is a desire and need to have the semantic be "came from the mailing > list" then there needs to be a mailing list equivalent to ADSP, which > correlates > a DKIM signature with the domain in a List-ID header field. > > > d/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
Dave CROCKER wrote: > > If there is a desire and need to have the semantic be "came from the mailing > list" then there needs to be a mailing list equivalent to ADSP, which > correlates > a DKIM signature with the domain in a List-ID header field. +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 5/17/2010 10:08 PM, John Levine wrote: >The signature means that this message really truly > came from the mailing list Actually, DKIM makes no statement about authorship or even actors in the handling sequence. It merely says that that verified domain is willing to take "some" responsibility for the message. The more we slip into loose references to authorship or operational origins, the more we wind up having to dig ourselves out of semantic mismatches later. If there is a desire and need to have the semantic be "came from the mailing list" then there needs to be a mailing list equivalent to ADSP, which correlates a DKIM signature with the domain in a List-ID header field. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 5/20/2010 11:42 AM, MH Michael Hammer (5304) wrote: >> From: John Levine [mailto:jo...@iecc.com] >> Entirely agreed. As this point the only concrete datum I'm aware of >> is that ADSP has been observed to break IETF mailing lists. I would >> want to see a lot more practical as opposed to hypothetical experience >> before offering further advice. >> > > That's ironic, I heard it the other way around that many mailing > lists break DKIM signatures and thus ADSP. go figure. Well, I think both perspectives are valid and useful. The "list breaks adsp" is perhaps the more intuitive view. On the other hand, the purpose of a mailing list is to get a message delivered to a set of recipients. An ADSP record for a subscriber will break their ability to get that mailing list message, which can reasonably be viewed as breaking the mailing list... When talking about tradeoffs, this sort of inverted perspective can be quite helpful in understanding implications. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 20/May/10 13:25, Michael Deutschmann wrote: > 1. Must relay message verbatim. No subject tags, disclaimers, or "how > to unsubscribe" footers. But new headers above the DKIM signature can > be ok. If MLM software were smart enough to avoid adding subject tags and footers in case they are already present, then the list manager could ask subscribers who sport incompatible ADSP policies to carefully submit their posts, so that list processing won't break their author domain signatures. > 2. Must only accept mails that pass DKIM/ADSP validation, again treating > "all" as my "rejectable". Yes, reject so that inattentive posters have a chance to amend their messages as required. This second option seems simple enough to me. -- ___ 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] Lists "BCP" draft available
On May 20, 2010, at 10:09 AM, MH Michael Hammer (5304) wrote: > If Brett or anyone else has data points that would impact the decision > as to whether the group sticks to a Lists BCP discussion based on > current practice/implementations or sets that aside to modify ADSP, now > is the time to present it. A) I hear you and I'm working on making some confidential data publicly available for the first time. It's more than a notion to achieve, but I'm working on it. But if folks don't trust my anecdotal evidence/use case, why would they trust my data? B) I'm going to re-subscribe to this (and all outside-the-firewall mailing lists) with a personal email address to avoid the current situation (of my messages going to SPAM or the bit bucket due to the firm ADSP=discardable policy on paypal.com and MLM's inability to sustain DKIM signatures in a form receivers need to see it in order to verify the paypal.com signature). It's a temporary work-around and we are developing a long-term solution for our employees that I'll write about once it's live so other ADSP=discardable organization can learn from our experience. C) I don't know if this list is the right place to discuss updating/expanding ADSP, but it is absolutely related and important in the big picture. That said, I agree the BCP for MLM's is separate and needs to be published for the world as it is today, or it won't be published for quite some time. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 5/20/10 11:22 AM, John Levine wrote: > > From my perspective, it would have to be very compelling for me to > >> support modifying ADSP at this point. ADSP is the DKIM tail and not >> vice a versa. >> > Entirely agreed. As this point the only concrete datum I'm aware of > is that ADSP has been observed to break IETF mailing lists. I would > want to see a lot more practical as opposed to hypothetical experience > before offering further advice. > John, Your advise is generally good, but not in respect to "all". Rather than weakening MTA acceptance barriers imposed by DKIM+ADSP "all" or "discardable", these barriers need strengthening. ADSP "all" is intended to mitigate the significant harm caused by phishing. It is not reasonable to expect recipients will know whether a message contains a mailing list related headers that might defeat ADSP protections. ADSP "all" or "discardable" offers email service providers a clear basis to not deliver non-compliant messages. Email service providers should ensure strict ADSP compliance. While resorting to "discardable" might increase the number of non-complaint messages blocked, this is at the expense of delivery integrity, which "all" was to avoid. To achieve greater compliance with "all" or "discardable", a legal imperative seems needed. The "except-mlist" assertion offers potentially deceptive results, where the author domain needs to make explicit exceptions. An ADSP "copyrighted" assertion along with an Author Domain Signature that includes a "(copyright)" comment should allow injured domains a means to seek expeditious compliance. By creating a potential for needing to respond, email service providers would then likely become proactive and strictly adhere to ADSP assertions. Those wanting to participate on mailing list would then need to use alternative domains, where perhaps the list subscription could ask about their desired ADSP compliance, with a checkbox or command "as currently signed". -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> -Original Message- > From: John Levine [mailto:jo...@iecc.com] > Sent: Thursday, May 20, 2010 2:23 PM > To: ietf-dkim@mipassoc.org > Cc: MH Michael Hammer (5304) > Subject: Re: [ietf-dkim] Lists "BCP" draft available > > >From my perspective, it would have to be very compelling for me to > >support modifying ADSP at this point. ADSP is the DKIM tail and not > >vice a versa. > > Entirely agreed. As this point the only concrete datum I'm aware of > is that ADSP has been observed to break IETF mailing lists. I would > want to see a lot more practical as opposed to hypothetical experience > before offering further advice. > That's ironic, I heard it the other way around that many mailing lists break DKIM signatures and thus ADSP. go figure . Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
>From my perspective, it would have to be very compelling for me to >support modifying ADSP at this point. ADSP is the DKIM tail and not >vice a versa. Entirely agreed. As this point the only concrete datum I'm aware of is that ADSP has been observed to break IETF mailing lists. I would want to see a lot more practical as opposed to hypothetical experience before offering further advice. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Michael Thomas > Sent: Wednesday, May 19, 2010 5:29 PM > To: J.D. Falk > Cc: DKIM List > Subject: Re: [ietf-dkim] Lists "BCP" draft available > > On 05/19/2010 02:21 PM, J.D. Falk wrote: > > On May 19, 2010, at 7:53 AM, MH Michael Hammer (5304) wrote: > > > >> +1. The current discussion was supposed to be about BCP. I agree with > >> Stephen with the caveat that if the group thinks re-opening ADSP > >> discussion is important then include it in the re-charter. Personally > >> I'd like to wait until we hear some numbers about ADSP deployment and > >> experience. > > > > +1 > > Doesn't that sort of undermine the impetus to do a BCP on lists? > Most of the sticky questions about lists are intertwined with ADSP, > as evidenced by the recent messages here from paypal folks. > > Mike Let me clarify my statements. My point was that re-opening ADSP was not part of the re-charter so unless the group feels it is important to change ADSP we should stick to discussing the Lists BCP based on the way that DKIM and ADSP are currently written. If Brett or anyone else has data points that would impact the decision as to whether the group sticks to a Lists BCP discussion based on current practice/implementations or sets that aside to modify ADSP, now is the time to present it. >From my perspective, it would have to be very compelling for me to support modifying ADSP at this point. ADSP is the DKIM tail and not vice a versa. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On Wed, 19 May 2010, MH Michael Hammer wrote: > +1. The current discussion was supposed to be about BCP. I agree with > Stephen with the caveat that if the group thinks re-opening ADSP > discussion is important then include it in the re-charter. Personally > I'd like to wait until we hear some numbers about ADSP deployment and > experience. Well, if RFC 5617 (current official ADSP) is to be regarded as engraved in stone, writing a list BCP seems trivial to me: There's just two options: 1. Must take ownership of the header From: -- change it to something in the list operator's domain. 2. Should DKIM-sign the outgoing message. 3. Should only accept mails that pass DKIM/ADSP validation, treating "all" as what I call "rejectable". (List input mailboxes don't need to worry about whether "all" means "rejectable" or "except-mlist", because lists don't subscribe to lists). Or: 1. Must relay message verbatim. No subject tags, disclaimers, or "how to unsubscribe" footers. But new headers above the DKIM signature can be ok. 2. Must only accept mails that pass DKIM/ADSP validation, again treating "all" as my "rejectable". After selecting an alternative, breaking any of its musts will risk mails getting blocked, so long as anyone publishes dkim=all (regardless of what they *mean*), and anyone interprets dkim=all as my "rejectable". Neither sounds that palatable to list operators. Which one is mipassoc.org going to use? Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 05/19/2010 02:35 PM, J.D. Falk wrote: > On May 19, 2010, at 3:29 PM, Michael Thomas wrote: > >> On 05/19/2010 02:21 PM, J.D. Falk wrote: >>> On May 19, 2010, at 7:53 AM, MH Michael Hammer (5304) wrote: >>> +1. The current discussion was supposed to be about BCP. I agree with Stephen with the caveat that if the group thinks re-opening ADSP discussion is important then include it in the re-charter. Personally I'd like to wait until we hear some numbers about ADSP deployment and experience. >>> >>> +1 >> >> Doesn't that sort of undermine the impetus to do a BCP on lists? >> Most of the sticky questions about lists are intertwined with ADSP, >> as evidenced by the recent messages here from paypal folks. > > If writing the BCP reveals situations where ADSP makes DKIM difficult for > mailing lists, let's document it so that a future effort can work on fixing > it. We shouldn't be trying to fix it within the BCP effort. > I'm not suggesting we fix anything, I just find it odd the juxtaposition of "no adsp experience" with "Let's do a BCP about lists". ADSP experience is a pretty important component for the "common practices" part of BCP because it's the source of lots of conflict, and we frankly don't have any common practices, best or otherwise. It seems that this would be a whole lot more interesting if the paypal folks could give a report about their experience with the way they're dealing with this when they're ready. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 05/19/2010 02:21 PM, J.D. Falk wrote: > On May 19, 2010, at 7:53 AM, MH Michael Hammer (5304) wrote: > >> +1. The current discussion was supposed to be about BCP. I agree with >> Stephen with the caveat that if the group thinks re-opening ADSP >> discussion is important then include it in the re-charter. Personally >> I'd like to wait until we hear some numbers about ADSP deployment and >> experience. > > +1 Doesn't that sort of undermine the impetus to do a BCP on lists? Most of the sticky questions about lists are intertwined with ADSP, as evidenced by the recent messages here from paypal folks. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of J.D. Falk > Sent: Wednesday, May 19, 2010 2:22 PM > To: DKIM List > Subject: Re: [ietf-dkim] Lists "BCP" draft available > > On May 19, 2010, at 7:53 AM, MH Michael Hammer (5304) wrote: > > > +1. The current discussion was supposed to be about BCP. I agree with > > Stephen with the caveat that if the group thinks re-opening ADSP > > discussion is important then include it in the re-charter. Personally > > I'd like to wait until we hear some numbers about ADSP deployment and > > experience. > > +1 +1. (Or at least change the Subject: field!) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 19, 2010, at 3:29 PM, Michael Thomas wrote: > On 05/19/2010 02:21 PM, J.D. Falk wrote: >> On May 19, 2010, at 7:53 AM, MH Michael Hammer (5304) wrote: >> >>> +1. The current discussion was supposed to be about BCP. I agree with >>> Stephen with the caveat that if the group thinks re-opening ADSP >>> discussion is important then include it in the re-charter. Personally >>> I'd like to wait until we hear some numbers about ADSP deployment and >>> experience. >> >> +1 > > Doesn't that sort of undermine the impetus to do a BCP on lists? > Most of the sticky questions about lists are intertwined with ADSP, > as evidenced by the recent messages here from paypal folks. If writing the BCP reveals situations where ADSP makes DKIM difficult for mailing lists, let's document it so that a future effort can work on fixing it. We shouldn't be trying to fix it within the BCP effort. -- J.D. Falk Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 19, 2010, at 7:53 AM, MH Michael Hammer (5304) wrote: > +1. The current discussion was supposed to be about BCP. I agree with > Stephen with the caveat that if the group thinks re-opening ADSP > discussion is important then include it in the re-charter. Personally > I'd like to wait until we hear some numbers about ADSP deployment and > experience. +1 -- J.D. Falk Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Stephen Farrell > Sent: Tuesday, May 18, 2010 8:28 PM > To: Michael Deutschmann; Douglas Otis > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Lists "BCP" draft available > > > That doesn't seem to be about mailing lists. > > I don't see that we're re-opening ADSP now and we're not > chartered for that, so I don't really see much point in > this discussion. > > So perhaps take that discussion offlist? > > Stephen. > +1. The current discussion was supposed to be about BCP. I agree with Stephen with the caveat that if the group thinks re-opening ADSP discussion is important then include it in the re-charter. Personally I'd like to wait until we hear some numbers about ADSP deployment and experience. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 19 May 2010, John Levine wrote: > If you already know what lists you're subscribed to, why would you do > anything other than accept all the mail from the lists? True, vanity domains likely won't bother to treat "rejectable" differently than "except-mlist". The only difference is in a case that shouldn't happen. But the advantage of "except-mlist" to vanity domains is that *many* more senders are eligible to publish it. They would otherwise use "unknown". With the status quo, vanity domains can only protect themselves from forgeries of: 1. The minority of senders who truly send to no mailing lists 2. Senders who recklessly assume that "all" is universally treated as "except-mlist" Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On Wed, 19 May 2010 03:52:01 +0100, John Levine wrote: >> 1. "except-mlist" is primarily for the benefit of vanity domain >> recipients who have programmed their MTA with knowledge of exactly which >> lists they are subscribed to. > > If you already know what lists you're subscribed to, why would you do > anything other than accept all the mail from the lists? And conversely reject everything from lists you are not subscribed to (which will likely include the ones invented or appropriated by the Bad Guys). My MUA detects and displays separately all mailing list message (by the presence of List-* headers). If an unfamiliar mailing list shows up (as occasionally happens), it sticks out like a sore thumb. -- 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] Lists "BCP" draft available
On 18/May/10 19:16, John R. Levine wrote: >> It'll be the one that's not broken, I presume. If there's more than one >> unbroken signature, I guess the signing domain might want to match the >> list-id header. Unfortunately, that header does not make a net distinction between the list-label and the domain-name. Perhaps, the list-label could be made explicit using the local part of the "i=" tag (RFC 5672 exemplifies a "mailing list manager" for this datum.) > Why is it important to match signatures? If there's a valid signature > with a good rep, deliver the mail. If the mail turns out to be nasty, > decrease the rep of all of the valid signatures. Why make this more > complicated than it needs to be? To recommend any special treatment for mailing lists --e.g. tweaking FBL routes-- we should also say how a verifier can recognize a list message when it sees one. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
>1. "except-mlist" is primarily for the benefit of vanity domain >recipients who have programmed their MTA with knowledge of exactly which >lists they are subscribed to. If you already know what lists you're subscribed to, why would you do anything other than accept all the mail from the lists? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
That doesn't seem to be about mailing lists. I don't see that we're re-opening ADSP now and we're not chartered for that, so I don't really see much point in this discussion. So perhaps take that discussion offlist? Stephen. On 05/19/2010 01:18 AM, Michael Deutschmann wrote: > On Tue, 18 May 2010, Douglas Otis wrote: >> Why would you see "rejectable" as being different from "all" assertions? > > Just about everyone thinks EITHER that "rejectable" would be redundant > with "all", OR ... ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 5/18/10 5:28 PM, Stephen Farrell wrote: > That doesn't seem to be about mailing lists. > > I don't see that we're re-opening ADSP now and we're not > chartered for that, so I don't really see much point in > this discussion. > > So perhaps take that discussion offlist? > Stephen, Deprecating "all" to "except-mlist" and "rejectable" is about dealing with message state changed by mailing lists. Without this state change, there would not be an issue. IMHO, the suggestion for changing ADSP assertions does not resolve the uncertainty, but instead creates risks related to mailing list operation, when they then become exploitation targets. Perhaps John and Michael are right, and people need explicit instruction. Nevertheless, these instructions should not be spelled out in ADSP assertion mnemonics. That is the purpose of the RFC being discussed. I agree, the chartered work is not aimed at changing the spelling of ADSP assertions, but instead at explaining how they are best used. A rose by any other name would still smell as sweet. P.S. It turned out leaving Ireland was not as hoped. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On Tue, 18 May 2010, Douglas Otis wrote: > Why would you see "rejectable" as being different from "all" assertions? Just about everyone thinks EITHER that "rejectable" would be redundant with "all", OR that "except-mlist" would be redundant with "all". But narrowing "all"'s meaning down to two choices is not an agreement. This ambiguity is paralysing deployment - a conservative sender who means "except-mlist" must publish "unknown", and a conservative receiver who sees "all" must read it as "except-mlist" (and thus as "unknown" in most cases due to ignorance of local users' subscriptions.). Rather than try to settle the fight over what "all" means, let's just deprecate it and give each camp their own, *unambiguous* flag. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 5/18/10 1:46 PM, Michael Deutschmann wrote: > On 18 May 2010, John Levine wrote: > >>> If I were in charge, I'd retire "all", to be replaced with two new >>> options with clearer semantics. One would be the "except-mlist" I >>> proposed a few months back. >>> >> I don't understand what verifiers are supposed to do with that. How >> is an MTA doing the DKIM verification and filtering supposed know >> what's a mailing list and what's not? If I were a bad guy, I'd put >> fake headers on my spam to make it look like a list mail. >> > 1. "except-mlist" is primarily for the benefit of vanity domain > recipients who have programmed their MTA with knowledge of exactly which > lists they are subscribed to. Just guessing which list to forge is a big > hurdle for the bad guys. > > *I* recognize friendly mailing lists by their MAIL FROM: domains, which > means SPF will also be an obstacle to such forgers. > The ADSP effort started by agreeing not to dictate how messages are to be handled, and to assume administrators are able to take correct actions. The assertion "discardable" muddled an expectation of competence, where some now suggest "all" lacking a valid Author Domain signature does not empower "rejection". MTAs are to ignore invalid Author-Domain signatures with "except-mlist" assertions. Vanity, or otherwise, it is not difficult to defeat SPF, to find mailing-lists offering one-time access, or to create messages appearing to be from some mailing-list where the message lands in the inbox. > But yes, big ISPs that know no details about their users have to treat > "except-mlist" as "unknown". > Agreed, and "except-mlist" declares open season on mailing-lists, and perhaps any message that has ever touched one. > But they still gain, because they will know > everyone who publishes "rejectable" really means it. All messages are "rejectable", especially when "all" assertions lack Author Domain Signatures. Why would you see "rejectable" as being different from "all" assertions? There is no ADSP assertion that makes it clear which messages are _really_ from mailing lists. > 2. As I touched on in a parenthetical at the end of the message, mail heading > to a mailing list *input* can be processed as if "except-mlist" was > "rejectable". Lists don't subscribe to other lists. > How would this be any different from recommending mailing-lists to reject ADSP "all" assertion lacking a valid Author-Domain signature? A recommendation might also suggest tolerance be given mailing lists. A better alternative would be to use a third-party authorization mechanisms to curtail exploits caused by the knowledge gap. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 18 May 2010, John Levine wrote: > >If I were in charge, I'd retire "all", to be replaced with two new > >options with clearer semantics. One would be the "except-mlist" I > >proposed a few months back. > > I don't understand what verifiers are supposed to do with that. How > is an MTA doing the DKIM verification and filtering supposed know > what's a mailing list and what's not? If I were a bad guy, I'd put > fake headers on my spam to make it look like a list mail. 1. "except-mlist" is primarily for the benefit of vanity domain recipients who have programmed their MTA with knowledge of exactly which lists they are subscribed to. Just guessing which list to forge is a big hurdle for the bad guys. *I* recognize friendly mailing lists by their MAIL FROM: domains, which means SPF will also be an obstacle to such forgers. But yes, big ISPs that know no details about their users have to treat "except-mlist" as "unknown". But they still gain, because they will know everyone who publishes "rejectable" really means it. 2. As I touched on in a parenthetical at the end of the message, mail heading to a mailing list *input* can be processed as if "except-mlist" was "rejectable". Lists don't subscribe to other lists. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 17, 2010, at 11:08 PM, John Levine wrote: > I like Murray's draft, and I hope that we can resist the urge to add > vast amounts of non-productive complication to it. +1 Likewise, I hope that we can resist the urge to re-argue all the old arguments about ADSP. This BCP won't fix those issues, but it might clarify 'em somewhat. -- J.D. Falk Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 5/18/10 10:16 AM, John R. Levine wrote: >> It'll be the one that's not broken, I presume. If there's more than one >> unbroken signature, I guess the signing domain might want to match the >> list-id header. >> > Why is it important to match signatures? If there's a valid signature > with a good rep, deliver the mail. If the mail turns out to be nasty, > decrease the rep of all of the valid signatures. Why make this more > complicated than it needs to be? > Signed messages might be replayed in a spam campaign. Many copies of a signature's hash would be normal for mailing lists. When a mailing-list signature provides greater acceptance, wouldn't this lead to mailing lists being exploited? How should new signatures be handled? If your wish for ADSP "except-mlist" is granted, how would a domain's recipients protect themselves exploits or spoofs of mailing lists? Perhaps there should also be "except-signed-mlist"? Wouldn't a non-specific mailing list exception lead to mailing list being targeted? Why can't "all" represent "reject" as you described? Is your concern that "all" creates an obligation for mailing list to either reject or bounce messages lacking valid Author Domain signatures? How many MTAs check DKIM signatures during the SMTP session? How many invalid signatures would normally seen by mailing-lists? -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
--On 18 May 2010 14:55:14 +0200 Alessandro Vesely wrote: > On 18/May/10 07:08, John Levine wrote: A DKIM-aware resending MLM is encouraged to sign the entire message as it arrived, especially including the original signatures. >>> >>> Would I as an MLM want to resign a message that I received that itself >>> was not signed? Do I want to confer more authority to that message than >>> is warranted? >> >> Yes, of course. The signature means that this message really truly >> came from the mailing list, as opposed to being a random piece of spam >> that happened to resemble list mail. > > +1. However, may I ask how does the verifier know which signature is > the one that belongs to the list? I can think of > > * look at the MAIL FROM domain, à la SPF (breaks forwarding), > * have the list's domain in a white list (requires maintenance), > * use some of the "List-*" fields (which one?) It'll be the one that's not broken, I presume. If there's more than one unbroken signature, I guess the signing domain might want to match the list-id header. > Apparently, section 5.4 doesn't cover this point. > ___ > 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] Lists "BCP" draft available
> It'll be the one that's not broken, I presume. If there's more than one > unbroken signature, I guess the signing domain might want to match the > list-id header. Why is it important to match signatures? If there's a valid signature with a good rep, deliver the mail. If the mail turns out to be nasty, decrease the rep of all of the valid signatures. Why make this more complicated than it needs to be? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
>If I were in charge, I'd retire "all", to be replaced with two new >options with clearer semantics. One would be the "except-mlist" I >proposed a few months back. I don't understand what verifiers are supposed to do with that. How is an MTA doing the DKIM verification and filtering supposed know what's a mailing list and what's not? If I were a bad guy, I'd put fake headers on my spam to make it look like a list mail. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 18 May 2010, John Levine wrote: > Agreed. We have no idea what "all" means in practice, other than perhaps > an ill-defined small decrement to some sort of reputation if the signature > isn't present. If I were in charge, I'd retire "all", to be replaced with two new options with clearer semantics. One would be the "except-mlist" I proposed a few months back. The other would be "rejectable". "rejectable" would indicate that all missing/bogus signature mail is to be rejected -- the reciever is not to worry about the possibility that the message went through a mailing list. "rejectable" would differ from "discardable" only in the case of a validator that has no ability to reject in-transaction. The most obvious case would be a DKIM-checking plugin for an MUA using POP3 with a DKIM-unaware ISP. "discardable" would tell the MUA that it is ok to simply drop invalid messages. "rejectable" would indicate that, should it be impossible to send the problem message backwards, it is better to let it go forward to the end user than to blackhole it. "discardable" would be the choice for those paranoid about phishing in their name. "rejectable" would be for those who are eligible to use "discardable", but prefer not to risk mail *silently* disappearing should a bug cause the signature to appear bad to some receivers. Sending a bounce message would comply with the spirit of rejectable, but that is not wise in general as the internet is beginning to punish backscatter. Unless the problem message's MAIL FROM: is independently proved valid (eg: by SPF), discarding or delivery are the only choices a late-acting validator has. (One note referencing things upthread: Back when I proposed "except-mlist", most objections were on the basis that there is no *automatic* way for the reciever to implement it differently from "unknown"; only vanity-domain recipients can benefit. But it would be correct for a mailing list input mailserver to treat "except-mlist" as "rejectable", since lists don't mail to each other.) Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 18/May/10 07:08, John Levine wrote: >>> A DKIM-aware resending MLM is encouraged to sign the entire message >>> as it arrived, especially including the original signatures. >> >>Would I as an MLM want to resign a message that I received that itself >>was not signed? Do I want to confer more authority to that message than >>is warranted? > > Yes, of course. The signature means that this message really truly > came from the mailing list, as opposed to being a random piece of spam > that happened to resemble list mail. +1. However, may I ask how does the verifier know which signature is the one that belongs to the list? I can think of * look at the MAIL FROM domain, à la SPF (breaks forwarding), * have the list's domain in a white list (requires maintenance), * use some of the "List-*" fields (which one?) Apparently, section 5.4 doesn't cover this point. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available --FBL
On 17/May/10 13:36, Eliot Lear wrote: > Section 1.3 > > FBL? What a horrible misuse of an already common term. Is there a cite > for this or can we change it? Would you expand on that, please? In particular, it doesn't seem misused to me, according, e.g., to wikipedia's definition[1] Feedback loop - the causal path that leads from the initial generation of the feedback signal to the subsequent modification of the event and its application to email[2]. What "already common" acceptation do you mean? For MLMs, there is a tradition of equating a feedback signal to an unsubscribe request, thereby preventing the possibility to use a list-specific FBL for cooperative list maintenance. Section 1.3 does not mention this, but conveys the idea that abuse reports should be routed differently when reported messages belong to lists. -- [1] http://en.wikipedia.org/wiki/Feedback [2] http://en.wikipedia.org/wiki/Feedback_Loop_(email) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
--On 18 May 2010 10:40:05 +0100 Ian Eiloart wrote: > > > --On 17 May 2010 11:47:11 +0200 Serge Aumont wrote: > >> >> "ADSP = discardable" means : "the domain encourages the recipient(s) to >> discard it.". So a pretty MLM should discard thoses messages unless it >> is able to brodcast it to subscribers without DKIM signature alteration. > > > No, it (or it's foreground MTA) should reject the message at SMTP time, > on the grounds that it can't be sure to deliver it. Of course, if the DKIM signature is good, and the return-path is in the signing domain, then it's probably OK to generate a bounce. -- 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] Lists "BCP" draft available
--On 17 May 2010 11:47:11 +0200 Serge Aumont wrote: > > "ADSP = discardable" means : "the domain encourages the recipient(s) to > discard it.". So a pretty MLM should discard thoses messages unless it > is able to brodcast it to subscribers without DKIM signature alteration. No, it (or it's foreground MTA) should reject the message at SMTP time, on the grounds that it can't be sure to deliver 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] Lists "BCP" draft available
John, > Yes, of course. The signature means that this message really truly > came from the mailing list, as opposed to being a random piece of spam > that happened to resemble list mail. What else would it mean? Lists > have never promised that the original sender was "real" nor that > messages aren't edited on the way through. Lists never have had DKIM to deal with, so they've never had the option to make any such promise. The signature lends the MLM's credibility to the message, which in turn could hurt the MLM's credibility if it turns out to be signing garbage. How else would a reputation for signers work? The MLM wants to signal to the recipient the veracity of the origon. That's why Murray's approach in the draft is to add an A-R header, which he states in the draft goes beyond A-R's intent in terms of trust. An alternative would be to simply not sign the message. Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> Lists never have had DKIM to deal with, so they've never had the option to > make any such promise. The signature lends the MLM's credibility to the > message, which in turn could hurt the MLM's credibility if it turns out to be > signing garbage. How else would a reputation for signers work? Once again we return to this strange assumption that list managers will supinely allow garbage to flow through their lists, yet go to great effort to apply clever signature hacks so their recipients can recognize that same garbage. The lists I've been using for the past 35 years have used a variety of techniques, some automated and some manual, to manage the stuff that gets onto the list and keep the garbage out in the first place. Does anyone expect that to change? Why wouldn't a list just do whatever it does to manage its traffic, and then sign all its outgoing mail, so you can recognize mail from the list? It might well add DKIM to the repertoire of techniques used to filter the incoming mail, but that's no more evident (mechanically at least) to the recipients than any of the filtering techniques they use now. And if a list does lousy message management and does leak garbage, wouldn't you want the list and its signature to have a poor reputation? > The MLM wants to signal to the recipient the veracity of the origin. Nothing personal, but there is not a shred of evidence that any list has any such intention. If it were important for lists to verify that the contributor's address were "real", they would be verifying and applying S/MIME signatures. The fact that there's no A-R like thing to tell whether an S/MIME signature used to verify suggests that it's not something anyone's wanted to know. I want to know whether an incoming message is from a list to which I subscribe. But I don't try to second guess the way the list owners manage the lists now, and I see no reason why DKIM would change that. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
>> A DKIM-aware resending MLM is encouraged to sign the entire message >> as it arrived, especially including the original signatures. > >Would I as an MLM want to resign a message that I received that itself >was not signed? Do I want to confer more authority to that message than >is warranted? Yes, of course. The signature means that this message really truly came from the mailing list, as opposed to being a random piece of spam that happened to resemble list mail. What else would it mean? Lists have never promised that the original sender was "real" nor that messages aren't edited on the way through. I like Murray's draft, and I hope that we can resist the urge to add vast amounts of non-productive complication to it. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
>If think it would be an error to recommend that MLM handles "ADSP = >all" in the same way as they handle email with "discardable" domain. If >so "ADSP = all" will have a very poor difference with "ADSP = >discardable" a very very low number of domaines will use such ADSP policy. Agreed. We have no idea what "all" means in practice, other than perhaps an ill-defined small decrement to some sort of reputation if the signature isn't present. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 5/17/10 2:47 AM, Serge Aumont wrote: > On 05/11/2010 07:48 PM, Douglas Otis wrote: > >> On 5/11/10 7:37 AM, Serge Aumont wrote: >> Serge, >> >> >>>-Sympa include DKIM signature verification and use DKIM signature >>> status in the process of message submission and email commands >>>-it remove broken pre-existing DKIM signature and keep others as is >>> (not all messages are processed in way that brake signature) >>>-it reject message comming from author ADSP record is discardable >>> and if the process of message by the MLM brakes signature. This >>> prevent brodcasting of a message that should be discarded by final >>> recipients. >>>-it add it's own signature (on per list configuration parameter) >>>-it sign MLM services messages and digest. >>>- etc >>> >>> >> Why limit rejection to ADSP "discardable" and not include ADSP "all"? >> > "ADSP = discardable" means : "the domain encourages the recipient(s) to > discard it.". So a pretty MLM should discard thoses messages unless it > is able to brodcast it to subscribers without DKIM signature alteration. > "ADSP = all" does not recommend to drop thoses messages. > ADSP "discardable" modifies SMTP acceptance assurances by encouraging ADSP evaluation failures be discarded rather than generate rejections or DSNs. The lack of an Author Domain signature in conjunction with "all" assertions still represents an ADSP evaluation failure! Invalidation of Author Domain signatures will result in subsequent ADSP evaluation failures. ADSP "discardable" is not the only actionable assertion since "all" may also cause invalid Author Domain signatures to not be delivered. > If think it would be an error to recommend that MLM handles "ADSP = > all" in the same way as they handle email with "discardable" domain. If > so "ADSP = all" will have a very poor difference with "ADSP = > discardable" a very very low number of domaines will use such ADSP policy. > The difference between "all" and "discardable" is whether a rejection or DSN is expected when a message is not delivered. That represents a sizable difference! A mailing list that accepts messages containing From domains asserting "all" or "discardable" will not be in compliance when Author Domain signatures are made invalid by message modifications. Interpretations that suggest only "discardable" provides actionable assertions leaves DKIM as offering protection only in conjunction with inherently unreliable services. :^( >> Why would it be okay to accept messages having ADSP "all" that lack a >> valid Author Domain Signature? >> >> BTW, ADSP "discardable" does not imply the desire to have messages >> rejected, especially from a MLM application running post acceptance. >> Should any invalid Author Domain signature for domains asserting "all" or "discardable" cause mailing lists to not distribute the message? Discarding a message is limited to domains asserting "discardable", but ADSP "all" failures may also result in messages not being delivered! Under what conditions is it safe to accept ADSP "all" failures? It would be much safer to allow domains seeking ADSP protection to determine specific exceptions. >> In respect to Auth-Results, when is it safe to assume MLM applications >> ensure compliance with ADSP? >> > It can be useful to add an header that prove the MLM [has] verified the > DKIM signature and ADSP compliance of the incomming message. This can be > done in a safe way adding an [AUTH-RESULT] header included in the new > DKIM signature. > Should receiving MTAs know whether mailing list applications: a) remove spoofed Authentication-Results headers, b) make reasonable modifications to messages, c) and properly evaluate Author-Domain signatures? What grace period should MTAs allot for new mailing lists? Is ADSP "all" protection a function based upon interactions between users and MUAs? When would a user or MUA know whether it is safe to make ADSP failure exceptions for messages from unknown mailing lists? An authorization scheme would allow domains seeking protection to indicate in each case whether they deem it safe to accept messages not compliant with "all" or "discardable" assertions. >>> The "l=" tag is one of the worth idea of DKIM if introduced because of >>> message body footer added by some MLM. MLM must not add anything after >>> the end of a message because this break Mime content. When adding a >>> footer, MLM should add an extra mime part, and this often require to >>> modify mime headers. So "l=" tag should not ne considered as an >>> efficient way to protect DKIM signature. >>> >>> I known that the problem is comming from rfc-4871 but I propose to >>> remove this sentence from this draft. >>> >>> >> Would you also suggest a practice of not altering the Subject line, or >> of not providing uniform message formats? >> >> It seems unlikely there is a desire to have these fea
Re: [ietf-dkim] Lists "BCP" draft available
On 17/May/10 11:47, Serge Aumont wrote: > "ADSP = discardable" means : "the domain encourages the recipient(s) to > discard it.". So a pretty MLM should discard thoses messages unless it > is able to brodcast it to subscribers without DKIM signature alteration. > "ADSP = all" does not recommend to drop thoses messages. > > If think it would be an error to recommend that MLM handles "ADSP = > all" in the same way as they handle email with "discardable" domain. If > so "ADSP = all" will have a very poor difference with "ADSP = > discardable" a very very low number of domaines will use such ADSP policy. +1 > The "l=" seems to be ignored by every DKIM users. It's interest is > really limited. My opinion is that we should not recommend its usage > because it is not MIME compatible. MIME is an very old standard > implemented by almost every mail products. "l=" tag is an hack in DKIM > introduced only for dirty MLM software that still ignore MIME and will > probably ignore DKIM for a long time ;-). It should be forgotten ! I see my messages get a dkim=pass for my signature when they come back from the (few) mailing lists I'm subscribed to that don't remove signatures, because of the "l=". That is to say, IME it works as advertised. As for signing MIME messages, I agree DKIM is broken, because it is legal to alter even the MIME preamble. The discussion on a MIME-compatible canonicalization algorithm has been moved to ASRG, and I look forward to going about it in the near future. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
Hi Murray, Thanks for taking a shot at this. Here are some comments on the Lists draft. First, I support the draft becoming a working group document. However, I wonder if it requires simplification with a bit more discussion as to motivation. I'll get into some of that below. Introduction 3rd and 4th bullets should use consistent terminology, so I suggest: s/mailing list/MLM/ Section 1.2 MLM behaviors are well-established and standards compliant. I don't understand what you mean by standards compliant. Same section lower down: However, the fact that the From field of such a message is typically the same as for the original message and that recipients perceive the message as "from" the original author rather than the MLM creates confusion about responsibility and autonomy for the re-posted message. Isn't there standard terminology to distinguish between the From and from (e.g., SMTP-From)? Section 1.3 FBL? What a horrible misuse of an already common term. Is there a cite for this or can we change it? Section 3.1 I *love* the title of this section!!! However- I believe we need to be careful to cite the source of these definitions, so as to avoid conflict should they change. Section 3.2 The remainder of this document operates on the presumption that a message going through a re-posting MLM actually comprises two message transactions s/re-posting/resending/ ? I think, by the way, that 3.2 should probably be expanded with regard to the logic behind steps 1 and 2. Seems to me that's the thing that will help mailing list maintainers understand why the solution is correct. Section 4.1. I'm uncomfortable with this section. I don't know how an author is supposed to know whether an MLM is a participant or non-participant. Moreover, discrimination at the enterprise level seems like a great opportunity for us vendors to sell more hardware without much customer benefit. I would rather see this section simply say that messages originating from ADMDs that have strict ADSP polices are advised to not make use of either non-participating MLMs that corrupt signatures. Section 5.1 Authors may be well-advised to create a DNS domain specifically used for generating signatures when sending traffic to MLMs I think you have to be really clear on this point, because it can be read in one of several ways: * Author domain should be used expressly to transmit to MLMs, in which case you should make it clear when this should be the case (e.g., you couldn't imagine an entire enterprise redoing their email infrastructure to such an end) * The SIGNING domain and NOT the author domain should be used expressly to transmit to MLMs, in which case we have a problem I mentioned above; * Something else Section 5.2: In the case of verification of signatures on subscriptions, MLMs are advised to add an [AUTH-RESULTS] header field to indicate the signature(s) observed on the submission as it arrived at the MLM and what the outcome of the evaluation was. What if any level of operational trust should be placed in such a header? Section 5.4 A DKIM-aware resending MLM is encouraged to sign the entire message as it arrived, especially including the original signatures. Would I as an MLM want to resign a message that I received that itself was not signed? Do I want to confer more authority to that message than is warranted? Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 05/11/2010 07:48 PM, Douglas Otis wrote: > On 5/11/10 7:37 AM, Serge Aumont wrote: > Serge, > >> -Sympa include DKIM signature verification and use DKIM signature >> status in the process of message submission and email commands >> -it remove broken pre-existing DKIM signature and keep others as is >> (not all messages are processed in way that brake signature) >> -it reject message comming from author ADSP record is discardable >> and if the process of message by the MLM brakes signature. This >> prevent brodcasting of a message that should be discarded by final >> recipients. >> -it add it's own signature (on per list configuration parameter) >> -it sign MLM services messages and digest. >> - etc >> > Why limit rejection to ADSP "discardable" and not include ADSP "all"? > "ADSP = discardable" means : "the domain encourages the recipient(s) to discard it.". So a pretty MLM should discard thoses messages unless it is able to brodcast it to subscribers without DKIM signature alteration. "ADSP = all" does not recommend to drop thoses messages. If think it would be an error to recommend that MLM handles "ADSP = all" in the same way as they handle email with "discardable" domain. If so "ADSP = all" will have a very poor difference with "ADSP = discardable" a very very low number of domaines will use such ADSP policy. > Why would it be okay to accept messages having ADSP "all" that lack a > valid Author Domain Signature? > > BTW, ADSP "discardable" does not imply the desire to have messages > rejected, especially from a MLM application running post acceptance. > >> I notice a good idea : as Sympa verify incomming DKIM signature it >> should add a [AUTH-RESULTS] header field ; this header should be part >> of the DKIM signature added by the MLM engine. I will add this feature >> in Sympa in a near future. >> > In respect to Auth-Results, when is it safe to assume MLM applications > ensure compliance with ADSP? > It can be useful to add an header that prove the MLM as verified the DKIM signature and ADSP compliance of the incomming message. This can be done in a safe way adding an [AUTH-RESULT] header included in the new DKIM signature. >> The "l=" tag is one of the worth idea of DKIM if introduced because of >> message body footer added by some MLM. MLM must not add anything after >> the end of a message because this break Mime content. When adding a >> footer, MLM should add an extra mime part, and this often require to >> modify mime headers. So "l=" tag should not ne considered as an >> efficient way to protect DKIM signature. >> >> I known that the problem is comming from rfc-4871 but I propose to >> remove this sentence from this draft. >> > Would you also suggest a practice of not altering the Subject line, or > of not providing uniform message formats? > > It seems unlikely there is a desire to have these features removed from > most mailing-lists. > > Would you be interested in an alternative mechanism requiring the same > overhead as for ADSP, that eliminates a need to change any MLM handling? > > If ADSP is worth doing, why is it not worth doing in a way that > increases security? > The "l=" seems to be ignored by every DKIM users. It's interest is really limited. My opinion is that we should not recommend its usage because it is not MIME compatible. MIME is an very old standard implemented by almost every mail products. "l=" tag is an hack in DKIM introduced only for dirty MLM software that still ignore MIME and will probably ignore DKIM for a long time ;-). It should be forgotten ! Serge ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 05/11/2010 06:10 PM, Murray S. Kucherawy wrote: >> From what I see on the list, there is clear consensus that this >> document should be produced as a WG document (which I support as well). >> So can we consider that question closed? > > That's up to the chairs, but I suspect we have enough agreement to move > forward. Agreed. > There is the incomplete matter of re-chartering though. Right. Doing that now. Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 10, 2010, at 4:24 PM, Steve Atkins wrote: > What's described there as an "authoring" mailing list manager isn't really > what I think of as a mailing list, and there's not that much to say about it > compared with the other sorts discussed. If it simplified things it could be > dropped without affecting the rest of the document, I think. I think it should stay, primarily as a way to prevent confusion from people who think the "authoring"/one-way-blast MLM is the only important use of email. (I'm sure you know some people like that) -- J.D. Falk Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 5/11/10 7:37 AM, Serge Aumont wrote: Serge, > -Sympa include DKIM signature verification and use DKIM signature > status in the process of message submission and email commands > -it remove broken pre-existing DKIM signature and keep others as is > (not all messages are processed in way that brake signature) > -it reject message comming from author ADSP record is discardable > and if the process of message by the MLM brakes signature. This > prevent brodcasting of a message that should be discarded by final > recipients. > -it add it's own signature (on per list configuration parameter) > -it sign MLM services messages and digest. > - etc Why limit rejection to ADSP "discardable" and not include ADSP "all"? Why would it be okay to accept messages having ADSP "all" that lack a valid Author Domain Signature? BTW, ADSP "discardable" does not imply the desire to have messages rejected, especially from a MLM application running post acceptance. > I notice a good idea : as Sympa verify incomming DKIM signature it > should add a [AUTH-RESULTS] header field ; this header should be part > of the DKIM signature added by the MLM engine. I will add this feature > in Sympa in a near future. In respect to Auth-Results, when is it safe to assume MLM applications ensure compliance with ADSP? > > Section 4.2 > > "Verifiers that receive mail bearing DKIM signatures that fail to > verify might benefit from attempting to detect that such mail passed > through a non-participating MLM and then decide not to apply [ADSP] in > order to avoid aggressive filtering of mail that should otherwise have > been delivered.". > > This proposition may introduce a security issue : spammers could fake > an sender email and a MLM engine in order to bypass ADSP from a > particular domain. This proposition is a limit of what "ADSP > discardable" mean. If we accept this idea that the final verifier may > not test ADSP because the message comes from an non DKIM MLM, "ADSP > discardable" is not usefull anymore. We all known that the use case of > "ADSP discardable" is really limited. Agreed. When ADSP requires alternative domains to be compliant with third-party services, this lessens security. Essentially, this approach requires recipients to ignore the From header and to pay attention to an unseen DKIM signature perhaps without an indication of it being valid. > Please remove this paragraph from this draft. How would removing this paragraph change signing behaviors in a way that improves security? > > *Section 3.4* > > At last, another idea usefulness is that draft in * :* > "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 > has security considerations (see Section 3.5 of [DKIM])." > > The "l=" tag is one of the worth idea of DKIM if introduced because of > message body footer added by some MLM. MLM must not add anything after > the end of a message because this break Mime content. When adding a > footer, MLM should add an extra mime part, and this often require to > modify mime headers. So "l=" tag should not ne considered as an > efficient way to protect DKIM signature. > > I known that the problem is comming from rfc-4871 but I propose to > remove this sentence from this draft. Would you also suggest a practice of not altering the Subject line, or of not providing uniform message formats? It seems unlikely there is a desire to have these features removed from most mailing-lists. Would you be interested in an alternative mechanism requiring the same overhead as for ADSP, that eliminates a need to change any MLM handling? If ADSP is worth doing, why is it not worth doing in a way that increases security? s/brake/break/ -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 10, 2010, at 2:01 PM, Murray S. Kucherawy wrote: > http://datatracker.ietf.org/doc/draft-kucherawy-dkim-lists/ > > Would the WG like to bring it in and make it a WG document? If so, I > volunteer to act as editor. > I'm an IETF newbie, so correct me if I'm wrong. But it seems you are only asking the binary question of whether the WG is willing to add this deliverable to it's scope, with your draft as a strawman, and you acting as the editor. You are not asking us if we have rough consensus on the contents of the document in its current form. Correct? >From what I see on the list, there is clear consensus that this document >should be produced as a WG document (which I support as well). So can we >consider that question closed? Now that it's a WG document, what's the review process... do we just chime in with comments and suggested edits on this thread? -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> -Original Message- > From: McDowell, Brett [mailto:bmcdow...@paypal.com] > Sent: Tuesday, May 11, 2010 9:51 AM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Lists "BCP" draft available > > I'm an IETF newbie, so correct me if I'm wrong. But it seems you are > only asking the binary question of whether the WG is willing to add > this deliverable to it's scope, with your draft as a strawman, and you > acting as the editor. You are not asking us if we have rough consensus > on the contents of the document in its current form. Correct? Yes, that's right. (And I'm not sure you meant "strawman" so much as "skeleton"...) > From what I see on the list, there is clear consensus that this > document should be produced as a WG document (which I support as well). > So can we consider that question closed? That's up to the chairs, but I suspect we have enough agreement to move forward. There is the incomplete matter of re-chartering though. > Now that it's a WG document, what's the review process... do we just > chime in with comments and suggested edits on this thread? Once it's official, I'll go back and plow through the huge recent threads about DKIM and lists and try to distill things the document needs, as well as soliciting feedback explicitly. You're welcome to start commenting right away if you like. (Everybody else has!) -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 05/10/2010 08:01 PM, Murray S. Kucherawy wrote: I’ve posted an individual submission draft that attempts to capture some of the consensus and some appropriate guidance around the use of DKIM in the context of mailing lists. I don’t propose that it’s final at all, but merely an anchor point for further discussion. http://datatracker.ietf.org/doc/draft-kucherawy-dkim-lists/ That's a nice document. I would have be very glad to read it when I started DKIM implementation for Sympa. Sympa MLM already respect almost all ideas described in this draft (see DKIM Sympa reference manual chapter : http://www.sympa.org/manual_6.1/dkim ). -Sympa include DKIM signature verification and use DKIM signature status in the process of message submission and email commands -it remove broken pre-existing DKIM signature and keep others as is (not all messages are processed in way that brake signature) -it reject message comming from author ADSP record is discardable and if the process of message by the MLM brakes signature. This prevent brodcasting of a message that should be discarded by final recipients. -it add it's own signature (on per list configuration parameter) -it sign MLM services messages and digest. - etc I notice a good idea : as Sympa verify incomming DKIM signature it should add a [AUTH-RESULTS] header field ; this header should be part of the DKIM signature added by the MLM engine. I will add this feature in Sympa in a near future. Section 4.2 "Verifiers that receive mail bearing DKIM signatures that fail to verify might benefit from attempting to detect that such mail passed through a non-participating MLM and then decide not to apply [ADSP] in order to avoid aggressive filtering of mail that should otherwise have been delivered.". This proposition may introduce a security issue : spammers could fake an sender email and a MLM engine in order to bypass ADSP from a particular domain. This proposition is a limit of what "ADSP discardable" mean. If we accept this idea that the final verifier may not test ADSP because the message comes from an non DKIM MLM, "ADSP discardable" is not usefull anymore. We all known that the use case of "ADSP discardable" is really limited. Please remove this paragraph from this draft. Section 3.4 At last, another idea usefulness is that draft in : "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 has security considerations (see Section 3.5 of [DKIM])." The "l=" tag is one of the worth idea of DKIM if introduced because of message body footer added by some MLM. MLM must not add anything after the end of a message because this break Mime content. When adding a footer, MLM should add an extra mime part, and this often require to modify mime headers. So "l=" tag should not ne considered as an efficient way to protect DKIM signature. I known that the problem is comming from rfc-4871 but I propose to remove this sentence from this draft. Serge Aumont ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
--On 10 May 2010 15:24:05 -0700 Steve Atkins wrote: > > On May 10, 2010, at 11:01 AM, Murray S. Kucherawy wrote: > >> I’ve posted an individual submission draft that attempts to capture >> some of the consensus and some appropriate guidance around the use of >> DKIM in the context of mailing lists. I don’t propose that it’s >> final at all, but merely an anchor point for further discussion. >> >> http://datatracker.ietf.org/doc/draft-kucherawy-dkim-lists/ > > Looks good. > > What's described there as an "authoring" mailing list manager isn't > really what I think of as a mailing list, and there's not that much to > say about it compared with the other sorts discussed. If it simplified > things it could be dropped without affecting the rest of the document, I > think. It's just another MSA, isn't it? Granted, one can often use an MLM for announcements only, but those would not fit into this category for purposes of the present discussion. I agree that this type of list manager isn't really relevant here, because it's not going to break any DKIM signatures. However, a statement to that effect would not hurt. And, it should be made clear that we're NOT talking about a "resending MLM" used as an announcement list (ie, with a very restricted list of permitted senders). > Cheers, > Steve > > > ___ > 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] Lists "BCP" draft available
> Iâd argue that the practices for forwarding fall under the > aliasing-style MLMs as the mechanism is identical. Perhaps we could > say so here. I'll bet I can get a 50 message thread going arguing about whether and how the bounce address should change, with at least 10 of the messages pointing out that DKIM doesn't look at the bounce address. You are of course correct that they both have the same implications for DKIM (none, unless the signer is actively perverse), but when has that stopped us? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 5/10/10 4:55 PM, Murray S. Kucherawy wrote: > An MLM "supports DKIM" (or "is DKIM-friendly", to use some earlier language) > if it either (a) doesn't do any message modification that would generally > invalidate an author signature, or (b) re-signs mail upon re-posting it, or > (c) both (a) and (b). > This draft has not offered a reasonable solution for ADSP policy assertions of From email addresses having valid Author Domain Signatures. It is unreasonable to: A) assume ADSP policies will be applied by mailing lists. (Most don't.) B) assume mailing lists will not damage DKIM signatures. (Most do.) Section 4.1 third paragraph states: ,-- If this is cause for concern, the originating site can consider using a sub-domain for the "personal" mail that is different from domain(s) used for other mail streams, so that they develop independent reputations, and more stringent policies (including ADSP) can be applied to the mail stream(s) that do not go through mailing lists. '-- The protective goal underlying restrictive ADSP policies in blocking potentially deceptive messages is not provided by this strategy. Use of alternative domains represents a very bad practice as this leaves recipients even more vulnerable to look-alike ploys once the practice becomes common. No benefit is derived by not pursing a better solution. In fact, greater harm seems likely. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 5/10/2010 2:28 PM, J.D. Falk wrote: > I think we could write normative language for what MLM software MUST NOT do > if it wants to pass DKIM-signed messages through unscathed. Seems an odd thing to make normative, since all that is entailed is not breaking the signature, and the details of what goes into a signature are in the base DKIM signing spec. This actually winds up arguing for not worrying about the subtleties or niceties of normative language and instead just trying to provide discussion that is largely tutorial. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 5/10/2010 3:24 PM, Steve Atkins wrote: > What's described there as an "authoring" mailing list manager isn't really > what I think of as a mailing list, and there's not that much to say about it > compared with the other sorts discussed. If it simplified things it could be > dropped without affecting the rest of the document, I think. I don't think of it as a mailing list, either, but apparently some folks in industry do. Hence, including this case ensures that there is no confusion with readers. The incremental cost of including it is pretty small. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of J.D. Falk > Sent: Monday, May 10, 2010 2:28 PM > To: IETF-DKIM WG > Subject: Re: [ietf-dkim] Lists "BCP" draft available > > That brings up the strange question of what "supporting DKIM" is. > > I think we could write normative language for what MLM software MUST > NOT do if it wants to pass DKIM-signed messages through unscathed. We > could also write normative language for what MLM software MUST do if it > wants to sign the messages itself (that's pretty obvious.) But it's > all the places in between that get complicated -- particularly when MLM > developers are (in my experience) notoriously slow to add features. I think your second paragraph gave the definition that answers the first: An MLM "supports DKIM" (or "is DKIM-friendly", to use some earlier language) if it either (a) doesn't do any message modification that would generally invalidate an author signature, or (b) re-signs mail upon re-posting it, or (c) both (a) and (b). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 10, 2010, at 11:01 AM, Murray S. Kucherawy wrote: > I’ve posted an individual submission draft that attempts to capture some of > the consensus and some appropriate guidance around the use of DKIM in the > context of mailing lists. I don’t propose that it’s final at all, but merely > an anchor point for further discussion. > > http://datatracker.ietf.org/doc/draft-kucherawy-dkim-lists/ Looks good. What's described there as an "authoring" mailing list manager isn't really what I think of as a mailing list, and there's not that much to say about it compared with the other sorts discussed. If it simplified things it could be dropped without affecting the rest of the document, I think. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 10, 2010, at 2:43 PM, Franck Martin wrote: > This looks good. Ok to become a WG document +1 > Pity we may need a separate document for "forwarding" or can this notion be > included in the current document? It's complex enough with all the different ways that MLM-style remailing can be implemented. Single-address forwarding is clearly related to /some/ of those methods, but not all, so I think confusion would be even more certain if we included that too. > Also can parts be more normative than informational? ie what a MLM MUST do > when supporting DKIM. That brings up the strange question of what "supporting DKIM" is. I think we could write normative language for what MLM software MUST NOT do if it wants to pass DKIM-signed messages through unscathed. We could also write normative language for what MLM software MUST do if it wants to sign the messages itself (that's pretty obvious.) But it's all the places in between that get complicated -- particularly when MLM developers are (in my experience) notoriously slow to add features. -- J.D. Falk Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
>http://datatracker.ietf.org/doc/draft-kucherawy-dkim-lists/ > >Would the WG like to bring it in and make it a WG document? If so, I >volunteer to act as editor. Yes, please. I'll be happy to help. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
Whether or not this document is normative vs. informative is up to the WG really. I’d be fine with either, though there’s the argument that we should start with something informational (non-normative) first and then upgrade it to BCP (normative) later. I’d argue that the practices for forwarding fall under the aliasing-style MLMs as the mechanism is identical. Perhaps we could say so here. From: Franck Martin [mailto:fra...@genius.com] Sent: Monday, May 10, 2010 1:43 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Lists "BCP" draft available This looks good. Ok to become a WG document Pity we may need a separate document for "forwarding" or can this notion be included in the current document? Also can parts be more normative than informational? ie what a MLM MUST do when supporting DKIM. From: "Murray S. Kucherawy" To: ietf-dkim@mipassoc.org Sent: Monday, 10 May, 2010 11:01:54 AM Subject: [ietf-dkim] Lists "BCP" draft available I’ve posted an individual submission draft that attempts to capture some of the consensus and some appropriate guidance around the use of DKIM in the context of mailing lists. I don’t propose that it’s final at all, but merely an anchor point for further discussion. http://datatracker.ietf.org/doc/draft-kucherawy-dkim-lists/ Would the WG like to bring it in and make it a WG document? If so, I volunteer to act as editor. -MSK ___ 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] Lists "BCP" draft available
This looks good. Ok to become a WG document Pity we may need a separate document for "forwarding" or can this notion be included in the current document? Also can parts be more normative than informational? ie what a MLM MUST do when supporting DKIM. From: "Murray S. Kucherawy" To: ietf-dkim@mipassoc.org Sent: Monday, 10 May, 2010 11:01:54 AM Subject: [ietf-dkim] Lists "BCP" draft available I’ve posted an individual submission draft that attempts to capture some of the consensus and some appropriate guidance around the use of DKIM in the context of mailing lists. I don’t propose that it’s final at all, but merely an anchor point for further discussion. http://datatracker.ietf.org/doc/draft-kucherawy-dkim-lists/ Would the WG like to bring it in and make it a WG document? If so, I volunteer to act as editor. -MSK ___ 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
