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
[ietf-dkim] draft-kucherawy-dkim-reporting-01 posted
The secretariat appears to be catching up, and the DKIM reporting draft I discussed at the Vancouver WG meeting is now available for review and discussion. Having talked to the co-authors of the ARF draft, it's likely that I can just get that draft modified to add what is needed to make this a reality, so part of this draft might be moved over to that one. I'm going to begin looking at INCH as well. I'd be fine with this becoming a WG document rather than an individual one, but I'm also happy to see it through myself if the WG isn't interested in supporting it at this time. ___ 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
[ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"
<[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. Frank ___ 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] How SSP will assist DKIM-BASE
On Dec 18, 2007, at 9:58 AM, Hector Santos wrote: Douglas Otis wrote: 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. This dubious strategy provides a significant incentive for bad actors to insert "bogus" DKIM signatures. Would it matter whether the signature hash is valid, but the signature is not? Would it matter whether the hash is wrong, but the signature matches with the invalid hash? What level of forensics should invalid signatures entail? What is reasonable to expect of a DKIM verifier's resources? IOW, by lumping a broken signature, promoted to no signature status, then you have what you say is true. This still gives credit to an invalid signature which might be for lying. Lying is already being abused. The fallout of giving credit for lying would be to accelerate a need for DKIM resource triage. Any domain found emitting invalid signatures is likely to be identified as wasting these DKIM resources. The vast majority of messages are undesired, where DKIM already affords signers a sizeable advantage over that of verifiers. Signing a message requires a one-time effort which can be disseminated many fold. Add to this, an influx created by giving partial credit to bogus DKIM signatures. In all likelihood, when confronting rampant bogus signature abuse, _any_ source found emitting invalid signatures may find their messages blocked, or at least excluded from a DKIM validation process. The only way to ensure DKIM signatures are not abused requires NOT giving _invalid_ signatures _any_ credit over that of _no_ signatures. The base draft specifically declares "no" signature is equivalent to "invalid" signatures. A means to ensure your outbound MTA is not seen as producing "bogus" signatures requires removal of known invalid signatures. This mode of protection therefore means advice given in the DKIM base specifications regarding interpretation are ill-considered. Some like to learn the hard way. 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. This is just semantics. Any added weight for bogus signatures _will_ be abused. David wanted to see the threats and issues of SSP policies. IMO, this is one of them. We agree, but for entirely different reasons. Giving a message with a broken signature credit is a dangerous policy. True. But giving it credit wasn't the point here. Sigh. Section 4.2 is not clear that this prohibition on signature removal is to be for issuing a "different" message from the one originally signed. Well, according to, http://www.ijs.si/software/amavisd/amavisd-new-docs.html#dkim Mailman is already stripping and replacing signatures: "A representative of another type of mailing lists is Mailman, which often modifies mail body and strips out original signatures, unless explicitly configured not to." Mailman then has an extremely good default. A strategy that gives credit to bogus signatures spells disaster. Signers therefore should be prepared for the fallout created by ill-considered strategies. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Re: Re: Issue 1530 - replace use of term "suspicious"
Douglas Otis wrote: > "FAIL" says little about an underlying cause. In the context of SSP "FAIL" would mean whatever the SSP spec. says it means. Like SPF FAIL means what RFC 4408 says, it's very simple to show that this could be nobody's fault at all - "clueless user" arranged 1123 5.3.6(a) forwarding to an 821-emulating RFC 4408 hop is no "failure", normal users aren't supposed to know such details. Besides it still works if the next hop uses "reject" as a "receiver policy", arguably that could also work for any "SSP FAIL", or the proverbial "odd IP on Tuesdays FAIL". Traditional forwarding is anyway doomed since 1123 was published, it will only get worse with the transition to "IPv6 only" senders. > A breakdown of causes with respect to actual "exceptions" would > help clarify the different causes that _will_ legitimately exist. Is it "legit" if a "resending MUA" breaks Alice's DKIM signature ? What if Alice signed that her mail had no Resent-* header fields, is that "legit" ? Bob can't get it right in the latter case, he'd be forced to make another plan . Frank ___ 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] How SSP will assist DKIM-BASE
Douglas Otis wrote: 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. Giving a message with a broken signature credit is a dangerous policy. True. But giving it credit wasn't the point here. Section 4.2 is not clear that this prohibition on signature removal is to be for issuing a "different" message from the one originally signed. Well, according to, http://www.ijs.si/software/amavisd/amavisd-new-docs.html#dkim Mailman is already stripping and replacing signatures: "A representative of another type of mailing lists is Mailman, which often modifies mail body and strips out original signatures, unless explicitly configured not to." -- 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] 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] Issue 1530 - replace use of term "suspicious"
Damon wrote: 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. I think that will all depends on who is reading it. To me, an exception is not an ordinary event that one expected. Since I believe SSP is just validating the expected signing behavior as described by the domain, it is either a TRUE or FALSE condition - no exception. Checking for NXDOMAIN is a safe result to check for. Checking to see if its a given POLICY matches what is actually shown in the message, is a safe result to check for. I don't see those as exceptions. Now, if one can't make heads or tails of a SSP check, then maybe that can be viewed as an exception - because something happen you didn't expect. Here's the thing: The fact you and others had to look it up, means a lot here. Most people are not going to be wanting to have their dictionary or thesaurus around when they read these RFCs. The fact there are a "take your pick" untold semantics for exception tells ya it will probably cause one to scratch their head than now. I say being "Specific is Terrific!" As Frank suggested, PASS or FAIL is just as good. Most people don't need a dictionary for that. I suggested SSP Complete, maybe good if you understand 5016. I also suggested negative/positive classification, and this has a industry wide understanding and it is already in place for this type of work. SMTP uses positive/negative response code and classifications ideas. Spam Assassin already uses positive/negative classification as well as other heuristic based systems. Odds are good you will find more neural networks or fuzzy logic systems play a role, if not already. Jim's non-compliant/compliant is also straight to the point. But not sure it helps in laying the ground work to handling results. 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 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 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
[ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
