Re: [ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 19, 2007, at 2:16 AM, Charles Lindsey wrote: > On Wed, 19 Dec 2007 06:27:55 -, Eliot Lear <[EMAIL PROTECTED]> wrote: > >> Bingo. We are wasting time on what I think is an extraordinary >> superficial issue. Jim's original term "Suspicious" was defined >> within >> the document, and did not in itself mean that the message was a >> forgery >> - just that extra care is needed. I wonder whether there really is a >> developer who would be confused by the term and not know what to >> do. If >> so, please explain why you are confused by the text. > > How about "irregular"? Irregular is also good. I don't have any problem with "suspicious," myself, but I understand why some people have concerns. That's why I suggested "exception," which isn't a pejorative. "Irregular" is also non-pejorative. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHarNysTedWZOD3gYRAqrWAJ99Iwx/+H3pCcj+eQVr1B05D5edOwCgvmFX Tkp8Lt1WYDlGMVQmbuYUUio= =Wzi2 -END PGP SIGNATURE- ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"
Eliot Lear wrote: Hector, So much for getting the "easy issues" out of the way. :-) Bingo. We are wasting time on what I think is an extraordinary superficial issue. Jim's original term "Suspicious" was defined within the document, and did not in itself mean that the message was a forgery - just that extra care is needed. I wonder whether there really is a developer who would be confused by the term and not know what to do. If so, please explain why you are confused by the text. Eliot I agree with you. I don't think developers, including us, will have much of an issue with "suspicious" or even exception. So for me, I have no qualm with closing this issue. We know what we can or can not do and the "words" isn't going to change that. That said, I do recognize the dichotomy here and would I think I understand why David raised the issue. My opinion: From my viewpoint, I personally do not have a subjective concern for SSP and view it as directly tied to the DKIM-BASE protocol consistency implementation "requirements." I always felt SSP would be key part for DKIM's wide adopted success (not just high profile isolated implementations). Thus separating it, IMO, was going to cause some rather complex wide-adoption engineering implementation barriers. FWIW, we have very little interest in DKIM without a SSP framework. So for me, I see it more as black and white with no gray. The only gray is the imperfections of the DKIM protocol - not SSP. SSP is indeterminate in the gray areas of DKIM-BASE. However, they are interrelated because SSP can help in minimizing the gray areas of DKIM-BASE. The point of the illustrating the boundary conditions in the other thread was to highlight where SSP helps validate the DKIM protocol with 100% non-repudiation, meaning the mail was received in the framework it was expected and no one is disputing it. It illustrates the hard results - the pure violations and pure compliance of DKIM-BASE. It also shows unless hard choices or assumptions are made, it shows why the "BROKEN TO NO-SIGNATURE" DKIM-BASE mandate can be problematic. So to me, it is either a true or false check - no exception. In short, if you asking me why one can be "confused" by this, I say, lets not make it any more difficult for SMTP receivers and DKIM verifiers. Lets just describe it as it is. No beating around the bush. I wouldn't use suspicious or not suspicious because that is a "subjective" conclusion on bad vs good intentions. All should be part of the same considerations. So I would work along the line of what Jim has suggested - compliance and that applies to both good or bad. So for all the steps, I would use more direct semantics like: .. the message does not violate the domain signing policy|practice, and the algorithm terminates. The transaction SHOULD be given positive classification. .. the message violates the domain signing policy|practice, and the algorithm terminates. The transaction SHOULD be given a negative classification. To me, this does two things: 1) Straight to the point - it either satisfies or violates SSP, with terms most levels of people interested in this would understand or be able to follow. 2) Helps prepare augmented technology (filters, message handlers, heuristic systems, etc) with terms people concentrated in these areas would understand or follow. But since I can see how "suspicious" can cover both ideas, I have no problem keeping it as such. As we all know, receivers are going to train or code their ware to make it work for operators who may want to use this extra DKIM/SSP information about a message. But at the same time, we can't presume everyone are just going to invest in adding what is undoubtedly a very complex protocol and not expect a payoff. So I hope my input here, and that is all it is, input, helps to make sure it doesn't makes things worst - and that includes those don't implement it or legacy system and begin to become targets themselves with a worst case scenario that the domain reputation is now harmed. -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"
On Wed, 19 Dec 2007 06:27:55 -, Eliot Lear <[EMAIL PROTECTED]> wrote: Bingo. We are wasting time on what I think is an extraordinary superficial issue. Jim's original term "Suspicious" was defined within the document, and did not in itself mean that the message was a forgery - just that extra care is needed. I wonder whether there really is a developer who would be confused by the term and not know what to do. If so, please explain why you are confused by the text. How about "irregular"? -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email:[EMAIL PROTECTED]: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"
Hector, >> >> +1 for "Whatever" as the descriptive term. > > hahahahaha! > > So much for getting the "easy issues" out of the way. :-) > Bingo. We are wasting time on what I think is an extraordinary superficial issue. Jim's original term "Suspicious" was defined within the document, and did not in itself mean that the message was a forgery - just that extra care is needed. I wonder whether there really is a developer who would be confused by the term and not know what to do. If so, please explain why you are confused by the text. Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"
Steve Atkins wrote: On Dec 18, 2007, at 12:32 PM, Frank Ellermann wrote: <[EMAIL PROTECTED]> wrote: >> ... >> SSP could use "Whatever" in double quotes, at the moment it uses a title case Suspicious without double quotes. For some value of "Whatever", not necessarily "Fail" - but I think it will end up as "hardfail" in the Authentication-Results RFC. +1 for "Whatever" as the descriptive term. hahahahaha! So much for getting the "easy issues" out of the way. :-) -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"
On Dec 18, 2007, at 12:32 PM, Frank Ellermann wrote: <[EMAIL PROTECTED]> wrote: I think FAIL actually has a stronger connotation than non-compliant. [...] If the concern is that people won't understand that Suspicious is a defined term and will bring their own connotative filter is that likely to be less true for FAIL? I've just checked how RFC 4408 solved this, it uses "Fail" (etc.) in double quotes, and has a separate subsection for each of the *seven* result codes - now here's something where SSP can do better, *seven* is hilarious ;-) Using upper case was no option, the 2119 keywords (MUST etc.) are already upper case, some critical SPF terms like MAIL FROM and HELO also use upper case (inherited rom 2821), and adding more upper case terms would be unreadable. SSP could use "Whatever" in double quotes, at the moment it uses a title case Suspicious without double quotes. For some value of "Whatever", not necessarily "Fail" - but I think it will end up as "hardfail" in the Authentication-Results RFC. +1 for "Whatever" as the descriptive term. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"
Sorry for joining the debate a bit late. My $.02 are below Frank Ellermann wrote: > Jim Fenton wrote: > > > My suggestion: "non-compliant"/"compliant". > > If "non-compliant" is actually a "Resent-* as > specified in 2822upd with a twist" (signature > didn't survive it), then that's rather strong. > > Why not FAIL ? FAIL is short, neutral, and > some folks are used to the idea that FAIL is > a defined term. > > Frank I think FAIL actually has a stronger connotation than non-compliant. To me non-compliant just says it didn't comply with the published policy. It is a factual statement of the outcome of comparing this policy to the piece of data you have in front of you. FAIL doesn't feel either as neutral or as factually descriptive as that (key word there being feel, other people may have an entirely different feeling for that term). If the concern is that people won't understand that Suspicious is a defined term and will bring their own connotative filter is that likely to be less true for FAIL? _ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"
On Dec 18, 2007, at 6:55 AM, Frank Ellermann wrote: Jim Fenton wrote: My suggestion: "non-compliant"/"compliant". If "non-compliant" is actually a "Resent-* as specified in 2822upd with a twist" (signature didn't survive it), then that's rather strong. Any changes to message content might cause a signature to be invalid. An invalid signature may cause a message to appear "exceptional" when messages from the domain are asserted as "all" being signed. As with any retrofit, exceptions _must_ be permitted. Why not FAIL ? FAIL is short, neutral, and some folks are used to the idea that FAIL is a defined term. "FAIL" says little about an underlying cause. Was the signature valid, but "on-behalf-of" a header other than "From", or by a different domain, when "strict" had been asserted by the From domain? A breakdown of causes with respect to actual "exceptions" would help clarify the different causes that _will_ legitimately exist. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html