Date: 2005-07-27 23:12
From: John Levine <asrg(_at_)johnlevine(_dot_)com>
The root of the problem is various types of modifications made by
SMTP and other transport, and is a well-known problem ...
The issue isn't so much MTAs as network and gateway issues. ...
Yes, we all know that. My goal is to collect some real life data on
what the modifications likely to happen to messages in transit
actually are, to see if there are canonicalizations that will help a
message to survive the transit MTAs that people really use.
You are likely to miss quite a bit, depending on your test messages and
the particular sites and MTAs involved. Some examples:
o sendmail is known to rewrap message header fields at 990 octets.
Obviously, if your test messages have no lines that long, you won't
see any change. N.B. legal line length is <= 998 octets (the sendmail
issue has been reported). To see the effects of this issue, your test
messages will need at least one line with length between 991 and 998
o some ISP home-grown MTAs wrap at lower lengths; there is a recent set
of messages in the comp.mail.mime and comp.mail.sendmail newsgroups
about that. Unless you send through such a site, using a test message
with fairly long lines, you won't see that.
o some MTAs, due to network issues, downgrade 8bit message content to
7bit by applying a transfer encoding. You won't see that unless your
test message has 8bit content *and* is sent through a system that
downgrades to 7bit. [as of this time, the DKIM drafts recommend
applying a transfer encoding before DKIM processing, which might not
be practical in some mail configurations, and is likely to result in
Simply passing messages through plain vanilla MTAs in a pure SMTP
context won't reveal much about the problems that can be encountered
in the actual global mail system.
You appear to completely misunderstand the goals of systems like DKIM.
I understand quite well; the idea is similar in many ways to something
that I suggested on the ietf-822 list and here a couple of years ago.
The DKIM base draft states that verifiers may be (among others) MUAs.
Obviously any MUAs behind MS Exchange servers, Lotus Notes systems, etc.
would be affected by transformations made by such parts of the mail
in which they reside.
The point of DKIM is the sign messages in a way that will survive
SMTP message transit and be verifiable without a PKI,
Well there *is* a PKI, based on DNS for key exchange. A verifiable
signature within the context of Internet mail (no prior arrangement
between sender and recipient(s)) necessarily requires some sort of PKI.
not to be a
bullet-proof signature for the ages. Please see the DKIM drafts if
you want to contribute here.
I've seen the drafts (such as they are); there is no mention in them nor
in the I-D announcements at this time regarding solicitation of review
comments here or anywhere else.
Asrg mailing list