On Wed, Mar 25, 2009 at 10:14 PM, Mark Martinec
<Mark(_dot_)Martinec+dkim(_at_)ijs(_dot_)si> 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