Re: [ietf-dkim] Domain Existence Check and Erroneous Abstract
OK. Now that isn't going to happen. Let's be realistic. Anything short of aliens landing in Miami is going to get something like this into or out of Lotus Notes some time this century. (And sadly I am being realistic here) Saying that we ignore these systems because they haven't followed the rules just disenfranchised a large enough piece of the pie for this scheme to be called unworkable. Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Consensus check: Domain Existence Check
Modify ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
On Sun, Feb 24, 2008 at 2:46 PM, SM [EMAIL PROTECTED] wrote: At 09:14 24-02-2008, Hector Santos wrote: Pray tell, are you aware this tells the MTA who are processing the payload at the SMTP DATA state (not POST SMTP), to issue a 250 positive message accept response code with the true purpose of silently discarding it? Yes. Agreed. All you are doing at this point is releasing the responsibility for the delivery of the message from the sending MTA. What you do with the message after that is your own business. You ARE accepting the message, dropping it on the floor is a matter of policy, not RFC's. Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] discardable means discardable
On 24 Feb 2008 01:44:49 -, John Levine [EMAIL PROTECTED] wrote: The discarding of email is one of the key causes of some significant loss of trust in email as a reliable means of communication. Since I invented the term discardable perhaps I should explain why I mean discardable when I say discardable. There is a common meme that discarding mail is always bad. But generating and delivering bogus mail is just as bad, because nobody can find the real mail in a mountain of spam. Every day I get feedback loop spam reports for what is clearly real mail from a real person sent to a real recipient. But the recipient's eyes glazed over at all the spam in the inbox, and they discard the real mail along with the spam. Keep that in mind. I'm not sure how many people here other than Mike Hammer and me have direct experience running a heavily phished domain, so here's a report from the trenches. I run abuse.net, a tiny little domain that manages a reporting address database. On a busy day there might be 100 outbound messages with abuse.net return addresses, but due to some eastern European spammers with a strange sense of humor, every day I get 400,000 bounces, out of office, and other blowback. That's the reality of a phish target -- the fake mail vastly exceeds the real mail, by orders of magnitude. I don't know the absolute numbers for Paypal and the various banks, but I'm confident that they are in the same situation at even larger scale, way more fake than real mail. That's why when I say discardable, I really mean it. When I upgrade my MTA to sign all of abuse.net's mail, I will really want you to throw away unsigned mail. Not reject, not bounce, not send a DSN, just THROW IT AWAY. Even if you carefully do your filtering and reject at SMTP time, enough of the MTAs that see your reject will turn it into a bounce that I'll still be inundated with junk bounces for mail I didn't send. (Hmmn, large numbers of similar messages I didn't ask for and don't want. Don't we have a name for that?) I have some fairly effective heuristics to identify the bogus bounces, but they're not 100% accurate, which means that with all the noise, I lose some of my real bounces as well. Who benefits from that? If you aren't in this situation, vastly more fake mail than real mail, discardable doesn't apply to you. If you see the occasional bounce blowback, or even the occasional burst of a few hundred blowbacks, it still doesn't apply to you. Really. I entirely agree that for normal mail, you should reject it if you don't deliver it so that the real person (or perhaps the real ESP) who sent it can do something useful with the info. But this situation is different -- the bad mail is not from real senders, the forged sender is already acutely aware that there's a lot of forgery, and any response will just increase the noise. People do need guidance on discardable, but the guidance is pretty simple: A) If you're not sure whether discardable applies to you, it doesn't. B) If you're fairly sure that discardable applies to you, it still probably doesn't. C) If a heavily phished domain asks you to throw away the apparent forgeries, do the world a favor and take their advice. R's, John John, Standing O, loud thunderous applause and four finger whistles from me. I get the feeling that those of us in the trenches get bulldozed over sometimes. Regards, Damon Experience: Postmaster of a few tiny domains ;-) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: Fwd: Re: [ietf-dkim] Re: from'less 2822 messages
On Jan 28, 2008 1:30 PM, Hector Santos [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: But beyond that, I have to say I'm a bit confounded by the concern for invalid messages shown here. There are a gazillion ways for messages to be invalid and attempting to account for them all in our specifications is a practical impossibility. And yet many members of this group seem to have no problem blithely ignoring various legitimate protocol features. I find this dichotomy to be more than a little perflexing. +1. +1,000,000 I am VERY sorry if I had anything to do with this thread going as long as it did. My reply to the first message was just to clear up my confusion. Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] A proposal for restructuring SSP
On Jan 28, 2008 10:18 AM, MH Michael Hammer (5304) [EMAIL PROTECTED] wrote: Bill and anybody else who is responsible for outbound mail knows that they are going to get dinged - signed or not - if they don't address issues caused by mail coming from their system. Something that we (us trench warfare guys) have always had to do. But passing off signing to a third party and not having to be in that business (unless it's a value add ;-) and not having to sully the reputation of the ISP as a whole is a far better solution in my eyes. If Bill is willing to sign and wants a stronger statement made by SSP that the domain uses his DKIM signature, where is the technical objection? No objection on my part- but I think we could do better. It indicates the From domains signing policy and makes it easier for a receiver to more clearly ascertain a party that wants to take responsibility for the message. Isn't that the object of the exercise? Certainly but for largish ISP's and large corporations who do a lot of farming of their applications, being able to slice it up instead of getting the whole hog would be preferable and make the entire exercise worthwhile. I for one would certainly implement a lot faster with this capability. Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Re: from'less 2822 messages
As a follow up, I did a quick test and the Outlook Express MUA will not allow you to create Multiple From: authorships, but it will present (display) received mail with Multiple From: lines as one From: header line. I have not checked the non-free commercial Outlook MUA version but I do know it will do more then the Outlook Express which is available on every Windows machine. So maybe the commercial version will give you a Manual Editable or Multi-Select From: field as a Feature. Lotus Notes is the same way. Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] A proposal for restructuring SSP
You set your MTAs to sign the mail going out. It arrives other places, and they say aha, it's from Cox, they're OK so I'll treat it favorably, without having to worry about who's on the From line. (Or they might say, it's from Cox, they stink, but there's not much you can do about that.) Assuming that people believe that Cox's mail system is well run, your signature is all they need to link the mail with you. R's, John Pipe-dream. I am flabbergasted. Bad people sign up for accounts everyday and in this case, they would get to generate signed mail until they get shut down. How is this any different than how things are today? I would dare say it might even get worse. It says to me- I can't trust the signature. This does absolutely zero in helping to trust a domain. Not only that, all of a sudden we have reputation batteries required again. Even if the system is well run, which I am sure that it is, as is mine, the idea put forth that this is somehow tied to reputation is ludicrous. Bill, from now on, if you have a spammer who gets an account, I am going to hold you and your entire ISP responsible... I know you did it, I have your signature right here. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: from'less 2822 messages
When I pointed out that the first from rule enabled a trivial end run around SSP, by using a real first address and a forged second address that is likely to be visible in MUAs, I naively assumed that it would be obvious to everyone that any rule other than checking all the addresses would have the same hole, hence the fix is to check all the From: addresses, and then move on to something else. I for one understood the assumption you made. Misunderstanding was not this issue in my mind. The issue is what to do about evil do'ers that would certainly take advantage of this MUST - It concerns me. But no, we got endless nattering instead. This is not a subtle point, and I share Steve Atkins' concern that a group of people who don't understand the way that e-mail works can't design a working protocol. What? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP tounsigned messages
On Jan 25, 2008 12:08 PM, [EMAIL PROTECTED] wrote: Charles, Are you not making the assumption that implementaors may check SSP before checking dkim? A quick SSP lookup first returning a strict against a third party dkim signed mail may be processed differently than a SSP relaxed Thanks, Bill Oxley Messaging Engineer Cox Communications Are we assuming that multiple from's are going to fall in the same catagory as a 3rd party signed message? This is opening a can o' worms. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Seriously.
The protocol consistency must be consistent for the entire x822.From domain list. At best, we can recommend that the signer use the primary domain it is signing for, as the first address in the list. This might require reordering of the list when the message is first submitted for signing. Example of reordering (optional optimization) From: A, C, B, D A new message was created by a user B and he wishes to add co-authors A, C and D to the From: header. For some odd-ball, but still technically legal reason, the user B address is not the first: Nonetheless, User B submits it to his/her MSA and the MSA signing for domain B can reorder this prior to signing: From: B, A, C, D Dkim-Signature: d=B +1 +-[ NOTE ]+---+ | | | The MSA may also want to check the SSP for domains | | A, C and D to make sure they are not DKIM=STRICT. | | See Note1 below on this.| | | +-+ I am not so sure about this, please see my reasoning below As the logic is currently defined, a 3PS (3rd Party Signature) is when the DKIM d= domain is not matching the x822.From domain part. I believe that 3rd party signing and this issue are separate. So in this case, the signature d=B helps by checking the primary domain B regardless of the From: list order. Only if d=B and there has been a reorder. Without the reorder, the responsible party (at least in the readers eyes) is A. The Sender:, if provided, can possible add weigh if it was also pointing to domain B. Sender: B From: A, C, B, D Dkim-Signature: d=B and under this all matching case, there would be no need to reorder the From: list. o Missing Signature Of course, the situation is when we don't have a signature and we want to find what policies apply to the unsigned message. I don't think we can trust relying on Sender: especially if the domain is not among the From: list. So at best, an verifier can possible choose to use Sender: only if it matches and it helps define the order of the preferred lookup. I believe that we should say that in the absence of a d= the first from address will be the default author. In all cases, we can not violate the basic principle in SSP From: domain requirement - the single From: domain logic must be consistent with a multiple From: domains logic. Note #1: What rule is necessary for multiple SSP policies? None. Regardless of the policies of the other From: addresses, if a d= exists and there has been a reorder, the author is, at this point, defaulted to the first address. Anything else and we are going to break VERP implementations. This question pertains to how mixed SSP policies are interpreted. In order to be protocol consistent, IMO, any domain exposing a DKIM=STRICT or DKIM=ALL policy can not be violated by other mixed restrictive policies. I think we need to look at the mixed possibilities in order to get a handle on this multiple From: domains SSP logic. Here are few examples: Example 1: From: A, B, C DKIM-signature: d=A A -- DKIM=STRICT B -- NO SSP (DKIM=UNKNOWN) C -- NO SSP (DKIM=UNKNOWN) Issues: I see no Issue. Perfect SSP/DKIM protection. If the message was not signed, then it would be viewed as suspicious. Agree Example 2: From: A, B, C DKIM-signature: d=B A -- DKIM=STRICT B -- NO SSP (DKIM=UNKNOWN) C -- NO SSP (DKIM=UNKNOWN) Issues: Domain A is unprotected. This message should be suspicious. Disagree- There should be a reorder in this case where after processing: From: B,A,C DKIM-signature: d=B A is no longer the author. Example 3: From: A, B, C DKIM-signature: d=A A -- DKIM=STRICT B -- DKIM=ALL C -- DKIM=STRICT Issues: Can't have two DKIM=STRICT? One consideration might be, maybe as long as a valid signature was found any of the STRICT domains, in this case D=A matches one of the STRICT domains, this this may be an exemption. This is ok. The author is correctly identified and checked. However, this would be a LOOPHOLE if we allow this. Example 4: From: A, B, C DKIM-signature: d=B A -- DKIM=STRICT B -- DKIM=ALL C -- DKIM=STRICT Issues: Even though domain B allows anyone to sign, can it sign on its own behalf and still use strict co-domains? If we allow this, then we have a loophole. Disagree- If we allow reordering, it would then be allowed. -- Sincerely Hector Santos, CTO http://www.santronics.com Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to unsigned messages
On Jan 24, 2008 11:18 AM, Dave Crocker [EMAIL PROTECTED] wrote: Stephen Farrell wrote: 1521Limit the application of SSP to unsigned messagesnew dkim Nobody0 [EMAIL PROTECTED]9 days ago9 days ago0 Proposal: REJECT, but some wording changes may be needed for the next rev, thread is [4] I mainly saw opposition to the change suggested in the issue, and little support, but some text clarifying changes were suggested (e.g. [5]). [4] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008424.html [5] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008467.html Would you please explain the basis for assessing that this topic got sufficient discussion and that there was rough consensus on it? See above I mainly saw... Summary of proposal: All text that causes SSP to be applied to an already-signed message needs to be removed. Folks, I've reviewed the thread that took place on this topic. Here are summary statistics: Total postings in thread: 46 Number of different people posting: 14 Apparent REJECT of proposal: 4 Apparent ACCEPT of proposal: 5 I would like to ask folks with an opinion about this proposal to post an explicit note stating support or opposition. Some of the existing posts were about substantive issues in the proposal, but did not clearly indicate support or opposition. Given that this issue goes to the core of a significant fraction of the current specification's functionality and given that there is at least an implied requirement for the functionality in the SSP requirements RFC, I'll ask folks to do both a +1/-1 *and* to explain their reasons. I also do not find a record in the archive of working group agreement to add the features in question. So an assumption that the features should be retained unless there is a rough consensus *against* is problematic. Citing the SSP requirements RFC is comforting, but questionable, absent any history of group discussion and clear rough consensus about the matter. d/ -- -1 Creating the ability for any bad domain to bypass policy of other domains or worse, non-participating domains, IMO pokes a hole big enough to drive a truck through. I have always frowned upon senders using MY email address as a From: when the content was generated and delivered by THEM. Use my address as a nice name or Sender: but not as the From:. I have worked hard to remove this practice from the applications within the companies I have worked for. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Seriously.
My concern has to do with whether the SSP of the other From (author) domains has to be considered as well. Just as the point has been made that it's not proper to handle this case by arbitrarily picking the first From domain, I believe that it's also not proper to use Sender for this purpose. Given that belief, the question of whether Sender is signed or not is moot. -Jim In the case of multiple from: addresses, wouldn't promoting (maybe this is the wrong word) the from address(es) of the signing domain to author resolve this? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] from'less 2822 messages
On Jan 24, 2008 8:02 PM, Michael Thomas [EMAIL PROTECTED] wrote: I don't think this is handled in the current spec, but it's certainly possible to get delivered an otherwise valid 2822 message that doesn't have a From: address (or a null header field). What should an implementation do in this case? Mike ___ Such as a bounce? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Seriously.
This is a fair point. We need some words that don't create a normative dependency on reputation and accreditation systems that are out of scope. Suggestions welcomed. If the specification is restricted to statements of the type here is what I, an author domain, do, in case you a receiver find it useful to know then these issues become greatly simplified. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Are you are saying- If the Sender domain does not appear in the Author domain's SSP mark as suspicious? Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE 1525 -- combine Arvel's, Doug's, and John's ideas (?)
On Jan 19, 2008 4:15 PM, Douglas Otis [EMAIL PROTECTED] wrote: On Jan 18, 2008, at 11:53 PM, Frank Ellermann wrote: Douglas Otis wrote: There is a domain within the signature that should be used to assess compliance. What prevents a valid signature of the From domain from allowing a message to comply with all or strict? The most interesting case for SSP is no signature. SSP should create compliance requirements for messages based upon From header's domain(s). A strict or all compliance requirement should be met with a signature that could be valid for the From email- address's domain. The signature should not need to be on-behalf-of the From email-address (as determined by the signatures i= parameter). IMHO there should be an exception for restricted keys, where these signatures must be on-behalf-of the From email-address to fulfill a compliance requirement of all or strict. For my unconvincing toss a coin list (Message-ID or first author or Reply-To) it's of course possible to add use any signature for a domain in From addresses to figure out a relevant domain for SSP. It should not matter which header a domain's signature is on-behalf- of. DKIM is not about establishing an author's identity. The trust being established is with the signing domain. The signing domain has the option of using ambiguous signature (no i= or no local-part and multiple email-addresses of their domain). IMHO, the signing domain should be able to even use an opaque identity that does not associate with any header. An opaque id could prove useful to protect someone's privacy. A domain should be able to indicate they sign all without conveying anything more than that it was signed by their domain. But that only works if there is a corresponding DKIM signature, when it's not really necessary to test SSP. Just having a DKIM signature is not enough. Domains protected by DKIM and an SSP assertion of all or strict must include a signature from a domain that would be valid for the From email-address domain in question. The DKIM WG seems unnecessarily focused on the on-behalf-of feature of the DKIM signature. This feature _might_ enable an MUA to highlight which identity the signature was on-behalf-of. There may be cases where it is not possible for MUAs to establish which identity the signature was on-behalf-of. In that case, just the signature domain could be highlighted. Due to the possible on-behalf-of uncertainty, DKIM signature notifications must be able to convey just the domain of the signature. Although compliance for all or strict could be defined to require an unambiguous on-behalf-of, such a requirement will make unambiguous on-behalf-of less certain. The signing domain might then falsify the on-behalf-of to meet an unambiguous on-behalf-of. Security concerns are better met by not placing constraints on the types of signatures used. There are also the issue of body length, and subject lines where security might be impacted. The verifier/MUA can use the information and display whatever they consider appropriate. One could argue that excluding the subject line and including body length should not be used as well. There is no reason to use SSP as a means to constrain these parameters. Or do I miss something obvious in your proposal ? We could pick John's proposal where Arvel's idea doesn't work, just look at all domains in From addresses, for legit mail it's rare. That needs some SSP processing limits for malicious mails (not as badly as for SPF). EAI might wish to allow two From email-addresses to permit alternative formats. SSP could assert that messages containing more than two From email-addresses are not complaint with all or strict. This would limit the number of policy search operations to two per message. Except in cases of restricted keys, SSP compliance should not depend upon which header the address is on-behalf-of. Ensuring an unambiguous signature is within the control by the signing domain and is independent of SSP compliance. MUAs are free to display ambiguously signed, body length, and excluded subject line messages in any manner they consider appropriate. There is no reason for the DKIM WG to dictate how the on-behalf-of feature of the signature must be used before a domain can assert their signing practices or policies. Let the market decide. -Doug I liken this ~entire~ argument to something as asinine as not selling right-handed golf clubs because there are a lot of left handed people out there. Fringe cases should be considered only as to whether or not we should add an asterisk to the suggested usage page. Regards, Damon S ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: 1: 1 and assertions about third parties
On Jan 18, 2008 12:35 PM, Michael Thomas [EMAIL PROTECTED] wrote: John L wrote: In both cases, it leads to the receiver throwing away potentially useful mail so the inept sysadmin gets pretty much what they deserve. So why even worry about it at all? Because my goal is not to punish inept administrators, my goal is to deliver mail. Inept admins usually have other users who send actual mail to my users. Seems to me that you've said that if your goal is to deliver your users' mail, you dare not use SSP. If you're that concerned, you shouldn't be using any sort of reputation and/or filtering since the chance of false positive is 0. But of course you do, so you obviously accept the possibility of inept sysadmins doing themselves harm. Why badly configured SSP is any different is beyond me. Frankly, I'd be a lot more worried about badly administered RBL's and their ilk since they aren't accountable to anybody but themselves. Mike Are we seriously saying that we need to be concerned because of inept sysadmins? I would hate to see the training wheels welded on. Funny thing about inept sysadmins is that when all of their email starts to get thrown away, they either fix it or get replaced. Please let's not try to water this down so much that it becomes useless (again). Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Accidental versus malicous error (was: SSP assist DKIM)
Although an invalid signature should be considered equal to no signature (as also specified in the base specification), from the responses on this list, expect many will bet on initial statistics and get this wrong. This does not bode well, and could represent a sizeable loss of receiver resources. -Doug I do not see this as being correct and I never agreed with it. I am going to have to do something whether the signature is broken or not. Just because messages have broken signatures does not mean that I am going to have to add even 1 more linux server to my farm to handle them. My disagreement comes with the difference between ALL and STRICT. ALL would mean that all of my messages are signed, broken or not. Any message coming from me with NO signature is a failure of my published policy. When I receive a message from this domain I will likely accept the message if it has a signature regardless of the validity and drop the messages with no signature on the floor. At this point I have not determined the validity of the signature just that one existed or didn't. Next I would run through the checks. If I determine that the signature is invalid, by having it promoted/demoted to no signature I should be able to drop it on the floor. This is a BAD idea and is not something I would like to promote as this action just removed the difference between ALL and STRICT and now everything is STRICT. What I do with a message that has a broken signature and the policy for the domain is ALL is up to me. It will likely go through rigorous testing- but that is none of your/our business and I believe that forcing the operational folks into this sort of corner is not something that we should be doing. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Accidental versus malicous error
leave it alone. It's not hard to understand their perspective though: they thought a broken signature would look more spammy than a missing signature. Rinse, repeat. Mike Just leave it to the developers to find a way around the problem rather than just fixing it ;-) I am sure that we could add some best practices and say that if you are maintainig a STRICT or ALL policy then this ~may~ break mailing lists. There are plenty of products out on the market that have nothing to do with messaging that have these same sort of issues. Smoking Causes Cancer, Don't operate heavy machinery, etc. I believe that if big enough ISP's and businesses follow the rules, the broken mailers will have to fix their issues rather then the policy makers having to find ways around their issues. Allowances are going to have to be made and a line in the sand drawn at some point... I just hope that it is not 6 yards offshore. If a domain can't live with loosing a mailing list, then my suggestion would be either fix the mailing list or don't use ALL or STRICT. Seems simple enough to me. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Accidental versus malicous error
A mailing-list not breaking signatures is a scary idea. This would open the door for all sorts of abuse. Yesterday, of the 32082 messages that Cisco sent through mailing lists, 99.6% of them passed verification. Keep your grubby mitts off of the supposedly broken signatures like RFC4871 says. Mike Exactly, So why again are we demoting broken signatures to No Signature? This promotes ALL to STRICT. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Accidental versus malicous error
Under the default SSP policy (UNKNOWN or OPTIONAL signing), a bad signature promotion to NONE will validate the message as it never occurred. The same will occur when a domain has a ALL|STRICT policy but the verifier does not support SSP. Of course, opinion may vary, to me, I stand by the idea that is not a demotion of state, but rather a promotion. Hector, You know me as a logical person that can persuaded into understanding something that I might have disagreed with in the past and we usually think alike. In this case, I am really trying to figure out how promotion from BAD to NONE doesn't break ALL and promotes to STRICT. Because a good or bad a signature is a signature whereas promoting a BAD signature to NONE fails ALL and therefor promotes ALL to STRICT. I realize in the real world we would likely promote BAD to NONE ~after~ the validation, but if we are going to do that way, then I would like to see wording as such in the draft. With this in place, I would not have an issue with it. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Accidental versus malicous error
Hector, You know me as a logical person that can persuaded into understanding something that I might have disagreed with in the past and we usually think alike. In this case, I am really trying to figure out how promotion from BAD to NONE doesn't break ALL and promotes to STRICT. Because a good or bad a signature is a signature whereas promoting a BAD signature to NONE fails ALL and therefor promotes ALL to STRICT. I realize in the real world we would likely promote BAD to NONE ~after~ the validation, but if we are going to do that way, then I would like to see wording as such in the draft. With this in place, I would not have an issue with it. Regards, Damon Sauer After re-reading what I wrote, I (like most people likely) went Huh? What I would like to see is something that keeps the integrity of ALL without promoting to NONE and some implementer pointing to the RFC later and saying See, I handled this message correctly because I promoted the broken signature to NONE in the case where a broken signature met an ALL policy. Maybe it is just too late at night. My wordsmith went home. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Accidental versus malicous error (was: SSP assist DKIM)
As an operations person, I imagine that I would have a type of double-check. I certainly would be monitoring how many good signatures that I would be getting from sources that sign. If suddenly my average good sign for a particular site went down and my average bad sign went up, it would cause me to take notice and have a look. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue 1530 - replace use of term suspicious
While exception can work for me personal, I don't see it as a good candidate for replacing suspicious. We might as will say SSP Fault or SSP Failure. My pennies of course. -- Sincerely Hector Santos, CTO We agree on most things... and this isn't one of them ;-) I believe a better word for what you are describing is an anomaly - which can lead to an exception. But exceptions can be specifically and purposefully placed whereas anomalies cannot (as far as I know). Maybe it is just the word the Blue Screen Of Death uses that everyone hates. However, I still believe the using the word exception would be accurate. My point in providing the thesaurus link was that I didn't believe that this should take up too much of our time. Semantics - Pick a word or make one up, let's get on with more important things. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] How SSP will assist DKIM-BASE
Neither an invalid signature nor no signature offers a safe or any significant difference for non-repudiation. Your assumption appears based upon a invalid signature offering greater confidence in a message source than would no signature. On the contrary, less confidence on what a true NO signature condition provides. IOW, by lumping a broken signature, promoted to no signature status, then you have what you say is true. So its not giving it more confidence, but rather it us removing confidence away from the 100% assurance and benefits the ALL and STRICT policy provides. David wanted to see the threats and issues of SSP policies. IMO, this is one of them. Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com +1 This is something that we have been hashing out for a while but for some reason we are still trying to sneak through this verbiage. I believe there is a huge difference between broken and no signature and that this difference MUST be preserved. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue 1530 - replace use of term suspicious
Take your pick: http://thesaurus.reference.com/browse/exception I don't have a problem with exception in this case. I believe that it describes what is happening accurately. Regards, Damon Sauer On Dec 17, 2007 1:00 PM, Michael Thomas [EMAIL PROTECTED] wrote: Jim Fenton wrote: Michael Thomas wrote: Dave Crocker wrote: Jon Callas wrote: Dave Crocker wrote: With the use of language like suspicious, SSP is making value judgement on messages that do not satisfy SSP's criteria, even though those message well might be entirely legitimate. ... How about something like SSP Exception? Metaphorically, it works well with the programming use of the word exception. Folks, In the hope of trying to close some of the easy Issues, would folks comment on this specific proposal, or otherwise post comments seeking closure of the Issue? My suggestion is to just to take the exception/violation reason. For example, all-exception, strict-exception, nxdomain-exception and the like. A single word even if it's value-neutral gives the wrong impression that all exceptions/violations/suspicion should be given the same weight. Just saying what it is that went wrong doesn't do that. +0.5 Agree that a name change is in order, and that we need more than a binary 1/0 result. But exception makes it sound like a kernel panic or something. Hector had some alternative interpretations of exception too. My suggestion: non-compliant/compliant. My original suggestion was violation which still works with nxdomain and other states. I could live with exception though. Mike ___ 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] Re: NEW ISSUE: Simplify SSP decision tree
+1. Enough +1's on this one? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: Re: [ietf-dkim] NEW ISSUE: Restriction to posting by first Author breaks email semantics
On Dec 12, 2007 6:59 AM, Charles Lindsey [EMAIL PROTECTED] wrote: On Tue, 11 Dec 2007 16:09:36 -, Michael Thomas [EMAIL PROTECTED] wrote: Since SSP is about self-imposed limitations on what a domain does, I don't see what the dilemma is in the strict or all practice saying that they don't send mail with multiple From addresses. Considering how rare and out of date this practice is these days, I can't imagine that anybody would even notice. Then in that case you need a tag in SSP to say we never do multiple From:s. -- CharlesH.Lindsey-AtHome,doingmyownthing /dkim/ietf-list-rules.html I am a bit curious about how prevalent this is so I checked a month worth of logs. The only multiple From:'s I could find were from seemingly broken mailers that were putting in duplicate From: lines. Does anyone have any real world examples of where this might cause a basic functionality issue with legitimate MTA's? I am really expecting this to be so far in the fringe that it shouldn't even be on our radar. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Jim's issues - one more try
Issue#1: +1 - include use of XPTR as part of ssp-00 Issue#1: -1 - exclude use of XPTR from ssp-00 -1 Issue#2: +1 - Define how to use a TXT RR for SSP policies (with or without something else) Issue#2: -1 - Don't use TXT at all, only use new RRs for SSP +1 Issue#3: +1 - Define an upward query based approach to finding SSP statements Issue#3: -1 - Define a wildcard based approach to finding SSP statemetns I lean heavily towards -1 but will go for a +1 Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
No, this doesn't change the semantics of DKIM-BASE. The DKIM-Base ignore failures philosophy is basically an invalid signature is exactly the same as no signature at all: no better and no worse. What we're talking about is how the missing/invalid signature case is handled. -Jim The document already covers this case. It assumes that anyone doing so must be a bad actor. Says nothing about good players doing it on purpose :-) 8.7. Intentionally Malformed Key Records It is possible for an attacker to publish key records in DNS that are intentionally malformed, with the intent of causing a denial-of- service attack on a non-robust verifier implementation. The attacker could then cause a verifier to read the malformed key record by sending a message to one of its users referencing the malformed record in a (not necessarily valid) signature. Verifiers MUST thoroughly verify all key records retrieved from the DNS and be robust against intentionally as well as unintentionally malformed key records. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
Damon, You're right. I meant the NO-MAIL policy in my paragraph below. To me, the fundamental natural laws for DKIM or any SIGNING concept is: - I ALWAYS SIGN THIS DOMAIN - I NEVER SIGN THIS DOMAIN - SIGNED OR NOT SIGNED, DO NOT EXPECT MAIL FROM THIS DOMAIN - WE DON'T USE THIS DOMAIN FOR EMAIL. PERIOD. - NO ONE BUT MY DOMAIN SIGNS (no 3rd parties) - OTHERS CAN SIGN (Preferably from an authorized list) It really has nothing to do with the validity of the signature. The mere fact that one of the above may conflict with the domain expectations is a protocol violation in itself. And what is very important, which what DSAP was all about, they can all easily happen naturally in practice directly and indirectly - hence a security issue. -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Agreed. We are on the same page. However, does I sign no mail mean I send no mail? I don't think it does, but I think this is a source of confusion because I have seen the terms mixed several times. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
I have a huge fear that I am beating a dead horse down a rathole. I also fear that I no longer understand what's being discussed. However, I want to make a cryptographic observation. If you create a suitably-sized RSA key, throw away the private key, and put the public key in a DKIM selector, you have made a selector that can't have mail signed from it (or if you want to be really anal, forging a signature for that selector is equivalent to breaking that key). If you then say, I sign all mail for any domain pointing to that selector, you've effectively made a cryptographically enforced no- mail, no-use, etc. domain using the existing Tinkertoys. In short -- saying I sign everything with a non-existent or bogus key is the same thing as saying, You'll never see a valid one of these. Jon Jon, Horse of a different color that has already been hammered down another hole. A message with a broken sig - while less tasty - is still valid message. In general, verifiers SHOULD NOT reject messages solely on the basis of a lack of signature or an unverifiable signature; such rejection would cause severe interoperability problems. However, if the verifier does opt to reject such messages (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and the verifier runs synchronously with the SMTP session and a signature is missing or does not verify, the MTA SHOULD use a 550/5.7.x reply code. If it is not possible to fetch the public key, perhaps because the key server is not available, a temporary failure message MAY be generated using a 451/4.7.5 reply code, such as: 451 4.7.5 Unable to verify signature - key server unavailable Temporary failures such as inability to access the key server or other external service are the only conditions that SHOULD use a 4xx SMTP reply code. In particular, cryptographic signature verification failures MUST NOT return 4xx SMTP replies. Once the signature has been verified, that information MUST be conveyed to higher-level systems (such as explicit allow/whitelists and reputation systems) and/or to the end user. If the message is signed on behalf of any address other than that in the From: header field, the mail system SHOULD take pains to ensure that the actual signing identity is clear to the reader. The verifier MAY treat unsigned header fields with extreme skepticism, including marking them as untrusted or even deleting them before display to the end user. -Also- 8.7. Intentionally Malformed Key Records It is possible for an attacker to publish key records in DNS that are intentionally malformed, with the intent of causing a denial-of- service attack on a non-robust verifier implementation. The attacker could then cause a verifier to read the malformed key record by sending a message to one of its users referencing the malformed record in a (not necessarily valid) signature. Verifiers MUST thoroughly verify all key records retrieved from the DNS and be robust against intentionally as well as unintentionally malformed key records. 8.8. Intentionally Malformed DKIM-Signature Header Fields Verifiers MUST be prepared to receive messages with malformed DKIM- Signature header fields, and thoroughly verify the header field before depending on any of its contents. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
The DKIM Policies Concept design MUST include a I NEVER SIGN or NO SIGNATURE domain expectation concept as a requirement. This is a fundamental protection for the otherwise unprotected DKIM-BASE signature process and now that we are discussing wild cards and sub-domains, this no-signature idea becomes even more prevalent. -- Sincerely Hector Santos, CTO I hope someone can straighten me out on this because I am getting a little confused. There is a difference between I Never Sign and I send no mail. While I actually support BOTH, I didn't think that I Never Sign was in question. Is it? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Single Organization TXT Lookup with Multiple TXT Records Result
What I am suggesting is a bit different. As this label must have a prefix, why not allow the prefix to associate with another domain via a hash? Check the existence of an MX record when no policy record is found. When policy record lookup fails and the MX record exists (we are at two transactions), a third lookup could be for _dkim-all.email-address-domain to determine whether a lack of an association is acceptable. This approach represents the same number of transactions as suggested by Phillip, but also provides a means to curtail a replay-abuse and broken-signature bounce problem. Doing this now ensures at most one additional transaction occurs. This seems well worth it. Doug, Interesting idea. Can you provide an example of how this would work IRL? I am confused about the hash. Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] SSP issues
I don't see how I would end up in a situation where I attach a wildcard to a policy that says all mail is signed. Since NOMAIL is out of scope it is entirely acceptable to present the following options: 1) You can deploy DKIM policy for specific domain records using your existing DNS server. 2) To deploy a wildcard policy you will need to upgrade your server if it does not support new RRs Hence my belief that gating wildcards on a new RR is acceptable while gating policy itself is not. +1 Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
NOMAIL is out of scope, but wildcard is in scope. The relevance here is that it looks like we can get 95% or better coverage of the real use cases here by acknowledging that wildcards are primarily an issue for NOMAIL. It is? If I sign everything for my domain, I'd like to be able to say that for both the top level domain, and all of the subdomains too, right? Mike I think it is better to say, '*' means: ...and everything else. So the subdomains that are not currently signed are covered under the '*' rule. Which begs the question, if ~any~ subdomain is signed, wouldn't the top level have to have to be signed even though it may be .nomail? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC 4871 on DomainKeys Identified Mail (DKIM) Signatures (fwd)
On 5/23/07, Stephen Farrell [EMAIL PROTECTED] wrote: Well congrats and well done to us all! Now we need to get SSP done. Stephen. +1 :-) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Strawpoll on SSP requirement 5.3.10
4 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 1365 yes/no
-1 Keep On 3/2/07, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: This is pretty much my observation. Looking at it in the ternerary terms I suggested for 1368 I would say that the responses were ESSENTIAL : 0% USEFUL:30% NOT NEEDED:60% OUT OF SCOPE: 10% NOT NEEDED combines 'NOT USEFUL' and 'OTHER IMPLEMENTATIONS'. I do want to have the option to return to this on a recharter though. I would like to see us define a policy infrastructure that is capable of being the sole authoritative source of policy for outbound SMTP messaging. To do that I want to first prove proof of utility in the DKIM space then build on that base. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Farrell Sent: Friday, March 02, 2007 12:37 PM To: ietf-dkim Subject: Re: [ietf-dkim] 1365 yes/no So far I've seen about two to one in favour of eliminating this requirement so I guess Mike should not include it in the next rev. Not that many opinions though (12, incl one offlist) so if a storm of people show up saying that's wrong it can go back in where we're making the changes after WGLC. Stephen. ___ 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Additional lookups
It could be considered as a way of faster adoption. If I am a receiver and I am getting a lot of spam because I am not able to verify a particular algorithm, then maybe I should start... Self-correcting issue. Regards, Damon Sauer On 3/3/07, John L [EMAIL PROTECTED] wrote: What is at issue is not what the sender thinkg of the algorithm. All that is at issue is describing what they do Understood, but since what the sender does in this case has no effect on how a receiver handles incoming mail, there's still no point in publishing it. R's, John ___ 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] Re: 1368 straw-poll
Folks, Before we take a straw poll on solutions, perhaps we should take one on problems? The proposed mechanism incurs an additional lookup for every signed message. I don;t understand this statement. Can you clarify please? How would this happen exactly. The goal of this mechanism is to deal with a potential danger, during a transition. We can assume that there will, indeed, be transitions. Whether we can assume that there will be danger in using the older algorithm is the question. Yeah.. I regularly crack PGP with my morning coffee now-a-days :) Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Policy
I keep getting left off the acknowledgements section :-P. Guess I have to try harder not to cause the authors to get too upset at me ;-) OK, I will jump in with both feet-- In as far as signing, I think we had discussed before that an intermediary (I sign SOME mail) would be worthless without being able to communicate the cases in which the email MUST be signed. Regards, Damon Sauer On 2/21/07, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: I think that there is plenty on policy to keep us busy. I see three (related) questions: 1) What is the range of policy statements that should be supported? PHB: [DKIM[=keyselector]? ] * (signing is all or nothing, multiple signatures may be specified). Others: ? (does anyone argue for DKIM-Somethines as an actionable policy) 2) What syntax should be supported? PHB: Tag-value pairs, DKIM is a tag Other possible extension tags are for other protocols: SPF, PHISHED, DKIM-TEST, SMIME, PGP, etc. Others: ? (This answer depends on the andswer to 1, if you have a great deal of expression in your policy language then a DKIM language might be appropriate). 3) What should the discovery mechanism be? PHB: Finese the wildcard issue with a pointer record Reuse of PTR prefered but a new RR is acceptable Others: ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Farrell Sent: Wednesday, February 21, 2007 10:01 AM To: Barry Leiba Cc: IETF DKIM WG Subject: Re: [ietf-dkim] draft-ietf-dkim-base-10 submitted Barry Leiba wrote: The DKIM base draft has been updated and submitted. The changes are minimal, comprising response to IESG review and some XML updates intended to smooth the rfc-editor review. And the -base-10 draft is now on its way to the RFC editor queue,[1] having passed IESG review. Many thanks to everyone who worked to get this done. And now we just wait for the RFC editor process, and the RFC number for the Proposed Standard. And get active on SSP again. (Or should I cancel the Prague meeting slot? So far we've little to discuss it seems.) S. ___ 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Collection of use cases for SSP requirements
On 12/9/06, Hector Santos [EMAIL PROTECTED] wrote: Dave Crocker wrote: old news, but i'm trying to catch up. Steve Atkins wrote: While I strongly agree with this interpretation of dkim-base, some have argued that there are three states in dkim-base: signature verification suceeds, signature verification fails and no signature. Since -base explicitly direct a failure as being equivalent to no signature, that leaves a total of 2 states: 1. GoodSig 2. NoSig Unfortunately, it will probably not have that effect when it all said and done - Cry Wolf Syndrome. FAILURE SIGNATURE == NOSIG has no logical basis for it. In short, when systems begin to see an avalanche of DKIM failures, a pattern of NOSIGS will not be ignored. --- HLS +1 I understand what we are trying to accomplish - not treat harshly any valid messages that for some reason get their sigs munged. I am wondering how often this ~actually~ happens. I submit that spammers will take advantage of this in the hopes that the fallback rule will treat them more kindly. I also believe that once sysadmins see the volume of failed sigs- a failed sig will be treated harshly or checking will be turned off to save the overhead of checking something that offers no value if it checks bad- whether we say it is legal or not. The volume of bad vs. good will be as it is now. Why waste the cycles? Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Blocking improperly signed messages
Since you brought it up... No mailing list (or other _ Spam_ ) corruption of an email in transit _or just plain spam_ can do anything worse than change the delivery of a legitimate _or purposely munged_, DKIM-signed email into the delivery of a legitimate _or more likely illegitimate_ non-DKIM-signed email. It's not until you hang the SSP bag on the side that this has any _positive_ snipnegative impact on _il_legitimate email usage. Cheers, Steve The volume of spam is now -- what-- 7 out of 10? Doesn't BAD=NOSIG seem, even a little, useless... Especially at the cost of decoding it at our current volume levels? Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Blocking improperly signed messages
On 12/11/06, Steve Atkins [EMAIL PROTECTED] wrote: (Just background for Damon, and anyone else in the same frame of mind, nothing SSP or DKIM specific here). Were you around for the fiasco that was SPF? That's where a lot of our operational experience of throwing away perfectly good mail, simply because it wasn't transmitted in a way that followed the dogma of the message signers came from. I don't think it was a fiasco. I believe that it was the first attempt at doing ~something~ meaningful. There were many intelligent people involved, many are still here and still involved. (Nods to Dave, Hector, Scott, Douglas, and others). Please note the date on this post (an interesting historical read :) - http://www1.ietf.org/mail-archive/web/asrg/current/msg00334.html DK wasn't even around yet. The real death knoll came with MS decided to license our next step just as we were getting there (PRA). All in all I believe that it was an excellent learning experience. Too bad many of the lessons from it are still not learned. It was, basically, a failure, in that the SPF policies (which are very much equivalent to SSP) that are published are almost ?all, which is pretty much equivalent to I sign some things in SSP speak. And ?all is/was supposed to be temporary. But I do know many domains that protect themselves with SPF. If an admin inadvertently posts a bad SPF, it can be fixed. You are missing the point. You are pointing to the fact that valid mail is thrown away and saying SPF is broken. I point to it and say- It is working exactly as it should! It is an administrative issue, not a technical fault. SPF was NOT supposed to block spam, it was an attempt at validating where the email is/should be coming from. The real issue as I see it is admins discovered they really don't know the extent of their own infrastructure. Hence all the ?ALL's. I believe that I remember a thread asking what we are going to recommend people do when sig validation fails. From an operational side, I would say that it would be nice if I got a rejection notification but only from email that ~also~ passed the SPF check. SSP does not do what SPF does. SPF isn't dead or even sick, just misunderstood. SSP lets admins have granular control over their rules. People wouldn't tolerate mail being thrown away for no good reason, nor were even the developers of SPF prepared to modify the way in which they forwarded email around in order to work around the flaws of SPF. As those involved will tell you... this was because it was watered down and good suggestions from people like Hadmut Danish were not even considered. Hadmut finally got tired of it all and stopped participating... which is too bad. Have not heard from him since. There seems to be some belief that if SSP does exactly the same thing as SPF then we'll pull the phishing-proof, spam-resistant mail architecture out of the hat this time. I am going to get my knuckles rapped again by the chairs for this trip down memory lane so I will stop here. Since Base is closed to the type of modification I would have hoped to see, I am looking forward to debate on SSP. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: Applicability of SSP to subdomains
I think the answer lies on the application side: Should DKIM/SSP offer domains the ability to have two or more policies with the same base domain? Example: public.santronics.com- a more relaxed option policy santronics.com - exclusive policy --- HLS Hector, I believe they should. Many mail systems I have been involved with have things like: news.example.com critical.example.com mail.example.com statements.example.com etc. Some of these sub domains are outsourced to ASP's. While there is an issue with wild cards, I think that if a site wished to implement this type of solution, un/wild carding the domain would be on the check list of things to do to implement the solution. Or.. could the parent domain provide the information for each of its sub domains in its record somewhere? Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Role of Sender header as signing domain
One really wants to be able to trust something. As it currently stands, by allowing any bad actor an ability to replay any message from a white-listed domain prevents trust from ever being established. Trust MUST be protected as an ssp-requirement. Trust requires an ability to associate the SMTP client, the MailFrom, and other email-address domains within other headers with that of the signing-domain. DKIM MUST be able to protect trust that might be established from abuse. These associations as an ssp-requirement provides this protection. -Doug Section 1.1 DKIM separates the question of the identity of the signer of the message from the purported author of the message. In particular, a signature includes the identity of the signer. Verifiers can use the signing information to decide how they want to process the message. The signing identity is included as part of the signature header field. In this case, wouldn't it be better to say: DKIM separates the question of the identity of the signer of the message from the purported author of the message. In particular, a signature includes the identity of the signer which can be traced to a specific author or first party signer. Verifiers can use the signing information to decide how they want to process the message based on the reputation of the author. The signing identity is included as part of the signature header field. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Role of Sender header as signing domain
+1 Damon Sauer On 11/29/06, Douglas Otis [EMAIL PROTECTED] wrote: On Nov 29, 2006, at 3:42 AM, Eliot Lear wrote: Charles Lindsey wrote: I utterly fail to see why what is displayed to the user is of the least relevance. Because it's very possible UAs will indicate whether a message is signed or not. This is already done with various plugins. The same plug-ins can also verify an associative policy regarding other headers as well. Being signed might be for entities found in the 2822.From, the 2822.Sender, or for the 2821.MailFrom (to help ensure DSNs). Annotation of a message being signed by itself is of little value. Being signed and recognized is what is important when the desire is to curtail spoofing. This recognition should not be visual. Because a great deal of email is sent by entities not found within the 2822.From header, being able to recognize other headers becomes important when extending protection for this portion of the email traffic. Leaving holes in what gets protected only invites abuse. -Doug ___ 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] Re: ISSUE: Better definition of DKIM signing complete required
On 11/28/06, Michael Thomas [EMAIL PROTECTED] wrote: Hector Santos wrote: It depends on how mixed failure and success is interpreted. DKIM-BASE says as long as one signature is valid in a multi-signature message, the message is valid. Failures MUST be ignored as if it was never signed. There is something not very kosher with that. That's incorrect. DKIM says nothing about messages being valid or not. Only signatures. Mike Cluck- The signature validates the authenticity of the message by verifying the sender (loose definition). If paypal sets up a rule that is something less than I sign all and be cruel to messages purporting to be from me without valid signatures, then DKIM-BASE in the case of a spammer putting a RND# in the signature field, fails to do anything other than waste CPU cycles. Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 1365, with a question about the we never send mail
+1 Sorry.. no time to reitterate what has already been said. Regards, Damon Sauer On 10/14/06, Scott Kitterman [EMAIL PROTECTED] wrote: On Thursday 12 October 2006 14:51, DKIM Chair wrote: That left issue 1365, with a question about the we never send mail issue. The initial proposal was to remove the text, considering it to be a special case of strict, but when Doug opened that back on the list there was significant support to keep it. I'll put that back out to the list now (please put the issue number in the subject line): If you object to leaving it in, please say so and say why. I think that being able to express 'we never send mail' is important. There is already one way to express this defined as part of an experimental protocol in RFC 4408 that has significant deployment. While that is a controversial protocol in general, I do not think that most of the controversy applies to domains that send no mail. That one piece could be broken out in a separate draft without carrying forward the aspects of the experimental protocol that some find problematic. Instead of defining yet another way to express the same thing (which may at least be arguably outside the charter of the group), an alternative approach might be for this working group to punt 'we never send mail' back to the AD/IESG (I'm still hazy on lots of IETF process, so forgive me if that's the wrong direction) with a recommendation that this is something the group feels will support receivers in evaluating DKIM signed mail, but that the group felt was better addressed elsewhere. Scott K ___ 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] 1359: ssp-requirements-01 // Outsource First Party Signing concerns extended
+1 I can't attend due to firewall restrictions it seems. (*sigh*) But I think there is plenty of positive concensus on this AND https://rt.psg.com/Ticket/Display.html?id=1358 -DKIM Strict- Regards, Damon Sauer On 10/11/06, william(at)elan.net [EMAIL PROTECTED] wrote: On Wed, 11 Oct 2006, Stephen Farrell wrote: Doug, That was agreed to be closed on the jabber session. No-one spoke against that, so please consider this closed/rejected. You're quite wrong. Number of people spoke - just not on the jabber. You're abusing jabber as means of making decision for WG items - jabber is just a discussion forum for some group of WG participants but as per IETF rules all decisions are really done based on discussions on the list. --- William Leibzon Elan Networks [EMAIL PROTECTED] ___ 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] open jabber issue: ssp-requirements-01 // Req. forDoes Not Send
On 9/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Leave it in Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] +1 Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC 4686 on Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
All the threat listed in the document require some sophistication on the part of the spammer. Would this mean the end of the basement spammer if widely deployed? I also see (not listed in the document) a long deployment time a threat. Notice that spammers were the first to jump on the SPF band-wagon and made their domains SPF compliant. Some people pointed to this as an SPF failure and asked themselves what the point was to deploy it. This caused the garage spammer to live on. Hopefully this document does not raise the question What is the point of deployment? but is used, in part, to show the hoops that spammers will have to jump through. Any time you make it more difficult (and therefore more costly) for a spammer to spam, you start to thin out the players. Just food for thought. Regards, Damon Sauer On 9/27/06, Stephen Farrell [EMAIL PROTECTED] wrote: Well done to all concerned, esp. Jim of course! S. rfc-editor@rfc-editor.org wrote: A new Request for Comments is now available in online RFC libraries. RFC 4686 Title: Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) Author: J. Fenton Status: Informational Date: September 2006 Mailbox:[EMAIL PROTECTED] Pages: 29 Characters: 70382 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dkim-threats-03.txt URL:http://www.rfc-editor.org/rfc/rfc4686.txt This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks. This memo provides information for the Internet community. This document is a product of the Domain Keys Identified Mail Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New issue: Requirement #10 - Invoking SSP - Suggestion to Remove this.
Hector, How about: 10. The Protocol MUST NOT be required to be invoked if a valid first party signature *and* valid first party policy is found. I believe that the _MUST NOT_ was put in so that implementers do not continue to process even though a valid sig and policy are found and this was the way to enforce it. Taking it out would open up a whole new problem with whose policy is most valid? etc. My vote is for leaving it in but changing the wording to address the issue you brought up. Regards, Damon Sauer Now that I think about it for one second longer... isn't it considered a valid first party sig because of policy? Wouldn't a broken policy invalidate the first party sig? Maybe we do not have to change this at all. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: New Issue
On 9/22/06, Frank Ellermann [EMAIL PROTECTED] wrote: Michael Thomas wrote: [never send mail] I think that this subject has been pretty well beaten to death Yes, this could be a question about the purpose of MUST in the requirements: If SSP proper doesn't saddle this dead horse it's IMO still okay, not lacking a required feature. If it was just strict, I can see reasons why you might want to be more careful. Yes, never send mail is a nice to have feature at least for SID-unaware senders / receivers (SID-unaware includes most of SPF, just for the records). Maybe say SHOULD or MAY. Frank Being an administrator, any time you give me more low hanging fruit that I don't have to process, the more money you save me. Because this translates into dollars/yen/rials whatever :) I am all for this feature. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New issue: Definition of DKIM Signer Complete
When policy allows for an association to be made to other domains, then this definition would be constraining that choice. Allow policy to define what is a valid signature for a particular email-address field or parameter. -Doug +1 Note: Try as I might, I was not able to get logged in. Sorry I missed this session. Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] SSP = FAILURE DETECTION
On 9/12/06, Michael Thomas [EMAIL PROTECTED] wrote: Wietse Venema wrote: What was the advantage of SSP with look-alike domains? To find large unproductive ratholes? Neither DKIM or SSP claim to have any direct effect on look-alike domain names, and there's nothing in our charter that says that we'll be doing anything about that ever. DKIM/SSP are two pieces for a much larger set of things that need to come together to combat phishing including software layered on top of thse base authentication mechanisms, user base training/human factors, and law enforcement -- most of which will not have any IETF involvement at all. No amount of hand-wringing here is likely to tell us how this will ultimately play out. Mike +1 Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] SSP = FAILURE DETECTION
On 9/11/06, Douglas Otis [EMAIL PROTECTED] wrote: On Sep 11, 2006, at 8:04 AM, Thomas A. Fine wrote: With SSP, I can only receive mail that looks ALMOST like it is from one of my orgs. This is huge. This gives the user layer the ability to quickly, accurately, and precisely differentiate between fake and real messages. That's what SSP accomplishes. When a strong email-address policy assertion that disrupts the use of common services might block exact spoofs. SSP does not differentiate real messages. As far as what happens in the user layer, no specification can control that. We can certainly predict that a significant number of people will still fall for look-alike domains. An association with a retrained email-address will curtail look-alike attacks and clarify which messages are real. For this, the signing domain must offer an assurance that the email-address is valid as well. But this is vastly different than people falling for the exact valid email address they were expecting. Deploying just this mechanism will likely provide a minor impact upon the spoofing success rate. It may however have a major impact upon the delivery rate of valid messages. What are we here for if we aren't here to fix that? To offer a comprehensive solution that offers genuine protection without impairing email delivery. -Doug My father used to tell me that locks were to keep honest people honest and give those that wish to get through a dickens of a time doing it. A lock will not ever stop someone who is determined to get through it. In this case, I believe that it will give those that want to get through SSP a whole new set of locks to bypass. There are only so many look-alike domains compared to as it is now, being able to come from anywhere. If we were able to just focus on look-alike's (as an admin) it would make things a lot simpler. I believe that we ARE trying to offer a comprehensive solution and outlined in exacting detail on just how we are going to do it... which is a lot better than someone suggesting Nirvana and no clear idea as to what someone means when they suggest another comprehensive solution that offers genuine protection without impairing email delivery. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Additional per user policy requirments
On 9/5/06, Frank Ellermann [EMAIL PROTECTED] wrote: Stephen Farrell wrote: As Doug said that predates the WG. The WG charter says policy (incl. the quotes) and mentions draft-allman-dkim-ssp once reqs-01 is out. we're planning to move back into using the issue tracker, so you can of course raise this as an issue if you like Yes. I fear the SSP adventure is over, PRA is bad, anything else is impossible. On the SPF lists folks tried for years to invent wild and wonderful new identities in addition to the Return-Path, and they all failed miserably, incompatible with 2822, only PRA makes remotely sense. This first address of the From can't work. Maybe you could get the RFC 2822 author as external expert about this idea, IIRC he was also invited to comment on some MARID proposals. Frank Only because people insist that it *must* work in every scheme they can make up. I believe that we could implement what we have discussed and the fact that it won't work for everybody should be an asterisk. It will work for most systems and I am comfortable with that. Implementation is not a requirement. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Additional per user policy requirments
On 9/6/06, Douglas Otis [EMAIL PROTECTED] wrote: On Wed, 2006-09-06 at 10:08 -0400, Damon wrote: Only because people insist that it *must* work in every scheme they can make up. I believe that we could implement what we have discussed and the fact that it won't work for everybody should be an asterisk. It will work for most systems and I am comfortable with that. Implementation is not a requirement. What percentage of domains want to experience delivery issues when the 2822.From address is not signed by the same domain? An annotation scheme aimed at assuring an originating address should be able to satisfy virtually all domains. Introduce an optional m=email-address parameter to both the signature field and the key. This optional parameter could then work in conjunction with a designated domain when assuring this email-address. (Some might call this address a PRA, but it would not depend upon any proprietary algorithm.) An optional parameter added to the DKIM signature header not limited to a specific domain, as well as policy records that can associate signing domains with these other domains and offer far better coverage. Making this change would permit the largest percentages of the email-addresses to be assured by DKIM, while also permitting simple autonomous administration. This would fully leverage the capabilities of a policy record, where its administration also has a chance of scaling. -Doug Why not both? I have no issues with using both. I am not seeing this as a this proposal against that proposal. I think they both have their place and we will be serving the community as a whole much better by offering a choice between two schemes rather than one or none. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] user level ssp
On 9/6/06, Douglas Otis [EMAIL PROTECTED] wrote: On Sep 6, 2006, at 10:14 AM, Michael Thomas wrote: All of this talk about additional requirements for user level ssp ignores the basic question: should there be any requirements for user level SSP at all? If so, what are the use cases? I'm not terribly convinced that even that has consensus -- this is the first that I even recall the subject being raised. When a large financial institution wishes to have a specific email- address receive added assurances via annotations, then having a means to include these addresses within policy satisfies this desire without specific arrangements made separately with each verifier. The current strategies for financial institutions require an assertion that _all_ messages be signed. Not all messages from a large domain warrant receiving annotations of added assurances however. Having a means to convey which email-address warrants this annotation can be accomplished via policy. Rather than a direct translation into a DNS label, a base32 encoding of a SHA-1 hash ensures long local-parts, UTF-8, and subaddress symbols can be handled by this scheme. (SHA-256 could be used, but there does not seem to be a need for this extreme.) -Doug +1 Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Responsibility concerns with DesignatedSigning Domains
H, maybe we have a compromise here with a special policy? I don't care if 3rd party exist, I don't want them, but if they DO exist, it BETTER not destroy my 1st party signature. I will agree to this, as long as the 1st party can say I always sign and I have the expectation that an unsigned message from me will be treated with extreme prejudice. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Responsibility concerns with DesignatedSigning Domains
A rare policy will expend greater efforts searching each 2822.From for policies up name trees that in the end are unlikely to exist. Even if DKIM were being used, the suitable default is implied when nothing is published. A repository listing phished domains would likely gain greater adoption and consistent use by DKIM verifiers. This repository could identify those being phished as well as their look-alikes. -Doug In reality, I don't think that heavily phished domains would have very deep trees. So assuming this to be true, I sign everything because I am at risk would still have a benefit. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] there is no such thing as a valid dkim-base *message*
On 8/28/06, Michael Thomas [EMAIL PROTECTED] wrote: Hector Santos wrote: Subject: Check your account Date: Sun, 27 Aug 2006 05:04:42 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] DKIM-Signature: d=bank.com # invalid 1st party DKIM-Signature: d=asp.com... # valid 3rd party [...] According to DKIM-BASE, the valid 3PS signature would make this an valid DKIM message, even if the 1st party signature failed. I'm afraid that this is a pretty fundamental misunderstanding of what dkim-base does and does not provide. DKIM-base does not say whether a given message is valid: that is not something that it can say with any accuracy. It does provide a mechanism for a receiver to determine whether one or more dkim signatures are valid. How those (in)valid signatures are evaluated by the receiver is out of scope of the protocol. IMO that the contention that remains is how this mechanism is to be used and interpreted and a particular signing level. Providing a level of valuation is not a dictation how that valuation is used. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] there is no such thing as a valid dkim-base *message*
Correction to my previous: IMO that the contention that remains is how this mechanism is to be used and interpreted at a particular signing level. Providing a level of valuation is not a dictation how that valuation is used. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Policy Discovery
To: Thomas A. Fine [EMAIL PROTECTED] Finally! Someone from Harvard proofing some of my previous points... How do you like them apples? ;-) Thomas, What are your suggestions? Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Responsibility concerns with DesignatedSigning Domains
On 8/27/06, Frank Ellermann [EMAIL PROTECTED] wrote: Douglas Otis wrote: Look-alike exploits exist without designated domains. Sure, but they sail under their own look alike flag. They can't steal the reputation of an ISP with millions of zombies for their criminal purposes. Admittedly that reputation won't be good, but still better than eboy = unknown stranger. How is this any different than what we are doing with reputation systems based on IP right now? Seldom does less information improve security however. Make sure that eboy is treated as the unknown stranger it is, even if isp.example.com signed it, and there's no problem. An eboy-SSP trying to change this should be ignored. Basing reputation on key provider wouldn't be prudent. If I were a less than honorable person, I would send all my spam using someone with a good reputation (goodrep.com) as my DSD. My sig fails because I purposely munged it, there is no policy saying that this should definitely be rejected. Because goodrep.com can not publish all of the domains that it signs for, it is helpless to do anything about this. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Responsibility concerns with DesignatedSigning Domains
The provider still must be diligent. DKIM helps from the reporting side. The 2822.From can not be held accountable as it can not be verified as being culpable. A designated domain involves trusting the signing domain. Trust alone can not be defended with respect to reputation. -Doug Doug, I am in agreement with you 99% of the time... here is my 1% :) The provider still must be diligent. IMO and extensive experience, some of the largest are not diligent at all... not because they don't want to be... but because they are understaffed, underfunded, and underpaid. If diligence is any sort of hinge pin, I don't expect it to be successful. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision
DSD = Delegate Signing Domain: additional mechanism to delegate the signing authority from the ((author)||(domain)?) to a 3rd party signer. D'KIMAYESIAN = My t-shirt submission ;-) Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] T-Shirt Entries
On Fri, 25 Aug 2006 10:36 -0400, Scott Kitterman [EMAIL PROTECTED] wrote: Mine: DKIM = Who you are DKIM != What you are Scott K The matter, I hope, is not great, sir, begging but a beggar: Cressida was a beggar. My lady is within, sir. I will construe to them whence you come; who you are and what you would are out of my welkin, I might say 'element,' but the word is over-worn. - Shakespeare's Twelfth Night ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision
The receiver has a fourth piece of info, his address book (any white or black list). In a parallel thread about filters Phil or John just discussed again that a DKIM PASS or similar from unknown strangers is pointless. With over 84% probability it's spam like any other mail with or without signature (based on 95% probability unsolicited mail minus 11% misdirected bounces, I don't recall where I read this some weeks ago). So for your scenario, if you don't have [EMAIL PROTECTED] in your address book, and you also don't have [EMAIL PROTECTED] in your address book, then you simply do not care what this is. There are 12,434 employees worldwide at my company that are either sales people or handle some sort of customer service where email is 'directed' to them. I hope that you are not suggesting that DKIM is pointless unless you already know the person that is sending to you. Although... now that I think about it- I agree with you! In my opinion, I am agreeing with you due to the lack of specific rules covering who can and cannot sign for me and when/how do I expect my policy to be enforced. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision
On 8/24/06, Michael Thomas [EMAIL PROTECTED] wrote: Damon wrote: In my opinion, I am agreeing with you due to the lack of specific rules covering who can and cannot sign for me and when/how do I expect my policy to be enforced. This is factually incorrect. Dkim-base has very clear and unambiguous rules about who can sign for you. It would be helpful if you became acquainted with them. Mike Really? How so? Can I say that any email coming from xyz.example.com MUST be signed and if it isn't, toss it in the bit bucket even if my ISP signs it? Can I also go on to say, any email coming from abc.example.com may or may not be signed, but if it is, it needs to be MY signature. EHLO xyz.example.com MAIL FROM: [EMAIL PROTECTED] RCPT TO: [EMAIL PROTECTED] From: [EMAIL PROTECTED] and apply a policy that says this mail may or may not be signed. and also be able to say: EHLO abc.example.com MAIL FROM: [EMAIL PROTECTED] RCPT TO: [EMAIL PROTECTED] From: [EMAIL PROTECTED] and apply a policy that says this mail MUST be signed, if it isn't deliver it to null? and then say: EHLO myASP.test.com MAIL FROM: [EMAIL PROTECTED] RCPT TO: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] and apply a policy that says this mail MUST NOT be signed because I am outsourcing my advertising to someone I may trust but I have no control over them and I never ever want it confused with my abc.example.com email which is a huge phishing target? I don't know... this seems like a typical scenario to me.. If it can't do this, or even come close, then Mike, you have not read a word I or Hector or others have said. I don't know if this should surprise me or not. Aren't you the person that is going to be writing this document? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision
What do we do when there is no signature and no d= domain to work with? This is sort of hazy in my mind. Regards, Damon Sauer On 8/24/06, Michael Thomas [EMAIL PROTECTED] wrote: Damon wrote: On 8/24/06, Michael Thomas [EMAIL PROTECTED] wrote: Damon wrote: In my opinion, I am agreeing with you due to the lack of specific rules covering who can and cannot sign for me and when/how do I expect my policy to be enforced. This is factually incorrect. Dkim-base has very clear and unambiguous rules about who can sign for you. It would be helpful if you became acquainted with them. Mike Really? How so? Can I say that any email coming from xyz.example.com MUST be signed and if it isn't, toss it in the bit bucket even if my ISP signs it? Can I also go on to say, any email coming from abc.example.com may or may not be signed, but if it is, it needs to be MY signature. It would be helpful if you didn't conflate too many things at once. I've heard you say on more than one occassion that you believe that DKIM doesn't have the ability to constrain who signs on your behalf. That's incorrect. That constraint is provided by the requirement that the domain holder place a selector into their DNS for the signer's d= to hold true. The domain holder is thus in control who signs with their domain name. I'm not commenting on the rest, just that particular aspect. Mike EHLO xyz.example.com MAIL FROM: [EMAIL PROTECTED] RCPT TO: [EMAIL PROTECTED] From: [EMAIL PROTECTED] and apply a policy that says this mail may or may not be signed. and also be able to say: EHLO abc.example.com MAIL FROM: [EMAIL PROTECTED] RCPT TO: [EMAIL PROTECTED] From: [EMAIL PROTECTED] and apply a policy that says this mail MUST be signed, if it isn't deliver it to null? and then say: EHLO myASP.test.com MAIL FROM: [EMAIL PROTECTED] RCPT TO: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] and apply a policy that says this mail MUST NOT be signed because I am outsourcing my advertising to someone I may trust but I have no control over them and I never ever want it confused with my abc.example.com email which is a huge phishing target? I don't know... this seems like a typical scenario to me.. If it can't do this, or even come close, then Mike, you have not read a word I or Hector or others have said. I don't know if this should surprise me or not. Aren't you the person that is going to be writing this document? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision
On 8/24/06, Jon Callas [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24 Aug 2006, at 10:38 AM, Damon wrote: What do we do when there is no signature and no d= domain to work with? This is sort of hazy in my mind. You do anything you want to do. Perhaps more correctly, you do what you're doing now. If there's no signature, it's not a DKIM message. Jon Even if my policy states that it must be signed? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision
On 8/24/06, Michael Thomas [EMAIL PROTECTED] wrote: Damon wrote: What do we do when there is no signature and no d= domain to work with? This is sort of hazy in my mind. That's an orthogonal question to your first assertion, and is the very subject that SSP attempts to answer. My only point here is that dkim-base does give you control over who signs in your domain's name. That's an already solved problem that needn't be revisited by SSP. Mike I don't subscribe to the Word of the Day but orthogonal is indeed what the question was. I completely understand that I have control over whom may sign for me. The issue I have is the granularity and selectivity's of the policy. See my earlier example. This is exactly (minus the fake domain names) what I am doing right now on a very large scale. So it is a very real world example. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buydesigndecision
On 8/24/06, Hector Santos [EMAIL PROTECTED] wrote: - Original Message - From: Jon Callas [EMAIL PROTECTED] To: Damon [EMAIL PROTECTED] On 24 Aug 2006, at 10:38 AM, Damon wrote: What do we do when there is no signature and no d= domain to work with? This is sort of hazy in my mind. You do anything you want to do. Perhaps more correctly, you do what you're doing now. If there's no signature, it's not a DKIM message. Then this is a MAJOR loophole and it causes harm to verifiers and users, never mind to domains who did not expect this. It lowers the payoff for verifiers to even support DKIM and get this: Spammers now do not need to bother with DKIM. A zero cost do nothing technological discovery! If we can resolve this, the value of DKIM-BASE has been watered down tremendously. +1 I hired an alarm company to protect my house. They put an alarm on my front door. I use it thinking it is protecting me and under every window there is a sign that says Burglars Enter Here! and a sign on the front door that says The key is under the mat. I don't want to have to purchase not one more box or peice of software that is going to protect me by managing all my keys, relationships, and make reports on the trust levels of everyone else in order to make this work. I will say the magic word... Please. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Clarification: Section 5.1 Last Paragraph.
If an email cannot be signed for some reason, it is a local policy decision as to what to do with that email Since this is in the Signer section, it would imply that it is up to the sender. But it is implied. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision
And I think after re-reading what you said.. that we are saying the same thing. So... I am just re-re-reiterating what Jon said. Color me red. Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision
You do anything you want to do. Perhaps more correctly, you do what you're doing now. If there's no signature, it's not a DKIM message. Jon Even if my policy states that it must be signed? Whoa, whoa. Hang on. A signing policy is something that exists for the *receiver*. If you get a message that has no signature, your policy doesn't come into play. The *sender's* policy comes into play. Stop Horse. This is lowest denominator of where we disagree. What's the point of ~having~ a policy for my signature if the receiver is just going to make up his own anyway. Can they? Sure they can... and I can drive my car 140 mph on the freeway if I want. That is not the way it is going to work. The sender, having gone through all the trouble of creating a policy is going to expect and in my opinion, should have every reason to expect, that that policy is going to be honored. I think we can both agree that the receiver is going to do what they want anyway, but these people are not free radicals, they are going to do what your policy says to do and if we don't allow the language that is going to be used in the policy to make it useful AND encompassing, then we are going to seriously hamstring this whole thing. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Keys vs. Reputation
On 8/22/06, Douglas Otis [EMAIL PROTECTED] wrote: On Tue, 2006-08-22 at 05:54 -0400, Hector Santos wrote: But 99% of the times or lets just say it is expected police protocol and practice for a traffic stop that if there is a problem with your Driver's license; the photo, the sex, age, height, etc, it is simply not quite consistent which what he is seeing in reality, at this point, there is increase scrutiny and by Police Protocol and Practice he should radio the HQ database (i.e., Reputation Service) to find out if there anything bad or new to find out about you or the vehicle you are driving. Most bad actors are not fools. Playing a hard nose cop will block vastly more legitimate email than spoofing attempts. Due to look-alike and internationalization issues, the ultimate solution can not rely upon failed concepts that attempt to impose a problematic authorization scheme. Who can afford an increase in phone calls and complaints anyway? 2822.From policy is best used to indicate which 2822.From addresses are valid. With DKIM and this policy, the number of messages that can be discerned to have a valid 2822.From address can greatly increase without imposing hardships. Policy does this by permitting autonomous administration. When the MUAs annotate messages that are both found in the Address Book, and appear to be signed with valid 2822.From addresses, look-alike and internationalization exploits will have been thwarted. This prevention does not rely upon a reputation or an authorization scheme. A great deal of legitimate email will not be assured to have a valid 2822.From address. Over time that may change. Nevertheless, DKIM can restore trust in the 2822.From address, especially for critical messages. This trust must not be based upon visual examination. The bad actors are too good at creating forgeries. The MUA must implement the final check at the highest resolution possible. The MTA can not achieve the same level of scrutiny. Perhaps a 2821.MAIL_FROM policy of a designated domain list can provide an association with the DKIM signing domain. These associations could improve upon the MTA triage process without DoS concerns, but not as a type of authorization scheme and without the badges. : ) Wow, that was a lot of typing to try and convince me that everyone hates more phone calls and trouble tickets and therefore we should punt. Are you saying that you see NO value in it or so little value that it would be statistically insignificant? Remember- it is OPTIONAL. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision
It sounds like what you and few other people want is an SSP policy that says if you receive a message that is supposedly from this site (for some definition of from) and it doesn't have the mark that says that XYZ is authorized to sign the message, assume the message is forged. Is that a correct summary of the requirement you see? I am glad you put a question mark at the end. It took me a while to read through this can of worms, but for every argument against the optional flags that myself, Hector, and I few others are looking for, I see contrary arguments that only bolster the point that these thing we are hinging on are OPTIONAL. Just because they are OPTIONAL does not automatically make them irrelevant nor unnecessary. I have yet to see an argument that shows where they are technically unsound in everything but statistically insignificant situations, which in my opinion is the litmus test for dismissal. I really did not want to see this turned into an 'us' against ya'll discussion. (ya'll _is_ a word in Georgia) But arguing against something that a) Is technically sound b) Would benefit many entities c) is OPTIONAL, to me, sounds like ya'll are being contrary just to be contrary. And if the 'Ya'll' shoe fits... please don't take this as a personal attack. I have always been impressed with the amount of intelligence in this group and I consider each and every person in it my friend and colleague. I can't name many people in this group that are less eloquent than I, so I have chosen a few points to high lite. Also, it seems to me that people are not really reading what Hector is taking a lot of time and thought in putting forth. While I may not always agree with approach, I mirror his technical points. Hector and I have not always seen eye to eye in technical discussions in the past, but I believe (and have experienced) that both of us submit to better arguments. I notice that neither of us is budging on this point. -Hector Santos- But we also want the option to control the potential abuse this open-ended 3rd party signing can caused as it been shown can and will happen. The SSP people provide all the OPTIONS, the relaxed and the strong, the restricted and unrestricted, including the relaxed to no-policy concept you guys seem to want. By You guys I meant those who have shown to be nearly 100%consistently opposed or resistant to any kind of 3rd party signature restrictions which has been the numero uno basis division going back to MAILSIG. I see no technical reason not to allow for strong/restrictive policies. -Michael Thomas- I wish you'd stop putting words into people's mouths. There is a major disconnect between your understanding of what is needed and as far as I can tell just about everybody else's. -- I am baffled by the above statement. -Hector Santos- The fact is you have not being trying very hard to tell because there are clearly people here who have expressed repeatedly the benefits of allowing restrictive 3rd party policies, if so desired by the domain. That's the kicker here, its all OPTIONAL yet, you are not even open to making it an option. So who is more open-minded here? -- I could not have said this better myself... hence the cut and paste. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision
OTOH, it seems to me that it's been said Ad Nauseum. Where feasible I agree it's better, but there are operational frictions that will impede this approach in some cases. What I believe that we've discovered is that this isn't nearly simple as some people hoped. Doing as little up front as possible so that you can get operational experience is almost certainly better than guessing -- especially when the guessing wrong is a likely outcome. In this particular case, I dooubt there will be harm because receivers will always have an incentive to make better decisions (and hence the desire to upgrade). With 15 years of design/build/operations under my belt for some Global 500 companies, being the 'wrench turner' or 'blue-collar guy' for what comes out of these/our groups, I agree whole-heartily with what you have said. I would like to add, in my opinion, put as many buttons, bells and whistles on it as you can, I will find a use for them... or not... at least I have a choice. Right now I feel like I am in a Russian supermarket... Regards, Damon Sauer Senders are Recievers too. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Keys vs. Reputation
It seems too early to know how key selectors might be used, whether reputation accrues to just the parent domain, and the role of the 2822.From address. Perhaps a convention is established for transactional messages where the right-most label in the key selector is named safe. Selectors might be used to partition the domain's messages. Not all users within a domain are equally trustworthy. This trust may be partitioned by using the 2822.From local-part, different selectors, or perhaps an r= parameter. It seems premature to speculate on how reputation is best applied or how the domain's traffic is partitioned, identified, and reported. This is _exactly_ the direction I would like to go, and so far, I don't see a technical issue with it as long as we _do not_ say, 3rd parties can sign for me even if I don't want them to. Otherwise, you can put as many selectors as you want, but without being able to say that, depending on the situation an unsigned or possibly signed message from you can be trumped by a 3rd party signature- Handing all the spades to the unsavory. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision
In (1) the public key is listed under the author's domain, while the secret key is operated either by 1a) the author's MTA or by 1b) the signing party's MTA. This is what I called a first-party scenario above. The verifier can't distinguish between 1a) and 1b) except by parsing the contents of Received: message headers. In (2) the public key is listed under the signer's domain, and the secret key is operated by the signing party's MTA. There is no relationship between author-domain and signing-domain. This is what I called a third-party signature above. In both (1) and (2) an assessment can be made on the basis of the the signing-domain. If I get mail with a signature from some no-name signing domain, then the author-domain (rfc822.from) is mostly irrelevant. And if I actually do have reasons to trust the signing-domain, then the author-domain is mostly relevant in case (1), and mostly irrelevant in case (2). Wietse, Thank you for the clearest definition I have seen to this point. What is the mechanism for depreciating (2)? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision
On 8/18/06, Wietse Venema [EMAIL PROTECTED] wrote: Damon: In (1) the public key is listed under the author's domain, while the secret key is operated either by 1a) the author's MTA or by 1b) the signing party's MTA. This is what I called a first-party scenario above. The verifier can't distinguish between 1a) and 1b) except by parsing the contents of Received: message headers. In (2) the public key is listed under the signer's domain, and the secret key is operated by the signing party's MTA. There is no relationship between author-domain and signing-domain. This is what I called a third-party signature above. In both (1) and (2) an assessment can be made on the basis of the the signing-domain. If I get mail with a signature from some no-name signing domain, then the author-domain (rfc822.from) is mostly irrelevant. And if I actually do have reasons to trust the signing-domain, then the author-domain is mostly relevant in case (1), and mostly irrelevant in case (2). Wietse, Thank you for the clearest definition I have seen to this point. What is the mechanism for depreciating (2)? In case (1), when the trusted signer-domain matches the author-domain, I might trust that the mail actually originates from the rfc822.from domain. In case (2), when the trusted signer-domain is not related to the author-domain, I might trust that mail was distributed by the mailing list that I subscribe to, or that it was processed by the malware removal service that I subscribe to. Thus, in (2) the author-domain (rfc822.from) is relatively unimportant compared to the signing-domain; even in (1) its importance is only secondary. Wietse, But this takes away my control over who can sign for me. In my opinion there _must not_ be a way for someone to sign for _me_ without my approval. In this example you are showing what (1) might do if they receive email from (2) which has nothing to do with the (1) and has everything to do with (2). Having said that, there should be no relationship between (1) and (2) in this example. Trusted or not trusted... You are mixing the receiver and the sender policies. Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Re: Role of 2822.From policy
On 8/18/06, Douglas Otis [EMAIL PROTECTED] wrote: On Aug 18, 2006, at 9:20 AM, Damon wrote: In (1) the public key is listed under the author's domain, while the secret key is operated either by 1a) the author's MTA or by 1b) the signing party's MTA. This is what I called a first-party scenario above. The verifier can't distinguish between 1a) and 1b) except by parsing the contents of Received: message headers. In (2) the public key is listed under the signer's domain, and the secret key is operated by the signing party's MTA. There is no relationship between author-domain and signing-domain. This is what I called a third-party signature above. In both (1) and (2) an assessment can be made on the basis of the the signing-domain. If I get mail with a signature from some no-name signing domain, then the author-domain (rfc822.from) is mostly irrelevant. And if I actually do have reasons to trust the signing-domain, then the author-domain is mostly relevant in case (1), and mostly irrelevant in case (2). Wietse, Thank you for the clearest definition I have seen to this point. What is the mechanism for depreciating (2)? - DKIM signatures clearly indicate which domain can be held accountable for the message. o When can the 2822.From address be assumed to represent the recipient of this address? o Can 2822.From policy play a role in clarifying whether a 2822.From address represents the recipient? o Can 2822.From policy assertions extend to other domains signing on behalf of the 2822.From address? 2822.From policy can offer assertions the 2822.From address is validated (it is being used by the recipient). This validation can extend beyond just the immediate 2822.From domain. This type of validation is commonly done by third-parties in many situations. Key/ Selector assignments between a domain owner and an email provider, or zone delegations arrangements between an email-provider and a name- service provider represents _significantly_ greater administrative and procedural effort than just listing a domain in the 2822.From policy. A policy listing tactic also allows a common signature to be applied by the email-provider for all their user accounts, even for those where the 2822.From is outside the signing domain. In this case the 2822 and the 3rd party have an established relationship. However, in my opinion, in some cases I may only be able to control this using a 2822 policy to supersede any 'common' signature that may be in place. Whether the designated domain protects the 2822.From address is something the domain owner of the email-address decides. Any domain that is designated should be assumed to protect the 2822.From. Any signing domain failing this protection should be removed with a complaint submitted to a certifying organization. Unless 2822.From policy offers greater assurances the message is from the address's recipient, it provides little value. Agreed. If only signatures by the domain of the 2822.From can offer this assurance, then there is indeed less need for a 2822.From policy. Unless 2822 is a I Sign All When a verifier discovers a policy that indicates all 2822.From address are always signed, exceptions must still be handled. Even with a flag that asserts no other non-compliant services are used, cousin and look alike domains will remain a problem. How so? The greatest protective value of DKIM is achieved with annotations that indicate 2822.From address is valid (per policy), and that this 2822.From address has been recognized as a prior correspondent. This annotation needs to happen as often as possible for greater protection. This annotation does not require the signing domain and the 2822.From domain match. When not matching, but where the designated signing domain is well-known, this should offer even greater acceptance than a matching From/signing domain message coming from some obscure domain. This is a way to fix something that is broken through the use of software. I will start writing some now... just in case. The greatest possible protection comes from the 2822.From having granular control over whom may sign and when and from where a signature is required, . (which we can't do right now). Regards, Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision
On 8/17/06, Wietse Venema [EMAIL PROTECTED] wrote: Dave Crocker: To explore this approach a bit further, I'm going to wonder about the supposed need for an SSP check when a signature is present. If a signature uses a domain related to the author's domain, then we have no SSP issue. The author's domain is used for assessment. No SSP query need be made. [Plus a straightforward DNS-based delegation mechanism so that the author's ISP can use a UNIQUE signing domain that relates directly to the author's domain] If a signature is not present, THEN an SSP I sign everything record might be useful (modulo the problem of surviving mailing list.) If a signature is present, but is not associated with the author's domain, then make the assessment based on the signing domain, not the author's domain. Again, no SSP query is needed. OK. Start shooting... I like this. This is very close to what I want: signed mail that speaks for itself, whether it's first-party or third-party signed. No batteries required. Sounds good to me. But it's late... :-) +1 anyway Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Requirements #9 NOT REQUIRED for 1st party valid signatures.
On 8/10/06, Stephen Farrell [EMAIL PROTECTED] wrote: Damon, There are some problems with your suggested statement. (Note: I'm not saying I'd agree with it if its fixed, but as of now its just not ready for the WG to consider.) Damon wrote: The Protocol MUST NOT be required to be invoked if a valid first party signature (without the 's') is found. Ambiguous. Do you mean: MUST NOT be invoked if any valid first party signature is found, or, MUST NOT be invoked if exactly one valid first party signature is found ? (Aside: the latter would be, IMO, silly, so I guess you didn't mean that.) Was just keeping with what was already there in #9 and expounding upon it. However, if the first party signature if damaged in transit A signature or message may be changed in transit, or may be bogus, but the verifier cannot know that - the verifier can only tell that there is no good (first party) signature. Ok. What happens if there is a list of authorized signing domains and one of those signs the message... then what? We already said that a damaged sig = no sig. We also said that a valid signer is a valid signer. the Protocol MUST be invoked to determine if any authorized domain or third party signers have signed the message. Nope. The verifier can tell if they've signed by looking and checking, so s/have signed/have been flagged by the first party as acceptable signers for/ or something like that. Stealing from Phillip... aww fishpaste.. your right. The order in which each authorized domain or third party signer is validated MUST NOT be specified. Why? Seems like a nit. And I'd probably steer clear of calling these authorized, on the basis that the term has a lot of ancillary baggage that we don't really want to have to explain away. (Having said that, it is a natural word to use, but not the best technical term;-) I wasn't too clear myself on how best to say, if an authorized domain sig is valid over a broken first party sig, but there are multiple authorized sigs, it should not matter which one is used, just the first one you check and it valid is fine. I am not a very good wordsmythe Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Clarification: Requirement #8
8. The Protocol is not required to publish a Practice of any/all unreleated third parties that MUST NOT sign on the domain holder's behalf. [INFORMATIVE NOTE: this is essentially saying that the protocol doesn't have to concern itself with being a blacklist repository.] Spelling issue: unreleated = unrelated also This might be a semantics issue but, does this mean that, while it is not required, it is still an option to be able to publish who MUST NOT sign? And if it _is_ still an option, does this mean that the unrelated parties sig should be ignored or is it suggested that it be treated with prejudice? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Clarification: Requirement #8
On 8/9/06, Stephen Farrell [EMAIL PROTECTED] wrote: Damon wrote: 8. The Protocol is not required to publish a Practice of any/all unreleated third parties that MUST NOT sign on the domain holder's behalf. [INFORMATIVE NOTE: this is essentially saying that the protocol doesn't have to concern itself with being a blacklist repository.] Spelling issue: unreleated = unrelated also This might be a semantics issue but, does this mean that, while it is not required, it is still an option to be able to publish who MUST NOT sign? As I read it, it says that the (SSP) protocol MUST NOT have that feature. Some other protocol might. Personally I think this is right since I can't think of any reason why the presence of a signature would in itself be a negative. I guess that 5.3, req #9 also more-or-less says this. I (and others, I expect) would argue strongly that it would be wrong to do otherwise. We had a related discussion about whether mail is required to be routed directly or not, but that should IMO be separate from this and doesn't currently seem to be in the document, which again I think is probably correct, though others may differ. Stephen. PS: The above is with chair hat off, of course. I am thinking that the purpose of the original discussion was to keep the OA's reputation from being tarnished by the subsequent signers. Like it or not, the sig is likely going to be tied to reputation somehow anyway. Are there any thoughts on how to avoid this? Regards, Damon Sauer I have all my hair so no need to wear a hat ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Clarification: Section 5.4.6
6. Practices and Expectations MUST be presented as an information service from the sender to be consumed as an added factor to the receiver's local policy. In particular a Practice or Expectation MUST NOT specify any particular disposition stance that the receiver should follow. Should the last sentence say: Expectation MUST NOT specify any particular disposition stance that the receiver MUST follow.? In my opinion, if the Expectation is set, it is stating a suggested usage. Or in other words, what the receiver should follow. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Requirements addition: Policy/Practice record for first party signatures
--- 542,556 for signing its messages to a non-related domain in such a way that it does not require active participation by the non-related domain. That is, the published information MUST have a way to ! specify the domains that are allowed to sign on its behalf. ! Signatures by such delagatees SHOULD be treated like First Party ! DKIM signatures. --- 542,556 for signing its messages to a non-related domain in such a way that it does not require active participation by the non-related domain. That is, the published information MUST have a way to ! specify the domains that are allowed to sign on its behalf. ! Signatures by such delagatees SHOULD be treated like First Party ! DKIM signatures. I am thinking that the SHOULD might be a MUST. ! specify the domains that are allowed to sign on its behalf. ! Signatures by such delagatees MUST be treated like First Party ! DKIM signatures. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Requirements clarification/addition: DKIM Signing Complete should include designated third parties
--- 350,357 previous scenario. A receiver, on the other hand, may be able to take advantage of the knowledge the domain's practice of signing all mail in order to use it to bias filters against the unexpected !arrival of a piece of unsigned, damaged in transit mail, or mail !signed by an entity not described in the RFC2822.From sender policy. (Scott's ideas incorporated too) !! arrival of a piece of unsigned, damaged in transit mail, or if a RFC2822.From sender policy exists which specifies authoritative domain(s), a mail signed by an entity other than described in the sender policy. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Real Numbers
Some of my own contentions revolve around what happens when signing fails, but to be honest, I have never seen it fail. Can anyone (Mark?) provide some real numbers for this for me? Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I sign everything is not a useful policy
Friends, Let it never be said that I am inflexible and can't change my mind from good arguments. After a restless night thinking about this, I am going to change my thoughts just slightly. All email that has a munged sig or no sig that comes from an I sign all domain should be expected not to reach its destination. I want to see: I sign all and/or these domains can sign for me. If the message is not signed, it is expected by me that the messages will not reach its destination. I sign none Nothing from me at this domain should be signed. If it is, it is expected by me that the message will not reach its destination. I sign all only from this domain(s) or _FDQN(s)_. Messages from this domain(s) or FDQN(s) that are not signed are expected by me not to reach their destination. However, messages coming from everywhere else may or may not be signed. I expect that these messages will not be effected under this policy. I think that these policies should cover every scenario I can think of. The FDQNs are important. As an admin who has several gateways at the same domain, it would be nice to be able to route some mail fitting a policy to a particular MTA to have it signed and delivered without effecting my other mail. If munging is too much of an issue, turn the policies off, fix the problem, turn them back on. I don't think we should stop work just because this _might_ happen. The benefits outweigh the risks. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I sign everything is not a useful policy
S.. How's the weather? Nice and HOT here in Atlanta :) Damon On 8/8/06, Stephen Farrell [EMAIL PROTECTED] wrote: Again - this raises no new technical issue. So, let's please wait and work on reqs-00's text, Stephen. Damon wrote: Friends, Let it never be said that I am inflexible and can't change my mind from good arguments. After a restless night thinking about this, I am going to change my thoughts just slightly. All email that has a munged sig or no sig that comes from an I sign all domain should be expected not to reach its destination. I want to see: I sign all and/or these domains can sign for me. If the message is not signed, it is expected by me that the messages will not reach its destination. I sign none Nothing from me at this domain should be signed. If it is, it is expected by me that the message will not reach its destination. I sign all only from this domain(s) or _FDQN(s)_. Messages from this domain(s) or FDQN(s) that are not signed are expected by me not to reach their destination. However, messages coming from everywhere else may or may not be signed. I expect that these messages will not be effected under this policy. I think that these policies should cover every scenario I can think of. The FDQNs are important. As an admin who has several gateways at the same domain, it would be nice to be able to route some mail fitting a policy to a particular MTA to have it signed and delivered without effecting my other mail. If munging is too much of an issue, turn the policies off, fix the problem, turn them back on. I don't think we should stop work just because this _might_ happen. The benefits outweigh the risks. Regards, Damon Sauer ___ 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] I sign everything is not a useful policy
Since someone who doesn't sign anything wouldn't publish any keys, how could this possibly be useful? Where would these rogue signatures come from, and how is a recipient going to verify a signature that has no key record? This was put in because I was reading threads where they wanted to be able to say I sign no mail. From what I read, this was for domains that expliciately do not send _any_ mail what-so-ever. I sign no mail is quite different from I send no mail. The latter says to throw away unsigned mail. I sign all only from this domain(s) or _FDQN(s)_. Messages from this domain(s) or FDQN(s) that are not signed are expected by me not to reach their destination. However, messages coming from everywhere else may or may not be signed. I expect that these messages will not be effected under this policy. It should be obvious that domain and FQDN are exact synoyms in this discussion. With that in mind, how does this differ from the first I sign all? Nobody's going to be looking at your SSP for any domains other than yours. I do not see them as being exact but fdqn being a subset. In the DNS, a domain is a domain. Subdomains are useful when you think about organizing your network, but when we're talking protocols, a query for dsl-467.podunk.someisp.com is no different from one for someisp.com. It is if there is a policy record at dsl-467.podunk.someisp.com I have some real life examples if you would like to see them. For instance, all the messages I send come from the mta: mail1.bigbank.com which are not signed and have a mail from: of employee/at/bigbank.com except for my transactional messages. These come from the mta: reciepts.bigbank.com which has a mail from: customer_service/at/bigbank.com for which I want to apply the policy of I sign all with the expected result of do not deliver anything that is not signed. Please send that scenario in to the list so someone other than me can tell you that path authentication is completely off the table. If you want your transactional mail treated differently from your employee mail, put them in different domains, e.g. [EMAIL PROTECTED] This is *exactly* my problem with SSP. Without being able to state the above, it makes it unwieldly. My example shows just one domain but what if I have 132 peppered within these, 1 to 10 mta's some I would want to sign for, some I would not. So now I would have to have all email sent to postmaster/at/svc.bigbank.com forwarded to postmaster/at/bigbank.com, plus every address that may be signing mail. As an administrator, I would like the policy that says any time I send to XYZ.com from bigbank.com due to a content policy or because the email was sent between 3:15 and 3:17pm, whatever... I want to be able to point that email at my signing mta and not break my return-paths or add extra work for myself. Why is it completely off the table? I will let you send to the list if you'd like so that it is not assumed that I am blindsiding you. :) ..on second thought... I will go ahead and post it. Since I feel this _may_ be a new way of looking at the problem, I believe that it follows Stephan's rules. Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I sign everything is not a useful policy
On 8/8/06, Damon [EMAIL PROTECTED] wrote: Since someone who doesn't sign anything wouldn't publish any keys, how could this possibly be useful? Where would these rogue signatures come from, and how is a recipient going to verify a signature that has no key record? This was put in because I was reading threads where they wanted to be able to say I sign no mail. From what I read, this was for domains that expliciately do not send _any_ mail what-so-ever. I sign no mail is quite different from I send no mail. The latter says to throw away unsigned mail. I sign all only from this domain(s) or _FDQN(s)_. Messages from this domain(s) or FDQN(s) that are not signed are expected by me not to reach their destination. However, messages coming from everywhere else may or may not be signed. I expect that these messages will not be effected under this policy. It should be obvious that domain and FQDN are exact synoyms in this discussion. With that in mind, how does this differ from the first I sign all? Nobody's going to be looking at your SSP for any domains other than yours. I do not see them as being exact but fdqn being a subset. In the DNS, a domain is a domain. Subdomains are useful when you think about organizing your network, but when we're talking protocols, a query for dsl-467.podunk.someisp.com is no different from one for someisp.com. It is if there is a policy record at dsl-467.podunk.someisp.com I have some real life examples if you would like to see them. For instance, all the messages I send come from the mta: mail1.bigbank.com which are not signed and have a mail from: of employee/at/bigbank.com except for my transactional messages. These come from the mta: reciepts.bigbank.com which has a mail from: customer_service/at/bigbank.com for which I want to apply the policy of I sign all with the expected result of do not deliver anything that is not signed. Please send that scenario in to the list so someone other than me can tell you that path authentication is completely off the table. If you want your transactional mail treated differently from your employee mail, put them in different domains, e.g. [EMAIL PROTECTED] This is *exactly* my problem with SSP. Without being able to state the above, it makes it unwieldly. My example shows just one domain but what if I have 132 peppered within these, 1 to 10 mta's some I would want to sign for, some I would not. So now I would have to have all email sent to postmaster/at/svc.bigbank.com forwarded to postmaster/at/bigbank.com, plus every address that may be signing mail. As an administrator, I would like the policy that says any time I send to XYZ.com from bigbank.com due to a content policy or because the email was sent between 3:15 and 3:17pm, whatever... I want to be able to point that email at my signing mta and not break my return-paths or add extra work for myself. Why is it completely off the table? I will let you send to the list if you'd like so that it is not assumed that I am blindsiding you. :) ..on second thought... I will go ahead and post it. Since I feel this _may_ be a new way of looking at the problem, I believe that it follows Stephan's rules. Damon Or how about a useful example: I run my eBay business out of my webmail account. I know that one of the domains that I send to, for reasons of security or insanity, requires that all email be signed. My webmail service does not want to sign every piece of email that goes out the door, so they offer an option in the form of a checkbox that says sign this email. This email is then diverted to a signing MTA which adds the sig. The policy for _that_ mta is I sign all mail. This is just a generic scenario, but I have no doubt that something like this could be applied somewhere quite usefully. Damon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] SSP requirements
On 8/5/06, Hector Santos [EMAIL PROTECTED] wrote: - Original Message - From: John L [EMAIL PROTECTED] To: Michael Thomas [EMAIL PROTECTED] That's a pretty reasonable question, frankly. The set of domains that would actually benefit from SSP from the consensus I've seen seems like it's a pretty tiny fraction of the internet at large and almost certainly could be handled by third party dnsbl-like or accreditation schemes as well. Agreed. That's what I've been thinking all along. In other words, your 3rd party dnsbl-like DAC business venture with some highly exploitable VBR protocol, with $10,000, $5000 entry feeds, with absolutely no plans for SSP, is the right solution for everyone and will resolved all the security issued related to DKIM. This wasn't about the your so called SSP FOG rethorical chaos but rather a conflict of interest. Having SSP still in play will not serve your business well. Wonderful. How many +1's am I allowed to put on this? +1 Fog?! Give me a break. I have caught up with what is going on in a matter of days and I am NOT confused or in a fog. I have disagreements and suggestions, but by no means do I think we are tripping around in the dark here. To say there have been no suggestions that you have heard from something less strict than I sign all means you have not read a word I and others have said and especially over the last few days. In the movies when the Whig's pretend not to hear the cannon fire, it's funny- I'm not laughing. Stop trying to steer the ship from the purser's vault. Regards, Damon Sauer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The problem with sender policy
I believe that without policy records (we can discuss the particulars later), the rest is useless. Regards, Damon Sauer On 8/5/06, william(at)elan.net [EMAIL PROTECTED] wrote: On Sat, 5 Aug 2006, John L wrote: In no way does accreditation=DKIM But policy records are in a way. Lets look at it in general - policy record is just a statement of what sender believes to be true about their email system setup and how receiver can use the email.. Accreditation is basically the same thing but the difference is that its not sender directly saying it but that sender asked (paid) some other party to provide this information to the public (and depending on how good accreditation service is they might go through some sort of checks to verify its true; in the end its still that accreditation service has been paid by the sender and is thus not true neutral party no matter what they say). Another slight difference is that accreditation focuses more on the use of the email rather then email system setup. Reputation is actually highly similar too but in that case it only answers about use of the email from perspective of 3rd party that has [hopefully] nothing to do with the sender. We could in fact have a system/protocol that accommodates all of these at once. The difference would be that for policy record the answer would be found directly at the service run by the sender (or whoever appears to be the sender in case you need to check on that). In the case of accreditation you'd ask some 3rd party chosen by the sender where as with reputation you'd ask 3rd party chosen by the receiver. The questions asked could all actually be the same and could even be if that party always sends signed email. As far as example given by John [FDIC and banks], I think its special corner-case because banks members of FDIC so what FDIC does is answer a question if they are member or not and there is no doubt that FDIC is only place to reliably find this out. However if a bank were to have paid some other 3rd party to say this bank belongs to FDIC, I'd not believe it much more then if bank itself said that directly (in fact lawyers would say it should be believed less). -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ 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
