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
-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
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
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
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 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
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
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
