On Wed, Mar 25, 2009 at 10:14 PM, Mark Martinec <[email protected]> wrote: > > Hector Santos wrote: > > The problem is protocol consistency. The signer within the domain > > network needs to make sure it adds the missing headers. > > There is probably a general agreement that a message when submitted > to a signer should contain all mandatory header fields (From and Date) > as required by RFC 5322, along with all the SHOULD ones (Message-ID, > and some others in special cases according to section 3.6). > And it should be syntactically correct in other aspects too (line length, > allowed characters, ...), otherwise a garbage-in garbage-out principle > applies. > > It also seems prudent to supply a To, even though it is not required by > the RFC 5322, as many MTAs or MUAs expect it and/or supply it if missing.
Many systems, including ours, leave level of compliance up to the operator. Some systems, will abort the transaction (at DATA) when the headers did not to either 822, 2822/5322. Others will do the same post SMTP (accept first). Some systems behavior as drop off points for printers, faxing, text messagings, etc using simple clients where the addressing is purely at the envelope. Not the headers. Generally, these systems required authenticated clients. The submission protocol may also enforce the injection of headers. I'm old school though, I really really really hate middle ware that fool with passthru mail. <g> so if this is an original submission, that is one thing, you have more ethical engineering acceptance and authority to "adjust" the mail. With relays, other than adding the required trace headers, I always leaned on not "adjusting" the headers. It is really a taboo to do so. I believe RFC 5322 reflects this traditional practice. > > And receivers really should not be adding one - especially if it is as you > > say, DKIM compliant. > > I don't agree with the above. I think the core issue is the fact that > there is a great semantic difference between including an absent > header field name into the 'h' tag, and including an existing one. > The fact that DKIM uses the same syntactic mechanism to express > each is just a coincidence. Well, I am quickly coming to cerment the reality that much of the philosophical and discipline conflicts depends on how one expects to use DKIM. I come from an Fault Tolerance background - AI, Expert Systems, process controllers, simulators, modeling, etc. where fault detection is very much part of the working success of a system. So if you (speaking in general) can't define how to handle DKIM faults, I find to see how one can succesfully work in the handling of DKIM whitelisting without eliminating or reducing the abuse of it. So even if one wants to use DKIM for whitelisting, you still need to protects against the faults of the WhiteListing models. > > The DKIM specification clearly says what headers SHOULD be considered > > and what SHOULD NOT. I always felt there should a default and that h= > > was optional (to reduce the bandwidth), but having h= should help > > remove any guessing. > > The invention of an 'h' tag made a tremendous improvement in survivability > of a DKIM signature over the initial DomainKeys drafts. But thats because DKEYS signed all headers. I was referrig to a default set of headers. For example, no h=, might mean the basic fundamental headers: From: To: Subject: Date: at the very least, something 100% of all mail systems have, and 99.99% of all rendering devices ergonimically show to users. [Note: I'm not proposing to make it optional] > > > - signature includes Message-ID in h tag, but there was no Message-ID in > > > the original message at the time of signing. When a receiving MX > > > inserts a missing header field, it breaks the signature. > > > > But if it was signed with one, then someone stripped it before the MX > > got it. > > Not in cases I observed. There was no Message-ID at the time of signing. > It's easy to prove - just deleting the late-added Message-ID makes a > signature valid again. Ok, I was scatching my head by what you mean by MX. Do you mean the MDA? Sure, the MX does not have to be a MDA, it can be a router. This all goes back to my first point above. It is final destination or a relay. Problems begin when relays begin to tamper with mail. But if its final destination, why would a DKIM-aware reciever add something before it attempts to validate the signature, if any? > > This is an issue for many. We are talking about the MS-DOS, UNIX vs > > MAC storage and/or display world. This is one of the reasons why we > > have not implemented yet. > > That was a lone incident of bare CR characters finding their way into > a message. It was due to a bug in a disclaimer-adding software. > > I don't think that MS/Unix/Mac differences in line endings will present > a share of failures worth mentioning. So far I have yet to find a single > case of such breakage. The DKIM rfc is clear on it, and as long as > implementers do it by the book, this is a non-issue. Well, that depends on implementations and the frameworks of backends. The variety is to great to expand on here. But I will say, this issue has raised a barrier to adoption for us. That is why the cost of implementation DKIM must have a payoff if we are to justify the design changes that are required to support it. We are not going to add DKIM for marketing reasons. We don't need it. We are not going to add it for someone elses good (a trust service) unless there is a Fault Handling involved. But that just us. I like to think others are in similar positions, but I can't change the fact that DKIM would be a very expensive implementation effort for us. > Despite my list of failures, I'm generally pleasantly surprised with > the survivability of DKIM signatures. Yes, which keeps people interested in its promise. > Despite limited present use, signing already offers genuine benefits, like > easier and more reliable whitelisting, reputation-based scoring, > non-repudiation > when filing abuse reports, etc. You see, that is what I am talking about. What about failures? <g> This is really two different schools of though. But in my view, its all really part of the same paradigm, failure and success are mirror images of the same thing. Using a chemisty methapor, there are left sided and right sided modular structure of the same modulars. One is bad for humans (not ediable), one is. We are a right-handed world. :But they have the same molecular composition. :-) > Even though the listed case of a signed Return-Path was probably due > to a mistake and not an intentional deed, I found it interesting and > intriguing to use such approach of signing envelope information. One of the reasons it is hard to work in these list issues is because a good portion of it deals with implementation issues. I think we need to focus on the general aspect that applies to all as a maximum (or possibly minimum). Spell of the standards, the BCP and work from there. -- hls _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
