Re: [ietf-dkim] [EAI] UTF-8/MIME
On Thu, 19 Aug 2010 18:43:13 +0100, Shawn Steele wrote: > John was asserting that EAI messages have to be MIME. IMO I think > that's overkill, people use "simple" submission tools, telnet even, but > I don't really want to block the RFC over that discussion. Interesting point. From time to time I use telnet to send email (usually when testing that something is working). I try to use as few header as possible, and if I were doing it in some EAI environment, it would be tedious to type in 3 extra headers (MINE, CT and CTE) which appeared to serve no useful purpose. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@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 http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
Right, but emphasize that the granularity is a signing domain -- it is not and cannot be a way to attribute mail to individual people. Unless you have reason to believe that the signer is taking steps to ensure that the sender information is accurate. A reputation system could make an assertion like that, but it's definitely outside the scope of DKIM. For about the billionth time, why aren't the people who are worried about the identity of individual senders using S/MIME? I have trouble envisioning a problem so serious that we need to invent complex extra mechanisms and try to force people to use them, yet so trivial that we can't be bothered to use the existing tools built into every MUA. R's, John smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
--On 19 August 2010 16:20:36 + John Levine wrote: > >> * DKIM is a really well developed standard for signing email > > Right, but emphasize that the granularity is a signing domain -- it is > not and cannot be a way to attribute mail to individual people. > Unless you have reason to believe that the signer is taking steps to ensure that the sender information is accurate. I'd say that a DKIM signature from a reputable service provider would quite likely increase the *chance* that the sender information is accurate. Of course, you can't be certain (with any technology), because any account might be compromised by phishing. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
--On 19 August 2010 11:18:06 -0700 Dave CROCKER wrote: > > dkim's primary use is the attachment of a verifiable label, to be used for > assessment. The nature of the design of the mechanism makes its ability > to be used for this purpose uncontroversial and very low risk. The risk, > now, is all market preference, rather than functional. That is, there is > no technical risk to DKIM's ability to satisfy this requirement. The > extent to which the market finds it useful for that purpose is still > being established. > And, one thing's for sure: uptake is everything. Talking DKIM down increases the risk that we'll never get widespread domain based reputation services. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
--On 19 August 2010 12:29:35 -0400 Hector Santos wrote: > bill.ox...@cox.com wrote: >> Daniel, >> DKIM signing clearly defines who takes responsibility for >> signing an email > > Responsible for what? Can I get sued when something goes wrong? If you're doing stuff that's illegal, then your DKIM signature makes it easier to prove a law suit against you. Similarly, if you're not doing anything illegal, then your signature could provide evidence of tampering by the recipient or a third party. >> ADSP is only useful if it is implemented by draconian senders >> like financial emailers who really really want all malformed >> dkim signatures to be dropped regardless of consequences > > Draconian? Maybe they don't to get sued when the new signer > ignorantly ignores policy and resigns the mail thus passing the > responsibility buck. You know the "You break, you own" pottery > principle. PAYPAL was pretty smart to put a official RFC sanctioned > technological disclaimer out there. Yes, I wouldn't call an ADSP user draconian. Defensive (in a neutral sense), perhaps. >> There is NO filtering usefulness using DKIM as it is >> not reputation based. It does give one the ability to slow >> down spoofing. If the signature matches then indeed the sending >> ISP did in fact send it > > But what if it didn't match? Do you continue sending potentially > spoofed mail? Actually, there is filtering usefulness in DKIM, because it can be used in conjunction with a reputation database. > >> Now why would anyone make time to evangelize against a >> protocol at a conference is beyond me unless it was SPF :-) > > Maybe because for so long everyone heard about how great DKIM is, with > years of no real proof or payoff shown, and now the conference > sponsors decided to add an opposing viewpoint or a viewpoint that > might suggest where there might be a payoff with DKIM. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
Daniel, et al, Persistent misunderstanding of DKIM is a significant problem, and worthy of efforts to make corrections. To that end: On 8/18/2010 6:59 PM, Daniel Black wrote: > > I've got a presentation slot for DKIM at APNIC next week to a bunch of ISPs. > > My current plan for a talk is: > * DKIM is a really well developed standard for signing email As noted, "signing email" is not DKIM's goal. Attaching a verifiable label that can be used for assessment is DKIM's goal. The difference is not merely significant; it is fundamental. > * Combined with ADSP=discardable it can filter email at ISP gateways without > too much fear of unduely lost email The utility of ADSP is not yet established and is clearly controversial. That's another way of saying that it's utility is risky. > * BUT otherwise its useless in its current state. 1. It can be used in exactly the same way an IP Address is used, for establishing statistical reputation. Except that it can't be spoofed and it's better suited to this task than is a topology-dependent label. More stable. Not shared. Etc. 2. It permits attachment of multiple labels, by different actors. You can't really do that in an unspoofable way with IP Addresses. The benefit is a richer basis for reputation assessment. 3. It permits stream differentiation; you can't do that conveniently with IP Addresses. 4. It enables verifiable accountability, such as is already used for feedback loop registration. > Costs: > * Product deployment and DKIM training and documentation for staff > * Trying to work out why some outbound streams of email get lost (when there > is no IETF guidance for the receiver) Researching "lost email streams" (whatever that actually means) is an existing, generic cost that has nothing specific to do with DKIM. > * Fixing/changing mailstreams by destination (draft-ietf-dkim-mailinglists-02 > 4.1) This is not a DKIM problem. It's an ADSP problem. As noted, it's important not to confuse the two. > Benefits: > * A recipient may through good design manage to pass good signatures and drop > bad signatues while allowing mailing list mail through. This is not a DKIM problem. Broken signatures are supposed to be treated as no signature. > Given likelyhood of benefits are signficantly lower that costs I'm not seeing > a benefit for a signer. The benefits are significantly higher when the costs and benefits are more accurately defined and assessed. > Cost/benefit to verifier: > Costs: > * software deployment training and documentation > * increases concurrancy of email processing waiting for DKIM keys OR post > processing where rejection could result in backscatter. This one is confusing, but sounds silly. There's no indication that DKIM processing slows mail down, and there's quite a lot of experience processing DKIM mail. There has also been some direct research on DKIM overhead and it was deemed negligible. If DKIM processing had a significant performance effect, we'd have heard about it by now. But we haven't. > * implement some filtering scheme based on RFC5863 "based on"? That sounds as if the document specifies filtering schemes. It doesn't. It discusses them. The difference is fundamental in terms of type, granularity and intended utility of the topic. > Benefits: > * rejecting ADSP=discardable messages with missing or broken signatures Whether that is actually a benefit is not yet established, particularly since we already have demonstration of false positives due to signer errors. > * Adding AR headers (that a user or their MUA may never work out how to use > effectively) There is no particular intent and certainly no guidance about using Authentication-Results for end-user consumption. There is even less basis for asserting that it will provide end-user benefit. > Again, the likelyhood of benefits are signficantly is lower than costs. > > So DKIM is at a state where there is no offering of filtering advice beyond > the theoretical discussion in RFC5863. The current mailing list approach: > > MLM behaviors are well-established and standards compliant. Thus, > the best approach is to provide these best practices to all parties > involved, imposing the minimum requirements possible to MLMs > themselves. > > is rather defeatist and limits the encouragement for DKIM-Friendly lists. First, you seem to be placing quite a lot of emphasis on mailing list issues. While that's a topic worthy of pursuit -- which is why the working group is doing it -- it has not been demonstrated to be a fundamental aspect of DKIM success and there is pretty good indication that it isn't. Of all DKIM-signed mail, a relatively small percentage goes through mailing lists. > So for DKIM, filtering is painful as it requires end user specific knowledge > of what lists they subscribed to. No it doesn't. This is simply inaccurate and appears to be predicated on a logic sequence tha
Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis
I went through it. It's a very thorough piece of work. So far I only have two comments. Section 3.5, near the bottom of page 23: Local- part MAY be drawn from a namespace that does not contain the user's mailbox I'd suggest changing that to Local- part MAY be drawn from a namespace unrelated to any mailbox. The document never says who "the user" is, and I see no advantage to language that implies that there is one. Section 7: Should this section reiterate all of the stuff in 4871, or since the IANA registry already exists, just say what if anything is different since 4871? I don't know which is better. http://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
> > Right, but emphasize that the granularity is a signing domain -- it is > > not and cannot be a way to attribute mail to individual people. > > > > Unless you have reason to believe that the signer is taking steps to ensure > that the sender information is accurate. I'd say that a DKIM signature from > a reputable service provider would quite likely increase the *chance* that > the sender information is accurate. Of course, you can't be certain (with > any technology), because any account might be compromised by phishing. Why isn't a signed 822.From sufficiently accurate sender information from a provider who cares? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
No matter which way you wish to preach this David, and ignore all comments, the protocol inconsistency issues in the WG documents are clearly present and make it very difficult to employ DKIM with any of the WG proposed methods. Any current DKIM-CORE deployment cited is not used by itself but rather augmented with proprietary methods, special host to host arrangements and non-standard solutions. Resolving the inconsistency with the working WG documents would be much welcome. Ignoring it, just continue a status quo of lack of wide understanding and usefulness for DKIM from SMALL to LARGE MTAs. -- 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] marketing dkim
>Why isn't a signed 822.From sufficiently accurate sender information >from a provider who cares? The "who cares" bit is a reputation system, you know. I also suspect that my signing model is fairly typical of small providers. I sign everything, and make no effort to validate stuff on the From: line. In the unlikely event that one user engages in hostile spoofing of another, there's enough stuff in the Received: headers and logs to figure it out. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
On 8/20/2010 11:18 AM, John Levine wrote: >> Why isn't a signed 822.From sufficiently accurate sender information >>from a provider who cares? > ... > I sign everything, and make no effort to validate stuff on > the From: line. They key point is that DKIM makes no statement about the basis by which a given signature is made or not made, AND different signers do indeed have very different criteria. No doubt some do validate the From: field. Others merely mean "the message went through my MTA". Any assertion of From: field assessment is therefore far outside the scope of the DKIM base specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
John Levine wrote: >> Why isn't a signed 822.From sufficiently accurate sender information >>from a provider who cares? > > The "who cares" bit is a reputation system, you know. > > I also suspect that my signing model is fairly typical of small > providers. I sign everything, and make no effort to validate stuff on > the From: line. In the unlikely event that one user engages in > hostile spoofing of another, there's enough stuff in the Received: > headers and logs to figure it out. I don't see how because that would represent the anonymous unknown world. However, what is shown is your 5322.From domain if you simply exposed a DKIM=ALL (or DISCARDABLE if it applies) policy for your IECC.COM domain or any other you are hosting, then all ADSP RECEIVERS would be able to protect your DOMAIN reputation from abuse. You won't be responsible for any harm done and further more, the resigner would not assume any erroneous responsibility. All the eyes dotted, tees crossed - common sense protocol consistency within WG documents. You can't development a consistent protocol with unknown methods and solutions only privy to MTAs outside this group. -- 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] marketing dkim
Dave CROCKER wrote: > > No doubt some do validate the From: field. Others merely mean "the > message went through my MTA". Any assertion of From: field assessment > is therefore far outside the scope of the DKIM base specification. This is hard to grasp and conflicts with the DKIM base specification which makes the 5322.FROM a fundamentally required binding hashed entity in the DKIM signature manufacturing. In additional, the 5322.From header is a historic persistent entity from handler to handler. i.e. it can not change for any single and/or collective set of signature. Inherently, there are assessment assertions to be made within DKIM 5322.From binding requirement - ergo the protocol inconsistency with between WG documents. -- 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
[ietf-dkim] Reputation Filtering
Ian Eiloart wrote: >>> There is NO filtering usefulness using DKIM as it is >>> not reputation based. It does give one the ability to slow >>> down spoofing. If the signature matches then indeed the sending >>> ISP did in fact send it >> >> But what if it didn't match? Do you continue sending potentially >> spoofed mail? > > Actually, there is filtering usefulness in DKIM, because it can be used > in conjunction with a reputation database. Do you mean in lieu of Reputation Information? Because the question above is when it doesn't match. I just have a problem received two messages: MSG #1: From: some...@domain.com DKIM-SIGNATURE: . MSG #2: From: some...@domain.com (NO DKIM-SIGNATURE) And MSG #1 is whitelisted with confidence and MSG#2 is passed anyway, even if its has been assigned initial dirty score with it, passed to users to make a decision themselves. That is a very risky think to pass on to MUAs, especially OFFLINE MUAS where you have no real control of what they in mail presentation. Whatever this "REPUTATION" IDEA is, it still needs some "bit" that it expects "something" about domain.com having a signature, right? I don't see a difference with REPUTATION with regard to the same issues people complained about SPF or ADSP: known reputation - make a hard decision - GOOD CITIZEN MODEL unknown reputation - soft failure? or Neutral? or Reject? Do you see a difference? I don't other than one group wants to accept the unknown (or learn the badness of the message, if your lucky to accumulated repeated scoring) and the other group wants to do something about it. -- 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] marketing dkim
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Hector Santos > Sent: Friday, August 20, 2010 11:42 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] marketing dkim > > Dave CROCKER wrote: > > > > No doubt some do validate the From: field. Others merely mean "the > > message went through my MTA". Any assertion of From: field assessment > > is therefore far outside the scope of the DKIM base specification. > > This is hard to grasp and conflicts with the DKIM base specification > which makes the 5322.FROM a fundamentally required binding hashed > entity in the DKIM signature manufacturing. I don't know what you mean by "binding". DKIM doesn't say From: has to contain any particular value, only that it has to be one of the signed fields. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Splitting the mailing list document?
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Dave CROCKER > Sent: Tuesday, August 10, 2010 7:06 AM > To: DKIM IETF WG > Subject: [ietf-dkim] Splitting the mailing list document? > > I think I saw 3 different topics, and that there has already been > a bit of > discussion about this. The topics are: > > a. Handling DKIM messages transiting a Mailing List Manager > > b. Trust-based enhancements for Mailing List Managers based on > DKIM > > c. Best practices for Mailing List Managers > [...] > > 2. If a split is appropriate, how should the existing content be > divided? > > I vote for letting Murray handle this. (You're welcome, Murray.) > > So, the first question is intended to get some working group consensus, > before > Murray puts in the effort of dividing things up. Ah, the deafening silence... After thinking about it for a while, I believe it would be fine to fork the document as described. Given the working group's scope and charter, and in the absence of any objection, I propose the following: 1) The current document covers what you have as (a) above with no change to name, and an intended status change to BCP. 2) The parts of the current document suggesting possible enhancements become a new WG document with a similar name. The status of this document would be Informational. 3) A general BCP for lists irrespective of DKIM is probably something the email world should have. I'd be fine with this being either Informational or BCP status. I would take this up as an individual submission and probably move it through the APPS area, but I would really like to hear from some of the MLM maintainers, past and present, on this list willing to help with that work before I agree to add it to my queue. None of this will happen before the start of September in any case, but I thought I should finally reply to this. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
On Fri, Aug 20, 2010 at 11:55:40AM -0700, Murray S. Kucherawy allegedly wrote: > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > > boun...@mipassoc.org] On Behalf Of Hector Santos > > Sent: Friday, August 20, 2010 11:42 AM > > To: ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] marketing dkim > > > > Dave CROCKER wrote: > > > > > > No doubt some do validate the From: field. Others merely mean "the > > > message went through my MTA". Any assertion of From: field assessment > > > is therefore far outside the scope of the DKIM base specification. > > > > This is hard to grasp and conflicts with the DKIM base specification > > which makes the 5322.FROM a fundamentally required binding hashed > > entity in the DKIM signature manufacturing. > I don't know what you mean by "binding". DKIM doesn't say From: has > to contain any particular value, only that it has to be one of the > signed fields. I don't know about binding either, but my point, before this sub-thread is completely lost, is that the suggestion that a "caring provider" put in some user identifiable token amounts to the same thing as asking a "caring provider" to ensure that 822.From can be used as a user identifiable token. In other words, there is no need to invent anything new here to achieve the OP's result. After all, an uncaring provider means that >From is as reliable as any other user identifiable token, which is to say, not at all. So, assuming you can determine a caring provider, then ask them to be careful about 822.From rather than ask them to invent and insert some other user identifiable token. Note: I'm not necessarily advocating the OP's suggestion, just saying no new token needs to be invented to support it - instead, just make the recommendation to "caring providers". Job done. Move along. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Fwd: Oops! (was Re: [EAI] UTF-8/MIME)
On Fri, 20 Aug 2010 12:02:27 +0100, Charles Lindsey wrote: > On Thu, 19 Aug 2010 18:43:13 +0100, Shawn Steele > wrote: > >> John was asserting that EAI messages have to be MIME. ... > > Interesting point. From time to time I use telnet to send email (usually > when testing that something is working). Oops! Wrong list (thanks to John for telling me). But to bring it marginally back on topic, it arose because my MUA provides no facility to reply to list only. Just Reply amd Reply all. Another thing to add to the list of bad MUA behaviours we have noted in recent threads. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@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 http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
I thought it might be useful to chime in here. My goal is simply to show where a commercial sender/receiver might see some value, with Daniel's APNIC presentation in mind. I'm not asserting that any of this applies to a regional ISP per se, but insofar as it applies to their customers they may wish to understand it. If you want to use any of what follows outside of this mailing list, contact me before doing so. Bank of America has been using SPF and DKIM for more than a few years now. We have a rich mix of originators of message traffic using various domains and subdomains, located on both sides of traditional corporate boundaries, and targeting different internal and external recipients. We've gone to considerable effort to implement these techniques as widely as possible, and to educate and encourage other corporations to do so. We have done this because we believe that doing so will enable us to better protect our customers from fraud and abuse, with respect to our brands and relationships. Speaking about this publically may help others reach similar conclusions, which may help protect our customers from being compromised through other brands and relationships. So for us, this is a very real and practical matter. Early on, even without 100% coverage we were able to address certain issues around bad actors targeting our employees. We found that to be of great benefit, even though it wasn't why we started down this path. We see real value in DKIM for what we believe it gives us - a way for a receiver to tell whether or not a given message using one of our domains was sent by ourselves or one of our delegates. There are definitely cases where the technique breaks down, and there is also an added cost to our operations, but these factors have not changed our cost/benefit decisions. There hasn't been much press coverage lately about high-profile bilateral DKIM+SSA adoption, such as the Yahoo and eBay/PayPal arrangement. However in the past year or so several startups have appeared that seek to act as SSA clearinghouses or brokers. This approach certainly seems more practical than a proliferation of bilateral agreements, offering some kind of uniform mechanism while avoiding real/perceived limitations of ADSP - but you've got to have a handle on DKIM to participate. Also over the past several years a lot of MTA appliance vendors have delivered DKIM functionality that can be used in making receiver filtering decisions. I would suggest that we don't know how many of their customers are using DKIM with a local policy for high-value or certain highly-phished traffic. Consider the use of mandatory TLS to protect messages in transit between specific endpoints - something we know the financial and legal communities have adopted with vigor and real savings, despite any weakness over other solutions. It seems likely to me that something similar is happening with DKIM, though getting the data to back it up would be difficult. --Steve. Steven M Jones ET&D Desktop & Electronic Communications Bank of America; Concord, California steven.m.jo...@bankofamerica.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
Mark Delany wrote: > On Fri, Aug 20, 2010 at 11:55:40AM -0700, Murray S. Kucherawy allegedly > >> I don't know what you mean by "binding". DKIM doesn't say From: has >> to contain any particular value, only that it has to be one of the >> signed fields. > > I don't know about binding either, hmm, I am surprise that I have to be put into an awkward position to explain what "binding" means here as digital signature term in what I thought was a technical qroup. Very odd. It is a well understood computer term especially when talking about hashing values and electronic signatures. Google it: binding hash signatures Here is a hit that might help: http://en.wikipedia.org/wiki/Digital_signature Digital signatures cryptographically bind an electronic identity to an electronic document ... The term bind or binding is a commonly used in hashing ideas when you want to associate parts, as in like Collections or Association Arrays. For DKIM, when you hash the h= headers, you are technically binding values, "entities", parts, to the signature. Changing any values breaks the bind. Since 5322.FROM is a required binding for DKIM, it means you can not change the 5322.FROM without breaking the signature. This naturally implies an digital signature binding assertion that can used for security purposes. I am surprise it is even questioned at this point. Very odd. -- 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] marketing dkim
> hmm, I am surprise that I have to be put into an awkward > position to explain what "binding" means here as digital signature > term in what I thought was a technical qroup. Very odd. Hector. You are too funny. You miss the subtlety and then you assume the OP is inexcusably ignorant. I just love the Schoolmarm lessons that inevitably follow. Priceless. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
Honestly, no assumption of ignorance. I did have a few variations "You're joking?... This is a joke right? ... Yeah right!" etc. But you're right, I missed any subtlety and should of left it alone. I apologize to anyone who felt offended for the Binding 101 lesson. :) -- HLS Mark Delany wrote: >> hmm, I am surprise that I have to be put into an awkward >> position to explain what "binding" means here as a digital signature >> term in what I thought was a technical group. Very odd. > > Hector. You are too funny. > > You miss the subtlety and then you assume the OP is inexcusably > ignorant. > > I just love the Schoolmarm lessons that inevitably follow. Priceless. > > > > Mark. > ___ > 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] marketing dkim
So, assuming you can determine a caring provider, then ask them to be careful about 822.From rather than ask them to invent and insert some other user identifiable token. It's fairly difficult to validate From lines when you have users with catchall domains, since they can use any address in their domain. On a system like Yahoo, it makes perfect sense to lock down what the users can do, since your users are all strangers and when someone wants to do something unusual, you have to assume it's malicious until proven otherwise. On small systems like mine or my ISP, the management has a reasonably good idea who the users are, they rarely misbehave, and they have all sorts of funky setups with domains, web servers, scripts, or whatever, and there aren't throwaway accounts. I have no idea what addresses my users are allowed to use, but I add enough stuff to audit the mail in case of questions rather than trying to pre-validate anything that might appear on the From line. R's, John smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Mailing lists and signatures
We've had a lot of arguments about the importance of verifying the identity of contributors to mailing lists. If you think that's important, take a look at this message. Even though Mailman has added a subject line tag and a message footer, the S/MIME signature still verifies, and your MUA should show a green star or whatever, at least once you've told it to import my S/MIME cert. Mailman automagically wrapped the multipart/signed in multipart/mixed. And the signing cert has both my full e-mail address and my True Name. So I suggest we update the DKIM MLM draft to take out all the stuff about signatures surviving lists, and just say that if it's important for your signature to survive, S/MIME already does that, with a suitable pointer. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [summary] marketing dkim
Thanks for all the comments. I probably don't have quite enough time to respond to them individually. I'm responding to say thanks for the bits of value that I can actually use to promote dkim and to comply with Stephen Farrell's request to move on. Thanks for the warnings against ADSP=discardable. I'll take this into account. I'll incorportate comments about forensic verification. Thanks to those that responded on and offlist to say that DKIM isn't totally a reputation company's bait for getting hooked on their services, or useless, and does have a use outside of it. Your examples are valuable and thanks. Appoligies for my small wimper of dispair about where dkim was going. Lets move on. There's drafts to review. Daniel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
