Clearly bogus false positives -- on "abuse" contact point, no less Hmmm.  I think we need a BL for reporting ISP's that are clueless as to  run filtering on their "abuse" mailbox (or the mailbox that's listed for  their ARIN/RIPE AbuseEmail attributes). Anyway, I have no idea why I'm seeing some of these scores.  URL matches  when there aren't even URL's in my message? A 2.6 score on BAYES_00?  URIBL_JP_SURBL and URIBL_OB_SURBL?  And what  the heck is DNS_FROM_OPENWHOIS??? TVD_STOCK1?  There's no mention of stock anywhere in the message.  Why am I seeing all of these bogus matches? I looked on the wiki for some of these, but couldn't find descriptions. What should I do?  Just block their domain?  I don't want to deal with their misconfiguration issues. -Philip ======== >From msqllzelja@e-dialog.com  Sat Apr 26 15:50:05 2008 Message: 1 Date: Wed, 20 Feb 2008 18:30:37 -0500 From: Jeff Macdonald  Subject: Re: [ietf-dkim] SSP-02 the problem with Author Signature To: Douglas Otis  Cc: DKIM List  Message-ID: <20080220233037.GD15211@jmac> Content-Type: text/plain; charset=us-ascii; format=flowed On Tue, Feb 19, 2008 at 03:04:08AM -0800, Douglas Otis wrote: >Expanding upon the effect of the SSP-02 Author Signature definition   >based upon a conversation with Jim... > >Jim suggested that to comply with SSP-02, signatures will not make use   >of the i= parameter, since the i= parameter is needed only for g=   >restricted keys. Is that really true? I thought one could use i= in cases like so: d=bar.org i=@foo.bar.org I didn't think g= was needed in that case. >Instead of a practice that offers an explicit token (even one that is   >opaque) identifying the user/agent that introduced the message, once   >again examining the header stack and guessing which header might apply   >again becomes necessary.  It is also unknown whether the entire header   >stack will have been captured within the signatures hash, so this   >guessing may also be prone to the introduction of spoofed headers   >while attempting to resolve top most identifiers. > >Secondly, this also means that MUAs attempting to highlight who the   >signature indicates as having introduced the message is also prone to   >getting this wrong, because the signature's identity (i=) MUST BE   >absent whenever the entity introducing the message is _not_   >represented by the email-addresses within the From header. : ( > >Although unlikely, some domains may feel compelled to sign the message   >twice.  One signature to comply with the SSP-02 Author Signature   >definition, and another to clarify who actually introduced the   >message. : ( I think being able to use multiple signatures offers flexibility. >As a result, instead of DKIM offering a "reportable" or "displayable"   >identifier clarifying who introduced the message, this identifier must   >again be guessed. : ( I don't think it really matters who introduced the message. What really matters is if any of the DKIM identities are recognizable. > >Jim's example as to why this definition is needed offers yet another   >problem with this scheme. > >Recommendation: > >1) Change "Author Signature" to "Author Domain Signature". > >2) Change "Author Signing Policy" to "Author Domain Signing Policy". > >3) Accept the premise that when the "Author Domain" signs the message,   >the message is complaint with the "Author Domain's Signing Policy" _by   >definition_. > >4) Only when the message is not signed by the "Author Domain", is the   >"Author Domain Signing Policy" in need of checking. These seem reasonable to me, but I don't know if we need to be that fine grained. --  :: Jeff Macdonald | Director of Messaging Technologies :: e-Dialog | msqllzelja@e-dialog.com :: 131 Hartwell Ave. | Lexington, MA 02421 :: v: 781-372-1922 | f: 781-863-8118 :: www.e-dialog.com ------------------------------ >From lhmn@communigate.com  Sat Apr 26 15:50:05 2008 Message: 2 Date: Wed, 20 Feb 2008 16:43:57 -0800 From: "Thom O'Connor"  Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt 	Discardable/Exclusive To: gfky-hddl@mipassoc.org Message-ID: <47BCC94D.7030200@communigate.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Eric Allman wrote: > I am in no way married to the word DISCARDABLE.  We used it in SSP-02  > because it matched ASP. >  > It has occurred to me that we've spent FAR too much time arguing  > about exactly what word to use.  I'm deeply tempted to switch to  > numbers, special characters, or random gibberish strings so that  > people have to read the actual description. Hi Eric, I understand this sentiment, and your point here is notable. However, it is very important that the terminology in use here is  accurate and appropriate. The global messaging user-base wants and  expects guidance on implementation that should be clear and direct. The  truth of the matter is, the discarding of email should be expressly  discouraged. No message should ever be discarded - RFC 2821 suggests  this though does not explicitly disallow or discourage it: http://www.ietf.org/rfc/rfc2821.txt > Delivery SMTP systems MAY reject ("bounce") such messages rather than deliver them. The discarding of email is one of the key causes of some significant  loss of trust in email as a reliable means of communication. While it  may be argued that spam may have caused email receiving domains to react  in this way as a defense mechanism, it is actually the overreaction -  perhaps due to a lack of guidance - that has allowed providers to think  that discarding messages is a satisfactory response to the spam or  malware threat. Perhaps, if our techniques were 100% accurate in  ensuring that no valid message was ever lost, discarding could be  appropriate. These techniques will not likely ever reach 100% accuracy. If we (where "we" is the email industry here that seeks to maintain and  even expand the usefulness of email itself, rather than seeing our users  resort to making a phone call or using IM when they need a "sure" method  of communication) should be clear about this then, one appropriate value  for the SSP record would be "reject" or something equally directive,  perhaps "verify". And if we are to really seek to be clear on the  Signing Practice in use, then perhaps we may even include a "none" value: none - The domain signs no email. unknown - The domain may sign none, some, or all email. all - All mail from the domain is signed with an Author Signature. reject (or verify) - All mail from the domain is signed with an Author           Signature.  Furthermore, if a message arrives without a valid           Author Signature due to modification in transit, submission via           a path without access to a signing key, or other reason, the           domain encourages the recipient(s) to reject it if it does not           verify. There are certainly valid reasons that a domain may request this higher  level of requested interpretation - signature-based verification moves  email towards an (optional) higher level of reliability and identity  verification with legal and commercial implications. Douglas Otis wrote: >> Agreed.  This changes "strict" (the exclusivity) assertion into >> something that does not express a domain's intentions on >> exclusivity.  This assertion simply increases the likelihood of >> having the domain's messages discarded. >> >> Using Hector's term "exclusive"- >> >> exclusive: >> All mail from the domain is signed with an intent to avoid >> agents that may damage or remove signatures.  Furthermore, >> in lieu of a trusted third-party signature, if a message >> arrives without a valid Author Signature due to >> modification in transit, submission via a path without >> access to a signing key, or other reason, the domain >> encourages the recipient(s) to reject the message or issue >> a DSN when the RFC 2821 MAILFROM domains match. This line of thinking is on target, though we really need to get better  at using words our users will understand. "exclusive" is ambiguous, and  I would argue, not an easily understood concept. "Signature did not  verify" would seem to be an error message that could possibly be  understood by a normal user in a DSN message. Sincerely, respectfully, -thom ------------------------------ >From dyrbcm@cisco.com  Sat Apr 26 15:50:05 2008 Message: 3 Date: Wed, 20 Feb 2008 21:55:09 -0800 From: Jim Fenton  Subject: Re: [ietf-dkim] SSP-02 the problem with Author Signature To: Jeff Macdonald  Cc: DKIM List  Message-ID: <47BD123D.3040206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Jeff Macdonald wrote: > On Tue, Feb 19, 2008 at 03:04:08AM -0800, Douglas Otis wrote: >    >> Expanding upon the effect of the SSP-02 Author Signature definition   >> based upon a conversation with Jim... >> >> Jim suggested that to comply with SSP-02, signatures will not make use   >> of the i= parameter, since the i= parameter is needed only for g=   >> restricted keys. >>      > > Is that really true? I thought one could use i= in cases like so: > > d=bar.org > i=@foo.bar.org > > I didn't think g= was needed in that case. >    I was misunderstood here.  A local part on i= is REQUIRED if the signing  key is "restricted" through use of a g= parameter other than *.  i= can  be used at other times and for other things as well, as you point out.   In the example you gave, i=@foo.bar.org would result in an Author  Signature when the Author Address on the message is something like  jdoe@foo.bar.org. >    >> Instead of a practice that offers an explicit token (even one that is   >> opaque) identifying the user/agent that introduced the message, once   >> again examining the header stack and guessing which header might apply   >> again becomes necessary.  It is also unknown whether the entire header   >> stack will have been captured within the signatures hash, so this   >> guessing may also be prone to the introduction of spoofed headers   >> while attempting to resolve top most identifiers. >> >> Secondly, this also means that MUAs attempting to highlight who the   >> signature indicates as having introduced the message is also prone to   >> getting this wrong, because the signature's identity (i=) MUST BE   >> absent whenever the entity introducing the message is _not_   >> represented by the email-addresses within the From header. : ( >>      Huh??  ASP does not prohibit other signatures, it just provides no  additional information about them. >> Although unlikely, some domains may feel compelled to sign the message   >> twice.  One signature to comply with the SSP-02 Author Signature   >> definition, and another to clarify who actually introduced the   >> message. : ( >>      > > I think being able to use multiple signatures offers flexibility. >    Sure, and doesn't signing the Sender header field clarify who actually  introduced the message, if that's important? >    >> As a result, instead of DKIM offering a "reportable" or "displayable"   >> identifier clarifying who introduced the message, this identifier must   >> again be guessed. : ( >>      > > I don't think it really matters who introduced the message. What really > matters is if any of the DKIM identities are recognizable. >    Yes, that's the point. > >    >> Jim's example as to why this definition is needed offers yet another   >> problem with this scheme. >> >>      > >  > >    >> Recommendation: >> >> 1) Change "Author Signature" to "Author Domain Signature". >> >> 2) Change "Author Signing Policy" to "Author Domain Signing Policy". >> >> 3) Accept the premise that when the "Author Domain" signs the message,   >> the message is complaint with the "Author Domain's Signing Policy" _by   >> definition_. >> >> 4) Only when the message is not signed by the "Author Domain", is the   >> "Author Domain Signing Policy" in need of checking. >>      > > > These seem reasonable to me, but I don't know if we need to be that > fine grained. >    Just because the signing policy is expressed only at the domain level  doesn't mean that the definition of Author Signature must also be at  exactly the same level of granularity.  So an Author Domain Signing  Policy can still deal with Author Signatures. -Jim ------------------------------ >From vhwi.ohowb@cox.com  Sat Apr 26 15:50:05 2008 Message: 4 Date: Wed, 20 Feb 2008 23:17:38 -0500 From:  Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt 	Discardable/Exclusive To: ,  Message-ID: 	 Content-Type: text/plain;	charset="iso-8859-1" How very strange I wonder what explains the over 2k bounce messages of undeliverability due to content in my honey trap mail account that has been spoofed in the last 3 days alone. It appears that cheap software, designer shoes and On line degrees don't apply to the RFC's. It seems that organizations around the world don't adhere to the specs. That is why commercial messages need to be delivered to the inbox in some other method from edge to edge than smtp via a community service bureau or other entity. This WOULD allow a 99.999% delivery rate of valid messages while killing 99.999% of spam. Also it would free up considerable bandwith as commercial mail would only need one copy of a message to be delivered to each ISP instead of spraying millions hoping for a high receive rate.  thanks, Bill -----Original Message----- From: lrbi-gfuh-nacdbbd@mipassoc.org on behalf of Thom O'Connor Sent: Wed 2/20/2008 7:43 PM To: gfky-hddl@mipassoc.org Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive   Eric Allman wrote: > I am in no way married to the word DISCARDABLE.  We used it in SSP-02  > because it matched ASP. >  > It has occurred to me that we've spent FAR too much time arguing  > about exactly what word to use.  I'm deeply tempted to switch to  > numbers, special characters, or random gibberish strings so that  > people have to read the actual description. Hi Eric, I understand this sentiment, and your point here is notable. However, it is very important that the terminology in use here is  accurate and appropriate. The global messaging user-base wants and  expects guidance on implementation that should be clear and direct. The  truth of the matter is, the discarding of email should be expressly  discouraged. No message should ever be discarded - RFC 2821 suggests  this though does not explicitly disallow or discourage it: http://www.ietf.org/rfc/rfc2821.txt > Delivery SMTP systems MAY reject ("bounce") such messages rather than deliver them. The discarding of email is one of the key causes of some significant  loss of trust in email as a reliable means of communication. While it  may be argued that spam may have caused email receiving domains to react  in this way as a defense mechanism, it is actually the overreaction -  perhaps due to a lack of guidance - that has allowed providers to think  that discarding messages is a satisfactory response to the spam or  malware threat. Perhaps, if our techniques were 100% accurate in  ensuring that no valid message was ever lost, discarding could be  appropriate. These techniques will not likely ever reach 100% accuracy. If we (where "we" is the email industry here that seeks to maintain and  even expand the usefulness of email itself, rather than seeing our users  resort to making a phone call or using IM when they need a "sure" method  of communication) should be clear about this then, one appropriate value  for the SSP record would be "reject" or something equally directive,  perhaps "verify". And if we are to really seek to be clear on the  Signing Practice in use, then perhaps we may even include a "none" value: none - The domain signs no email. unknown - The domain may sign none, some, or all email. all - All mail from the domain is signed with an Author Signature. reject (or verify) - All mail from the domain is signed with an Author           Signature.  Furthermore, if a message arrives without a valid           Author Signature due to modification in transit, submission via           a path without access to a signing key, or other reason, the           domain encourages the recipient(s) to reject it if it does not           verify. There are certainly valid reasons that a domain may request this higher  level of requested interpretation - signature-based verification moves  email towards an (optional) higher level of reliability and identity  verification with legal and commercial implications. Douglas Otis wrote: >> Agreed.  This changes "strict" (the exclusivity) assertion into >> something that does not express a domain's intentions on >> exclusivity.  This assertion simply increases the likelihood of >> having the domain's messages discarded. >> >> Using Hector's term "exclusive"- >> >> exclusive: >> All mail from the domain is signed with an intent to avoid >> agents that may damage or remove signatures.  Furthermore, >> in lieu of a trusted third-party signature, if a message >> arrives without a valid Author Signature due to >> modification in transit, submission via a path without >> access to a signing key, or other reason, the domain >> encourages the recipient(s) to reject the message or issue >> a DSN when the RFC 2821 MAILFROM domains match. This line of thinking is on target, though we really need to get better  at using words our users will understand. "exclusive" is ambiguous, and  I would argue, not an easily understood concept. "Signature did not  verify" would seem to be an error message that could possibly be  understood by a normal user in a DSN message. Sincerely, respectfully, -thom _______________________________________________ NOTE WELL: This list operates according to  http://mipassoc.org/dkim/ietf-list-rules.html ------------------------------ >From wyz@clerew.man.ac.uk  Sat Apr 26 15:50:05 2008 Message: 5 Date: Thu, 21 Feb 2008 12:01:35 -0000 From: "Charles Lindsey"  Subject: Re: [ietf-dkim] ***SPAM-3*** Re:  NEW ISSUE: SSP-02: Policy 	Scope To: DKIM  Message-ID:  Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 On Wed, 20 Feb 2008 18:30:53 -0000, Douglas Otis    wrote: > On Feb 20, 2008, at 3:41 AM, Charles Lindsey wrote: > >> On Fri, 15 Feb 2008 19:27:29 -0000, Douglas Otis > abuse.org> >> wrote: >> >>> On Feb 15, 2008, at 4:50 AM, Charles Lindsey wrote: >>> >>>> On Thu, 14 Feb 2008 19:08:41 -0000, Douglas Otis >>> > >>>> wrote: >> >>>>> s= Policy Scope (plain-text; OPTIONAL; default is "SMTP").  A >>>>> colon- >>>>> >>>> No! The default must be '*'. >>> >>> The concern regarding defaults was addressed in Take #3.  This >>> version includes a means to exclude policy. >> >> And indeed Take #3 starts: >> >> s= Policy Scope (plain-text; OPTIONAL; default is "*"). >> >> so it seems my point is accepted. >>> >>>    *  matches against all unlisted transport protocols >>>    !  disavows protocol use >>>    -  excludes protocol from policy assertions >>> >>> I suspect the default should be "s=SMTP" where this would be the >>> same as "s=SMTP:-*".  When the domain exchanges no communication >>> whatsoever, "s=!*" could be used.  When only SMTP messages are >>> used, then "s=SMTP:!*" would make this assertion. >> >> But now you are contradicting yourself. First you say 'default is >> "*"'; >> now you are saying 'I suspect the default should be "s=SMTP"'. Which >> is it? > > The policy assertion of "s=*", this would mean that other protocols > might be affected the publisher did not expect.  Rather than > potentially blocking other protocols, an assertion of "s=SMTP", as a > default, would require publishers to proactively make explicit > restrictions on other protocols.  From the comments on this list, it > seems most view the policy record as being related to messages > entering the SMTP related infrastructure.   In that respect, the SMTP > policy would be applied anyway.  Having this policy record impact > fully independent and separate message transports seems as though it > should be explicit.  Having an explicit policy will also allow the > verifier to better trust that this restriction was the intent of the > policy.  Trust in assertion is important. And after all that waffle, you still have not answered the question. Are   you proposing the default is "s=*" or are you proposing the default   "s=SMTP" (since your message seemed to be proposing both). But as for publishers of SSP records, the stricter the policy they   declare, the more careful they must be that users of their domain, are not   able to bypass the signing mechanism by using strange protocols/whatever.   How they do that is their problem. So if they publish "s=*" (or if that is   the default), then they are saying that if anything arrives looking like   an RFC 2822 message from our dopmain, but unsigned, then you should   reject/discard/suspect/whatever it. But if they publish "s=SMTP" and something leaves their domain via   UUCP/NNTP/whatever-else, then they are syaing it is OK not to be signed.   But then it it gets gatewayed back into SMTP, verifiers may not be able to   tell that it was not SMTP originally, and so will still   reject/discard/suspect/whatever it. Or if you intend that the "s=SMTP" is to be avaluated according to the   protocol by which it was received by the verifier, then it will still be   rejected/whatever, even though it legitimately left the original domain   unsigned via UUCP/NNTP; is the gateway supposed not to have gatewayed it   in that situation. All you have created then is a glorious opportunity for   everyone to blame everyone else for preventing the mail from being   delivered. In short, the only thing which will work in the face of gatewaying of any   sort is to say that SSP applies to anything looking like an RFC 2822   object, in which case you don't need an "s=" tag at all. > Type of transport is always implied.  Messages handled primarily by > SMTP transport, you would be absolutely right, SMTP is the only > assumption that should be made.  DKIM can also be used by independent > and separate message transports protocols that are completely > unrelated to SMTP.  In that case, the transport is also implied, but > it would not be SMTP. And just what is all that supposed to mean? --  Charles?H.?Lindsey?---------At?Home,?doing?my?own?thing------------------------ Tel:?+44?161?436?6131?                       ???Web:?http://www.cs.man.ac.uk/~chl Email:?wyz@clerew.man.ac.uk??????Snail:?5?Clerewood?Ave,?CHEADLE,?SK8?3JU,?U.K. PGP:?2C15F1A9??????Fingerprint:?73?6D?C2?51?93?A0?01?E7?65?E8?64?7E?14?A4?AB?A5 ------------------------------ _______________________________________________ NOTE WELL: This list operates according to  End of ietf-dkim Digest, Vol 108, Issue 4 *****************************************